Tuesday, May 20, 2014

Galileo RTK with NV08C-CSM hw 4.1

Being European I am often subject to skepticism about Galileo and compelled to justify its delays and usefulness. Explaining why Galileo is better and needed is beyond the scope of my blog but IMHO there is one key selling point that not many people stress.

Galileo was designed from the ground up in close collaboration with the USA: GPS and Galileo share L1 (1575.42 MHz) and L5/E5a (1176.45 MHz). In the future, a dual frequency GPS+Galileo L1/L5 receiver will deliver products with an incredible ratio between (performance+availability)/silicon.
According to scheduled launches there could be 12+ satellites supporting open L1+L5 by the end of this year already.
In the meantime, NVS touches base first in the mass-market receiver domain by delivering consistent carrier-phase measurements for GPS+Glonass+Galileo.

I have recently run zero-baseline double-differences in static, perfect visibility conditions using a high-end survey antenna:
Figure 1: Galileo double differences in static zero-baseline (NV08C-CSM hw4.1)
Using E11 as reference, the carrier phase noise is well contained within 0.01 circles (2mm).
With RTKLIB I run a Galileo-only static IAR and the result is as expected:

Figure 2: Static IAR with Galileo only (4 IOVs)
The combined GPS+Galileo static IAR looks like this:

Figure 3: Static IAR with GPS+Galileo
Note the 12 satellites above the 10° elevation mask used in the computation of carrier ambiguities :)

Understandably, Skytraq is working on GPS+Beidou carrier phase and I may publish some results on that too although visibility of Beidou MEOs is not great from here.

In the meantime, for people who wonder where uBlox NEO6T stands in terms of GPS carrier phase noise in similar conditions to the above here it is my result:
Figure 4: GPS double differences in static zero-baseline (uBlox NEO6T)
Which shows similar noise levels to NV08C-CSM.

Monday, May 12, 2014

GNSS carrier phase, RTLSDR, and fractional PLLs (the necessary evil)

A mandatory principle when processing GNSS -in order to have high accuracy carrier phase- is to have a well defined frequency planning. This entails knowing precisely how the Local Oscillator (LO) frequency is generated.
With RTL-SDR it is not a trivial task given that both R820T and RTL2832U use fractional Phase Locked Loops (PLLs) in order to derive respectively the high-side mixing frequency and the Digital Down Conversion (DDC) carrier.
I guess most people use RTL-SDR with a 50ppm crystal so the kind of inaccuracies I am going to describe are buried under the crystal inaccuracy ..within reason.

Let us start from the common call

> rtl_sdr -f 1575420000

This means "set to 1575.42 MHz" but what is hidden is:
1) R820T, set to 1575.42e6 + your IF
2) RTL2832U, downconvert the R820T IF to baseband
.. there are approximations everywhere.

Now, the R820T has a 16 bit fractional PLL register meaning that it can only set to frequencies multiple of 439.45 Hz (exactly).
Instead, the RTL2832U has a 22 bit fractional PLL register meaning that is can recover IFs in steps of 6.8665 Hz (exactly).
Of course, nor 1575.42e6, nor 3.57e6 are exact multiples of either frequency so one always ends up with a mismatch between what he/she thinks he has set, and what really ends up with. Most of the times, this is fine. For GNSS it is not since carrier is accumulated over long intervals and even a few tenths of Hz will make it diverge from the truth.
So I went down the route of characterising the necessary evil of fractional PLLs.

The first test I did was to set the tuner to 1575421875, which leads to a -1875 Hz center frequency but is nicely represented in 16 bits using a 28.8 MHz reference (remember the R820T). In fact, 54 + 0.7021484375 = 54 + [1011001111000000]/2^16. ..ok well actually it fits on 10 :)

Here I found a small bug in the driver  and replaced the following messy (IMHO) code: 

/* sdm calculator */
while (vco_fra > 1) {
    if (vco_fra > (2 * pll_ref_khz / n_sdm)) {
        sdm = sdm + 32768 / (n_sdm / 2);
        vco_fra = vco_fra - 2 * pll_ref_khz / n_sdm;
        if (n_sdm >= 0x8000)
    n_sdm <<= 1;


mysdm = (((vco_freq<<16)+pll_ref)/(2*pll_ref)) & 0xFFFF;

Then I modified the IF of the R820T from 3.57 MHz to 3.6 MHz, as it is only a few kHz away and it is nicely represented on 16 bit  ..ok well it actually fits in 3 :)
Modifying the IF also impacted the RTL2832U fractional register of course.
I still had a significant error (about 115 Hz) which I could measure comparing the scaled code rate and the carrier rate (which should be proportional of a factor 1540).
After a long time wondering what could be happening, I decided to start tweaking the bits of the R820T.
One in particular called PLL dithering seemed suspicious. Disabling it kind of doubled the error to about 220Hz. Sad.. but I did recall now the resolution of the tuner (439.45 Hz) and guessed that there is a hidden 17th bit which toggles randomly when "dithering" and is instead fixed to 1 when "not dithering". A couple of references which could explain why are here:

How sneaky! But I could nicely recover that 17th bit with the RTL2832U (which has 22).
So I have now rock-solid code-carrier assistance ^_^
Figure 1: Code-carrier mismatch when tracking a satellite with RTL-SDR
One step closer to integer ambiguity resolution?


Monday, March 24, 2014

R820T with 28.8 MHz TCXO

I recently looked around for tools to use as low cost spectrum scanners, being the objective frequency range 400 MHz to 1.7 GHz (incidentally, DVB-T and GPS).
Of course rtl-sdr is an attractive option so I dusted off some dongles I had bought 6 months ago in China and played again with them, coming to the conclusion that I really like it especially after its main limitation is overcome :)

The 28.8 MHz crystal is quite poor. I asked Takuji for a TCXO but he said he emptied his stock rapidly. Of course a replacement is nowhere to be found on the big distribution (Digikey, Mouser, Farnell, RS, etc..), so I went to an old time acquaintance at Golledge and, despite having to order 100 pieces, my request was fulfilled. After all, dongles look quite good with the new crystal:
Figure 1: RTL-SDR with 28.8 MHz TCXO (Golledge GTXO-92)

I measured the frequency deviation with my simple GPS software receiver and I happy to report that it is within spec, bounded to 2ppm. By the way, I tried using other GNSS software receivers and will write about my experience in another post soon.

On the frequency plan side, the R820T combined with the RTL2832U is great for GPS. Most people would use it with an active antenna, where the LNA solves the problem of losses due to the impedance mismatch (50 against 75 ohm) and the noise figure of the tuner (3.5 dB according to datasheet).
The frequency plan with an IF of 3.57 MHz solves elegantly the problem of LO feedthrough and I/Q unbalance typical of ZIF tuner. The IF is recovered automatically in the digital domain by the demodulator so it does not appear in the recorded file. 8bit I/Q recording at 2.048 Msps is more than sufficient for GPS and I also tracked Galileo E1B/C with it (despite some obvious power loss due to the narrow filter band). In my tests, I used a Dafang technology DF5225 survey antenna and the signal time plot shows that 5 bits are actually exercised. I powered the antenna with 3.3V from a Skytraq Venus8 (Ducat10 with S1216F8) through an all-by-one DC blocked passive 4-way splitter/combiner (6 dB unavoidable loss) from ETL-systems.

Figure 2, 3 and 4: Power spectrum, histogram, and time series at L1.

I posted three GPS files here:

Since someone asked for it, here are the tracking results of Galileo E19 plotted after the fact with Matlab:

and Galileo E20:

More to come later,

Sunday, December 29, 2013

Wrapping up 2013 GNSS facts

Well, it has indeed been quite a long time since I wrote here the last time.
My personal situation has changed in such a way that it is hard to find the time to share my views and to comment your feedback on current advances in the GNSS R&D domain.
However I feel like dropping here an "end of the year" summary which serves more as a memorandum to me that anything else.
I might be challenging this article
but 2013 has not been a very good year for GNSS.
At least someone generally agrees:

Mass market receivers for low cost RTK
Lately there was one more item on the acquisitions list:
The above shows how aggressive this market is and leaves just a few players on the field.
Some of them, such as Intel, Qualcomm and Broadcom don't really sell to private and just target device manufacturers. Others have shelves as well and those are the most interesting for people thinkering with GNSS of course.
In no particular order:

Early in 2013 Mediatek announced MTK3333. This powerful true dual constellation receiver can be found in many modules (for example by Locosys and GlobalTop. Although impressive, it does not seem to offer pseudoranges or carrier phase at the moment.

IMHO, uBlox has a confusing roadmap with 6th generation modules overlapping with 7th generation and now apparently 8th generation. I design with uBlox modules and it is a little awkward to tell my customers that modules already advertised for are due for release in 6 months. The Company has done an aggressive marketing of a "PPP" technology that has nothing to do with Precise Point Positioning, but rather with carrier phase smoothing. uBlox still manages to sell navigation modules which are not true dual constellation but either one or the other constellation. Their "P" and "T" modules have well established pseudorange, carrier phase and more measurements for GPS.

STM has released in 2013 the TeseoII true dual constellation IC. The STA8088FG is 7x7 mm and is very capable. Pseudoranges can be obtained with some firmware, but never carrier phase. Carrier phase is rumored to be available in Teseo3, which is to be released next year. STM is more open to Galileo than any other Company, but it is weird to find their GNSS products under "Automotive Infotainment and Telematics" category.. not that STM website is an easy one to navigate anyway.

NVS continued to innovate in 2013 by releasing new FW for their NV08C-CSM and -MCM modules. However, after the press release of compatibility with the popular precision navigation software RTKLIB, they went quiet. By the way, I wrote the support driver for their receiver into RTKLIB but never received a mention.. you are welcome. Next year NVS will release a new hardware revision of their modules, but nothing is told about changes to expect against the current. I have high expectations :)

Geostar Navigation
This Company was pretty new to me and came as a surprise in 2013. It offers a true dual GPS+Glonass receiver module. In my opinion has still to improve in terms of reliability but the preconditions are all good (website is updated often so at least the Company seems well up and running). Rumors want Geostar-Navigation to release a pseudorange and carrier phase capable firmware (for GPS at least) very soon.

Furuno came back in 2013 with a true dual constellation chipset called eRideOPUS 7 and module called GN-87F. The Company has expressed interest in releasing Galileo compliant firmware soon and the chip seems to be able to output pseudoranges, but not carrier phase.

CSR has finally delivered a new standalone receiver IC, the SiRFstarV 5e. I bought the Telit Jupiter SE868 V2 (quite a mouthful) evaluation kit from Rutronik. I still did not have a chance of testing it out in real environment but it does track simultaneously GPS, SBAS and Glonass. The chip seems to be very swift and surely has best in class power consumption, but SiRF already departed from raw measurements path with their 3rd generation so I would not expect them to be back on that track now.

Last but not least, Skytraq was among the first ones to release a true dual constellation chip and module with the intention of supporting raw measurements. I bought some S4554GNS-LP back in 2011 already. Since then the Company has made a great progress in integration and quality of modules. The latest generation, the Venus8, has GPS 50Hz measurements, or GPS+Glonass at 20Hz. As all new modules comply with the uBlox NEO format, I already had a chance of integrating some S1216F8, S1216F8-GL and S1216F8-BD. Whilst not tested in the field but "only" with an Agilent GNSS simulator, these modules represent for me the greatest promise for 2014.
All GNSS enthusiastics should check out the NavSpark:
Although I am not a crowdfunding enthusiastic (see later as well) the news is that it is possible to get at least an evaluation kit (with libraries) for this powerful baseband processor for USD 199. There is a lot of room to play for sure, and 50Hz GPS raw measurements for less than USD 20 a module will buzz for sure.

  GNSS Software Defined Radios

Looking out for interesting devices to use for GNSS SDR, this year has been a promising one. But not all promises are kept, as I will explain below.

Memoto Camera

One year ago already, following the hype of the Cell-guide snapshot GPS technology, I decided for the first time to back a kickstarters project: the Memoto camera. This "lifelogging device" has an Aclys chip inside which will only turn on for a few milliseconds every so often and record a GPS signal snapshot, in order to achieve the lowest possible battery life. After more than 1 year not only I did not received the camera but my contact has been lost in the transition from Memoto to Narrative. Being my support request unanswered, it is hard to know wheter I have lost my pledge or not... fingers crossed.

Jawbreaker -> HackRF One

Michael Ossmann, creator of the Ubertooth, started developing other interesting devices for low cost SDR. I missed by very little the Jawbreaker giveaway back in June, so I decided to support its Kickstarters campaign for HackRF One, which is essentially the same object but not free and with 8 months more on its shoulders. Whether this time has actually served to real innovation or just made Michael more popular (at least well deserved in his case) and rich.
My plans of using HackRF One for GNSS record and playback are a little pushed back by the fact that it is a half-duplex design, although I see some potential by properly hopping between TX and RX.If and when I receive the thing.

Nuand BladeRF

BladeRF was probably the greatest disappointment so far. It mounts
  • the Lime Microsystems LMS6002D, a fully programmable RF transceiver capable of full-duplex communication between 300MHz and 3.8GHz
  • an Altera Cyclone 4 with options at 40KLE or 115KLE
  • a Cypress FX3 microcontroller
Sounds like the perfect board to have a GNSS receiver on FPGA, and a real-time continuous-time record and playback device. I received the boards back in Summer and was never really able to have them working reliably. I installed the Ubuntu several times, until now 13.10 seems to have native support at least for the libusb version they link to. Things might change tomorrow, but it has been six months of bleeding so far. Essentially the software is not stable. BladeRF might even work as a 450 USD spectrum analyzer once you install a leviathan like Gnuradio. But it won't work for me if it misses packets once in a while, if it randomly switches the I and Q channel, if it cannot tune to 1.5GHz in TX mode, if it works only with Renesas and NEC USB 3.0 hosts.

SwiftNav Piksi

Two bright guys, Fergus Noble and Colin Beighley founded Swiftnav and started developing Piksi, an "open source" GPS receiver for RTK implemented as a combination of a Spartan6 9KLE FPGA and STM32F4 168 MHz Cortex-M4 MCU. Swiftnav "kickstarted" Piksi back in the Summer, when I already had a sample of it. Unfortunately once the campaign was funded (and I was one of the backers of course) there has been little development on the software side. Sure, more boards were manufactured to address sales but Swiftnav customers are not yet able to see how the RTK engine will look like, nor they have visibility of the FPGA correlators code.
Actually those two are two valuable pieces of software so I cannot hide my sceptictism in believing the promised Open Source nature of the venture.
Before I publish here anything about Piksi, I need to be provided a simple way of
  1. recording data with the board connected to a perfect antenna. 
  2. converting the recorded stream into Rinex OBS
IMHO, those two are the fundamentals when a Company plans to sell a RTK capable receiver. It does not have to be small, to be low power, to have an embedded antenna if carrier phase isn't rock solid to begin with.
Very recently Swiftnav published a video (filmed in August, so why now?) where they show differential accuracy on the rooftop of their office building.. but that seems a very poor reward for three months of Github silence (1) (2).
I sent Fergus and Colin two pieces of the most recent Rap10LogWi release

asking them to try their RTK engine (I used their same MCU) on a bullet-proof low cost GPS receiver as the uBlox NEO6T.
I have not received any feedback so far.. I know they are busy investing their reward, but I think their customers (and I) need a bit of delivery of credibility at this point.

Ettus USRP B2x0

Probably the savior of my 2013 SDR hopes, the B2x0 boards from Ettus tick many boxes. They are a little expensive maybe, but they are supported by the UHD driver which has a huge community behind. How did Ettus manage to pull off a deal with Analog Devices and integrate first the super powerful AD9361 I don't know. The TI AFE7070 came close sometime this year in terms of chip integration, and the above mentioned LMS6002D (with its awkward footprint) even closer, but that ADI chip seems unbeatable right now. The Spartan 6 75KLE seems also large enough to run several channels of a GNSS receiver already. I will have access to a couple of these boards very soon and I cannot wait.