gnss-sdr-developers Mailing List for GNSS-SDR (Page 3)
An open source software-defined GNSS receiver
Brought to you by:
carlesfernandez
You can subscribe to this list here.
2011 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(13) |
Nov
(3) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
|
Feb
(9) |
Mar
(2) |
Apr
(3) |
May
(1) |
Jun
|
Jul
(12) |
Aug
(25) |
Sep
(6) |
Oct
(5) |
Nov
(25) |
Dec
(6) |
2013 |
Jan
(3) |
Feb
(2) |
Mar
(16) |
Apr
(57) |
May
(39) |
Jun
(8) |
Jul
(19) |
Aug
(12) |
Sep
(10) |
Oct
(15) |
Nov
(12) |
Dec
(12) |
2014 |
Jan
(6) |
Feb
(9) |
Mar
(24) |
Apr
(39) |
May
(13) |
Jun
(14) |
Jul
(4) |
Aug
(4) |
Sep
(18) |
Oct
(10) |
Nov
(17) |
Dec
(4) |
2015 |
Jan
(18) |
Feb
(3) |
Mar
(14) |
Apr
(2) |
May
(1) |
Jun
(9) |
Jul
(20) |
Aug
(1) |
Sep
(7) |
Oct
(2) |
Nov
(10) |
Dec
(23) |
2016 |
Jan
(11) |
Feb
(23) |
Mar
(16) |
Apr
(1) |
May
(5) |
Jun
(9) |
Jul
(3) |
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
(5) |
Dec
|
2017 |
Jan
(11) |
Feb
(6) |
Mar
(30) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(12) |
Aug
(6) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2018 |
Jan
(22) |
Feb
(29) |
Mar
(10) |
Apr
(14) |
May
(4) |
Jun
(9) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(5) |
Nov
(2) |
Dec
(3) |
2019 |
Jan
(1) |
Feb
(1) |
Mar
(12) |
Apr
(2) |
May
(7) |
Jun
(13) |
Jul
(17) |
Aug
(8) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
(8) |
Feb
(7) |
Mar
(5) |
Apr
(3) |
May
(4) |
Jun
(5) |
Jul
(4) |
Aug
(32) |
Sep
(7) |
Oct
(8) |
Nov
(10) |
Dec
(5) |
2021 |
Jan
(6) |
Feb
(7) |
Mar
(19) |
Apr
(6) |
May
(4) |
Jun
(3) |
Jul
(12) |
Aug
(4) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(1) |
2022 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
(8) |
May
(9) |
Jun
(5) |
Jul
(7) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
(1) |
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Mete B. <met...@gm...> - 2022-02-23 13:01:17
|
Hello, I have a USRP N210 connected to an active antenna (27dB, NF:2.6dB, ~170 deg view looking to the north), inline amplifier (27dB, NF:2dB), 20m RG58 cable (~20dB loss), 2-way active splitter. In this setup I see maximum ~35 dB-Hz C/N0 in ublox receivers, but particularly new ones are working fine (8th and 9th gen). I am having problems using N210+GNSS-SDR in the same setup, it cannot lock to any satellite (GPS L1). I also tried the Tong detector but without success yet. I am using the current latest release versions of everything (uhd, gnuradio, gnss-sdr) , all built from the sources. What can I do about this ? Is the C/No too low for N210+GNSS-SDR in this setup ? Thanks, Mete |
From: Pranjit K. <pra...@gm...> - 2022-01-12 11:21:27
|
Respected Sir/Madam I am Pranjit Kakoti, an undergrad. I am in my first year at NIT Silchar. I am new to open source contributions but I am well aware of C, C++ and python. I am open to learning new technologies.I would love to contribute to your organisation but could you please tell me how to get started? Hoping to hear from you soon. Regards Pranjit Kakoti |
From: ?? W. C. <iu...@ms...> - 2021-12-09 08:20:37
|
Hi, When I try to use smaller item type (e.g. cshort) through whole process. It can go through in Signal Conditioner. For acquisition module, it can accept gr_complex, cshort, cbyte. But for tracking module, it ONLY accept gr_complex. Which means the only allowed output item type of Signal Conditioner is gr_complex... So is there any reason tracking module can't accept cshort/cbype? Or just a TODO? Thanks, |
From: Jim M. <jim...@sn...> - 2021-10-18 20:15:19
|
All, For many years I have enjoyed access to a variety of development communities via Internet Relay Chat (IRC). Today, this type of communication has migrated to Matrix<https://matrix.to/>. I have created #gnss-sdr:gnuradio.org to encourage more real-time interactions. But this only works if you join. If you are new to Matrix, the simplest way to join the conversation is using the Element client (although others are available). Join the conversation here<https://app.element.io/#/room/%23gnss-sdr:gnuradio.org>. Once you are in a Matrix client, you may also find #gnuradio:gnuradio.org a useful room as well. I look forward to seeing you all there. --- Jim Melton CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You. |
From: <mal...@an...> - 2021-10-04 14:30:11
|
Dear Developers, Hello, We are developing a RISC-V based GPS receiver SOC. I am developing a GPS Navigation SW in Visual C++/RISC-V visualGDB, in accordance with GPS ICD document with MATLAB generated subframe words. I have successfully decoded all Subframe(SF)-1,2, and 3 words, except SF-1 IODC parameter. When I compare MATLAB decoded IODC and Software decoded IODC, there is an integer difference. I have correctly decoded the parameters before and after the IODC bits, in the same and different 30 bit words.. Does Anybody knows anything special about IODC number computation? I would be very grateful, if any helps. Thanks and best regards. Mehmet Ali Ipin -- This email has been checked for viruses by AVG. https://www.avg.com |
From: Jim M. <jim...@sn...> - 2021-09-21 00:48:30
|
I know this mailing list seems to be largely dead, but I'm hoping someone can offer some insight. We have an input source that cannot generate data at a lower rate than 8msps. Seeing that the software likes to run at 2msps, we clearly need to decimate the input. One would think, reading the Signal Conditioner documentation that all we need is a Resampler=Direct_Resampler block. However, I notice that the Matlab decimate function applies a filter. In chatting with my signal processing guru, he said that you always filter when you decimate. So the first question is, why are InputFilter and Resampler separate blocks? Now, ignoring the interpolation case for the time being, I started looking at the implementation of the FIR filter (Fir_Filter). It basically instantiates gr::filter::fft_filter_ccf (or some variant, depending in the input/output types). GNU Radio documentation<https://www.gnuradio.org/doc/doxygen/classgr_1_1filter_1_1fft__filter__ccf.html#details> identifies this as a decimating filter. However, in the GNSS-SDR implementation, the decimation factor is always 1. I would think that the ideal form of decimation would be to implement the filter with a decimation factor (a single block, rather than two). Second question: is there any value to separating the filter from the resampler, particularly in the decimation case? Does the filter not support decimation because most of the front-ends out there are low-rate and interpolation is more common than decimation? Any wisdom in this respect is appreciated. Thank. --- Jim Melton Principal Software Engineer Sierra Nevada Corporation CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You. |
From: 王璀 W. C. <iu...@ms...> - 2021-09-08 03:49:48
|
Or would it help if configure thread scheduling to SCHED_RR for gnss-sdr process? (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/tuning-scheduling-policy_monitoring-and-managing-system-status-and-performance#round-robin-priority-scheduling-with-sched_rr_tuning-scheduling-policy) From: 王璀 WANG Cui <iu...@ms...> Sent: Wednesday, September 8, 2021 11:19 AM To: gns...@li... Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Is it possible to configure all relevant GNU Radio blocks run in single thread mode (say simply round-robin)? If yes, maybe can also add one gnss-sdr single thread running mode, to avoid thread scheduling behavior. I know this is big architecture change, and performance will be lower down. However it can bring consistency for debugging. From: Jim Melton <jim...@sn...<mailto:jim...@sn...>> Sent: Wednesday, September 8, 2021 12:04 AM To: gns...@li...<mailto:gns...@li...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? GNU Radio is heavily threaded. While not a certainty, imagine each block running in its own thread. Blocks are connected by ring buffers (output of one is the input to another). The GNU Radio scheduler will call a block’s work function when there is data available. Precisely when it will call it is harder to tell. Also the host operating system is scheduling different processes to run, and potentially swapping pages in and out of active memory. All of these variables lead to non-determinism. Obviously, this non-determinism is frustrating to those of us looking for repeatable results. One might hope that there are things that can improve the determinism of GNSS-SDR, particularly with respect to recorded data, although we have observed strange behavior from run to run with a real signal as well. If anyone makes any progress, please be sure to share. --- Jim Melton From: 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> Sent: Sunday, September 5, 2021 20:38 To: gns...@li...<mailto:gns...@li...> Subject: [EXTERNAL] Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Importance: Low Hi Malte, Glad to see you are still investigating this topic. IMO, although there are many mathematical computing involved in processing, however theoretically, every computing result should be consistent since the input data are same file during different run. I still suspect the inconsistency is caused by multithreading. The collaboration of different channels (in different threads) might vary because of Thread Scheduling, which is highly depend on OS situation. If the signal file is long enough, I believe sooner or later PVT will be resolved despite of scheduling. Unfortunately I can’t validate it with given short file. WANG Cui From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Wednesday, September 1, 2021 10:52 PM To: Zelle, Hein <Hei...@nl...<mailto:Hei...@nl...>>; 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? As an afterthought: I guess as there is some statistics involved in the signal processing and parameter estimation, is is quite plausible that each run yields slightly different results (especially with many channels of which only one is in acquisition). However in the name of reproducability and testability it would be also good to have a way of achieving a deterministic outcome to a specified signal sample. I don't know how feasible that is, but i dare to propose that as a possible GSoC project ^^ (or a bachelor thesis or so). I.e., identifying all elements where imprecision is introduced and supply an optional method to fix parameters or whatever is causing it. This paper [1] could be taken as guidance (gives a few nice examples how to deal with randomness). Cheers, Malte [1] "Re-run, Repeat, Reproduce, Reuse, Replicate: Transforming Code into Scientific Contributions" https://arxiv.org/abs/1708.08205 On 01.09.21 15:48, Zelle, Hein wrote: Dear Malte Lenhart and Wang Cui Unfortunately I can only confirm from experience that gnss-sdr indeed does not create reproducable results from run to run. I would be very interested in a solution, so if you find further configuration settings that help, please let me know. Kind regards! Hein Zelle From: Malte Lenhart via GNSS-SDR-developers <gns...@li...><mailto:gns...@li...> Sent: Wednesday, 1 September 2021 13:38 To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...>; gns...@li...<mailto:gns...@li...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Think secure. This email is from an external source. Be careful when opening links and attachments! Hi Wang, sorry for the very late reply. There is one related Github issue [1], where someone confirms that indeed increasing the number of channels in acquisition would help (but it won't get it totally consistent unfortunately i expect). That is unfortunately as far as I can help with it as I don't have the time to dig deeper into the code. As this comes up more often, it might be a good idea to have a doc page or sth which provides information about it (I have the faint idea that I saw it mentioned somewhere in the docs, but I cannot remember where and a quick search returned nothing..) Best regards Malte [1] https://github.com/gnss-sdr/gnss-sdr/issues/256 On 01.08.21 17:35, 王璀 WANG Cui wrote: Hi Malte, Pleases see the attached config file. (I use .ini extension name for syntax highlight in text editor). The reason I only use 4 channels is because the signal file only contains 4 GALILEO satellites’ signal. I believe add more acquisition/track channel won’t help. :) Also I am using gnss-sdr-monitor tool, as you can see in the config file. Wish we can find the reason of inconsistency and fix it. Thanks, WANG Cui From: Malte Lenhart <mal...@ma...><mailto:mal...@ma...> Sent: Sunday, August 1, 2021 10:13 PM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, @Bemnet: he's using the first-fix signal source file, so no SDR config involved. @ Wang Cui: can you attach your entire config file? My initial thoughts are that it is less deterministic if the software has to do one acquisition at a time. So the order it tries the satellites or how long it takes might influence the overall result. And four satellites are of course the minimum number of required satellites to get a fix, it might be more fault tolerant if you let it track another one.. Depending on what you try to achieve of course.. What I always find useful for debugging is to have a look at the monitor output using one of the following: https://gnss-sdr.org/docs/tutorials/monitoring-software-receiver-internal-status/ https://github.com/acebrianjuan/gnss-sdr-monitor/ Cheers Malte On 01.08.21 05:06, 王璀 WANG Cui wrote: I am using latest Test branch, on Ubuntu 18.04. From: Bemnet Adefrcis <bem...@gm...><mailto:bem...@gm...> Sent: Sunday, August 1, 2021 04:10 AM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? What type gnss SDR version are using ? And operating systems ? Respectfully Bemnet On Thu, Jul 29, 2021, 6:34 PM 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> wrote: Hi Malte, Thanks for the reply. Actually I do set the channel and satellite fixed in my conf file as below: SignalSource.filename=/datalogger/signals/CTTC/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat … Channels_1B.count=4 … Channel0.satellite=20 Channel1.satellite=12 Channel2.satellite=11 Channel3.satellite=19 To avoid multi acquisition at same time, I also set below: Channels.in_acquisition=1 And finally to force channel keep tracking, I set below: Acquisition_1B.repeat_satellite=true However, not matter how I set, the decode results are still inconsistent, sometimes can fix position, sometime cannot. I like the gnss-sdr concept of Signal File Source for debugging, and suppose it should ENSURE same behavior for every time running, but it is not... From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Thursday, July 29, 2021 11:14 PM To: 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>>; iu...@ms...<mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, I looked a bit into this, but am no export either :-) From my understanding the issue is not the multithreading, but that the order of satellite it tries to track/acquire is not fixed. You can set the satellites to track manually and/or increase the number of channels (and possibly the number of channels in acquisition too). Increasing channels up to 16 made it more deterministic for me, but as a downside the processing time increases quite a bit. Hope this helps and maybe someone else has more ideas. Cheers Malte On 29.07.21 12:24, 王璀 WANG Cui wrote: Hi there, When I run gnss-sdr to decode same Signal File multiple times, sometimes it can fix position, sometimes it only decoded NAV messages without position fix. Is it because the multi-threading and can't reproduce the same result every time? This make it difficult to debug, especially for the codes after position fix. Is it a way (like disable multi-threading) to ensure get consistent result all the time? Thanks in advance, _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You. |
From: 王璀 W. C. <iu...@ms...> - 2021-09-08 03:34:18
|
Is it possible to configure all relevant GNU Radio blocks run in single thread mode (say simply round-robin)? If yes, maybe can also add one gnss-sdr single thread running mode, to avoid thread scheduling behavior. I know this is big architecture change, and performance will be lower down. However it can bring consistency for debugging. From: Jim Melton <jim...@sn...> Sent: Wednesday, September 8, 2021 12:04 AM To: gns...@li... Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? GNU Radio is heavily threaded. While not a certainty, imagine each block running in its own thread. Blocks are connected by ring buffers (output of one is the input to another). The GNU Radio scheduler will call a block’s work function when there is data available. Precisely when it will call it is harder to tell. Also the host operating system is scheduling different processes to run, and potentially swapping pages in and out of active memory. All of these variables lead to non-determinism. Obviously, this non-determinism is frustrating to those of us looking for repeatable results. One might hope that there are things that can improve the determinism of GNSS-SDR, particularly with respect to recorded data, although we have observed strange behavior from run to run with a real signal as well. If anyone makes any progress, please be sure to share. --- Jim Melton From: 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> Sent: Sunday, September 5, 2021 20:38 To: gns...@li...<mailto:gns...@li...> Subject: [EXTERNAL] Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Importance: Low Hi Malte, Glad to see you are still investigating this topic. IMO, although there are many mathematical computing involved in processing, however theoretically, every computing result should be consistent since the input data are same file during different run. I still suspect the inconsistency is caused by multithreading. The collaboration of different channels (in different threads) might vary because of Thread Scheduling, which is highly depend on OS situation. If the signal file is long enough, I believe sooner or later PVT will be resolved despite of scheduling. Unfortunately I can’t validate it with given short file. WANG Cui From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Wednesday, September 1, 2021 10:52 PM To: Zelle, Hein <Hei...@nl...<mailto:Hei...@nl...>>; 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? As an afterthought: I guess as there is some statistics involved in the signal processing and parameter estimation, is is quite plausible that each run yields slightly different results (especially with many channels of which only one is in acquisition). However in the name of reproducability and testability it would be also good to have a way of achieving a deterministic outcome to a specified signal sample. I don't know how feasible that is, but i dare to propose that as a possible GSoC project ^^ (or a bachelor thesis or so). I.e., identifying all elements where imprecision is introduced and supply an optional method to fix parameters or whatever is causing it. This paper [1] could be taken as guidance (gives a few nice examples how to deal with randomness). Cheers, Malte [1] "Re-run, Repeat, Reproduce, Reuse, Replicate: Transforming Code into Scientific Contributions" https://arxiv.org/abs/1708.08205 On 01.09.21 15:48, Zelle, Hein wrote: Dear Malte Lenhart and Wang Cui Unfortunately I can only confirm from experience that gnss-sdr indeed does not create reproducable results from run to run. I would be very interested in a solution, so if you find further configuration settings that help, please let me know. Kind regards! Hein Zelle From: Malte Lenhart via GNSS-SDR-developers <gns...@li...><mailto:gns...@li...> Sent: Wednesday, 1 September 2021 13:38 To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...>; gns...@li...<mailto:gns...@li...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Think secure. This email is from an external source. Be careful when opening links and attachments! Hi Wang, sorry for the very late reply. There is one related Github issue [1], where someone confirms that indeed increasing the number of channels in acquisition would help (but it won't get it totally consistent unfortunately i expect). That is unfortunately as far as I can help with it as I don't have the time to dig deeper into the code. As this comes up more often, it might be a good idea to have a doc page or sth which provides information about it (I have the faint idea that I saw it mentioned somewhere in the docs, but I cannot remember where and a quick search returned nothing..) Best regards Malte [1] https://github.com/gnss-sdr/gnss-sdr/issues/256 On 01.08.21 17:35, 王璀 WANG Cui wrote: Hi Malte, Pleases see the attached config file. (I use .ini extension name for syntax highlight in text editor). The reason I only use 4 channels is because the signal file only contains 4 GALILEO satellites’ signal. I believe add more acquisition/track channel won’t help. :) Also I am using gnss-sdr-monitor tool, as you can see in the config file. Wish we can find the reason of inconsistency and fix it. Thanks, WANG Cui From: Malte Lenhart <mal...@ma...><mailto:mal...@ma...> Sent: Sunday, August 1, 2021 10:13 PM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, @Bemnet: he's using the first-fix signal source file, so no SDR config involved. @ Wang Cui: can you attach your entire config file? My initial thoughts are that it is less deterministic if the software has to do one acquisition at a time. So the order it tries the satellites or how long it takes might influence the overall result. And four satellites are of course the minimum number of required satellites to get a fix, it might be more fault tolerant if you let it track another one.. Depending on what you try to achieve of course.. What I always find useful for debugging is to have a look at the monitor output using one of the following: https://gnss-sdr.org/docs/tutorials/monitoring-software-receiver-internal-status/ https://github.com/acebrianjuan/gnss-sdr-monitor/ Cheers Malte On 01.08.21 05:06, 王璀 WANG Cui wrote: I am using latest Test branch, on Ubuntu 18.04. From: Bemnet Adefrcis <bem...@gm...><mailto:bem...@gm...> Sent: Sunday, August 1, 2021 04:10 AM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? What type gnss SDR version are using ? And operating systems ? Respectfully Bemnet On Thu, Jul 29, 2021, 6:34 PM 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> wrote: Hi Malte, Thanks for the reply. Actually I do set the channel and satellite fixed in my conf file as below: SignalSource.filename=/datalogger/signals/CTTC/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat … Channels_1B.count=4 … Channel0.satellite=20 Channel1.satellite=12 Channel2.satellite=11 Channel3.satellite=19 To avoid multi acquisition at same time, I also set below: Channels.in_acquisition=1 And finally to force channel keep tracking, I set below: Acquisition_1B.repeat_satellite=true However, not matter how I set, the decode results are still inconsistent, sometimes can fix position, sometime cannot. I like the gnss-sdr concept of Signal File Source for debugging, and suppose it should ENSURE same behavior for every time running, but it is not... From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Thursday, July 29, 2021 11:14 PM To: 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>>; iu...@ms...<mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, I looked a bit into this, but am no export either :-) From my understanding the issue is not the multithreading, but that the order of satellite it tries to track/acquire is not fixed. You can set the satellites to track manually and/or increase the number of channels (and possibly the number of channels in acquisition too). Increasing channels up to 16 made it more deterministic for me, but as a downside the processing time increases quite a bit. Hope this helps and maybe someone else has more ideas. Cheers Malte On 29.07.21 12:24, 王璀 WANG Cui wrote: Hi there, When I run gnss-sdr to decode same Signal File multiple times, sometimes it can fix position, sometimes it only decoded NAV messages without position fix. Is it because the multi-threading and can't reproduce the same result every time? This make it difficult to debug, especially for the codes after position fix. Is it a way (like disable multi-threading) to ensure get consistent result all the time? Thanks in advance, _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You. |
From: Jim M. <jim...@sn...> - 2021-09-07 16:17:23
|
GNU Radio is heavily threaded. While not a certainty, imagine each block running in its own thread. Blocks are connected by ring buffers (output of one is the input to another). The GNU Radio scheduler will call a block’s work function when there is data available. Precisely when it will call it is harder to tell. Also the host operating system is scheduling different processes to run, and potentially swapping pages in and out of active memory. All of these variables lead to non-determinism. Obviously, this non-determinism is frustrating to those of us looking for repeatable results. One might hope that there are things that can improve the determinism of GNSS-SDR, particularly with respect to recorded data, although we have observed strange behavior from run to run with a real signal as well. If anyone makes any progress, please be sure to share. --- Jim Melton From: 王璀 WANG Cui <iu...@ms...> Sent: Sunday, September 5, 2021 20:38 To: gns...@li... Subject: [EXTERNAL] Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Importance: Low Hi Malte, Glad to see you are still investigating this topic. IMO, although there are many mathematical computing involved in processing, however theoretically, every computing result should be consistent since the input data are same file during different run. I still suspect the inconsistency is caused by multithreading. The collaboration of different channels (in different threads) might vary because of Thread Scheduling, which is highly depend on OS situation. If the signal file is long enough, I believe sooner or later PVT will be resolved despite of scheduling. Unfortunately I can’t validate it with given short file. WANG Cui From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Wednesday, September 1, 2021 10:52 PM To: Zelle, Hein <Hei...@nl...<mailto:Hei...@nl...>>; 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? As an afterthought: I guess as there is some statistics involved in the signal processing and parameter estimation, is is quite plausible that each run yields slightly different results (especially with many channels of which only one is in acquisition). However in the name of reproducability and testability it would be also good to have a way of achieving a deterministic outcome to a specified signal sample. I don't know how feasible that is, but i dare to propose that as a possible GSoC project ^^ (or a bachelor thesis or so). I.e., identifying all elements where imprecision is introduced and supply an optional method to fix parameters or whatever is causing it. This paper [1] could be taken as guidance (gives a few nice examples how to deal with randomness). Cheers, Malte [1] "Re-run, Repeat, Reproduce, Reuse, Replicate: Transforming Code into Scientific Contributions" https://arxiv.org/abs/1708.08205 On 01.09.21 15:48, Zelle, Hein wrote: Dear Malte Lenhart and Wang Cui Unfortunately I can only confirm from experience that gnss-sdr indeed does not create reproducable results from run to run. I would be very interested in a solution, so if you find further configuration settings that help, please let me know. Kind regards! Hein Zelle From: Malte Lenhart via GNSS-SDR-developers <gns...@li...><mailto:gns...@li...> Sent: Wednesday, 1 September 2021 13:38 To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...>; gns...@li...<mailto:gns...@li...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Think secure. This email is from an external source. Be careful when opening links and attachments! Hi Wang, sorry for the very late reply. There is one related Github issue [1], where someone confirms that indeed increasing the number of channels in acquisition would help (but it won't get it totally consistent unfortunately i expect). That is unfortunately as far as I can help with it as I don't have the time to dig deeper into the code. As this comes up more often, it might be a good idea to have a doc page or sth which provides information about it (I have the faint idea that I saw it mentioned somewhere in the docs, but I cannot remember where and a quick search returned nothing..) Best regards Malte [1] https://github.com/gnss-sdr/gnss-sdr/issues/256 On 01.08.21 17:35, 王璀 WANG Cui wrote: Hi Malte, Pleases see the attached config file. (I use .ini extension name for syntax highlight in text editor). The reason I only use 4 channels is because the signal file only contains 4 GALILEO satellites’ signal. I believe add more acquisition/track channel won’t help. :) Also I am using gnss-sdr-monitor tool, as you can see in the config file. Wish we can find the reason of inconsistency and fix it. Thanks, WANG Cui From: Malte Lenhart <mal...@ma...><mailto:mal...@ma...> Sent: Sunday, August 1, 2021 10:13 PM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, @Bemnet: he's using the first-fix signal source file, so no SDR config involved. @ Wang Cui: can you attach your entire config file? My initial thoughts are that it is less deterministic if the software has to do one acquisition at a time. So the order it tries the satellites or how long it takes might influence the overall result. And four satellites are of course the minimum number of required satellites to get a fix, it might be more fault tolerant if you let it track another one.. Depending on what you try to achieve of course.. What I always find useful for debugging is to have a look at the monitor output using one of the following: https://gnss-sdr.org/docs/tutorials/monitoring-software-receiver-internal-status/ https://github.com/acebrianjuan/gnss-sdr-monitor/ Cheers Malte On 01.08.21 05:06, 王璀 WANG Cui wrote: I am using latest Test branch, on Ubuntu 18.04. From: Bemnet Adefrcis <bem...@gm...><mailto:bem...@gm...> Sent: Sunday, August 1, 2021 04:10 AM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? What type gnss SDR version are using ? And operating systems ? Respectfully Bemnet On Thu, Jul 29, 2021, 6:34 PM 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> wrote: Hi Malte, Thanks for the reply. Actually I do set the channel and satellite fixed in my conf file as below: SignalSource.filename=/datalogger/signals/CTTC/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat … Channels_1B.count=4 … Channel0.satellite=20 Channel1.satellite=12 Channel2.satellite=11 Channel3.satellite=19 To avoid multi acquisition at same time, I also set below: Channels.in_acquisition=1 And finally to force channel keep tracking, I set below: Acquisition_1B.repeat_satellite=true However, not matter how I set, the decode results are still inconsistent, sometimes can fix position, sometime cannot. I like the gnss-sdr concept of Signal File Source for debugging, and suppose it should ENSURE same behavior for every time running, but it is not... From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Thursday, July 29, 2021 11:14 PM To: 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>>; iu...@ms...<mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, I looked a bit into this, but am no export either :-) From my understanding the issue is not the multithreading, but that the order of satellite it tries to track/acquire is not fixed. You can set the satellites to track manually and/or increase the number of channels (and possibly the number of channels in acquisition too). Increasing channels up to 16 made it more deterministic for me, but as a downside the processing time increases quite a bit. Hope this helps and maybe someone else has more ideas. Cheers Malte On 29.07.21 12:24, 王璀 WANG Cui wrote: Hi there, When I run gnss-sdr to decode same Signal File multiple times, sometimes it can fix position, sometimes it only decoded NAV messages without position fix. Is it because the multi-threading and can't reproduce the same result every time? This make it difficult to debug, especially for the codes after position fix. Is it a way (like disable multi-threading) to ensure get consistent result all the time? Thanks in advance, _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You. |
From: 王璀 W. C. <iu...@ms...> - 2021-09-06 02:38:04
|
Hi Malte, Glad to see you are still investigating this topic. IMO, although there are many mathematical computing involved in processing, however theoretically, every computing result should be consistent since the input data are same file during different run. I still suspect the inconsistency is caused by multithreading. The collaboration of different channels (in different threads) might vary because of Thread Scheduling, which is highly depend on OS situation. If the signal file is long enough, I believe sooner or later PVT will be resolved despite of scheduling. Unfortunately I can’t validate it with given short file. WANG Cui From: Malte Lenhart <mal...@ma...> Sent: Wednesday, September 1, 2021 10:52 PM To: Zelle, Hein <Hei...@nl...>; 王璀 WANG Cui <iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? As an afterthought: I guess as there is some statistics involved in the signal processing and parameter estimation, is is quite plausible that each run yields slightly different results (especially with many channels of which only one is in acquisition). However in the name of reproducability and testability it would be also good to have a way of achieving a deterministic outcome to a specified signal sample. I don't know how feasible that is, but i dare to propose that as a possible GSoC project ^^ (or a bachelor thesis or so). I.e., identifying all elements where imprecision is introduced and supply an optional method to fix parameters or whatever is causing it. This paper [1] could be taken as guidance (gives a few nice examples how to deal with randomness). Cheers, Malte [1] "Re-run, Repeat, Reproduce, Reuse, Replicate: Transforming Code into Scientific Contributions" https://arxiv.org/abs/1708.08205 On 01.09.21 15:48, Zelle, Hein wrote: Dear Malte Lenhart and Wang Cui Unfortunately I can only confirm from experience that gnss-sdr indeed does not create reproducable results from run to run. I would be very interested in a solution, so if you find further configuration settings that help, please let me know. Kind regards! Hein Zelle From: Malte Lenhart via GNSS-SDR-developers <gns...@li...><mailto:gns...@li...> Sent: Wednesday, 1 September 2021 13:38 To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...>; gns...@li...<mailto:gns...@li...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Think secure. This email is from an external source. Be careful when opening links and attachments! Hi Wang, sorry for the very late reply. There is one related Github issue [1], where someone confirms that indeed increasing the number of channels in acquisition would help (but it won't get it totally consistent unfortunately i expect). That is unfortunately as far as I can help with it as I don't have the time to dig deeper into the code. As this comes up more often, it might be a good idea to have a doc page or sth which provides information about it (I have the faint idea that I saw it mentioned somewhere in the docs, but I cannot remember where and a quick search returned nothing..) Best regards Malte [1] https://github.com/gnss-sdr/gnss-sdr/issues/256 On 01.08.21 17:35, 王璀 WANG Cui wrote: Hi Malte, Pleases see the attached config file. (I use .ini extension name for syntax highlight in text editor). The reason I only use 4 channels is because the signal file only contains 4 GALILEO satellites’ signal. I believe add more acquisition/track channel won’t help. :) Also I am using gnss-sdr-monitor tool, as you can see in the config file. Wish we can find the reason of inconsistency and fix it. Thanks, WANG Cui From: Malte Lenhart <mal...@ma...><mailto:mal...@ma...> Sent: Sunday, August 1, 2021 10:13 PM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, @Bemnet: he's using the first-fix signal source file, so no SDR config involved. @ Wang Cui: can you attach your entire config file? My initial thoughts are that it is less deterministic if the software has to do one acquisition at a time. So the order it tries the satellites or how long it takes might influence the overall result. And four satellites are of course the minimum number of required satellites to get a fix, it might be more fault tolerant if you let it track another one.. Depending on what you try to achieve of course.. What I always find useful for debugging is to have a look at the monitor output using one of the following: https://gnss-sdr.org/docs/tutorials/monitoring-software-receiver-internal-status/ https://github.com/acebrianjuan/gnss-sdr-monitor/ Cheers Malte On 01.08.21 05:06, 王璀 WANG Cui wrote: I am using latest Test branch, on Ubuntu 18.04. From: Bemnet Adefrcis <bem...@gm...><mailto:bem...@gm...> Sent: Sunday, August 1, 2021 04:10 AM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? What type gnss SDR version are using ? And operating systems ? Respectfully Bemnet On Thu, Jul 29, 2021, 6:34 PM 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> wrote: Hi Malte, Thanks for the reply. Actually I do set the channel and satellite fixed in my conf file as below: SignalSource.filename=/datalogger/signals/CTTC/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat … Channels_1B.count=4 … Channel0.satellite=20 Channel1.satellite=12 Channel2.satellite=11 Channel3.satellite=19 To avoid multi acquisition at same time, I also set below: Channels.in_acquisition=1 And finally to force channel keep tracking, I set below: Acquisition_1B.repeat_satellite=true However, not matter how I set, the decode results are still inconsistent, sometimes can fix position, sometime cannot. I like the gnss-sdr concept of Signal File Source for debugging, and suppose it should ENSURE same behavior for every time running, but it is not... From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Thursday, July 29, 2021 11:14 PM To: 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>>; iu...@ms...<mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, I looked a bit into this, but am no export either :-) From my understanding the issue is not the multithreading, but that the order of satellite it tries to track/acquire is not fixed. You can set the satellites to track manually and/or increase the number of channels (and possibly the number of channels in acquisition too). Increasing channels up to 16 made it more deterministic for me, but as a downside the processing time increases quite a bit. Hope this helps and maybe someone else has more ideas. Cheers Malte On 29.07.21 12:24, 王璀 WANG Cui wrote: Hi there, When I run gnss-sdr to decode same Signal File multiple times, sometimes it can fix position, sometimes it only decoded NAV messages without position fix. Is it because the multi-threading and can't reproduce the same result every time? This make it difficult to debug, especially for the codes after position fix. Is it a way (like disable multi-threading) to ensure get consistent result all the time? Thanks in advance, _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers |
From: Malte L. <mal...@ma...> - 2021-09-01 11:38:11
|
Hi Wang, sorry for the very late reply. There is one related Github issue [1], where someone confirms that indeed increasing the number of channels in acquisition would help (but it won't get it totally consistent unfortunately i expect). That is unfortunately as far as I can help with it as I don't have the time to dig deeper into the code. As this comes up more often, it might be a good idea to have a doc page or sth which provides information about it (I have the faint idea that I saw it mentioned somewhere in the docs, but I cannot remember where and a quick search returned nothing..) Best regards Malte [1] https://github.com/gnss-sdr/gnss-sdr/issues/256 On 01.08.21 17:35, 王璀 WANG Cui wrote: > > Hi Malte, > > Pleases see the attached config file. (I use .ini extension name for > syntax highlight in text editor). > > The reason I only use 4 channels is because the signal file only > contains 4 GALILEO satellites’ signal. I believe add more > acquisition/track channel won’t help. :) > > Also I am using gnss-sdr-monitor tool, as you can see in the config file. > > Wish we can find the reason of inconsistency and fix it. > > Thanks, > > WANG Cui > > > > *From:* Malte Lenhart <mal...@ma...> > *Sent:* Sunday, August 1, 2021 10:13 PM > *To:* 王璀 WANG Cui <iu...@ms...> > *Subject:* Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file > can't get same result? > > > > Hi, > > @Bemnet: he's using the first-fix signal source file, so no SDR config > involved. > > @ Wang Cui: can you attach your entire config file? My initial > thoughts are that it is less deterministic if the software has to do > one acquisition at a time. So the order it tries the satellites or how > long it takes might influence the overall result. And four satellites > are of course the minimum number of required satellites to get a fix, > it might be more fault tolerant if you let it track another one.. > Depending on what you try to achieve of course.. > > What I always find useful for debugging is to have a look at the > monitor output using one of the following: > > https://gnss-sdr.org/docs/tutorials/monitoring-software-receiver-internal-status/ > <https://gnss-sdr.org/docs/tutorials/monitoring-software-receiver-internal-status/> > https://github.com/acebrianjuan/gnss-sdr-monitor/ > <https://github.com/acebrianjuan/gnss-sdr-monitor/> > > > > Cheers > > Malte > > > > > > On 01.08.21 05:06, 王璀 WANG Cui wrote: > > I am using latest Test branch, on Ubuntu 18.04. > > > > *From:* Bemnet Adefrcis <bem...@gm...> > <mailto:bem...@gm...> > *Sent:* Sunday, August 1, 2021 04:10 AM > *To:* 王璀 WANG Cui <iu...@ms...> <mailto:iu...@ms...> > *Subject:* Re: [Gnss-sdr-developers] Why gnss-sdr decode signal > file can't get same result? > > > > What type gnss SDR version are using ? And operating systems ? > > Respectfully > > Bemnet > > > > On Thu, Jul 29, 2021, 6:34 PM 王璀 WANG Cui <iu...@ms... > <mailto:iu...@ms...>> wrote: > > Hi Malte, > > Thanks for the reply. > > Actually I do set the channel and satellite fixed in my conf > file as below: > > SignalSource.filename=/datalogger/signals/CTTC/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat > > … > > Channels_1B.count=4 > > … > > Channel0.satellite=20 > > Channel1.satellite=12 > > Channel2.satellite=11 > > Channel3.satellite=19 > > > > To avoid multi acquisition at same time, I also set below: > > Channels.in_acquisition=1 > > > > And finally to force channel keep tracking, I set below: > > Acquisition_1B.repeat_satellite=true > > > > However, not matter how I set, the decode results are still > inconsistent, sometimes can fix position, sometime cannot. > > > > I like the gnss-sdr concept of Signal File Source for > debugging, and suppose it should ENSURE same behavior for > every time running, but it is not... > > > > *From:* Malte Lenhart <mal...@ma... > <mailto:mal...@ma...>> > *Sent:* Thursday, July 29, 2021 11:14 PM > *To:* 王璀 WANG Cui <iu...@ms... <mailto:iu...@ms...>>; > iu...@ms... <mailto:iu...@ms...> > *Subject:* Re: [Gnss-sdr-developers] Why gnss-sdr decode > signal file can't get same result? > > > > Hi, > > > > I looked a bit into this, but am no export either :-) > > From my understanding the issue is not the multithreading, but > that the order of satellite it tries to track/acquire is not > fixed. You can set the satellites to track manually and/or > increase the number of channels (and possibly the number of > channels in acquisition too). Increasing channels up to 16 > made it more deterministic for me, but as a downside the > processing time increases quite a bit. > > Hope this helps and maybe someone else has more ideas. > > > > Cheers > > Malte > > > > On 29.07.21 12:24, 王璀 WANG Cui wrote: > > Hi there, > > When I run gnss-sdr to decode same Signal File multiple > times, sometimes it can fix position, sometimes it only > decoded NAV messages without position fix. > > Is it because the multi-threading and can't reproduce the > same result every time? This make it difficult to debug, > especially for the codes after position fix. > > Is it a way (like disable multi-threading) to ensure get > consistent result all the time? > > Thanks in advance, > > > > > _______________________________________________ > > 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... > <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... <mailto:GNS...@li...> > > https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers <https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers> > |
From: Carles F. <car...@ct...> - 2021-08-24 15:11:05
|
Dear all, we have just released GNSS-SDR v0.0.15. Compressed tarballs are available from https://github.com/gnss-sdr/gnss-sdr/releases <https://github.com/gnss-sdr/gnss-sdr/releases> and https://sourceforge.net/projects/gnss-sdr/ <https://sourceforge.net/projects/gnss-sdr/> , and the source code has a permanent DOI at https://zenodo.org/record/5242839 <https://zenodo.org/record/5242839> This release has several improvements, addition of new features and bug fixes in many dimensions, and it consolidates the work done in the last seven months. See our changelog at https://github.com/gnss-sdr/gnss-sdr/releases/tag/v0.0.15 Thanks to all contributors that made it possible! We hope you enjoy it. The Developer Team PD: The action continues in the ‘next’ branch. -- ------------------------------------------------------------ Dr. Carles Fernández Prades Head of Statistical Inference for Comm. & Positioning Dept. Communication Systems Division Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) Address: Parc Mediterrani de la Tecnologia Av. Carl Friedrich Gauss, 7 08860 Castelldefels, Barcelona, Spain. Phone: +34 936452900 Fax: +34 936452901 http://www.cttc.es/people/cfernandez/ <http://www.cttc.es/people/cfernandez/> ------------------------------------------------------------ |
From: Elie A. <Eli...@m3...> - 2021-08-24 09:50:50
|
Dear Carles, dear Javier, dear gnss-sdr developers, I have used GNSS-SDR code as a starting point to implement a receiver that processes a direct signal (LOS) and a reflected signal for a reflectometry application. The architecture looks like the figure below. For every acquired PRN, there must be 2 processing channels: one that tracks the direct signal and the other the reflected signal. [cid:image003.jpg@01D798D9.668B4F50] In order to implement this architecture in GNSS-SDR, I had to modify the flow graph as follows: two signal conditioners, one for each source (direct or reflected signal); and channels with a customized tracking block that takes inputs from two signal conditioners. This tracking block tracks the direct signal (using default GNSS-SDR tracking algorithms) and the reflected signal using an open loop that is driven by the direct signal closed loop. [cid:image005.jpg@01D798D9.668B4F50] I have created all the blocks that I need in gnss block factory, created all the necessary tracking adapters, and made the necessary connections in gnss flow graph. The obtained software is working fine, meaning that tests with 2 short signal records for direct and reflected (~ 15 to 20 min each) came out with expected correlator outputs. However, I have some anomalies that I suspect are beyond my level of understanding of the GNSS-SDR software architecture and coding: 1. When I use long signal records (1 hour or 2 hours), the processing just stops (after 10, or 13, or 17 or 20 min: this is random from run to run) without any error or exception being thrown. By stopping, I mean it gets stuck as if on the wait... 2. When more than 6 satellites are processed, the correlation power of the 6 first satellites (on the direct and reflected processing paths) is just as expected but the correlation power of the 7th, 8th, 9th, etc. satellites is abnormally low (as if they had very low C/N0, which is not the case). If anyone has encountered a similar problem, or understands what the cause for these behaviours may be, your help is welcome. I can share the source code if need be. Cordialement / Regards Elie AMANI Direct Line +33 (0) 5 62 23 13 55 |
From: 王璀 W. C. <iu...@ms...> - 2021-08-01 15:35:39
|
Hi Malte, Pleases see the attached config file. (I use .ini extension name for syntax highlight in text editor). The reason I only use 4 channels is because the signal file only contains 4 GALILEO satellites’ signal. I believe add more acquisition/track channel won’t help. :) Also I am using gnss-sdr-monitor tool, as you can see in the config file. Wish we can find the reason of inconsistency and fix it. Thanks, WANG Cui From: Malte Lenhart <mal...@ma...> Sent: Sunday, August 1, 2021 10:13 PM To: 王璀 WANG Cui <iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, @Bemnet: he's using the first-fix signal source file, so no SDR config involved. @ Wang Cui: can you attach your entire config file? My initial thoughts are that it is less deterministic if the software has to do one acquisition at a time. So the order it tries the satellites or how long it takes might influence the overall result. And four satellites are of course the minimum number of required satellites to get a fix, it might be more fault tolerant if you let it track another one.. Depending on what you try to achieve of course.. What I always find useful for debugging is to have a look at the monitor output using one of the following: https://gnss-sdr.org/docs/tutorials/monitoring-software-receiver-internal-status/ https://github.com/acebrianjuan/gnss-sdr-monitor/ Cheers Malte On 01.08.21 05:06, 王璀 WANG Cui wrote: I am using latest Test branch, on Ubuntu 18.04. From: Bemnet Adefrcis <bem...@gm...><mailto:bem...@gm...> Sent: Sunday, August 1, 2021 04:10 AM To: 王璀 WANG Cui <iu...@ms...><mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? What type gnss SDR version are using ? And operating systems ? Respectfully Bemnet On Thu, Jul 29, 2021, 6:34 PM 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> wrote: Hi Malte, Thanks for the reply. Actually I do set the channel and satellite fixed in my conf file as below: SignalSource.filename=/datalogger/signals/CTTC/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat … Channels_1B.count=4 … Channel0.satellite=20 Channel1.satellite=12 Channel2.satellite=11 Channel3.satellite=19 To avoid multi acquisition at same time, I also set below: Channels.in_acquisition=1 And finally to force channel keep tracking, I set below: Acquisition_1B.repeat_satellite=true However, not matter how I set, the decode results are still inconsistent, sometimes can fix position, sometime cannot. I like the gnss-sdr concept of Signal File Source for debugging, and suppose it should ENSURE same behavior for every time running, but it is not... From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Thursday, July 29, 2021 11:14 PM To: 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>>; iu...@ms...<mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, I looked a bit into this, but am no export either :-) From my understanding the issue is not the multithreading, but that the order of satellite it tries to track/acquire is not fixed. You can set the satellites to track manually and/or increase the number of channels (and possibly the number of channels in acquisition too). Increasing channels up to 16 made it more deterministic for me, but as a downside the processing time increases quite a bit. Hope this helps and maybe someone else has more ideas. Cheers Malte On 29.07.21 12:24, 王璀 WANG Cui wrote: Hi there, When I run gnss-sdr to decode same Signal File multiple times, sometimes it can fix position, sometimes it only decoded NAV messages without position fix. Is it because the multi-threading and can't reproduce the same result every time? This make it difficult to debug, especially for the codes after position fix. Is it a way (like disable multi-threading) to ensure get consistent result all the time? Thanks in advance, _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers |
From: 王璀 W. C. <iu...@ms...> - 2021-08-01 03:21:51
|
I am using latest Test branch, on Ubuntu 18.04. From: Bemnet Adefrcis <bem...@gm...> Sent: Sunday, August 1, 2021 04:10 AM To: 王璀 WANG Cui <iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? What type gnss SDR version are using ? And operating systems ? Respectfully Bemnet On Thu, Jul 29, 2021, 6:34 PM 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>> wrote: Hi Malte, Thanks for the reply. Actually I do set the channel and satellite fixed in my conf file as below: SignalSource.filename=/datalogger/signals/CTTC/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat … Channels_1B.count=4 … Channel0.satellite=20 Channel1.satellite=12 Channel2.satellite=11 Channel3.satellite=19 To avoid multi acquisition at same time, I also set below: Channels.in_acquisition=1 And finally to force channel keep tracking, I set below: Acquisition_1B.repeat_satellite=true However, not matter how I set, the decode results are still inconsistent, sometimes can fix position, sometime cannot. I like the gnss-sdr concept of Signal File Source for debugging, and suppose it should ENSURE same behavior for every time running, but it is not... From: Malte Lenhart <mal...@ma...<mailto:mal...@ma...>> Sent: Thursday, July 29, 2021 11:14 PM To: 王璀 WANG Cui <iu...@ms...<mailto:iu...@ms...>>; iu...@ms...<mailto:iu...@ms...> Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, I looked a bit into this, but am no export either :-) From my understanding the issue is not the multithreading, but that the order of satellite it tries to track/acquire is not fixed. You can set the satellites to track manually and/or increase the number of channels (and possibly the number of channels in acquisition too). Increasing channels up to 16 made it more deterministic for me, but as a downside the processing time increases quite a bit. Hope this helps and maybe someone else has more ideas. Cheers Malte On 29.07.21 12:24, 王璀 WANG Cui wrote: Hi there, When I run gnss-sdr to decode same Signal File multiple times, sometimes it can fix position, sometimes it only decoded NAV messages without position fix. Is it because the multi-threading and can't reproduce the same result every time? This make it difficult to debug, especially for the codes after position fix. Is it a way (like disable multi-threading) to ensure get consistent result all the time? Thanks in advance, _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers |
From: 王璀 W. C. <iu...@ms...> - 2021-07-29 15:33:08
|
Hi Malte, Thanks for the reply. Actually I do set the channel and satellite fixed in my conf file as below: SignalSource.filename=/datalogger/signals/CTTC/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat … Channels_1B.count=4 … Channel0.satellite=20 Channel1.satellite=12 Channel2.satellite=11 Channel3.satellite=19 To avoid multi acquisition at same time, I also set below: Channels.in_acquisition=1 And finally to force channel keep tracking, I set below: Acquisition_1B.repeat_satellite=true However, not matter how I set, the decode results are still inconsistent, sometimes can fix position, sometime cannot. I like the gnss-sdr concept of Signal File Source for debugging, and suppose it should ENSURE same behavior for every time running, but it is not... From: Malte Lenhart <mal...@ma...> Sent: Thursday, July 29, 2021 11:14 PM To: 王璀 WANG Cui <iu...@ms...>; iu...@ms... Subject: Re: [Gnss-sdr-developers] Why gnss-sdr decode signal file can't get same result? Hi, I looked a bit into this, but am no export either :-) From my understanding the issue is not the multithreading, but that the order of satellite it tries to track/acquire is not fixed. You can set the satellites to track manually and/or increase the number of channels (and possibly the number of channels in acquisition too). Increasing channels up to 16 made it more deterministic for me, but as a downside the processing time increases quite a bit. Hope this helps and maybe someone else has more ideas. Cheers Malte On 29.07.21 12:24, 王璀 WANG Cui wrote: Hi there, When I run gnss-sdr to decode same Signal File multiple times, sometimes it can fix position, sometimes it only decoded NAV messages without position fix. Is it because the multi-threading and can't reproduce the same result every time? This make it difficult to debug, especially for the codes after position fix. Is it a way (like disable multi-threading) to ensure get consistent result all the time? Thanks in advance, _______________________________________________ GNSS-SDR-developers mailing list GNS...@li...<mailto:GNS...@li...> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers |
From: 王璀 W. C. <iu...@ms...> - 2021-07-29 10:58:38
|
Hi there, When I run gnss-sdr to decode same Signal File multiple times, sometimes it can fix position, sometimes it only decoded NAV messages without position fix. Is it because the multi-threading and can't reproduce the same result every time? This make it difficult to debug, especially for the codes after position fix. Is it a way (like disable multi-threading) to ensure get consistent result all the time? Thanks in advance, |
From: <wk...@ir...> - 2021-07-21 16:56:54
|
Quoting "Farkas, Márton" <mf...@sz...>: > Hi Álvaro, > > Yes it was open-sky, and we used a GPS antenna. How much time is required > to get data from the satellites? I used non SDR receivers at the same place > and they need less than a minute to have a fixed position. > > Thanks, > > Marton > > Álvaro Cebrián Juan <ace...@gm...> ezt írta (időpont: 2021. júl. > 21., Sze 17:05): > Hello; I have some experience with RTL dongles. The best working were first batches with E4000 frot end, now discontinued and har to get. They worked reliably on 1575MHz and some of them even to above 2GHz. All currently manufactured items use RTL820T or T2 work to around 1,3 to 1,6GHz. T2 is slghtly better but not all work at 1575MHz. I have one chinese clone (with v3 printed on case and TCXO present but unconnected) that works on L1 and original v3 that does not. So here are my advices: 1. If you have RF dignal generator that covers L1 frequency, test if the dongle works on that frequency using general purpose radio software as gqrx or SDR# (Windows). 2. Check the bias for the actine antenna with a noltmeter, so far gnss-sdr hae no ability to control DC bias in v3 dongle. 3. Investigate noise level at and around L1 frequency, visible on gqrx spectrum plot. There should be some noise increase if the antenna is connected and DC bias is applied. IF not, either the dongle is not receiving on that frequency or antena is not dfficient enough. 4. In config file set IF frequency to 0 and sample rate to 2 000 000 Hz, if your dongle has TCXO. The values in file are correct for a dongle used for test (using X-tal with 50ppm offset). Gnss-sdr can tolerate slight offset of few ppm. -- Wojciech Kazubski |
From: Farkas, M. <mf...@sz...> - 2021-07-21 15:26:26
|
Hi Álvaro, Yes it was open-sky, and we used a GPS antenna. How much time is required to get data from the satellites? I used non SDR receivers at the same place and they need less than a minute to have a fixed position. Thanks, Marton Álvaro Cebrián Juan <ace...@gm...> ezt írta (időpont: 2021. júl. 21., Sze 17:05): > Hi Márton, > > Judging by your log file, it looks like you are not detecting any GPS > signals. > Are you using a GNSS antenna? Does the antenna have a clear unobstructed > view of the sky? > > Regards, > Álvaro > > > El mié, 21 jul 2021 a las 15:36, Farkas, Márton (<mf...@sz...>) > escribió: > >> Dear all, >> >> I would like to ask for help with gnss-sdr again. We bought two RTL-SDR >> v3 receivers. We built the gnss-sdr on raspberry pi 4 from the source and >> an ubuntu laptop via docker. There was no error message during the >> installation. We use the rtl-sdr realtime configuration sample with the >> modification >> >> *SignalSource.osmosdr_args=rtl,bias=1*The software reports Tracking and >> loss of lock messages, and we don't get any navigation or observation data, >> or PVT solution. >> Can you help me find out what might be causing this? >> I've attached the log info file. >> >> Best regards, >> Marton Farkas >> _______________________________________________ >> GNSS-SDR-developers mailing list >> GNS...@li... >> https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers >> > |
From: Álvaro C. J. <ace...@gm...> - 2021-07-21 15:05:48
|
Hi Márton, Judging by your log file, it looks like you are not detecting any GPS signals. Are you using a GNSS antenna? Does the antenna have a clear unobstructed view of the sky? Regards, Álvaro El mié, 21 jul 2021 a las 15:36, Farkas, Márton (<mf...@sz...>) escribió: > Dear all, > > I would like to ask for help with gnss-sdr again. We bought two RTL-SDR v3 > receivers. We built the gnss-sdr on raspberry pi 4 from the source and an > ubuntu laptop via docker. There was no error message during the > installation. We use the rtl-sdr realtime configuration sample with the > modification > > *SignalSource.osmosdr_args=rtl,bias=1*The software reports Tracking and > loss of lock messages, and we don't get any navigation or observation data, > or PVT solution. > Can you help me find out what might be causing this? > I've attached the log info file. > > Best regards, > Marton Farkas > _______________________________________________ > GNSS-SDR-developers mailing list > GNS...@li... > https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers > |
From: Farkas, M. <mf...@sz...> - 2021-07-21 13:34:26
|
Dear all, I would like to ask for help with gnss-sdr again. We bought two RTL-SDR v3 receivers. We built the gnss-sdr on raspberry pi 4 from the source and an ubuntu laptop via docker. There was no error message during the installation. We use the rtl-sdr realtime configuration sample with the modification *SignalSource.osmosdr_args=rtl,bias=1*The software reports Tracking and loss of lock messages, and we don't get any navigation or observation data, or PVT solution. Can you help me find out what might be causing this? I've attached the log info file. Best regards, Marton Farkas |
From: Javier A. <jar...@ct...> - 2021-07-15 21:37:18
|
correction: GNSS-SDR.use_acquisition_resampler=true > El 15 jul 2021, a las 23:31, Javier Arribas <jar...@ct...> escribió: > > Hi there, > The problem with L2CM signal is that the PRN code length is 20 ms thus even thought the tracking is using more less the same resources as the L1 CA tracking with 20 symbols integration, the L2CM acquisition is using FFTs and IFFTs of 20ms x sampling frequency length. This is the bottleneck of L2C. It is possible to reduce the sampling frequency just for the acquisition, but the limit for L2C is set to 2 MSPS. > > Try to enable the automatic acquisition resampler by adding to your config file the following line at top, just after [GNSS-SDR] > > [GNSS-SDR] > > use_acquisition_resampler=true > > see more here https://gnss-sdr.org/docs/sp-blocks/global-parameters/ <https://gnss-sdr.org/docs/sp-blocks/global-parameters/> > > Regards, > Javier. > > >> El 15 jul 2021, a las 21:05, wk...@ir... <mailto:wk...@ir...> escribió: >> >> Quoting Wojciech Kazubski <wk...@ir... <mailto:wk...@ir...>>: >> >>> Hello! >>> >>> We are trying to receive GPS L2 signal with rtl-sdr dongle, but we have some >>> problems with overflows. >>> >>> Our computer is a 4-core i5-4590 CPU (clock 3,3GHz). We are able to receive L1 >>> GPS signal with tracking for 8 satellites with all cores running at around 40% >>> CPU load (see attached picture, on the left). But if we switch to L2C signal, >>> the CPU is not working smooth, one core has 100% load and other much less, >>> even if set to track only one satellite (as on the right side of picture). >>> Also, some "O"s are printed (around 20 every minute). With 8 satellites to >>> track we get 100% load on all cores and more overflows. >>> >>> Is L2C decoder less effective? >>> >>> -- >>> dr Wojciech Kazubski >>> -- >> Hello, >> >> Recently I managed to get messages from 2 satellites using original RTL-SDR v3 (with TCXO). If both channels are synchronized, the CPU load is stable, below 20% each core. But if one of the channels is loosing lock, the CPU load starts to vary, some overflows are signaled and another channelis thrown off sync. >> >> -- >> dr Wojciech Kazubski >> >> >> >> >> _______________________________________________ >> GNSS-SDR-developers mailing list >> GNS...@li... <mailto: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 |
From: Javier A. <jar...@ct...> - 2021-07-15 21:32:00
|
Hi there, The problem with L2CM signal is that the PRN code length is 20 ms thus even thought the tracking is using more less the same resources as the L1 CA tracking with 20 symbols integration, the L2CM acquisition is using FFTs and IFFTs of 20ms x sampling frequency length. This is the bottleneck of L2C. It is possible to reduce the sampling frequency just for the acquisition, but the limit for L2C is set to 2 MSPS. Try to enable the automatic acquisition resampler by adding to your config file the following line at top, just after [GNSS-SDR] [GNSS-SDR] use_acquisition_resampler=true see more here https://gnss-sdr.org/docs/sp-blocks/global-parameters/ <https://gnss-sdr.org/docs/sp-blocks/global-parameters/> Regards, Javier. > El 15 jul 2021, a las 21:05, wk...@ir... escribió: > > Quoting Wojciech Kazubski <wk...@ir...>: > >> Hello! >> >> We are trying to receive GPS L2 signal with rtl-sdr dongle, but we have some >> problems with overflows. >> >> Our computer is a 4-core i5-4590 CPU (clock 3,3GHz). We are able to receive L1 >> GPS signal with tracking for 8 satellites with all cores running at around 40% >> CPU load (see attached picture, on the left). But if we switch to L2C signal, >> the CPU is not working smooth, one core has 100% load and other much less, >> even if set to track only one satellite (as on the right side of picture). >> Also, some "O"s are printed (around 20 every minute). With 8 satellites to >> track we get 100% load on all cores and more overflows. >> >> Is L2C decoder less effective? >> >> -- >> dr Wojciech Kazubski >> -- > Hello, > > Recently I managed to get messages from 2 satellites using original RTL-SDR v3 (with TCXO). If both channels are synchronized, the CPU load is stable, below 20% each core. But if one of the channels is loosing lock, the CPU load starts to vary, some overflows are signaled and another channelis thrown off sync. > > -- > dr Wojciech Kazubski > > > > > _______________________________________________ > GNSS-SDR-developers mailing list > GNS...@li... > https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers |
From: <wk...@ir...> - 2021-07-15 19:23:30
|
Quoting Wojciech Kazubski <wk...@ir...>: > Hello! > > We are trying to receive GPS L2 signal with rtl-sdr dongle, but we have some > problems with overflows. > > Our computer is a 4-core i5-4590 CPU (clock 3,3GHz). We are able to > receive L1 > GPS signal with tracking for 8 satellites with all cores running at > around 40% > CPU load (see attached picture, on the left). But if we switch to L2C signal, > the CPU is not working smooth, one core has 100% load and other much less, > even if set to track only one satellite (as on the right side of picture). > Also, some "O"s are printed (around 20 every minute). With 8 satellites to > track we get 100% load on all cores and more overflows. > > Is L2C decoder less effective? > > -- > dr Wojciech Kazubski > -- Hello, Recently I managed to get messages from 2 satellites using original RTL-SDR v3 (with TCXO). If both channels are synchronized, the CPU load is stable, below 20% each core. But if one of the channels is loosing lock, the CPU load starts to vary, some overflows are signaled and another channelis thrown off sync. -- dr Wojciech Kazubski |
From: <fr...@fr...> - 2021-07-14 18:42:14
|
The PlutoSDR frontend (AD9363/4) is pretty much the same as the B210 frontend (AD9361) and in both cases the LO offset will be caused by the medium quality TCXO clocking the receiver. 1/ make sure your active antenna is properly polarized with a bias T, that would be my most probable cause of missing signal 2/ possibly extend the Doppler shift range if your TCXO is excessively poorly tuned Acquisition_1C.doppler_max=15000 The larger this value the more computational power is needed but the better your chances of getting a signal (could be up to 100 kHz for poor quality RTL-SDR) 3/ use front-end-cal to check your LO frequency offset: you might tune https://github.com/gnss-sdr/gnss-sdr/blob/master/conf/front-end-cal.conf to collect data from the PlutoSDR source instead of OsmoSDR RTL-SDR dongle to calibrate the LO if in doubt. When I am in doubt I collect a couple of seconds worth of data and plot the auto-correlation of the signal to make sure the GNSS signal is visible as correlation peaks every ms. See https://www.youtube.com/watch?v=U4hAyPv5s1Y around 34'50" (although prior theoretical basics might be useful if not familiar with the topic) Best, JM ----- Mail original ----- De: "Álvaro Cebrián Juan" <ace...@gm...> À: "Márton Farkas" <mf...@sz...> Cc: "GNSS-SDR-Developers" <GNS...@li...> Envoyé: Mercredi 14 Juillet 2021 14:14:10 Objet: Re: [Gnss-sdr-developers] gnss-sdr with Adalm Pluto Hi Marton , I have no real experience with the Adalm PLUTO SDR front - end so please take my words with a grain of salt but, judging by the specs , I don't think the PLUTO is a well suited SDR for GNSS reception primarily due to its clock frequency stability of ±25 ppm, which is insufficient for GNSS applications (which typically require 1 ppm or better). There are ways to circumvent this by making modifications to hardware which I find very inconvenient. You can find more info in this discussion . Hope this helps. Regards, Álvaro El mié, 14 jul 2021 a las 13:33, Farkas, Márton (< mf...@sz... >) escribió: Dear All, We are working on a moving baseline GNSS test with Adalm Pluto SDRs. After the gnss-sdr installation we connected the device via usb. We modified only the SignalSource.device_address in the sample configuration file ( gnss-sdr_GPS_L1_plutosdr_realtime.conf ) to the usb uri of the device. We ran the software several times and the RINEX, the gpx and the kml files are empty or they are not generated. We also tested it in open-sky environment. I would like to ask for help on what might be causing the problem. Thank you! Best regards, Marton Farkas _______________________________________________ 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 |