GPS module measurements, part 2

After the previous tests, I ordered another GPS antenna to improve the signal conditions.

They're just the cheap puck style antennas with SMA connectors ($10 on Amazon), and I've put them on my windowsill.

There's something wrong with my NS-T, either I've messed up the configuration or something else is wrong with it. I tried resetting it to factory defaults and changing the PPS settings. Sometimes the NS-T would work well, for example the half-hour below.

Other times, it would jump around a lot more than I would expect.

So in the end, I swapped the NS-T (Venus 838LPx-T chipset) GPS module with a Navspark-GL (Venus 822A chipset) GPS module.

This is a pretty good result. I changed the antenna delay compensation on the NEO-6M at 01:09 UTC from 50ns to 0ns, but that didn't seem to make any difference. Swapping antennas and swapping timer channels didn't have a noticeable effect. The NEO-6M is ahead of both the Navspark-GL and the NS-T by 72ns on average.

In terms of signal, the Navspark-GL was much better than the NEO-6M. Of the 76,815 seconds this test ran for, the Navspark-GL had a PPS 100% of the time and the NEO-6M had a PPS 88% of the time.

You can also see the difference in signal strength through their vendor supplied interfaces:

Navspark-GL/GNSS Viewer, SNR average 26dB:

NEO-6M/u-center, SNR average 20dB:

The u-center application is very nice, however. In the screenshot above, you can see both the per-satellite detail (left panel) and the average SNR over time (right panel). This is the NAV-SVINFO UBX message and is not enabled by default.

The SVINFO fields are defined in the "u-blox 6 Receiver Description" PDF. To make this information easier to find, the columns are as follows:

• Ch - GPS module's channel used to track this satellite
• SV - satellite identifier
• CNO - carrier to noise ratio (signal to noise)
• residual - "Pseudo range residual in centimetres"
• Nav - currently being used in navigation
• Qi - quality
• 0: This channel is idle
• 1: Channel is searching
• 2: Signal aquired
• 3: Signal detected but unusable
• 4: Code Lock on Signal
• 5, 6, 7: Code and Carrier locked
• El - elevation
• Az - azmuth
• Orbit - orbit information availability
• Eph - Ephemeris (best)
• Aop - AssistNow Autonomous
• Alm - Almanac Plus
• none - no information
• Healthy - satellite is healthy
• DGPS - differential correction data

More neat data from u-center:

This data is from the NAV-CLOCK UBX message. It is showing the GPS module's frequency error on the left in us/s (which is also ppm). It is showing the time offset of the GPS module's internal clock on the right, which happens to have a slope of around -1.8 ppm. Before the GPS module's first lock, both of these graphs swing wildly while it tries to estimate the local clock. I've been trying to speed up the process by using the AID-INI UBX message after starting the module and giving it the last clock drift value with a clock drift accuracy of 1ppm. It still takes 10 minutes+ for the initial lock, even with u-center's online data assistance. I want to test one of u-blox's TCXO based modules to see if that improves this at all.  See part 3 for those tests.