I am using an OpenLog Artemis with the GNSS Logging Firmware, version V10 v22 to log the GNSS data of my Neo-M8P-2 (SparkFun Board GPS 15005) to a micro SD-card (Transcend 16GB SDHC, freshly formatted to FAT32). The devices are connected via a 100mm qwiic cable. The i2c jumper on the GNSS module is opened. The qwiicBusMaxSpeed=400000 is set in the config file on the OLA.
The sd-card is formatted and the only file on it is the ‘OLA_GNSS_settings.cfg’ with my wanted settings to initialize the GNSS module. I want to log the RAWX and SFRBX of GPS and GLONASS simultaneously at a rate of 2Hz, if possible I would be happy to log also the PVT.
For a power supply I use 3x AA batteries in a row, soldered to the VIN of the OLA, the GNSS is powered via the qwiic cable. I start and end the logging by applying and removing the voltage through a simple switch. The OLA creates a new .ubx-file for every time it is turned on. The GNSS-module gets a fix, indicated by the PPS light flashing.
When replaying my .ubx-log in u-center with the Packet Console I see a frequent loss of packages, with a lot of missing times. Also after converting the .ubx to RINEX in EMLID Studio (rtklib does not work at all with my log files), samples are only collected in irregular intervals with a lot of gaps.
In other forums the issue has been discussed already, unfortunately without a final solution yet:
As I understood it so far it must be a problem with the recording in the OLA or the qwiic transfer of the data. When I log only GPS in 1Hz intervals still logs are missing but it is definetely more reliable than at a higher rate. Also the absolute number of logs/minute at a rate of 1Hz is higher that at 2-5Hz. Seems like the ports are congested.
What can be the cause for this issue and how do I have to address it to get a continuous log with the required information? What other configurations of the GPS 15005 or the OLA should I try?
I would be really happy if I could solve this somehow.
Thanks and best regards!
You’ve already got the salient people looking at the situation, you could always diagnose and code your own solution if you don’t think things are happening fast enough…
Could try the SERIAL connection rather than the I2C, with a baud rate adequate for the volume of data you’re fire hosing out. Something that logs ALL the data coming out of the receiver and processing/filtering that on the PC
Receiver’s capable of generating output at speed, but you are responsible for getting the message mix and interfaces setup appropriately
Thank you Paul!
I am working on it and if I have any new findings I will let you know. My next step would be to try the serial logging, although for my overall project using the OLA with the GNSS firmware and a qwiic connection comes in handy, as the initialization is done automatically via the file on the SD card.
For my project several logs have to be made with different configurations and the GNSS firmware allows to use properly formatted sd cards with configuration file on it. For the actual data collection no computer will be available and changes in configuration have to be made via changing the sd card.
The OpenLog Artemis repo has a shed-load of code, you’ll probably need to take some ownership of the code and the mechanics.
The logging to the card seems to be solid, there’s some efficiency and scaling issues, but everything it is writing is done correctly, although corrupt packets with viable checksums are getting through, end-to-end.
The receiver is very solid in terms of data generation. I2C is a frequent cause of headaches. Might be an issue with over-loading the receiver with persistent hammering, if you’ve exhausted content asking again 1ms later, repeatedly, isn’t going to make data that’s 900 ms away arrive any quicker. There’s also clock-stretching, and how the master deals with the slave dragging.
The data read by the logger is already corrupted off the interface, flagging UBX packets with bad checksums, and providing debugging and telemetry on that, might more quickly illustrate what’s going wrong, and when. With a logic analyzer or scope you could use that as a trigger, and inspect the signalling more directly.
Using the UART output might be simpler, the receiver will just keep pushing available data out, and then it’s the loggers job to recover and buffer that without loss. Improving the efficiency of the card writing code to better match the blocks and erases size will help it dwelling unduly long there, potentially stalling the ingress via the UART on the host side.
For USB, perhaps a RPi based board, recording all output directly to files on a card might be worth exploring