Re: [Gnss-sdr-developers] Repost: Getting Acquisition and Tracking Block Status From Monitor with N
An open source software-defined GNSS receiver
Brought to you by:
carlesfernandez
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 |