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).
|
|
||||
|
|||||
|
|||||
|
|||||
|
|||||
|
|
||||
|
|
||||
2. RTL-SDR
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:
|
|
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
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
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.
https://rapidshare.com/files/558977948/20120415_1714BST_fs2048_iq8.001.dat
https://rapidshare.com/files/2431212520/20120415_1714BST_fs2048_iq8.002.dat
https://rapidshare.com/files/4187716662/20120415_1714BST_fs2048_iq8.003.dat
https://rapidshare.com/files/107864226/20120415_1714BST_fs2048_iq8.004.dat
https://rapidshare.com/files/4187716662/20120415_1714BST_fs2048_iq8.003.dat
https://rapidshare.com/files/107864226/20120415_1714BST_fs2048_iq8.004.dat
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:
http://gnss-sdr.ru/index.php?blogid=2
http://en.qi-hardware.com/wiki/GPS_Free_Stack
http://blog.goo.ne.jp/osqzss/
Stay tuned, GNSS is evolving rapidly!
37 comments:
Nice.
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.
Guido
Why did you remove my comment?
It was in topic IMHO.
Hi Zibri,
Allow me to disagree. This is my technical blog, not a compatibility list. Please refer to the official one here:
http://www.reddit.com/r/RTLSDR/comments/s6ddo/rtlsdr_compatibility_list_v2_work_in_progress/
All the best,
Michele
Guido,
I uploaded a simple Matlab (or Octave) acquisition script here:
http://www.onetalent-gnss.com/downloads/20120414_rtl-sdr_matlab-gnss.7z
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.
Ciao,
Michele
Michele,
Thanks for your help. Have the code running now and observe similar results, very impressed by your experiment.
Guido
Hi there,
you can find another open source receiver here: http://gnss-sdr.org
Best regards,
Carles.
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?
Cheers,
Michele
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.
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
http://www.sparkfun.com/products/8254
will work just fine.
Michele
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:
http://www.cttc.es/document/d4d8be473170ab0301328c3780ef0041/publications-copyright.jsp
Again, thanks for your interest and for maintaining this amazing blog!
Best regards,
Carles
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.
Guido
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:
http://www.reddit.com/r/RTLSDR/comments/rqrwo/quality_comparisons_can_anyone_help_us_build_a/
and I am hoping for feedback from the developers team.
All the best,
Michele
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
% SEEK THE FILE POSITION
fseek(fid, round(fs*1.0+fs*time*0.01), 'bof');
...
end
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.
Regards,
Guido.
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:
https://rapidshare.com/files/558977948/20120415_1714BST_fs2048_iq8.001.dat
Cheers,
Michele
hello,
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...
best
-Magnus
Hi Magnus,
You don't need specifically a MCX.. maybe a SMA or TNC bias tee is easier to source?
Any luck with this?
http://www.rfsupplier.com/advanced_search_result.php?keywords=dvb+adapter&x=0&y=0
Cheers,
Michele
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?
-Magnus
Hi Magnus,
I cannot help further: this is off-topic. Please refer to the rtl-sdr official support website.
Best regards,
Michele
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.
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.
-Adam
@justafire:
it's not a HD bottleneck (at 5MBytes/sec) but thanks for suggesting
@Adam:
I uploaded a short capture of NV08C-CSM output here:
https://rapidshare.com/files/3407033565/120505_base.nvs
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:
http://www.navis.ru/images/content/Docs/NAVIOR-24S-Reference_Manual.pdf
Please get in touch with NVS for more details, they are really friendly and responsive.
Cheers,
Michele
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?
Regards,
Jefferson.
My e-mail contact:
jeffersonlferreira@yahoo.com.br
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?
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.
Cheers,
Michele
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
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
http://www.gnss-sdr.org/documentation/gnss-sdr-operation-realtek-rtl2832u-usb-dongle-dvb-t-receiver
Visit http://www.gnss-sdr.org for more information about the GNSS-SDR project.
Enjoy!
The GNSS-SDR Team.
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;
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,
Ravi
Hola Ravi,
Pictures speak more than a thousand words:
http://picasaweb.google.com/111166516525827756469/RTL2832UR820T
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.
Cheers,
Michele
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.
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?
Regards,
Ravindra H J
Hi, Michele, I have it working too!
http://panteltje.com/pub/run_50_outside_2728000.gif
4000 tuner, GPS 'mouse' from ebay, made a small T section with a LM317 at 4.75 V:
http://panteltje.com/pub/GPS_antenna_T_power_section_IMG_3790.GIF
(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 :-)
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.
These guys of osmocom are smart and -what's even better- their work with the ... smarttvnachruesten.blogspot.de
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.
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!
Bests,
Mic
Post a Comment