Thread: [Gnss-sdr-developers] Getting Acquisition and Tracking Block Status From Monitor with No Decoding
An open source software-defined GNSS receiver
Brought to you by:
carlesfernandez
From: John B <jl...@ho...> - 2020-08-14 18:00:14
|
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 |
From: John B <jl...@ho...> - 2020-08-24 16:01:07
|
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 |
From: Don K. <don...@ma...> - 2020-08-24 16:17:49
|
John, I’m very interested in having that capability as well. I was wondering if the GUI that Alvaro wrote, GNSS-SDR-Monitor, might be able to do that with some mods. Have you tried installing GNSS-SDR-Monitor? It shows PRN status/results (somewhat) as it starts to acquire and track, so I was thinking that might be great place to see how to establish some sort of acq and track status capability. Don Don Kelly Agile Engineering LinkedIn: www.linkedin.com/in/kellydak Cell: 281-221-2853 4403 Orange Leaf Court Houston, TX 77059 On Aug 24, 2020, at 11:00 AM, John B <jl...@ho...> wrote: 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... <mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers <https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers> |
From: John B <jl...@ho...> - 2020-08-24 16:23:12
|
Don, Thanks for the tip. No, I have not run the GUI yet. It sounds like the answer is in there. Best Regards, John ________________________________ From: Don Kelly <don...@ma...> Sent: Monday, August 24, 2020 12:17 PM To: John B <jl...@ho...> Cc: gns...@li... <gns...@li...> Subject: Re: [Gnss-sdr-developers] Repost: Getting Acquisition and Tracking Block Status From Monitor with No Decoding John, I’m very interested in having that capability as well. I was wondering if the GUI that Alvaro wrote, GNSS-SDR-Monitor, might be able to do that with some mods. Have you tried installing GNSS-SDR-Monitor? It shows PRN status/results (somewhat) as it starts to acquire and track, so I was thinking that might be great place to see how to establish some sort of acq and track status capability. Don Don Kelly Agile Engineering LinkedIn: www.linkedin.com/in/kellydak<http://www.linkedin.com/in/kellydak> Cell: 281-221-2853 4403 Orange Leaf Court Houston, TX 77059 On Aug 24, 2020, at 11:00 AM, John B <jl...@ho...<mailto:jl...@ho...>> wrote: 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...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers |
From: Don K. <don...@ma...> - 2020-08-24 16:26:23
|
The challenge with the GUI is that it doesn’t really provide status explicitly, but things start popping up as acq and track get underway. So my guess is that a more formal/informative acq and track status could be developed if we look at some of Alvaro’s GNSS-SDR-Monitor code perhaps. Don Don Kelly Agile Engineering LinkedIn: www.linkedin.com/in/kellydak Cell: 281-221-2853 4403 Orange Leaf Court Houston, TX 77059 On Aug 24, 2020, at 11:22 AM, John B <jl...@ho...> wrote: Don, Thanks for the tip. No, I have not run the GUI yet. It sounds like the answer is in there. Best Regards, John From: Don Kelly <don...@ma... <mailto:don...@ma...>> Sent: Monday, August 24, 2020 12:17 PM To: John B <jl...@ho... <mailto:jl...@ho...>> Cc: gns...@li... <mailto:gns...@li...> <gns...@li... <mailto:gns...@li...>> Subject: Re: [Gnss-sdr-developers] Repost: Getting Acquisition and Tracking Block Status From Monitor with No Decoding John, I’m very interested in having that capability as well. I was wondering if the GUI that Alvaro wrote, GNSS-SDR-Monitor, might be able to do that with some mods. Have you tried installing GNSS-SDR-Monitor? It shows PRN status/results (somewhat) as it starts to acquire and track, so I was thinking that might be great place to see how to establish some sort of acq and track status capability. Don Don Kelly Agile Engineering LinkedIn: www.linkedin.com/in/kellydak <http://www.linkedin.com/in/kellydak> Cell: 281-221-2853 4403 Orange Leaf Court Houston, TX 77059 On Aug 24, 2020, at 11:00 AM, John B <jl...@ho... <mailto:jl...@ho...>> wrote: 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... <mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers <https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers> |
From: Álvaro C. J. <ace...@gm...> - 2020-11-09 19:23:12
|
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 > > |
From: Don K. <don...@ma...> - 2020-11-09 19:37:08
|
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... <mailto: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... <mailto: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 <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... <mailto: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... <mailto:ace...@gm...>> Sent: Friday, August 28, 2020 8:11 AM To: John B <jl...@ho... <mailto: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/ <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 <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... <mailto: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... <mailto:ace...@gm...>> Sent: Thursday, August 27, 2020 1:12 PM To: John B <jl...@ho... <mailto: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/ <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... <mailto: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... <mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers <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 |
From: Álvaro C. J. <ace...@gm...> - 2020-11-12 07:02:07
|
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 > > |