I am experimenting with a redboard connected to a NEO-M9N board via qwiic. I am running the callback example NAV_PVT in the SparkFun GNNS v2 library. Just running it as is for the moment and I notice that it mostly works but every 4-5 seconds or so it just hangs and misses some of the messages for 2-3 seconds but then comes back to life and catches up. Watching the 50 ms dots in the example it seems to just block(hang) in the first few dots (100 ms?) and other times it will just spin dots across the serial monitor indicating it is not seen a call back. Is this expected behavior? The ublox is reliably sync’d and pulsing away. I find these issues tend to not be the ublox but rather catching the message.
Not that it should make a difference but to make this example work on the redboard I did have to modify the checkCallbacks() routine in the libary to comment out everything except the autoNAVPVT case.
You shouldn’t need to modify the library to let the example work. I’m curious why you needed to do that?
Please tell us more about your hardware setup. Which microcontroller board are you using? How are the two boards connected? Do you have anything else connected to the Qwiic bus?
I am using a redboard Qwicc connected the NEO-M9N via that qwicc interface. Nothing else on the qwicc bus at the moment.
What I found was that the v2 of the arduino sparkfun GNSS library exceeds the 32K memory of that redboard but probably just for the callback example. Its like 104% per the IDE so I pruned some of the cases that I dont use and got it to fit. I did make sure those two defines for memory reduction were active but by themselves that callback example for PVT was too big. If you can tell me something to try to replicate I would be interested.
As an update I tried an EVK-M8F ublox module and wired it into the I2C bus (qwicc) and it actually keeps up pretty well without skipping or stalling. Maybe the NEO is not getting configured right but the v8 part works OK? My target app is actually the M8F and so I added the UBX-TIM-TOS message(with all the auto stuff) to the library and it works great. Maybe someone would be interested in it? I know many don’t use the M8F but I use it for a SDR app and it has the holdover spec and stable reference I need.
The interfaces can jam on the slowest to output, as all share a common pool, and release once dispatched to all. Watch for $GxTXT “txbuf,alloc” warning as an indicator of loss of packets due to bandwidth issues.
If you’re using I2C, disable output to UART
For the M9 there may be significantly more GSV sentences covering the multiple constellations. Should be Ok at 38400, probably not at 9600 baud.
I’ve used LEA-M8F parts, with external clocks and DAC, they don’t support GALILEO, so even less data output than a typical M8 or M9
Ok thanks, that makes sense. In the example the following is being done during setup so I think its probably doing the right thing from a minimal messaging perspective.
myGNSS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
Will have to look into what the I2C is running at. Only the serial port is being configured at the top level in this example to 115200.
So probably not that, but just saying there will be warning as it chokes the output.
This would be different from the I2C stall caused by 1.5s of inattention, where it needs to be restarted with a query command.
On the NAV-PVT front there are two variants, the 7 Series had an 84 byte payload, and the 8 Series a 92 byte payload.
That makes sense. The library has grown over the years and is now a monster. We’ve tried to keep the code size down, but it is now too much for the good old ATmega328P. If I was starting again I’d make the library scalable, so you can selectively add support for individual UBX messages, each with its own inherited class, instead of the current sledgehammer one-code-to-rule-them-all approach.
As Clive says, it is best to disable UART1 if you are not using it. Or disable NMEA output at least. With our library, call one of:
myGNSS.setUART1Output(COM_TYPE_UBX); //Set the UART1 port to output UBX only (turn off NMEA noise)
myGNSS.setUART1Output(0); //Turn off UART1
To turn it back on again:
myGNSS.setUART1Output(COM_TYPE_UBX | COM_TYPE_NMEA); //Set the UART1 port to output both NMEA and UBX messages
I hope this helps.
We have a new GNSS disciplined-oscillator (time and frequency reference) product - coming soon. Keep an eye out for that. It is rather special.
Thanks for all the help. Great products and support. I was able to get ubx control of the M8F in a very short time. Ublox told me I need to program up the dynamic platform mode for airborne use and your library and a little arduino made that super easy.
Yes the library is a big one. Instead of refactoring it maybe just adding defines to turn off message types and support specific to certain devices. Could still be messy I suppose. Nevertheless its the most complete library I have seen for GNSS and now that ublox gave up on theirs you guys are the best game in town.
Will be on the lookout for your new timing product. I would definitely be interested in helping test that if it comes out on the sparkX side.