Re: [Gnss-sdr-developers] Repost: Getting Acquisition and Tracking Block Status From Monitor with No Decoding

[Álvaro C. J. <ace...@gm...>]

Don,

The new Acquisition and Tracking monitoring ports that were added in PR #437
<https://github.com/gnss-sdr/gnss-sdr/pull/437> follow the same mechanism
as the original Monitor <https://gnss-sdr.org/docs/sp-blocks/monitor/>
block, in fact, they are all using instances of the gnss_synchro_monitor
<https://github.com/gnss-sdr/gnss-sdr/blob/next/src/core/monitor/gnss_synchro_monitor.h>
GNU Radio block for streaming Gnss_Synchro
<https://github.com/gnss-sdr/gnss-sdr/blob/next/src/core/system_parameters/gnss_synchro.h>
objects to the outside world through the same serialization protocol. The
key difference between each of these dedicated streams is the amount of
information that their respective Gnss_Synchro objects contain and the
spawning time of each UDP stream. Roughly speaking this is how things
unfold when you activate all four monitoring ports:

   - Acquisition UDP stream will spawn first once one or more channels
   achieve positive acquisition; Gnss_Synchro objects will only contain
   basic Channel info and Acquisition data.
   - Tracking UDP stream will spawn later once one or more channels have
   achieved a satellite lock; Gnss_Synchro objects will contain the same
   info as Acquisition + new data from Tracking.
   - Observables UDP stream (i.e. the original Monitor block) will spawn
   later once it has been possible to obtain pseudoranges from one or more
   channels; Gnss_Synchro objects will contain the same info as Acquisition
   and Tracking + new data from Telemetry Decoder and Observables.
   - PVT UDP stream
   <https://gnss-sdr.org/docs/sp-blocks/pvt/#custom-streaming> will spawn
   last once a position fix is obtained; Monitor_Pvt
   <https://github.com/gnss-sdr/gnss-sdr/blob/next/src/algorithms/PVT/libs/monitor_pvt.h>
   objects will be streamed containing the user coordinates among other data.


(An easy way to visualize the gradual spawning of the different monitoring
ports is by watching the UDP port activity of your system with the command $
watch -n 1 'netstat -nup' while you are running GNSS-SDR side by side.)

So, as you can see for the Acquisition, Tracking and Observables streams,
the more upstream you are in the processing chain, the more aggregated data
your Gnss_Synchro objects will contain, but also the more time you will
have to wait to get said data and the less channels you will likely see.
This is the main shortcoming of the original Monitor block, it can take
close to a minute until it starts streaming data and you will only get data
from channels that have reached the Observables stage, so it's only telling
part of the story. You might have other channels stuck in acquisition which
you won't know about by using the Monitor block on its own. This was the
point that John Burkhardt was raising at the beginning of this thread. The
new monitoring ports add the missing pieces, so now you can get the full
picture of the receiver.

I might be missing some details here and there but that's the general idea.

Regarding the GNSS-SDR-Monitor
<https://github.com/acebrianjuan/gnss-sdr-monitor> GUI, currently it can
only handle the Observables and PVT streams, therefore, an upgrade will be
required to take advantage of the new monitoring ports.

I hope you find this information helpful.
Regards,

Álvaro


El lun., 9 nov. 2020 a las 20:36, Don Kelly (<don...@ma...>) escribió:

> Alvaro,
>
> Thanks, this looks great. I see how to set up the conf file with the two
> additional ports. How does one setup and open the new monitors? Are they
> stand-alone programs we compile like GNSS-SDR-Monitor?
>
> Thanks!
>
> Don
>
> Don Kelly
>
> Agile Engineering
>
> LinkedIn: www.linkedin.com/in/kellydak
> Cell:  281-221-2853
> 4403 Orange Leaf Court
> Houston, TX   77059
>
> On Nov 9, 2020, at 1:22 PM, Álvaro Cebrián Juan <ace...@gm...>
> wrote:
>
> Forwarding chain of messages which went off-list by accident back to the
> list.
> See thread below.
>
> Sorry for the inconvenience.
>
> Álvaro
>
> ---------- Forwarded message ---------
> De: Álvaro Cebrián Juan <ace...@gm...>
> Date: lun., 9 nov. 2020 a las 20:04
> Subject: Re: [Gnss-sdr-developers] Repost: Getting Acquisition and
> Tracking Block Status From Monitor with No Decoding
> To: John B <jl...@ho...>
>
>
> Hi John,
>
> About a month ago we got a very cool pull request which added the
> monitoring capabilities to the acquisition and tracking blocks that you
> were asking about.
>
>    - https://github.com/gnss-sdr/gnss-sdr/pull/437
>
> I thought I would let you know just in case you missed it.
>
> Regards,
> Álvaro
>
>
> El vie., 28 ago. 2020 a las 20:09, John B (<jl...@ho...>)
> escribió:
>
>> Thank you again for the excellent response Álvaro. I will submit that
>> feature request.
>>
>> Respectfully,
>> John
>>
>> ------------------------------
>> *From:* Álvaro Cebrián Juan <ace...@gm...>
>> *Sent:* Friday, August 28, 2020 8:11 AM
>> *To:* John B <jl...@ho...>
>> *Subject:* Re: [Gnss-sdr-developers] Repost: Getting Acquisition and
>> Tracking Block Status From Monitor with No Decoding
>>
>> John,
>>
>> Thank you so much for the reply. Just validating what I suspected is very
>> valuable in our efforts. And what a great job your team has done in
>> documenting and publishing your designs!
>>
>>
>> Thank you for your comments.
>> Most of the great documentation available at https://gnss-sdr.org/ has
>> been written by Dr. Carles Fernández, so credit should really go to him.
>>
>> Has your team considered a design where each GNU Radio block:
>> acquisition, tracking and decoding has a GNU Radio message port to push
>> their respective status variables to the observables block based on either
>> a change in their variable values or a configurable timer? If this is
>> feasible, would it be worth submitting as a feature request?
>>
>>
>> Yes.
>> I recall discussing this exact idea with Dr. Carles Fernández, Dr.
>> Javier Arribas and Dr. Jordi Vilà a couple of years ago while I was
>> developing the gnss-sdr-monitor
>> <https://github.com/acebrianjuan/gnss-sdr-monitor> GUI during Google
>> Summer of Code 2018
>> <https://summerofcode.withgoogle.com/archive/2018/projects/6562581313486848/>
>> .
>> In fact, being able to monitor acquisition, tracking and decoding was a
>> feature included in the project ideas list
>> <https://gnss-sdr.org/google-summer-code-2018-ideas-list/#design-and-implementation-of-a-graphical-user-interface-gui-to-show-the-gnss-sdr-status-in-real-time>.
>> So, as you can see, this is something that has been officially considered
>> by the team.
>>
>> In the end, the workload of developing the GUI and the Monitor block
>> itself was so involved, that I had to leave the acquisition, tracking and
>> decoding monitoring feature as a future direction in my To Do list (see my
>> GSoC 2018 Final Evaluation
>> <https://drive.google.com/file/d/1oumzKzhrW4b0tQu1d7BpkllZw0d-E3wQ/view>
>> document).
>>
>> Nevertheless, I do believe implementing such a feature is feasible, even
>> though it poses a few challenges which would have to be thoroughly
>> discussed.
>> I think it would be great if you submit a feature request so that this
>> can be revisited in the near future and/or be considered for the next
>> Google Summer of Code edition.
>>
>> Lastly, regarding the Telecommand via TCP/IP feature I mentioned in my
>> previous email, I have tested the "status" command via a telnet session and
>> it currently does not print the plain text table that is shown in the
>> documentation. It seems that this feature is still under development, as
>> you can see in the code (https://github.com/gnss-sdr/gnss-sdr/blob/next/
>> src/core/receiver/tcp_cmd_interface.cc#L126-L137).
>>
>> Thank you for your interest.
>>
>> Regards.
>> Álvaro
>>
>>
>> El jue., 27 ago. 2020 a las 19:30, John B (<jl...@ho...>)
>> escribió:
>>
>> Alvaro,
>>
>> Thank you so much for the reply. Just validating what I suspected is very
>> valuable in our efforts. And what a great job your team has done in
>> documenting and publishing your designs!
>>
>> Has your team considered a design where each GNU Radio block:
>> acquisition, tracking and decoding has a GNU Radio message port to push
>> their respective status variables to the observables block based on either
>> a change in their variable values or a configurable timer? If this is
>> feasible, would it be worth submitting as a feature request?
>>
>> Thanks again!
>>
>> John
>>
>> ------------------------------
>> *From:* Álvaro Cebrián Juan <ace...@gm...>
>> *Sent:* Thursday, August 27, 2020 1:12 PM
>> *To:* John B <jl...@ho...>
>> *Subject:* Re: [Gnss-sdr-developers] Repost: Getting Acquisition and
>> Tracking Block Status From Monitor with No Decoding
>>
>> Hi John,
>>
>> I've been experimenting with your tutorial using the GNSS monitor tool.
>> Can you validate for me the following: if a channel doesn't achieve success
>> on the full processing chain - acquisition, tracking and decoding, then the
>> GnssSynchro objects are not pushed to the gnss_synchro_monitor block and
>> therefore, we will not see any data on the UDP socket?
>>
>>
>> That's correct. And this is somehow its main limitation.
>>
>> The Monitor <https://gnss-sdr.org/docs/sp-blocks/monitor/> block can be
>> thought of a "hacked" copy of the PVT block that simply streams the Gnss_
>> Synchro objects that it gets from the Observables block. Notice how the
>> Monitor and PVT blocks are both connected to the same Observables block in
>> the signal processing blocks diagram (https://gnss-sdr.org/docs/sp
>> -blocks/). This implies that achieving success in the full processing
>> chain (acquisition, tracking and decoding) is a precondition that must be
>> met for a given Channel to deliver data to the blocks further downstream in
>> the receiver chain until reaching the Monitor block.
>>
>> If this is the case, is there a way to obtain status on the acquisition
>> and tracking blocks using a monitor client even when full processing is not
>> achieved?
>>
>>
>> The only thing that comes to mind is the Telecommand via TCP/IP feature.
>> From the documentation
>> <https://gnss-sdr.org/docs/sp-blocks/global-parameters/#telecommand-via-tcpip>,
>> it seems that the "status" command can provide a plain text table with
>> information of all the channels.
>> While I cannot confirm if this feature actually works, it might be enough
>> for your needs.
>>
>> Regards.
>> Álvaro
>>
>>
>> El lun., 24 ago. 2020 a las 18:02, John B (<jl...@ho...>)
>> escribió:
>>
>> GNSS SDR Developers,
>>
>> I've been experimenting with your tutorial using the GNSS monitor tool.
>> Can you validate for me the following: if a channel doesn't achieve success
>> on the full processing chain - acquisition, tracking and decoding, then the
>> GnssSynchro objects are not pushed to the gnss_synchro_monitor block and
>> therefore, we will not see any data on the UDP socket?
>>
>> If this is the case, is there a way to obtain status on the acquisition
>> and tracking blocks using a monitor client even when full processing is not
>> achieved?
>>
>> Thank you,
>>
>> John Burkhardt
>> _______________________________________________
>> GNSS-SDR-developers mailing list
>> GNS...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers
>>
>> _______________________________________________
> GNSS-SDR-developers mailing list
> GNS...@li...
> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers
>
>