I have to say I like /dev.
Everybody likes /dev! Except String
-lovers. They've got no stars upon thars.
The reason I asked about the baud rate is because the ublox knows when there's too much data to send at a particular baud rate. It will throw "frames" away if they can't get transmitted before the next update. If you're running at 9600, an 80-character NMEA sentence will take ~80ms. That's most of the update interval right there. A second sentence can't get sent before the next update interval has started. So to be sure the baud rate isn't the bottleneck, you must increase it.
Regarding polling for fixes instead of letting it send them at a fixed interval, I hope you realize it will increase the Nano CPU load, both in the number of interrupts it has to handle (TX), and in the time it takes to queue up the the request. I'm not sure what else the Nano is doing, but 10Hz updates with logging is a significant load for this processor. If you're careful, it's easily doable. Logging and printing is usually what trips people up, though.
Which brings me to this last suggestion. Many projects have trouble because so many libraries take too much time away from loop()
. Even logging or printing takes time to execute, sometimes blocking until all the data gets logged or printed. GPS data keeps rolling in, and if you don't do the Serial.read()
often enough (64ms @ 9600), you will miss receiving some characters (aka input buffer overflow). And if you increase the baud rate to 115200, that window gets even shorter: 6.1ms! That means that no single operation you perform can take longer than 6ms, or you will lose some GPS data.
The only solution is to use an interrupt-driven approach like in NMEAfused_isr.ino (which requires NeoHWSerial). Letting the characters be handled in an interrupt allows you to do your data logging without worrying about getting back to loop
. The fixes are "magically" updated by the interrupts, and you never have to do Serial.available()
and Serial.read()
.
have you tried running only on UBX sentences?
Yes. The ublox example turns off the NMEA sentences and runs in pure UBX binary protocol. BTW, if you switch back to one of the NMEA examples, they won't work until you power off the ublox.
Everything is more complicated because it's a two-way protocol: configuration commands have acknowledgements. And starting up takes a few seconds because you must request and receive the current GPS leap seconds and the current UTC time. You need both before you can convert the GPS time-of-week value (ms since midnight Sunday) to a UTC time (leap seconds + time-of-week + UTC midnight Sunday). There's a state machine in ublox.ino
that shows how to do that.
I haven't seen an application yet where it's worth it to use the UBX protocol. It does save about 120 RX interrupts per update (only 40 characters instead of 160), and the binary numbers don't have to get parsed from ASCII decimal. It is more efficient, but unless you're trying to squeeze every last cycle out of the Nano, it may not be worth the effort. Are you planning on using an IMU? That does require frequent sampling and computation.
Cheers,
/dev