gnss-sdr / gnss-sdr Goto Github PK

Hello,
I have a USRP-N210 series. I have both DBSRX2 and WBX daughterboards. I want to collect both L1/L2 GPS signals for my research project. In your readme. txt you mentioned "Configuring the USRP X300 with two front-ends for receiving signals in L1 and L2 bands". I didn't quite understand what sort of setup you used for this purpose? Did you use two different USRPs each equipped with a daughterboard and synced them using an external clock? Or did you accomplish this using a single USRP? If you used only 1 USRP, do you know if I can use USRP-N210 as well for this purpose? Or do I need USRP-X300? What sort of daughterboard needs to be used for this purpose?

Thank you,

Cheers
Ramya

In the Getting Started, I have successfully performed each item once, and got position fixes with my open source software-defined GPS receiver on Ubuntu16.04!

At the moment I just need GPS L1 signal

I have some questions about how to collect raw GPS data, I have NI-USRP 2922 like N210, but I do not know if the daughter board is necessary. What should I do next to get the original data like “2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat”

Hi,
I am trying to run the gnss-sdr_GPS_L1_USRP_realtime.conf file with a USRP B200. However, the output provides the following error:

linux; GNU C++ version 4.8.4; Boost_105600; UHD_003.009.005-0-g32951af2

Initializing GNSS-SDR v0.0.9.git-next-265caed ... Please wait.
Logging will be written at "/tmp"
Use gnss-sdr --log_dir=/path/to/log to change that.
-- Detected Device: B200
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 16.000000 MHz...
-- Actually got clock rate 16.000000 MHz.
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Asking for clock rate 32.000000 MHz...
-- Actually got clock rate 32.000000 MHz.
-- Performing timer loopback test... pass
Sampling Rate for the USRP device: 2000000.000000 [sps]...
UHD RF CHANNEL #0 SETTINGS
Actual USRP center freq.: 1575420000.000297 [Hz]...
PLL Frequency tune error 0.000297 [Hz]...
Actual daughterboard gain set to: 60.000000 dB...
Setting RF bandpass filter bandwidth to: 1000000.000000 [Hz]...
Check for front-end LO: locked ... is Locked
Starting a TCP Server on port 2101
The TCP Server is up and running. Accepting connections ...
E0824 08:23:47.129644 15475 gnss_flowgraph.cc:84] copy(3): insufficient connected output ports (1 needed, 0 connected)
E0824 08:23:47.129838 15475 control_thread.cc:126] Unable to start flowgraph
Total GNSS-SDR run time: 0.000730433 [seconds]
GNSS-SDR program ended.
Stopping TCP Server on port 2101

Can you provide some insight on this? Also is there a preferred config file that I should use for a B200?

Thanks,
Kyle

I've noticed that configuring gnss-sdr to run with both GPS and Galileo leads to a hang. It seems all threads are blocked, this occurs about 1 second into the data file in general.

I've created a gist with three config files: 1) gps.conf; 2) gal.conf; 3) gps-gal.conf see here. These config files work with the CTTC data set available here

When I run these with the current next branch the individual system configs everything runs fine (beautifully even!) - but when I run the gps-gal.conf the receiver just stops processing after about 1 second of file time with no errors. The keyboard listener is still responsive, so typing q works.

I've noticed this with other files as well.

Running on Mac OS X 10.10 using homebrew. Anyone else seeing this issue?

Hello,
I am trying to build the source code, since the previous install with apt-get didn't had all of the required functions. I made it compile until 96%, but now I am stuck. Here is the log

Any tips?
Thanks

Hello,

First I want to say thank you for being up to date with all the issues posted. Second, I keep getting an error about item size mismatch...

E0810 20:56:46.229605 13762 gnss_flowgraph.cc:154] itemsize mismatch: copy2:0 using 8, complex_byte_to_float_x20:0 using 2

E0810 20:56:46.229755 13762 control_thread.cc:139] Unable to connect flowgraph

I am using the code from the "My first position fix" portion of the guide and I am trying to process my own data. I understand that there must be some consistency when it comes to item types so I made sure that different parts of the code blocks matched (copy0:0, copy1:0, direct_resampler_make_conditioner_cb0:0 and valve0:0). These correspond to the .item_types of the DataTypeAdapter, the InputFilter, the Resampler and the Acquisition_1C respectively. I figured this out through trial and error. However, I reached this message and I cannot figure out what item_type copy2:0 is referring to. It can't be Tracking_1C can it? That one only accepts gr_complex and therefore it cannot be modified. Then again it would explain why it has a value of 8. Let me know what you think; what should I change to make the item types match?

HI,
I ran the Next branch overnight, and found two issues. These are probably unrelated, so I've titled this post to reflect just one:

1. The warning log shows ~23 minutes of

W0912 [timestamp] 9444 rtcm.cc:2836] GPS satellite ID must be between 0 and 31, but PRN 32 was found

2. The second issue is that the receiver was stalled. I believe this is unrelated because the time at which it stalled (i.e. ceased to provide a PVT solution) was ~4 hours after the timestamp of the warnings in item 1 above.

Are these known issues?

Thanks,
Blair

Current calculation Doppler occupy too much memory, as well as a good way to calculate the Doppler do?

It seems that there is a copy/paste error in Galileo_E5a.h: lines 252-269 ( E5aI codes for prns 33 to 50) are identical to lines 305-322 (E5aQ codes for prns 33 to 50)

Checking against the ICD its clear that the E5aI codes are in error

As far as I can tell, there's no actual fortran code in this project, and the check for gfortran is there because of the requirement for LAPACK, BLAS and Armadillo.

I'm currently working on a buildroot configuration to install gnss-sdr on embedded devices. Fortran has been deprecated in buildroot, and the LAPACK and BLAS packages have been replaced by their C equivalents. Additionally, Armadilo can be built without a fortran compiler.

I propose that simply checking for LAPACK and BLAS is enough, and there's no need to check for fortran. This would allow configurations where non-fortran versions of LAPACK and BLAS are used.

Quoting @odrisci from #69:

I've been thinking a bit about the implementation of the pcps_acquistion_sc - it really pains me to have two classes with almost identical implementation, it makes for a real code maintenance headache. One possible solution would be to make the current implementation a generic pcps_acquisition block that would take an item_type parameter as input. From what I can see the current pcps_acquisition_sc simply converts the input from lv_16sc_t to gr_complex using a volk kernel and then implements precisely the same functionality as pcps_acquisition_cc. I'm hacking together a solution along these lines for my personal use, do you think this would be a good idea? Or is the separation of blocks into specific implementations for specific data types a key design decision within gnss-sdr?

After performing all the mentioned steps, I'm getting this error. As a beginner I'm not able to rectify the problem.

gnss-sdr --config_file=./my-first-GNSS-SDR-receiver.conf
linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown

Initializing GNSS-SDR v0.0.6.git-- ... Please wait.
Logging will be done at "/tmp"
Use gnss-sdr --log_dir=/path/to/log to change that.
Processing file /home/vamsi/work/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat, which contains 1339452928 [bytes]
GNSS signal recorded time to be processed: 83.71480799999999 [s]
Using Volk machine: avx2_64_mmx_orc
E0825 16:48:45.303230 13893 gnss_flowgraph.cc:355] itemsize mismatch: gps_l1_ca_pvt_cc0:0 using 8, null_sink0:0 using 2
E0825 16:48:45.303338 13893 control_thread.cc:139] Unable to connect flowgraph
Total GNSS-SDR run time 0.001826 [seconds]
GNSS-SDR program ended.
gnss-sdr: /usr/include/boost/thread/pthread/condition_variable_fwd.hpp:81: boost::condition_variable::~condition_variable(): Assertion `!ret' failed.
Aborted (core dumped)

armadillo 5.200.2 is not available on sourceforge

Dear all,

We used to process 2-bit packed real data by converting them beforehand to bytes. Today we investigated the use of the Two_Bit_Packed_File_Signal_Source with SignalSource.sample_type=real, by using the same parameters as in the configuration file form the repo:
gnss-sdr_GPS_L1_nsr_twobit_packed.conf

and we got the following error:

E0616  gnss_flowgraph.cc:129] itemsize mismatch: char_to_float0:0 using 4, valve0:0 using 8
E0616 control_thread.cc:116] Unable to connect flowgraph

The error also arises using the conf file from the repo.

Could you please double check and try to locate the issue, as we were not able to do it?

We also tried with another Two_Bit_Packed_File_Signal_Source configuration with iq data (SignalSource.sample_type=iq) and everything worked fine.

Thanks!

I'm running Ubuntu 15.04 with:
o gcc: 4.9.2
o GNU Radio: 3.7.9git-226-ge0a70a92
o Boost: 1.55
o gnss-sdr: next branch - 217ed14

Running make check in debug mode fails with:

1: control_thread_test: /usr/include/boost/thread/pthread/condition_variable_fwd.hpp:81: boost::condition_variable::~condition_variable(): Assertion `!ret' failed.
1/5 Test #1: control_thread_test ..............***Exception: Other  0.78 sec

The issue appears to be with the order of destructors and the concurrent_queue object. The concurrent queue is destroyed before the threads that are reading from it. These threads are still waiting on the condition_variable when the condition_variable destructor is called, which throws the above exception.

Note that I have not seen this issue when running gnss-sdr on a Mac, which has a later version of boost (1.59).

I think this is the same issue as was raised here

After fixing the config file as I described in #36 I have now come across another issue. When I run the example I get:

gnss-sdr --config_file=test2.conf
linux; GNU C++ version 6.2.0 20160927; Boost_106100; UHD_003.009.005-0-unknown

Initializing GNSS-SDR v0.0.8 ... Please wait.
Logging will be done at "/tmp"
Use gnss-sdr --log_dir=/path/to/log to change that.
Processing file >/home/matt/gnss/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN/2013_04_04_GNSS_SIGNAL_at_CTTC_SPAIN.dat, which contains 1600000000 [bytes]
GNSS signal recorded time to be processed: 99.999 [s]
E1030 12:43:27.096798 16579 gnss_flowgraph.cc:159] itemsize mismatch: copy1:0 using 8, stream_to_vector0:0 using 4
E1030 12:43:27.096873 16579 control_thread.cc:110] Unable to connect flowgraph
Total GNSS-SDR run time 0.000353 [seconds]
GNSS-SDR program ended.

Unfortunately its difficult to tell where this error message has come from, so I'm unsure where to change the configuration file to make it work.

Thanks,

Matt

The function pcps_acquisition_cc::set_local_code only copies the first 1 ms of data of the pre-computed code samples to the d_fft_if input buffer without taking into account the configuration data.

If the correlation of the acquisition is done using 1 ms then this is ok.

But if the correlation is done using more than 1 ms then there are missing samples in the fft input. The energy of the correlation will not grow according to the integration time.

This has been checked by testing the acquisition using 1 ms, 2 ms and 4 ms with and without the bug fix.

i have installed and tried GNSS SDR following the steps in "http://gnss-sdr.org/my-first-fix/" and it works ....

but i want to use antenna instead of the raw file ... so how can configure the conf file to connect with my antenna ???

Hello,

I am running this config modified for UHD_Signal_Source, but I get this error:

E0801 06:48:39.465976 13095 gnss_block_factory.cc:1278] TelemetryDecoder_2S.GPS_L2C_Telemetry_Decoder: Undefined implementation for block
Segmentation fault

I looked it up and looks like the source did not compiled successfully, but the software was installed via apt-get install command. Any tips? Also tried a reinstall.

My setup: USRP N210, Linux kali 4.9.0-kali4-amd64 #1 SMP Debian 4.9.30-2kali1 (2017-06-22) x86_64 GNU/Linux; "gnss-sdr is already the newest version (0.0.8-1+b5)" . Is this an old build? (i noticed the latest version is 0.0.9) but even so, the software should work.

Thanks

Hi, I am trying to build gnss-sdr on EI Captain. When cmake ../, I got the following error:

-- gflags library found at /usr/local/lib/libgflags.dylib
-- Looking for OpenSSL instead...
-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing:  OPENSSL_INCLUDE_DIR) 
 The GnuTLS library with openssl compatibility enabled has not been found.
 You can try to install the required libraries by typing:
 sudo port install gnutls
CMake Error at CMakeLists.txt:819 (message):
  GnuTLS libraries with openssl compatibility are required to build gnss-sdr

I did follow the instructions on Mac and installed required libraries with Homebrew.

The config files specify the intermediate frequency (IF) with the ".if" property but the acquisition code checks for the ".ifreq" property for the IF configuration.

(for instance : Acquisition_1C.if = 0)

As the acquisition code does not find an .ifreq property it always sets the IF frequency to 0.

view openhpsdr.org

I have done the non-real-time GPS L1 signal processing. When I do real-time processing, cannot get the correct results and do not return "New Message...". I tried the gnss-sdr_GPS_L1_USRP_realtime.conf and gnss-sdr_GPS_L1_USRP_X300_realtime.conf. What should I pay attention to or what parameters I need to adjust?
I have changed those parameters:
GNSS-SDR.internal_fs_hz=2000000
SignalSource.sampling_frequency=2000000
SignalSource.item_type=gr_complex
SignalConditioner.implementation=Pass_Through
Look forward to someone to answer, thank you

Is there a pre-compiled version of gnss-sdr? (.deb for Debian)
I really need to do some quick data capture and I am experiencing some issues with building the source. gnss-sdr disappeared from the latest repository. Or maybe somebody knows a repo I can add and install it from there.

Thanks a lot

Following the hello world tutorial and running
$ gnss-sdr --config_file=hello_world.conf
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.0.git-28-gc66cb1ba

Initializing GNSS-SDR v0.0.8.git-next-74a23c5 ... Please wait.
Logging will be done at "/tmp"
Use gnss-sdr --log_dir=/path/to/log to change that.
...

but running
$ gnss-sdr --log_dir=$HOME/temp --config_file=hello_world.conf
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.0.git-28-gc66cb1ba

ERROR: unknown command line flag 'log_dir'

So it appears that there's no log_dir flag. Interesting that the GLOG_log_dir env var does work which means some definition is getting through from glog. More info:

$ gnss-sdr --version
linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.0.git-28-gc66cb1ba

gnss-sdr version 0.0.8.git-next-74a23c5

This bug that randomly appear was reported internally by the GNSS-SDR team long time ago. The visible symtom is that GNSS-SDR often looses all tracking satellites and apparently the acquisition process can not recover any new satellite. The bug was observed several times when GNSS-SDR is working in real-time for long runtimes (i.e. run times grater than 120 minutes).

I finally managed to reproduce the bug in post processing mode:

Here you can see the output log for a single channel GPS L1 receiver:

javier@pcjarribas:~/git/gnss-sdr/build$ ../install/gnss-sdr --config_file=../conf/gnss-sdr_Hybrid_nsr.conf
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-113-g6b367da7

Initializing GNSS-SDR v0.0.6.git-next-1bafa1e ... Please wait.
Logging will be done at "/tmp"
Use gnss-sdr --log_dir=/path/to/log to change that.
Processing file /media/javier/SISTEMA/signals/ifen/E1L1_FE0_Band0.stream, which contains 1500195840 [bytes]
GNSS signal recorded time to be processed: 293.005 [s]
Using Volk machine: avx2_64_mmx
connected
n acq=27.43444061279297
n acq=12.60478496551514
*Current input signal time = 1 [s]
Current input signal time = 2 [s]
Current input signal time = 3 [s]
Current input signal time = 4 [s]
Current input signal time = 5 [s]
Current input signal time = 6 [s]
Current input signal time = 7 [s]
Current input signal time = 8 [s]
Current input signal time = 9 [s]
Current input signal time = 10 [s]
Current input signal time = 11 [s]
Current input signal time = 12 [s]
Current input signal time = 13 [s]
Current input signal time = 14 [s]
Current input signal time = 15 [s]
Current input signal time = 16 [s]
Current input signal time = 17 [s]
Current input signal time = 18 [s]
Current input signal time = 19 [s]
Current input signal time = 20 [s]
Current input signal time = 21 [s]
Current input signal time = 22 [s]
qCurrent input signal time = 23 [s]
*
Quit keystroke order received, stopping GNSS-SDR !!
Stopping GNSS-SDR, please wait!
Total GNSS-SDR run time 2.450165 [seconds]
GNSS-SDR program ended.

I have added a simple debug print in PCPS_acquisition_cc to show the acquisition threshold in the console, printed each time that acquisition fails. Apparently, after two negative acquisitions, the acquisition scheduler is not activating acquisition anymore, even there is a tracking channel available. As a consequence, GNSS-SDR is doing nothing, not acquiring nor tracking any satellite. The bug is related to the control_thread that dispatches satellites to acquisition and tracking (80%) or may be it involves some bug in the PCPS acquisition module internal state machine (20%).

I've been doing some work on optimising gnss-sdr for real-time operation and I have a number of small observations that can help speed things up.

The simplest one is the use of complex local replica codes. I'm not sure that I get the logic here, perhaps it is something to do with data alignment? But in most cases GNSS spreading codes are real valued. By generating real-valued local replicas we can significantly reduce the number of operations performed in each correlation period.

I've pushed a commit to my mirror here. Running volk_gnsssdr_profile for the rotator dot product kernels gives the following results:

RUN_VOLK_GNSSSDR_TESTS: volk_gnsssdr_16ic_x2_rotator_dotprodxnpuppet_16ic(8111,1987)
generic completed in 4375.07 ms
generic_reload completed in 4401.19 ms
a_sse3 completed in 70.8445 ms
a_sse3_reload completed in 66.7536 ms
u_sse3 completed in 72.2266 ms
a_avx2 completed in 56.9406 ms
a_avx2_reload completed in 54.3238 ms
u_avx2 completed in 56.096 ms
u_avx2_reload completed in 55.0206 ms
Best aligned arch: a_avx2_reload
Best unaligned arch: u_avx2_reload
RUN_VOLK_GNSSSDR_TESTS: volk_gnsssdr_16ic_16i_rotator_dotprodxnpuppet_16ic(8111,1987)
generic completed in 709.682 ms
generic_reload completed in 628.565 ms
a_sse3 completed in 46.4894 ms
u_sse3 completed in 46.1271 ms
a_avx2 completed in 24.1963 ms
u_avx2 completed in 24.5185 ms
Best aligned arch: a_avx2
Best unaligned arch: u_avx2
RUN_VOLK_GNSSSDR_TESTS: volk_gnsssdr_32fc_x2_rotator_dotprodxnpuppet_32fc(8111,1987)
generic completed in 1099.62 ms
generic_reload completed in 1104.81 ms
u_sse3 completed in 108.187 ms
a_sse3 completed in 108.041 ms
u_avx completed in 84.7187 ms
a_avx completed in 82.0969 ms
Best aligned arch: a_avx
Best unaligned arch: u_avx
RUN_VOLK_GNSSSDR_TESTS: volk_gnsssdr_32fc_32f_rotator_dotprodxnpuppet_32fc(8111,1987)
generic completed in 450.866 ms
generic_reload completed in 445.909 ms
u_avx completed in 42.0306 ms
Best aligned arch: u_avx
Best unaligned arch: u_avx

Note that the 16ic_16i and 32fc_32f are approximately twice as fast as the complex by complex equivalents. The resamplers are also faster, but not to the same extent:

RUN_VOLK_GNSSSDR_TESTS: volk_gnsssdr_16ic_resamplerxnpuppet_16ic(8111,1987)
generic completed in 3134.48 ms
a_sse3 completed in 129.152 ms
u_sse3 completed in 127.664 ms
u_sse4_1 completed in 114.952 ms
a_sse4_1 completed in 116.136 ms
u_avx completed in 90.8682 ms
a_avx completed in 91.2342 ms
Best aligned arch: u_avx
Best unaligned arch: u_avx
RUN_VOLK_GNSSSDR_TESTS: volk_gnsssdr_16i_resamplerxnpuppet_16i(8111,1987)
generic completed in 241.116 ms
a_sse3 completed in 100.528 ms
u_sse3 completed in 99.4621 ms
u_sse4_1 completed in 87.001 ms
a_sse4_1 completed in 87.0222 ms
u_avx completed in 77.4584 ms
a_avx completed in 77.1455 ms
Best aligned arch: a_avx
Best unaligned arch: u_avx
RUN_VOLK_GNSSSDR_TESTS: volk_gnsssdr_32fc_resamplerxnpuppet_32fc(8111,1987)
generic completed in 303.419 ms
a_sse3 completed in 164.896 ms
u_sse3 completed in 167.329 ms
u_sse4_1 completed in 154.883 ms
a_sse4_1 completed in 153.66 ms
a_avx completed in 129.876 ms
u_avx completed in 131.457 ms
a_avx2 completed in 128.1 ms
u_avx2 completed in 129.207 ms
Best aligned arch: a_avx2
Best unaligned arch: u_avx2
RUN_VOLK_GNSSSDR_TESTS: volk_gnsssdr_32f_resamplerxnpuppet_32f(8111,1987)
generic completed in 245.054 ms
a_sse3 completed in 102.244 ms
u_sse3 completed in 102.041 ms
u_sse4_1 completed in 89.4185 ms
a_sse4_1 completed in 89.13 ms
a_avx completed in 75.8414 ms
u_avx completed in 77.2551 ms
Best aligned arch: a_avx
Best unaligned arch: u_avx

The GPRMC sentence has a little bug. The Latitude should be 3801.4808

$GPRMC,203857.000,A,381.4808,N,02350.6841,E,0.00,0.00,280317,,*36

If the config file is cut'n'pasted as is on the web page, and then the filename is fixed to point to the correct file, an error occurs:

gnss-sdr --config_file=test2.conf
linux; GNU C++ version 6.2.0 20160927; Boost_106100; UHD_003.009.005-0-unknown

Initializing GNSS-SDR v0.0.8 ... Please wait.
Logging will be done at "/tmp"
Use gnss-sdr --log_dir=/path/to/log to change that.
./example_capture.dat: No such file or directory
The configuration file has not been found.
Please create a configuration file based on the examples at the 'conf/' folder
and then generate your own GNSS Software Defined Receiver by doing:
$ gnss-sdr --config_file=/path/to/my_GNSS_SDR_configuration.conf
GNSS-SDR program ended.

looking at the log file says:

Log file created at: 2016/10/30 11:56:11
Running on machine: scarlett
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
I1030 11:56:11.010908 13734 file_configuration.cc:196] Configuration file test2.conf opened with no errors
I1030 11:56:11.011131 13734 gnss_block_factory.cc:148] Getting SignalSource with implementation File_Signal_Source
I1030 11:56:11.011562 13734 file_signal_source.cc:178] file_signal_source: Unable to open the samples file ./example_capture.dat, exiting the program.

so the output from the command line says the config file couldn't be read but the log file says it was read - which seems very confusing!!

So there are 2 issues:

1. There is a [GNSS-SDR] line missing from the example conf file in the tutorial
2. The handling of the conf file needs a little attention.

Thanks,

Matt

Hello,
if I set a static PRN for a (GPS) Channel, the aquisition still is done for all available channels in a somehow wired order. The channel never checks for its preconfigured PRN.

GPX (GPS eXchange) is used by quite a few GPS-related applications, notably OpenStreetMap, for storing and importing waypoints, routes and tracks. It features a more verbose (compared to KML) XML usage in paths which allows various metadata to be added to individual waypoints, paths and/or files. With GPX output, GNSS-SDR would be able to store useful information, including timestamps, DOP, and altitude in a more machine-friendly way.

Hello,

I am using the latest next branch source code, and my file input is duration 1800 sec. GNSS-SDR completes execution, but starting at 623 sec, I get "error: solve (): solution not found" messages for the remainder of the program.

Are there any known issues with maximum input signal length?

My computer is an Ubuntu 16.04 VM with 4 cores and 8 GB of memory allocated.

Hi, Charles,
I am trying to use CMake to create the project for Eclipse, but it seems fail, the details are as follows,

1. I use the command as follows,

$ cmake -G "Eclipse CDT4 - Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE -DCMAKE_ECLIPSE_VERSION=4.7 -DCMAKE_ECLIPSE_MAKE_ARGUMENTS=-j8 ../

(my CMake version is 3.5.1 , Eclipse version is 4.7.1)

the Warnings are shown as follows:

1.CMake Warning in CMakeLists.txt:
ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT is set to TRUE, but this variable is
not supported anymore since CMake 2.8.7.
Enable CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT instead.

2.CMake Warning in CMakeLists.txt:
The build directory is a subdirectory of the source directory.
This is not supported well by Eclipse. It is strongly recommended to use a
build directory which is a sibling of the source directory.

when I import the project to Eclipse, I find that I can see only a series of cmake files but none of src files and I can not build the project in Eclipse.

it seems that

1. the ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE is not work, but when I change the command what the terminal suggest, i.e. CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE,
   the CMake does work, and the errors are follows:

-- Configuring incomplete, errors occurred!
See also "/home/wu/work/gnss-sdr-master/build/CMakeFiles/CMakeOutput.log".
See also "/home/wu/work/gnss-sdr-master/build/CMakeFiles/CMakeError.log".

2. Will the warning2 affect the project too ?

How can I successfully generate the full functional Eclipse project?

Best regards,
Wu

Minor bug in pcps_acquisition.cc:

if d_bit_transition_flag is set then the constructor forces d_max_dwells to be 1. The value of d_max_dwells in pcps_acquisition.cc is then not consistent with the value of max_dwells_ in GpsL1CaPcpsAcquisition, which is set to either 2 or whatever value is specified in the conf file.

Hello I am using an RTL-SDR.com V3 which has an internal bias-t for powering my active gps antenna. The gnss apps (front-end-call, gnss-sdr) upon startup, they disable the bias-t, causing no gps signals to be found.

I build gnss-sdr from source, with uhd and gnuradio build from source.
I'm using gnss-sdr with my USRPN210 following http://gnss-sdr.org/conf/ .
What's wrong?

I tried to compile gnss-sdr with cmake. I had to to make some changes in the checkout code for gflags and link to another aclocal version to start make under openSUSE 13.1. But in the end i run in a compiler error, and i can't find out what is the cause for this.

My first suggestion is, that i run in a compile error because is used aclocal-1.13 instead of aclocal-1.14. Unfortunately only aclocal-1.13 is available in openSuse 13.1. Is it really necessary to use this version or it is possible to switch the call just to /usr/bin/aclocal instead of ``/usr/bin/aclocal-1.14`

Environment:

• openSUSE 13.1 (Kernel: 3.12.53-40-default)
• cmake (v3.3.2-1.2)
• make (v3.82-160.2.1)
• gnuradio (v3.7.9.2)

Changes:

• automake (v1.13) installed for aclocal-1.14 command => set an link to aclocal-1.13. Also change the link to test-drives
• change gflags git clone git://... to git clone http://... because company firewall is blocking git://

Attachment:

cmake_output.txt
make_output.txt

I'm running Ubuntu 10.4 and because the repositories doesn't provide gnuradio 3.7.3+, I installed gnuradio manually. (Gnuradio 3.7.2 has been installed on the computer before)

But the cmake script still assumes, I have Gnuradio 3.7.2 installed.

sven@sven-desktop:/src/gnss-sdr/build$ cmake ../
...
Found Version
3.7.2.1
-- The GNU Radio version installed in your system is too old.
-- CMake cannot find GNU Radio >= 3.7.3
Go to http://gnuradio.org/redmine/projects/pybombs/wiki
and follow the instructions to install GNU Radio in your system.
CMake Error at CMakeLists.txt:363 (message):
  GNU Radio 3.7.3 or later is required to build gnss-sdr

-- Configuring incomplete, errors occurred!
See also "/src/gnss-sdr/build/CMakeFiles/CMakeOutput.log".

sven@sven-desktop:/src/gnss-sdr/build$ gnuradio-companion --version
GNU Radio Companion v3.7.8.1-297-ga463fecc

This program is part of GNU Radio
GRC comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it.

As mentioned on the gnss-sdr developers list I am using gnss-sdr as a receiver for a (simulated) rocket trajectory from earth to orbit. gnss-sdr fails to calculate PVT above 50km. I figured out what was causing this - in gps_l1_ca_ls_pvt.cc on line 178:

 //ToDo: Find an Observables/PVT random bug with some satellite configurations that gives an erratic PVT solution (i.e. height>50 km)
            if (d_height_m > 50000)
                {
                    b_valid_position = false;
                    return false;
                }

Commenting this block of code out allows for calculations above 50km. I am able to now track a trajectory past 125km but after awhile the PVT starts failing again by generating ridiculously large altitudes (e+15) and lat/lon positions that dance around. I don't know if altitude or velocity is the culprit.

I am able to take the observables' pseudoranges and the trackers' prompt_I and decode both ephemeris and valid lat/lon/alt by post-processing in SoftGNSS, a Matlab-based offline GPS code. So I am pretty well convinced that the correct observables are being generated, and a problem exists in the calculation of the PVT. This is alluded to in the comment to the code block above.

I forked gnss-sdr and am willing to assist in debugging this, but any additional information or insights would be greatly appreciated. Thanks.

philip hahn

The interface of volk_32f_index_max_16u have changed as per gnuradio/volk@cb83e1c . This breaks building if GNSS-SDR is using Volk built from the latest source code snapshot. However, Volk’s master branch version is still tagged as ‘1.2.2’, so there is no way to detect this API change (for instance if Volk was installed through the libvolk-dev package, or from the ‘1.2.2’ tag.)

Hi,

It looks like in v0.0.9, in the Gnss_Synchro class, the Code_Phase_secs property was renamed to Rem_code_phase_secs, but this has not been updated in the GPU enabled tracking loop. Because of this, when compiling gnss-sdr with -DENABLE_CUDA=ON, the following error occurs:

~/pybombs/src/gnss-sdr/src/algorithms/tracking/gnuradio_blocks/gps_l1_ca_dll_pll_tracking_gpu_cc.cc:442:34: error: ‘class Gnss_Synchro’ has no member named ‘Code_phase_secs’

Thanks for checking! #

Hi @carlesfernandez and @Arribas, I'm Francesco, the guy who wrote you by email address. I'm going to post questions here instead of annoying you by email. Sorry if I have written you by direct email message.

The questions that I made you were about performance. Why?
The objective would be to work with it on Windows, because it is more versatile as an operating system and because it is wide used. So, what I did?
First of all, since I was a little bit scared about task scheduling on Windows for future real-time implementations, I modified gnuradio framework to include just the core capabilities to allow the creation and execution of the flowgraph. So I obtained a simplified version of the core system. Afterwards, I decided to test it on Linux to check about real-time performance with my front end (Maxim2769), so I had to handle and work on the gnss-sdr code for generating the appropriate library and for creating the interface to communicate with it.

Then, I made some tests on Linux with the following configuration:

1. Dell mobile PC, Intel core i7, 2.8 GHz, quadcore, 8GB RAM
2. Ubuntu 16.04
3. GPS only, 6 channels, serial search acquisition, pcps fine doppler algorithm, 4MHz sampling frequency

I reported as a result a 20% CPU load (using Intel VTune Amplifier as a bottleneck analysis tool, if needed I can show you some screenshots). So, according to this result, I was wondering if you had the same kind of performance on Linux (or maybe I made some mistakes), and for this reason, thinking to use it in the future on Windows with the proper modifications, I was a bit scared that on Windows it could be worst since the higher CPU load due to the task scheduling.

Best regards,

Francesco

how to install and build on windows? can you give a instruction

Consider change gflags and glog download location.

Hi there,

This is not a problem/issue, but a question. Maybe it is quite simple and the question is stupid (sorry for that if this is the case).

Why are you generating two local versions of the PRN code, one of them inverted?

I mean, if I am not wrongly interpreting the code: You generate the local PRN code at fs, then FFT, then conjugate. So far, so good.

But why are you generating a second local PRN, this time inverted?

Thanks a lot and sorry for bothering!

BR
Fran

I am trying to use both GPS and SBAS satellites. I have tried using the previous conf files (v5/6 has an SBAS conf) as references but I have been unable to successfully track both constellations with the Spain data set.

Through my testing I have noticed that I can only seem to use 1 Telemetry block. I have put an output statement in the init function for the SBAS telemetry and it only prints whenever I set the TelDec_1C.implementation=SBAS...

If I attempt to set TelDec#=SBAS... it never gets initialized.

Is there a working configuration file example for the newest version? master or next will do.

As the sampling rate and/or frequency uncertainty increases the acquisition block becomes the bottleneck in performance. This is a problem for real time operation with Galileo (at least 5 Msps) or with front-ends with poor oscillators (like the HackRF, which has a 10 ppm oscillator, leading to a frequency uncertainty in the +/- 15 kHz range).

The idea is to modify the pcps_acquisition_cc block so that the bulk of the work is done in a separate thread. A new parameter blocking is passed at construction, if this is true the behaviour is as normal, if its false then the acquisition block skips over samples that arrive while the processing thread is busy. The default value is true, as the existing implementation is blocking.

This I think is what the pcps_multithread_acquisition block was designed for, but this never worked for me. This implementation has a couple of advantages in that it re-uses the existing pcps_acquisition_cc block and it uses standard C++11 threading concepts.

The disadvantage of this approach is that we introduce yet another thread, with the associated overhead that comes with that. However, I've found that this enables real-time operation that would otherwise not be possible as all threads are held up waiting for the acquisition block to process.

I've pushed a working implementation to my fork here. Comments are welcome.

Hello,
I'm currently trying to use the version in "next" branch.
After using it a while it seems that the performance significantly decreased in comparison to the 0.0.6 release.

For example, on a machine with a Core i7 CPU and a X300 USRP I was able to easily run 8 channels in parallel. There were no (or negligible amount of) overflows ("O") or drops ("D") on the USRP/Host.
Now, after updating to the "next" branch (commit: 31ae25c), I get lots of drops on the host and, in addition, the tracking algorithm seems to perform worse than before which leads to no or only sporadic position fixes.

I'm using the multichannel X300 realtime config with 8 channels (4 on each subdevice), all set to GPS L1 tracking with PCPS acquisition.

Regards,
Jan

dh_auto_test is a debhelper program that tries to automatically run a package's test suite. It currently fails.

Error:

cd /Users/chenjack/temp/gnss-sdr/build/volk_gnsssdr_module/build && /usr/local/Cellar/cmake/3.3.0/bin/cmake -DCMAKE_C_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DCMAKE_CXX_COMPILER=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DCMAKE_INSTALL_PREFIX=/Users/chenjack/temp/gnss-sdr/build/volk_gnsssdr_module/install -DENABLE_STATIC_LIBS=ON -DPYTHON_EXECUTABLE=/opt/local/bin/python "-GUnix Makefiles" /Users/chenjack/temp/gnss-sdr/src/algorithms/libs/volk_gnsssdr_module/volk_gnsssdr
CMake Error at cmake/GrPython.cmake:105 (file):
  file FILE([TO_CMAKE_PATH|TO_NATIVE_PATH] path result) must be called with
  exactly three arguments.
Call Stack (most recent call first):
  CMakeLists.txt:59 (include)


-- Python checking for python >= 2.5
-- Python checking for python >= 2.5 - not found
-- Python checking for Cheetah >= 2.0.0
-- Python checking for Cheetah >= 2.0.0 - not found
CMake Error at CMakeLists.txt:64 (message):
  Python 2.5 or greater required to build VOLK_GNSSSDR

PYTHON_EXECUTABLE is defined here: