SparkFun Thing Plus NINA-B306 + SparkFun SAM-M10Q GPS breakout Cutting out issues

Uncategorized
1

SparkFun Thing Plus NINA-B306, logging IMU data to the onboard microSD at around 140 Hz. The sketch stops dead after anywhere from 3 seconds to 7 minutes - the status LED stops blinking, serial output stops, and the log file ends. No error message. Sample timing in the file is completely normal right up to the moment it stops, with no slowdown beforehand.

It happens with a SparkFun SAM-M10Q GPS breakout attached over Qwiic, and also with a minimal sketch using only the onboard ISM330DHCX and the SD card, with the Qwiic cable unplugged. Runs tend to get shorter across a session and are longest after the board has been off overnight. Battery reads 4.1 V throughout and the board does not get noticeably warm. SD card is a SanDisk Extreme 32 GB, FAT32.

Happens on both USB and battery power.

2

Hi Connor
Welcome

I don’t know anything about what you are doing here but this stands out.

That sounds like a temperature problem.

But you say

The word “noticeably” might be a bit of a clue. There still might be a component that is getting hot that you haven’t noticed. Although if one component is behaving like this it tends to be noticed when it burns a hole in your hand.

You could try one thing. Wrap the whole thing in a couple of bags of frozen peas or something and see if that extends the operating time.

It could be something like a bad solder joint that fails when it gets warm. Could fail with a moderate temperature rise that you might not think excessive.

You could also quickly run over the boards with a warm air jet. You would need to do this at first switch on to get max run time and carry out the experiment quickly.
Cheers Bob

3

Hi Bob, thanks for the response mate.

As for the noticably warm part - with some re-tests recently, I really do not notice any difference in temperature.

Interestingly, I have found that if I power on the SparkFun Thing Plus NINA-B306 and disconnect the GPS device - the device will run with no issues indeffinitely - have tried swapping the Qwiic cables that connect the two parts with no change.

I have tried 3 tests with the GPS connected Test 1 ~363s, Test 2 ~ 137s, Test 3 ~28s, Test 4 (With Ice gel pack underneath) ~ 142s

4

Hi Connor

So it does improve quite a bit when cooled. Interesting, could be a clue there.

One other thing. Like I said I don’t know anything about what you are doing but would you have something in your communications like a clock conflict. If you don’t have the same clock for timing would there be a possibility that one gets a bit out of sync with the other and this gets progressively worse until everything just stops. This could be somewhat heat sensitive if one oscillator is getting a bit warmer than the other thus changing the actual error.

Without having all this on a bench in front of me with some nice test instruments I am afraid i really don.t know what to do remotely. The fact that all works without the GPS connected suggests some sort of conflict but one would have to see it or be able to reproduce the problem to say what the problem is with any certainty.

Have you or can you try the hot air sleuthing method. A bit difficult if you have not got a fairly fine device, preferably with some temperature control so you don’t destroy anything.
Cheers Bob

5

Not sure on how this is coded, but I would check the fat file system settings and ensure files are closed off correctly.
On micro controllers often max fat files is 5 by default, meaning you can have 5 handles to open files and everything is working fine, but the 6th will have issues.
I run into this a while back (very different board/project) where If I refreshed my webpage too fast it would lock up, but slower refreshing was OK. this was mainly due to things timing out and handles getting released before I requested a new one on the next file open.

If the system simply uses 1 file hander for ALL writes, then this should not be the issue, but if it re-opens on every write, then the old handles need to be released prior to that.

edit:
Then there is the the SD card overhead as per this google ai response

image
image847×703 103 KB

So just some things to keep in mind and try.

6

Hey there, @Connor331218, and welcome to the forum.

You mentioned in your first post that there was some freezing without the GPS. Is the indefinitely running the same sketch or has the code changed? Either way, I’d suggest adding a third test in. Try using the your stable IMU/SD sketch with the SAM-M10Q physically connected, but with all GPS initialisation and reading calls disabled.

That will help separate the extra hardware on the power/I²C bus from something happening during GPS communication. If that runs reliably, re-enable the GPS calls and add short serial markers immediately before and after each GPS read and SD write. The last marker printed may help identify where execution gets stuck.

7

Hey Jane,

Sorry, I must have made a mistake - no freezing without the GPS. Recent testing seems to show the following info - the device will run indefinitely even when GPS is connected BUT not long after the GPS connects to satelites and starts data - the connection fails.

Result from your suggested test: IMU and SD logging at ~185 Hz with the SAM-M10Q physically connected and holding a satellite fix throughout, but with all GPS initialisation and reading calls removed and the library not included.

Ran 1,901 seconds (32 minutes), 351,852 rows, no stall. Stopped it myself.

With GPS calls enabled it stalls within 17–200 seconds of acquiring a fix, depending on navigation rate. It never stalls before a fix is acquired, and never stalls with the GPS physically unplugged.

So it is not the extra hardware on the power or I2C bus. It is something during GPS communication.

One lead from the SAM-M10Q datasheet, section 5.2: the module uses I2C clock stretching, holding SCL low for up to 20 ms. Does the nRF52840 TWI peripheral handle that reliably? It would fit a hang mid-transaction makes everything on the bus unreachable, including the IMU, so the sketch blocks and the LED stops.

I have tested at 100 kHz and 300 kHz with no improvement. The datasheet specifies Fast-mode only, 320 kHz maximum, Standard-mode unsupported.

Reproduced with SparkFun’s own unmodified example.

Ran Example1_PositionVelocityTime from the SparkFun u-blox GNSS v3 library. Only changes: added the Adafruit TinyUSB include (required for Serial on this board), set the navigation rate to 10 Hz, and added satellite count and uptime to the printed output. No SD card, no IMU, no other libraries.

It stalled at 47 seconds with 18 satellites. Serial output stops dead, no error.

Summary of all testing:

  • SparkFun’s own example, 10 Hz: stalls at 47 s after fix
  • My logging sketch, 10 Hz: 17–200 s after fix
  • My logging sketch, 1 Hz: 680 s after fix - still cutting out
  • IMU and SD logging, GPS physically connected and holding a fix but never addressed in code: 1,901 seconds, no stall
  • GPS physically unplugged: no stall
  • Never stalls before a fix is acquired
  • Same result at 100 kHz and 300 kHz I2C, two different Qwiic cables, both USB and battery power

The fault is reproducible with SparkFun’s own library and example on SparkFun hardware. It appears to be in the GPS communication path.

8

Makes me wonder if its a volume of data from the GPS.
e.g. NMEA packets selected * number of satellites etc.
I have fallen into that one a few times and the “serial” just cant keep up. Increased the data rate and/or unselecting the messages you dont need would both help (if that is the case). I do note when I had too much data it was only after I update my GPS unit to that support more concurrent satellites and GPS systems.

Note: My key point here is just something to look at. if you can stream the GPS output to a terminal you will see how busy it is. 1Hz should have less data then 10 Hz, but still 1 Hz with 20 Sats and lots of messages can still take more then the 1 second to clock out all its messages.

9

I think @Michael99645 is onto something that data volume is worth considering. Something is going wrong with the amount of GPS information coming through.

Clock-stretching could definitely be a cause. The nRF52840 supports stretching, but Nordic acknowledges that the first clock pulse can be too short. Because the current Adafruit nRF52 Wire implementation maps a request for 300 kHz to 400 kHz, I’d repeat the minimal example with Wire.setClock(250000); immediately after Wire.begin() to see if there’s any difference.

That driver also has hardware-event waits without timeouts, which could explain a complete stall if a transaction gets stuck. Could you post your board-package and GNSS library versions, along with the 250 kHz result? That should help establish whether your installed driver has those same behaviours.