Some suggestions/reccos:
- The firmware appears to go unstable when requesting fast logging times (Set log time of board to 10 or 50 msec and the board throws an error):
Here is the startup showing my configuration. Note that I was trying to push the board at 10 msec, but it was achieving something closer to 20 msec/line (I bumped serial rate to 230,400 bps to make sure serial wasn’t bottlenecking thruput):
SparkFun DataLogger IoT - 9DOF (c) 2023 SparkFun Electronics
Version: 01.00.02 - build 000098
[W] GNSS::isConnected no traffic seen (first attempt)
[I] Restoring System Settings ...restored from ESP32 Preferences
[E] WiFi: No credentials provided. Unable to connect
[W] [Startup] WiFi Network failed to initialize.
[I] Loading devices ... 3 devices detected
MAX17048 - MAX17048 LiPo Battery Fuel Gauge {qwiic}
ISM330 - ISM330 Inertial Measurement Unit {SPI}
MMC5983 - MMC5983 Magnetometer {SPI}
[I] Time: 2023-07-07T03:42:48
[I] Uptime: 0 days, 00:00:04.517
[I] External Time Source: NTP Client
[I] Board Name: SparkFun DataLogger IoT - 9DoF
[I] Board ID: SFD1DCC4B886E694
[I] SD card not available
[I] WiFi - Not Connected
[I] Battery - Not Connected
[I] System Deep Sleep: disabled
Sleep Interval: 0 seconds
Wake Interval: 0 seconds
[I] Logging Interval (ms): 10
[I] Serial Output: CSV Format
Baud Rate: 230400
[I] SD Card Output: Disabled
Rotate Period: 24 Hours
[I] IoT Services:
MQTT Client : disabled
MQTT Secure Client : disabled
HTTP IoT : disabled
AWS IoT : disabled
Azure IoT : disabled
ThingSpeak MQTT : disabled
MachineChat : disabled
[I] Connected Devices [3]:
MAX17048 - MAX17048 LiPo Battery Fuel Gauge {qwiic}
ISM330 - ISM330 Inertial Measurement Unit {SPI}
MMC5983 - MMC5983 Magnetometer {SPI}
Content-Type: text/csv
General.Time,MAX17048.Voltage (V),MAX17048.State Of Charge (%),MAX17048.Change Rate (%/hr),ISM330.Accel X (milli-g),ISM330.Accel Y (milli-g),ISM330.Accel Z (milli-g),ISM330.Gyro X (milli-dps),ISM330.Gyro Y (milli-dps),ISM330.Gyro Z (milli-dps),ISM330.Temperature (C),MMC5983.X Field (Gauss),MMC5983.Y Field (Gauss),MMC5983.Z Field (Gauss)
4561,4.909,199.227,-4.160,-10.858,-110.776,1018.700,332.500,-227.500,-297.500,24.875,0.22064,0.18378,0.36536
4598,4.909,199.227,-4.160,-10.980,-110.776,1018.700,262.500,-350.000,-280.000,24.816,0.22168,0.18420,0.36615
4618,4.909,199.227,-4.160,-10.980,-110.776,1018.700,262.500,-297.500,-332.500,24.859,0.22144,0.18427,0.36597
<Redacted for brevity here>
5959,4.904,199.227,-4.160,-10.858,-111.020,1018.700,192.500,-262.500,-385.000,24.809,0.22083,0.18433,0.36627
5979,4.904,199.227,-4.160,-10.858,-110.898,1018.578,210.000,-315.000,-332.500,24.797,0.22101,0.18427,0.36597
5999,4.904,199.227,-4.160,-10.736,-110.898,1018.578,175.000,-262.500,-350.000,24.789,0.22089,0.18457,0.36615
6019,4.904,199.227,-4.160,-10.858,-110.898,1018.700,262.500,-210.000,-315.000,24.781,0.22119,0.18475,0.36566
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x4020f94a PS : 0x00060530 A0 : 0x800edddf A1 : 0x3ffb2250
A2 : 0x00000000 A3 : 0x3ffcab10 A4 : 0x3ffb96e0 A5 : 0x000000ff
A6 : 0x3ffb9714 A7 : 0x003fffff A8 : 0x8020f950 A9 : 0x3ffb2230
A10 : 0x3ffc5548 A11 : 0x3ffc5470 A12 : 0x3ffc5170 A13 : 0x3ffca0c8
A14 : 0x3ffb8a6c A15 : 0x3ffbd5c4 SAR : 0x0000000c EXCCAUSE: 0x0000001c
EXCVADDR: 0x0000011b LBEG : 0x40085619 LEND : 0x40085621 LCOUNT : 0x00000027
Backtrace: 0x4020f947:0x3ffb2250 0x400edddc:0x3ffb2270 0x4014bdcd:0x3ffb2290
ELF file SHA256: d4c9f2bcdbeb828a
Note the above is from me requesting 10 msec logging, but actually getting about 20 msec. I still get the error when I try to log at 50 msec time steps, which per the above example shouldn’t be stressing the board.
Note the failure does appear to be coupled to a set amount of time after logging resumes. If I slow down the logging rate, the board survives a proportional amount of time longer before it faults. I always had it crash less than 20 seconds from logging resumption in my testing.
- Recommendation for enhancement: It sure would be nice to have an option to put out the ISO8601 time with fractional seconds, in order to avoid having to reconstruct it from the bottom three digits (msecs) of the TOW GPS field. This is a legal ISO8601 option, in which the lowest time parameter (in this case seconds) is allowed to have a set number of fractional seconds ("A decimal fraction may be added to the lowest order time element present in any of these representations. A decimal mark, either a comma or a dot, is used as a separator between the time element and its fraction". Since this is my recco, I vote for the dot!).
Not having fractional seconds doesn’t limit the utility of the board, but if you’re trying to make it easier to use, I’d much rather have a single time field than having to kludge them together after the fact