The reason I purchased this module is so I could simultaneously log IMU data, and GPS data from the ZED-F9P for post-processed RTK. The OLA firmware repository provides a specific firmware for logging GNSS data to a UBX file when connected to a GPS module like the ZED-F9P. But when I run that firmware, I only get the UBX file without the IMU data.
When I run the standard firmware, I get all the data (including GPS) in a text file, but I don’t think I can use the GPS data in that format to do post-processed RTK corrections in the ublox software.
How do you get time-synchronized UBX file and a csv/text file with other sensor data? This seems like it would be a very common application / trivial problem, and I’m a bit embarrassed I can’t figure it out.
Your understanding is completely correct. The GNSS_Logger version of the code only logs UBX data from the module. That firmware is not able to log IMU data simultaneously. The main reason is that writing to two files simultaneously on the SD card creates a bottleneck. We start to lose data when trying to log high-rate RAWX data (for PPK) as well as logging (e.g.) IMU data to a separate file. We’ve put a lot of effort into making sure that the UBX logging is reliable, even when the SD card ‘hiccups’ and a write takes much longer than usual.
Likewise, the standard OLA only logs PositionVelocityTime data from the GNSS, again to keep the data rates manageable.
The simplest solution will be to use two OLAs: one logging your UBX RAWX, TIM2 and SFRBX data with the GNSS_Logger code; and a second one logging IMU data and time using the standard OLA firmware.
You probably don’t need two GNSS modules. Once you have the Real Time Clock on the standard OLA synchronised to GNSS time (UTC), you can remove it and attach it to the second GNSS_Logger system.
Would it be possible to expand on this a bit more? I am interested in doing something similar to what I believe @spri is trying, as well as being personally curious about what the limits are.
Our of curiosity, what is the bottleneck that prevents logging UBX and IMU data? Is it because it is too hard to log two files at once (one a binary, and one a CSV)?
I would like high rate IMU data as well raw UBX data. I believe solution that Paul suggested above was to have one OLA logging the raw UBX, and one OLA to log IMU. I am a little nervous about this, because I am worried it would be hard to synchronize the time of the two loggers. If I understand correctly, Paul is suggesting connecting a GPS to the IMU logger to set its real time clock, and then letting it run open loop. This sounds like a reasonable first step. I would feel better about doing this if the IMU-OLA setup could also log the PPS pulse from the GPS. Does anyone know a simple way to do this? Can I simply hook up the PPS from the GPS to the ADC on the IMU’s OLA to observe any time drift (and help sync data in post processing)?
Thanks in advance for any ideas that anyone else has.
We see a bottleneck when trying to write data to two files ‘simultaneously’. We see the same thing when logging high rate serial data (to one file) at the same time as logging high rate IMU data (to a separate file). We haven’t found a way round it…
Yes, you could connect the 3.3V GNSS 1PPS signal to one of the analog pins on the IMU-logging OLA. That would certainly work.