I’m using the Openlog Artemis with the GNSS logger firmware to log raw data from the Ublox ZED-F9P breakout board, over i2c. The system is being powered via the Artemis’s LiPo connection.
I’m able to successfully log data but an seeing random gaps in the logs. Sometimes they’re only a few cycles long and frequent, other times they can be 10min+ or even indefinite after reliably logging for 30min. This is all in one log file by the way, not separate files. I’m wondering, where else should I be looking to troubleshoot the Artemis’s SD logging in this scenario?
I’ve already checked that the ZED-F9P is not exceeding its I/O interface limits by limiting its message output to i2c, reducing the logging rate and message types logged, and monitored it’s I/O interface limits. I monitored the F9P’s I/O limits and errors via its UBX-MON-IO, UBX-MON-COMMS, UBX-MON-TXBUF messages over USB. With the navigation rate at 4Hz it is safely below the F9P’s I/O limits (60%-ish utilization). At 1Hz it’s not even remotely close to its limits.
The gaps in the logs have even been happening with a rate of 1Hz logging RAWX and SFRBX and PVT messages. It’s configured to use contellations GPS, Galileo, and GLONASS (excluding Beidou). Initially, I was using 4-5Hz on all constellations and tried lowering to 1Hz and cutting out Beidou to see if that helped. It didn’t…
As far as SD card details, I’m using a 32GB Sandisk card FAT32 formatted.
Please make sure your antenna has a clear view of the sky. Perhaps you have it indoors near a window? If the view is limited, the RAWX and SFRBX messages will stop when the ZED loses lock on the satellites, and restart when they come back into view.
Thanks, I should’ve specified I’m testing this on the roof of a car and in front windshields of aircraft (with a clear sky view). I’m using the dual-band Ublox antenna. Also, I don’t think sky view can explain my issue as the gaps in the data isn’t just per satellite, it’s all data, even the NAV-PVT messages which should still be reported in absence of a GPS fix.
I seeing gaps with either engine on+moving or engine off+stationary. I was able to go out and do some tests. I had the Openlog Artemis connected via I2C and a standard Openlog connected via UART, simultaneously. Additionally, I used U-center to log over USB.
Interestingly, the gaps only show in the data logged via I2C but not in UART or USB. I’ve yet to review the logs for error messages and IO limits. I can attach screenshots if anyone is curious.
Many thanks for the extra diagnostics. That’s very helpful. The three-way logging is a great idea and lets you rule out sky view and (probably) electrical interference from the car engine.
Ah! Sorry. I should have asked sooner… Have you opened the split-pad I2C pull-up jumper links on your ZED breakout board? The pull-ups can cause I2C problems for the Artemis if left connected/enabled.
Thanks, I don’t think I have opened that jumper. I read elsewhere about opening a jumper, but it was in relation to I2C and SPI and if I recall right it disabled some outputs. So I elected to not open that jumper. After looking at the hookup guide I see that’s the DSEL jumper.
Are you talking about opening the jumper that will remove the 2.2k Ohm resistors from the I2C bus? It says to open it if one has many devices on the same I2C bus. However, I only have the ZED breakout connected to the Artemis.
The I2C double jumper connects extra pull-up resistors onto the I2C bus. We’ve found that they can cause problems with I2C communication on some platforms - the Artemis in particular. Please see:
The ZED has built-in active pull-ups which are perfectly adequate. The extra resistors cause problems. Please open the double jumper on the top of the board - it is labelled I2C.
The DESL jumper is completely different. It changes the ZED’s I2C pins into SPI pins. It is open by default. Please do not close that jumper. It would cause all kinds of chaos.
