ublox neo-m9n observations

[Kai Harrekilde-Petersen]

Prompted by Gary's mention of the ublox NEO-M9N devices, I bought a 
couple of SparkFun's breakout boards (GPS-15712 with u.FL connector), 
and have been playing around with it under Windows 10 (connected to a 
USB port) and their u-center evaluation software (v20.01, the latest 
from their website) to understand it.

I have so far made a couple of observations that I thought might be 
worthwhile passing along, but most are likely  to fall into the category 
where Gary will just say like the doctor: "Well, don't do that, then" 
when I say "It hurts when I do this".

My primary interest it to get multi-Hz (10-25Hz) position and time 
updates for datalogging a vehicle at-speed on a racetrack (so easily 
150+ mph).

Firt of all, I'm quite impressed by how many birds it will pick up - 
I've seen more than 30 at once: GPS, GLONASS, Galilleo, Beidou, QZSS, 
SBAS. Combined with an active external "puck" antenna placed in a rather 
sub-optimal place (just outside the window of my home, so half the sky 
is obscured), it can still pick a lot of birds up, with up to 47-50dB-Hz 
signal strength (best case) - see attached (I'm at 55.76 latitude, hence 
the "blank" sky). Even with an active 15x15mm antenna gets nice signal 
strength (up to 42dB-Hz as I recall. I could probably get better numbers 
with a 10x10cm ground plane).

I should try the same tests with the SkyTraq Venus838 module some time.

I have found that if the PC is - for whatever reason - is too slow in 
servicing the USB, the NEO-M9N will overrun the TX buffers and send out 
the message "$GNTXT,01,01,00,txbuf alloc*61\r\n". In u-center, this is 
quite obvious as you'll see the connection to  a number (or all) 
satellites are lost momentarily (but you won't get a notification about 
this). I've even seen 2 of these "txbuf alloc" messages in a row, spaced 
less than a second apart.

The u-center software in itself is a pretty big violator here - it's a 
big resource hog. If you want capture a long run, without buffer 
overruns, remember to minimize the graphical window. DAMHIK. In fact, I 
would recommend people to use putty instead to capture the COM-port 
stream instead on Windows.

Another very effective way of overrunning the TX buffer is to increase 
the update rate, but not the UART speed. I recommend 921600baud. DAMHIK. 
U-center understand absolutely nothing of the partial stream. I haven't 
looked into if or how you can make the NEO-M9N ignore the USB interface, 
when you hook it up to a real UART line (+ pps) under, say, Linux.

When using a 1Hz update rate, the deviation map looks pretty reasonable 
- elliptic, but not suspiciously so. But when I run with a 20Hz update 
rate, the major/minor axis of the 2D error is 2.97m and 0.00m(!) - see 
attached. The deviation error doesn't seem to be significantly worse 
with the high update rate though. What I found to affect the PDOP & HDOP 
the most, was turning off some of the GNSS constellations.

So while u-center do have a couple of niggles, the GUI is useful for 
replaying a recorded log and getting statistics information from it. 
Just remember to minimize the GUI if you have a long run (say 24h). 
Again, DAMHIK :-|

Finally a thanks to Gary for suggesting a new toy for me :-)

Best regards,

Kai

Sky view.png
Description: PNG image

deviation map 20hz.png
Description: PNG image