OLA DEV-16832 board multi sensor logger failure

Development Boards Artemis
1

Hi All,

I’ve been working on project where I want to log imu / gyro data to determine motions (pitch, roll, and yaw) and accelerations to compare against speed. I have had repeated OLA failures and I am at a loss to understand why.

Process/ sequence as follows:

Components:

  • SparkFun OpenLog Artemis (OLA DEV-16832) *
  • Ublox Zed F9P *
  • Sparkfun Micro Oled
  • Sparkfun qwiic I2C MUX

*donates initial setup, other components added later with AI code input

My first attempt used the initial setup only. All raw data was logged on SD card and post processed to obtain the required variables. I discovered an issue with “drift” and the quality of data was quite noisy which made post processing difficult.

My research suggested I use a Mahony filter and proceeded with this in mind. My programming skills are limited and have heavily relied on AI (I have used multiple sources to cross check output).

When I upload the code (through IDE 2.3.6) I experience an ola failure immediately. This has just happened for the 4th time.

After the failure the following is noted:

  • board showed no serial activity, no LED indicators, and did not enumerate consistently over USB.
  • Even with minimal code and no peripherals attached, there was no sign of successful boot or communication.
  • The ZED F9P is still functional when connected to my laptop.

Hardware Replacements

I have replaced/considered the following components as my research suggests the code is not responsible (not convinced but relying on AI here unfortunately).

  1. USB cable for data transfer
  2. All quiic cables
  3. MicroOLED
  4. Added a powered USB Hub for data transfer
  5. Sparkfun OLA x 4

Below is an output from AI that summarizes the code. I have attached the code for reference.

github boat test.txt (7.4 KB)

Primary Targe Functions of Code:

  • Collect and log synchronized IMU + GNSS data at 10 Hz
  • Fuse accelerometer, gyro, and magnetometer data using the Mahony filter to compute pitch, roll, and yaw
  • Display real-time orientation and speed on an OLED screen
  • Log buffered sensor data to SD once per second in CSV format
  • Safeguard board with watchdog-triggered soft reset and LED alert

Peripheral Interfaces (via TCA9548A I2C mux):

  • Channel 0 → ICM-20948 IMU (accel, gyro, mag)
  • Channel 1 → MicroOLED display
  • Channel 2 → u-blox GNSS module (e.g. ZED-F9P)

Key Libraries Used:

  • ICM_20948.h → IMU data acquisition (accel, gyro, mag)
  • Adafruit_AHRS.h → Mahony filter for orientation estimation
  • SFE_MicroOLED.h → OLED screen output
  • SparkFun_u-blox_GNSS_Arduino_Library.h → GPS data (lat/lon/speed/heading)
  • SdFat.h → High-speed SD file writing
  • Wire.h → I2C communication and mux control

Core Features:

  • 10 Hz loop collects sensor data, buffers in SensorData[10] struct
  • OLED displays live pitch, roll, yaw, and max speed
  • SD card logs buffered data every 1 second in CSV format
  • Soft watchdog resets board after 5 seconds of IMU inactivity
  • LED on pin 19 blinks 5× to signal watchdog resets

Any suggestions on what to try or modify would be greatly appreciated.

Thanks!

2

Hi Nate (@NateSP ),

If you are just getting started with using the OLA as a development board, jumping in with a load of AI-generated code is not the right choice.

The OLA is not like other development boards. There are some extra things you need to do to power-up the Qwiic I2C bus or the on-board IMU for example.

Let’s start with the basics. Please check you are using the SparkFun Apollo3 board package and have selected the “SparkFun RedBoard Artemis ATP” as the board. If you upload one of our “test sketches”, does the board start responding again? Please try the “OLA_IMU_Basics” sketch. What output do you see?

Once you have that working, you can copy the pin definitions and support functions into your own code. You will need to use TwoWire qwiic (pins 8 & 9), not Wire, and call qwiicPowerOn before you can use the Qwiic I2C bus for example.

Keep it simple. Add or change one thing at a time and test. Build it up: start with the F9P GNSS; then the F9P through the MUX; then add the OLED. When something breaks, backtrack to your previous test and work out where it went wrong.

I hope this helps,
Paul

3

Hi Paul,

Thanks for the reply and apologies for the double post (I posted again once I realised it wasn’t quite in the correct location, please feel free to delete the other post).

I definitely agree with your point regarding my approach. I currently have limited time, so I decided to take a shortcut which has evidently not paid off.

I uploaded OLA_IMU_Basics and the board responds with a solid green light.

In Teraterm with a baudrate of 115200 I get the following output.

image
image981×417 156 KB

Thanks for the assistance.

4

Hi Nate,

Good. Your board is alive and you can successfully upload code to it.

You’ve got some serial data corruption, which I don’t understand. TeraTerm should be displaying Scaled. Acc (mg) [ 00433.11, .... It seems to be displaying digits and capital letters OK, but the lower case letters are being corrupted. That’s really weird. Maybe TeraTerm is just having a bad day. Please try closing and reopening it. Or try the Serial Monitor built into the Arduino IDE.

You’re off and running. Now change / add one thing and test again. It’s slow, but it’s the only reliable way to develop and test your code. If you throw a bucket of AI-generated code in there, you don’t know where you are…

Good luck!
Paul

1 Like
5

Thanks Paul. I restarted and now the corruption is gone. The other good news is that two of the boards I thought that were failed took the code, so now I have a backup.

Lesson learnt from attempting to take a shortcut, I’ll just have to find the time to learn.

Appreciate the support :+1:

2 Likes