General Guidance on OLA Recording Speed Optimization

Development Boards Artemis
1

I see a few specific posts on this but looking for general guidance, or at least some things to test. I was hoping to get 500Hz from my OLA with the following sensors:

  • NEO-M9N GPS
  • ADS1015 analog input card
  • Qwiic button
  • Onboard IMU
  • 3 of the analog inputs onboard (RX,TX and 32; 11 is used to go into slow mode)

I am currently using an SD card purchased from SpakFun (SanDisk Ultra Class 10, 32GB).

It is obvious and intuitive that the more measurements I select to record the slower my max frequency is (down to 10Hz even). However even if I only select basic time recording and three onboard analog inputs, I can only achieve ~60Hz (measuring via the frequency recording option). This seems very slow.

Additionally when I select GPS to record, I am down to 10Hz and it seems incentive to other changes to improve this. I am hoping I can get this better by increasing I2C bus speed but unsure of the downsides.

I am using the latest firmware (v2.11).

Any ideas on what to try next would be really appreciated as this device might not work for me.

BTW, I ran with SparkFun for this project because your documentation seemed great. A section on recording speed guidance in the HookUp Guide would be awesome!

Thanks!

2

While I agree that would be nice the sheer amount of variables and settings/configs for each sensor and how their buffers operate individually and then when on a bus with other devices it becomes a mess of sorts. My general advice is to test each sensor individually and use the settings to optimize, then combine piecemeal to see what the practical max is

GPS is based on timing differentials, so it’s also intuitive that it slows logging down the most (as it has to wait for the next message) :-/

Is using two an option? Then you could try maxing one out for other sensors and have one for GPS

I can’t promise this would be any better in practice, but we also have Configuration - SparkFun DataLogger IoT Hookup Guide to consider

3

Thanks for the advice! I was thinking the same. Will give some detail as maybe it will help others.

To start with I setup the OLA in the best way I could think of to maximize record rate.

  • Updated OLA code to allow the requested frequency to be above the maximum allowed. I simply disabled the fault when a frequency is input above the specified max, 2000Hz in this case. This allows me to add whatever sensors I want to record and OLA just goes as fast as possible.

  • Updated OLA code to put the ADS1015 into useConversionReady(false). From the documentation this states that it will grab an already existing value in the register (with completed conversion and averaging). Also set my ADS1015 frequency to 128Hz because I have other reasons to use the onboard digital averaging feature available at that frequency.

  • Used the fastest random write SD card I could find (Amazon.com: Sandisk SDSQXCD-128G-GN6MA Extreme Pro Microsdxc 128gb+sd Flsh Adapter 200mb/s 90mb/s A2 C10 V30 U : Electronics)

  • I2C bus to 400kHz

  • Other settings:

    | 1) Log to microSD: Enabled
    2) Log to Terminal: Enabled
    3) Set Serial Terminal Baud Rate: 460800 bps
    4) Set Log Rate in Hz: 2000
    5) Set Log Rate in seconds between readings: 0.000500
    6) Enable maximum logging: Disabled
    7) Output Actual Hertz: Enabled
    8) Output Column Titles: Enabled
    9) Output Measurement Count: Disabled
    10) Open New Log Files After (s): 3600
    11) Frequent log file access timestamps: Disabled
    12) Use pin 11 to trigger logging: No
    13) Logging is triggered when the signal on pin 11 is: Rising
    14) Use TX and RX pins for Terminal: Disabled
    15) Use Pin 11 to control fast/slow logging: No

    17) Use RTC to control fast/slow logging: No

I then started the test and recorded the results below like you suggested. First row is just a single sensor active. I list the specific channels recorded from the header file to be clear. The rows below I added sensors one-by-one to be tested in combination with others.

image
image1798Ă—1214 261 KB

So now it gets more interesting! It was obvious the ADS1015 was the big hit to speed. If you convert to time, it adds about 50ms per cycle!

I tried many different configurations and surprisingly only switching to “singleShot” improved the speed, but not by much, and it shouldn’t do that. I can’t use “SingleShot” for my application so I kept digging.

Looking at the ADS1015 SparkFun code I see there is a 16ms delay deliberately added to the code (note: 16*3 = 48ms). I guess they figure people want to wait for a new converted measurement when requesting (not me!). I made a fork and just took that delay out ( SparkFun_ADS1015_Arduino_Library/src/SparkFun_ADS1015_Arduino_Library.cpp at master · NightRider-2000/SparkFun_ADS1015_Arduino_Library · GitHub ).

Now I am at about 135Hz with 2 onboard analog inputs, standard IMU inputs and 3 ADS1015 inputs. This should be good enough for my project but time will tell.

I guess next I should dig into if I can pull directly from a registry for the IMU and then maybe even GPS to get things faster.

The GPS is just a nice to have for me. Since this is for a Mountain Bike, I would rather just record GPS with my phone then deal with pulling data from a second OLA.

Thanks again for all the help! It is a cool product. Hopefully this helps others trying to maximize the OLA for faster projects.

2 Likes
4

Small update.

It seems the IMU is defaulted to continuous mode which should offer fastest speed. I could dig through the code like the ADS1015 to find delays, but considering it is far more complex code, will save that for later.

Regarding UBLOX M9, it seems it is limited to pretty low frequencies even in its fast delivery from registry mode. So will just live without it.

5

Thanks for sharing your results - this will surely help others :smiley: