Dear all,
First of all, I am not sure if the logging speed issue is caused by the I2C multiplexer (TCA9548A) or the SD library or others. So, please let me know if this post needs to be moved to a proper section.
I have wired eight lidar lite sensors on an I2C multiplexer (TCA9548A) and the multiplexer has connected to the AdaFruit SD datalogger shield. The datalogger shield is mounted on the Arduino DUE.
I've tired to increase the logging speed using the string method or the SDfat library method. Both of them can record ~25 logs to the SD card per second. Each log contains date, time, and readings from eight lidar sensors (I2C mode). I also just enabled one data bus on the multiplexer, resulting in a much faster logging speed at ~200 logs per second.
Any tips to improve my code in order to increase the logging speed?
Please see the attached working code. (1) the string method (testing_SD_2.ino) (2) the SDfat library method (testing_SD_1.ino).
Thanks.
testing_SD_v1.ino (4.5 KB)
testing_SD_v2.ino.ino (3.38 KB)
try this rewrite of your Version 1 sketch.
I only init the sensors on boot and at each sync interval.
Also I setup a RTC_Millis() object referenced to your I2C RTCC. I also sync it every sync_interval.
Chuck.
testing_SD_v1_fix.ino (5.11 KB)
Hello Chuck,
Please see attached revised file.
The code you attached just created a file without logging.
The issue probably was caused by the "RTC_Millis" and "rtcM.adjust()". I am not so sure about this.
So, I tried to revise your code at my end.
The logging speed increased from 25 log/s to 50 log/s.
Please take a look. Any further tips?
Thanks for your help!!
testing_SD_v3.ino (4.92 KB)
changks:
Hello Chuck,
Please see attached revised file.
The code you attached just created a file without logging.
The issue probably was caused by the "RTC_Millis" and "rtcM.adjust()". I am not so sure about this.
So, I tried to revise your code at my end.
The logging speed increased from 25 log/s to 50 log/s.
Please take a look. Any further tips?
Thanks for your help!!
I don't understand how commenting out the rtcM() calls would change the behavior of the sketch.
The rtc.now() actually does the I2C communications with the RTCC, and since the RTCC only has 1 second accuracy, calling it 25 times a second is very wasteful.
The rtcM() just uses an offset from the millis() counter to return the current time. The millisecond counter of the Arduino keeps pretty good time, it counts the 16MHz crystal cycles. The CPU crystal can be +-1%.
I use a combination of rtc() and rtcM() for a webserver project, I have found the rtcM() is acceptable +-5 seconds of the rtc() with a 2hr rtcM.adjust(rtc.now());
The biggest benefit is that rtcM.now() is hundreds of times faster than rtc.now(). All of the rtcM() operations are preformed by the Arduino at 16MHz instead of waiting on a series of 400KHz I2C transactions.
Chuck.