Tuesday, April 10, 2012

Spring news in the GNSS and SDR domain

I have been following in the last few days interesting developments in the GNSS and SDR domain.

1. NV08C-CSM and dual constellation RAW measurements

It's recent news that NVS has lifted the constraints on the firmware with RAW data for GPS and Glonass on L1. In my opinion this is one of those rare times that the rules of the game are changed by one of its players.
Essentially the NV08C-CSM provides real-time kinematic capability at 10Hz, with a price point as low as 35EUR/piece in small quantities. It is already possible to download an unofficial version of RTKNavi.exe and RTKConv.exe here, but RTKLIB will officially support the receiver from next version anyway.
Below are some pics of what Denga10 and the navXperience 3G+C could do with the good old 2.4.1 "Static Precise Point Positioning" over three hours.. bringing down the error to less than 20cm in complete standalone mode (by using only broadcast products).

Rtknavi (NVS mod) doing static PPP with 14 sats

Rtknavi (NVS mod) available satellite close-up

Glonass broadcast navigation data

GPS broadcast navigation data

GPS/Glonass observations.. 21!

Satellites used in the fix

From cold start, first three hours, ground track
From cold start, first three hours, position

From cold start, third hour, ground track

From cold start, third hour, position

The likes of Novatel, Trimble, Hemisphere, etc are not going to like it I suppose. On the other hand, users have perhaps a cheaper option to enter the high-precision domain.


For once, the group of innovators is European.
These guys of osmocom are smart and -what's even better- their work with the open source team. RTL-SDR is, I believe, one of the freshest finds in the Software Defined Radio domain. The Fun Cube Dongle, developed in UK, is already a very clever tool. But finding the super-tuner Elonics E4000 (note, again a UK Company) in 25$ USB DVB-T dongles and being able to grab data in a 3MHz bandwidth between 64MHz and 1.7GHz... that is really cool.

I had to buy one! ...actually two before I found the E4000..
A Terratec Cinergy T Stick Black rev.1, with the FC0012 which is not suitable for GPS
A Newsky TV28T, with the E4000.

The Realtek RTL2832U demodulator uses a 28.8MHz crystal by default.. which has too poor accuracy for a GPS receiver.. but a SDR acquisition algorithm can easily handle 100+kHz of apparent Doppler shift in the frequency search :)
So for a nominal sky plot as the one below:

And a signal looking like as follows:

Power spectrum around GPS L1, FS=2.728MHz
The ADC is saturated.. the gain I set was too high.

I could acquire the following birds:

SV 9: Doppler +112000.0 CodeShift:     99 xcorr: 553566.6
SV12: Doppler +113500.0 CodeShift:    502 xcorr: 301126.3
SV15: Doppler +110000.0 CodeShift:   1847 xcorr: 871305.9
SV17: Doppler +110500.0 CodeShift:   2225 xcorr: 401100.6
SV18: Doppler +110000.0 CodeShift:     38 xcorr: 368766.1
SV26: Doppler +107000.0 CodeShift:   1779 xcorr: 511844.4
SV27: Doppler +110500.0 CodeShift:    264 xcorr: 650033.9
SV28: Doppler +107500.0 CodeShift:    203 xcorr: 320405.6

The next step is to have my new version of GPS-SDR processing the data in real-time.. won't be long!
I managed to upload the binary file which is long enough for everyone with a SDR receiver to calculate the position. I used FS=2.048MHz and a nominal IF of 0.0Hz (but because of the crystal inaccuracy the IF actually falls at about 110kHz). The data type is I&Q interleaved int8_t.


3. Open source FPGA receivers

I waited too long for the code from the University of Tampere: they were promising to licence the TUTGNSS and never happened.
Finally the Open Source community is bringing to the reality an Open Source FPGA implementation of a GPS receiver based on the Namuru / Zarlink GP2021 correlator structure and soft CPU cores (the LatticeMico32 Milkymist and the Altera NiosIIe). As also scientists at the University of Tokio (remember RTKLIB?) are involved, this time I know it is going to happen.
Some useful links:

Stay tuned, GNSS is evolving rapidly!


ltx4096 said...


threeme3 said...

Hi Michele,
Trying to decode the .dat files with gps-sdr/primo/octave/visibility_gps.m. Understand that this file needs to be changed to handle the complex data. Any chance to share this modified file?
Thansk for the good work.

Zibri said...

Why did you remove my comment?
It was in topic IMHO.

Michele said...

Hi Zibri,

Allow me to disagree. This is my technical blog, not a compatibility list. Please refer to the official one here:


All the best,

Michele said...


I uploaded a simple Matlab (or Octave) acquisition script here:


You may try on your PC by calling:

visibility_gps('20120410_1721bst_rtlsdr.001.dat', 2.728e6, 0.0, 1, [1:32])

Where the first parameter is the file name, the second the sampling frequency in Hz, the third the Intermediate Frequency, the fourth the file type (0: real, 1: interleaved I&Q), and the last the list of satellites to search for.

Please note that the frequency search space is very wide (400kHz) so it does take some time to go through the whole constellation.


threeme3 said...

Thanks for your help. Have the code running now and observe similar results, very impressed by your experiment.

Unknown said...

Hi there,

you can find another open source receiver here: http://gnss-sdr.org

Best regards,

Michele said...

Dear Carles,

I am aware of gnss-sdr.org at CTTC but thanks for the link.

I see that you are the maintainer so maybe you could clarify what are the main features of gnss-sdr?
Also, a side by side comparison with other OS receivers such as osgps and indeed gps-sdr would be very appreciated.. maybe you have a link to refer to already?


threeme3 said...

Hi Michele,
May I ask you what antenna was used or if any special receiver settings applied for creating the signal files? Now trying to make my gps signal files with rtl-sdr/gr-baz on 1575.42MHz@2.728MSPS with a 1/4 labda antenna, seeing the same spur at 1574.4MHz (about 10dB stronger as yours on my Hama Nano), but not yet a decode.

Michele said...

Am I right understanding that you are using a linealy polarised antenna to receive GPS? A linear antenna is not as good as a RHCP antenna to receive GPS.
Is is your antenna passive? If yes it won't work for at least two reasons:
1) the overall gain may be too low
2) the noise figure of the receiver may be too high (you need a LNA before the E4000).

I used a very expensive 3G+C antenna from navXperience powered with a bias-tee
but I am ready to bet that a simple active 10$ antenna like
will work just fine.


Unknown said...

Dear Michele,

thanks for your interest. GNSS-SDR is an open source project developed in the framework of a couple of MS Theses. It is based on GNU Radio, a very nice framework for software radio that allows to build your own signal processing blocks and connect them in a very efficient way. Samples are passed through the processing chain via shared memory (in contrast to named pipes, as is the case of gps-sdr), and in my opinion this makes the software more scalable, since all the complex scheduling is handled by GNU Radio. We just rely on people that are much more experts than us on these matters! ;-)

At this moment, GNSS-SDR provides code-based PVT solution for GPS L1 C/A. The intention is to more forward and work on the Galileo and Compass signals along this summer, as well as working on carrier phase based navigation. I'm trying to get some funding in order to secure some amount of hours devoted to the project. Beside this, the current developers are very enthusiastic, and we are spending a lot of our "spare time" to the code, and the project is actively growing these days.

At this moment, I cannot refer any link with a sound comparison to osgps or gps-sdr. Actually, it would be an interesting exercise to do when we reach a little bit more of maturity (or at least stability in the core receiver API) of our code. For a high level description of the software receiver architecture, please check:


Again, thanks for your interest and for maintaining this amazing blog!

Best regards,

threeme3 said...

Hi Michele,
Thanks for your response. Hooked up a simple active GPS antenna to the DVB-T stick via a bias-tee (connecting antenna to 5v usb supply via 1uH inductor and to receiver via 300p capacitor, where 5v has 10nF cap to ground) and performed a 10sec capture with sudo rtl_sdr -f 1575420000 -g 40 -s 2728000 out.dat
The results are successful now, detected 6 sats with similar strengths (~6e+5) and IF frequency offset of about 53kHz for my Hama Nano. Saturating the ADC does not seem to degrade the performance much.
So yes... you won the bet, can we have a drink somewhere?
Thanks again for sharing this interesting experiment with us.

Michele said...

Dear Carles,

Thanks a lot for giving some references, let us keep in touch.

Dear Guido,

Great to know that you managed to acquire GPS too: I feel less lonely! A small remark: an inductor of 1uH can have a fairly low self-resonance frequency which decreases its performance as bias-tee and imply a -3dB loss at the front-end. The active antenna will anyway have enough gain to compensate this.

This morning I noticed a big problem with the consistency of the stream.. seems like the RTL2832U did not deliver continuous samples and the acquisition at 10ms intervals shows missing data. I don't know if this is a librtlsdr problem or just my fault. I explained the issue here:


and I am hoping for feedback from the developers team.

All the best,

threeme3 said...

Good afternoon Michele,
Trying to reproduce your findings of missing samples. Now with the latest asynchronuous rtl-sdr code doing acquisitions every 10ms, and here are my results:

time: 110.000000 Doppler -54000.0 CodeShift: 2240 xcorr: 340181.6
time: 120.000000 Doppler -54000.0 CodeShift: 2241 xcorr: 415809.9
time: 130.000000 Doppler -54000.0 CodeShift: 2241 xcorr: 378127.7
time: 140.000000 Doppler -54000.0 CodeShift: 2242 xcorr: 369713.8
time: 150.000000 Doppler -54000.0 CodeShift: 2242 xcorr: 340619.3
time: 160.000000 Doppler -54000.0 CodeShift: 2243 xcorr: 390668.7
time: 170.000000 Doppler -54000.0 CodeShift: 2243 xcorr: 354459.4
time: 180.000000 Doppler -54000.0 CodeShift: 2244 xcorr: 391096.7
time: 190.000000 Doppler -54000.0 CodeShift: 2244 xcorr: 386770.2
time: 200.000000 Doppler -54000.0 CodeShift: 4973 xcorr: 383737.1
time: 210.000000 Doppler -54000.0 CodeShift: 2245 xcorr: 415895.6
time: 220.000000 Doppler -54000.0 CodeShift: 2246 xcorr: 367252.1
time: 230.000000 Doppler -54000.0 CodeShift: 2246 xcorr: 387644.2
time: 240.000000 Doppler -54000.0 CodeShift: 4975 xcorr: 352409.6
time: 250.000000 Doppler -54000.0 CodeShift: 2247 xcorr: 372458.4
time: 260.000000 Doppler -54000.0 CodeShift: 2248 xcorr: 348135.4
time: 270.000000 Doppler -54000.0 CodeShift: 2248 xcorr: 359322.3
time: 280.000000 Doppler -54000.0 CodeShift: 2249 xcorr: 353555.9

It seems that there is a 2nd spike in the maxcorr vector which for some reason in some cases is stronger, resulting in the codeshifts >3000. I cannot reproduce the jumps every 50ms. In order to do an acquisition every 10ms I have modified the fseek section:

for time=1:1000; % time is ms
fseek(fid, round(fs*1.0+fs*time*0.01), 'bof');

Any ideas how I can reproduce your finding? I am using: Linux ubunt 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 17:34:21 UTC 2012 i686 i686 i386 GNU/Linux and libusb-1.0, all running in VMware player.


Michele said...

Hi Guido,

Yeah I have done a similar thing.

Moreover, I just run the test today with the latest code. I used aynch libusb as well. At 2.728Msps the stream is broken, but at 2.048Msps is perfectly fine.

2.048Msps is just enough for GPS so I think I will leave the broken stream problem to the maintainers of rtl-sdr for now.
Another thing I noticed: the 2.728M value is not achievable exactly setting the RTL2832U register, so maybe it's just an unlucky choice.

I started to upload a 2.048Msps file and I will edit the blog post when I am done. In the meantime, this is the first link:



Unknown said...


Do you think it is possible to find an iec to mcx converter and use between the dongle and a gps antenna? I can not find a dongle with mcx connector in my area...


Michele said...

Hi Magnus,

You don't need specifically a MCX.. maybe a SMA or TNC bias tee is easier to source?

Any luck with this?



Unknown said...

Hi again,

The thing is i have a receiver-dongle with a pal connector. I'm unsure about the name of the connector but it looks like the connector on the picture in your blog post above for the "Terratec Cinergy T Stick Black"-dongle. I tried to look thru the site you linked but I still can not figure out what gps antenna + connectors is most suitable for my receiver. Is it even possible?


Michele said...

Hi Magnus,

I cannot help further: this is off-topic. Please refer to the rtl-sdr official support website.

Best regards,

justasfire said...

Hello Michele,

Firstly thank you for your great article and for posting your matlab simulation + gps data.

Regarding the drop of samples which you said you encountered, maybe it is related to a hdd bottleneck.

You could check this by writing the samples directly into the ram and not on the hdd.
You could do this by creating a ramdisk.
In linux make sure to create a ramfs partition and not tmpfs, since tmpfs could also allocate swapspace which is located on the hdd. Also make sure you have enough ram available, ramfs might give you trouble otherwise.

Adam said...

Hi Michele,

Thank you for this great blog! Would it be possible to post an example raw data file from the NV08C-CSM so I can try out PPP with it? Also, where can you get documentation on the BINR format? Mr. Google has practically zero hits on the format spec and Tomoji Takasu's blog suggests there was an NDA in place before.


Michele said...

it's not a HD bottleneck (at 5MBytes/sec) but thanks for suggesting

I uploaded a short capture of NV08C-CSM output here:


You could use RTKCONV found on Denga10 webpage to decompress it in Rinex format.
I am not sure I can distribute the BINR specification, but a lot is in common with this:


Please get in touch with NVS for more details, they are really friendly and responsive.


Jefferson said...

Hi Michele,
I'm developing a Android software to use with GPS and I need sub-meter accuracy.
Unfortunately, I didn't find a low cost GPS device with USB interface yet.
I'd saw U-BLOX NEO-6P, that delivers this accuracy, but, it's developer kit is very expensive.
Fortunately I found this forum.
Maybe your project can fulfill my needs.
My first idea is to connect to the GPS device via USB and receive it's data in NMEA format.
Is this possible with your project?
May you send me more information about you projects?



Jefferson said...

My e-mail contact:

ltx4096 said...

Hi Michele,

I've acquired a device with the E4000 tuner and have been able to record and acquire GPS satellites but I am unable to track them. With the files you uploaded my software GPS receivers are unable to track them as well (Kai'Borre and NordNav).

I suspect the data stream from the device still isn't reliable enough for GPS signal tracking, have you had any luck with tracking since your last post?

Michele said...

Hi ltx4096,

May I know your name? It is good to know someone who shares my interests.

I have the same experience as you have. At 2048msps the stream is consistent so I can acquire GPS reliably.. but not track it.. at least not with the GPS-SDR code.
I would bet that a more customised SW receiver could.
In fact the Nordnav receiver should be flexible enough to tune the tracking loops bandwidth to tolerate almost any oscillator.

Apart from the XO, I don't see why we would not be able to track.
Unfortunately I have little time to experiment with these things.


Unknown said...

Hello there from Russia ;-)

Just a head's up on my experiments with your MatLab GPS detector:

I took e4000 SDR, changed antenna connector to SMA, modded vanilla Chinese active GPS antenna to be battery-powered (so that there is less stuff in RF path).

After trying several gain settings (optimal for me appeared to be in 27-34dB range), was able to detect 4 GPS sattelites which matched ones visible from my window by usual receiver.

Great work, looking forward for any progress on that :-)

-- Michail

Javi said...

Dear GNSS enthusiasts,

The team of developers of the open source project GNSS-SDR proudly announces that the latest version of our GNSS receiver supports the realtime operation using RTL-SDR compatible dongles.

We achieved GPS position fix with what is probability the cheapest GPS receiver ever made. If you have a RTL2832U based compatible DVB-T receiver you can have also a GPS just adding an active GPS antenna and our free GNSS software.

All the details can be found in this article


Visit http://www.gnss-sdr.org for more information about the GNSS-SDR project.


The GNSS-SDR Team.

Anonymous said...

Hi Michele,

I'm experimenting with RTL-SDR and this post is interesting. Thanks.

I think the reason your histogram has most values at the extremes is that you are reading the data as signed int8 when it's actually unsigned int8 with an offset.

The correct way to read the data in MATLAB is something like this:

signal = fread(fid, [2 round((0.007)*fs)], 'uint8');
signal = signal(1,:) - 128 + 1i*signal(2,:) - 128i;

Ravi said...

Hi All,

I purchased RTL SDR with R820T tuner. I also ordered a Active GPS L1 antenna from eBay with following features:
Gain : 28dBi
voltage: DC 3-5V
Connector: MCX male right angle
Impedance: 50 Ohm

I did a project on SW based GPS L1 receiver as part of my M.Tech thesis.

I wanted to continue this work to dual frequency and carrier phase techniques.

Since the GPS L1 active antenna needs a Bias-T, i need help in buying or making one.

Kindly let me know good Bias-T design for this application.

Basically i am looking to dump the IF data from the dongle and then try to process it.

Thanks and regards,

Michele said...

Hola Ravi,

Pictures speak more than a thousand words:


Also read the picture captions please.

I am afraid R820T has a 75 Ohm input so ideally it would be better to add a lossy matching pad on the RF line.. another day.


P.S.: It's nothing new: the R820T works well for GPS reception. I could recently acquire and track the constellation with a normal (not high sensitivity) software GPS receiver.

Ravi said...

Hi Michele,

Thanks for guiding on the bias T.
In your previous comment, you discussed on call to "visibility_gps". Can you explain me why this intermediate frequency is 0.0 in it?

Ravindra H J

Panteltje said...

Hi, Michele, I have it working too!

4000 tuner, GPS 'mouse' from ebay, made a small T section with a LM317 at 4.75 V:
(1nF coupling and about .3 uH inductor).

Had to hang the GPS receiver out a window to get any usable signal,
As it was now horizontal pointing probably more sensitive in that direction.
This is what my GPS module told me was in the air:

satellites used 5 ( 7 20 4 13 8 )
satellites in view 12
id 13 * elevation 69 azimuth 68 snr 27
id 10 elevation 63 azimuth 286 snr 0
id 4 * elevation 48 azimuth 221 snr 23
id 2 elevation 43 azimuth 287 snr 0
id 23 elevation 43 azimuth 69 snr 0
id 7 * elevation 40 azimuth 166 snr 32
id 16 elevation 15 azimuth 65 snr 0
id 30 elevation 14 azimuth 38 snr 0
id 8 * elevation 14 azimuth 182 snr 19
id 20 * elevation 10 azimuth 120 snr 23
id 5 elevation 10 azimuth 294 snr 19

So 7 and 8 at low elevation made it :-)
Thank you very much for this cool idea :-)

Unknown said...

Hi, Michele,

I am a new player for the rtl-sdr. I could not download the data file in the rapidshare link. Have you deleted it ever? Thank you for your attention.

Ingwer said...

These guys of osmocom are smart and -what's even better- their work with the ... smarttvnachruesten.blogspot.de

Unknown said...

Hello everyone,

Is there any one who is capable of receiving Galileo Signals using NV08C-CSM
(Hardware V4.1 1213)??

I also updated the current (Firmware version 0408) but i still could not be able to receive Galileo signals.

Please help.

Michele said...

I already mentioned elsewhere that one needs a special FW from NVS in order to acquire and track Galileo signals. The latest stock firmware will not do.
Please contact NVS!