OpenLog Artemis: stops logging after short interruption of Qwiic connection

Hi,

I want to log data from 4 load cells with an Artemis OpenLog. Logging starts fine, but then stops after a while.

Here is the hardware Set up: 4 mini load cells (500g, TAL 221, SEN-14728) each connected to a SparkFun Qwiic Scale NAU7802 connected via Qwiic cable to SparkFun QwiicBus EndPoint (Com-16988), connected via 1m RJ-45 cable to another SparkFun QwiicBus EndPoint, connected via Qwiic cable to SparkFun Qwiic multiplexer (TCA 9548A), connected via Qwiic cable to SparkFun OpenLog Artemis.

At the start it works fine, but at some point (after many minutes) logging stops (that is, instead of actual weight values, I get only 31.76, 0.00, 0.00, 0.00 on all consecutive lines no matter how much pressure I put on the load cells. I can provoke the same behaviour, when I briefly disconnect any of the 4 sensor cables (eg Qwiic cable from scale to endpoint or RJ-45 cable). So I deduce that the problem occurs as soon as connection between one of the sensors to the Artemis is briefly interrupted.

In the Artemis intro it also says “The Qwiic bus is pretty tolerant to “hot swapping”, but: disconnecting a sensor while it is in use will confuse the OLA software”. This is, what seems to be my problem. Having several sensor connected and running for a long time (a day) seems to make it very likely that at some point one signal from one of the scales is missed and this seems to be enough to “confuse” the Artemis software.

Is there a way how this can be avoided?

Here is an example from the terminal output:

⸮⸮⸮H⸮⸮⸮ѕ⸮⸮́OpenLog v1.7
Logging to: dataLog00376.TXT
Failed to create settings file
Failed to create sensor data file
SD card online
Datalogging offline
Serial logging offline
IMU online
Identifying Qwiic Muxes...
Identifying Qwiic Devices...
Multiplexers found. Scanning sub nets...
...
Unknown device at address (0x6E)(Mux:0x70 Port:3)
Known I2C address but device failed identification at address 0x77
Unknown device at address (0x79)(Mux:0x70 Port:3)
Autodetect complete
LoadCell-NAU7802 online at address 0x2A.0x70.2
LoadCell-NAU7802 online at address 0x2A.0x70.3
LoadCell-NAU7802 online at address 0x2A.0x70.5
LoadCell-NAU7802 online at address 0x2A.0x70.6
Multiplexer online at address 0x70
rtcDate,rtcTime,weight(no unit),weight(no unit),weight(no unit),weight(no unit),
10/14/2020,12:07:26.63,0.00,0.00,77.30,1.09,
10/14/2020,12:07:26.83,7.58,0.00,77.25,1.15,
10/14/2020,12:07:27.03,7.68,0.00,77.27,1.12,
10/14/2020,12:07:27.23,7.64,0.00,77.17,1.18,
...
10/14/2020,12:46:16.71,11.08,0.00,2.45,1.64,
10/14/2020,12:46:16.91,11.04,0.00,2.40,0.00,
10/14/2020,12:46:17.70,31.76,0.00,0.00,0.00,
10/14/2020,12:46:17.90,31.76,0.00,0.00,0.00,
10/14/2020,12:46:18.10,31.76,0.00,0.00,0.00,
10/14/2020,12:46:18.30,31.76,0.00,0.00,0.00,

Bernhard

Is this the full diagram?

4x Load Cells ↔ NAU7802 ↔ Endpoint #1 ↔ Endpoint #2 ↔ Mux ↔ Openlog Artemis

What is the mux doing? Are there more sensors on it?

The issue is almost guaranteed to be an issue of either the termination resistors on the qwiicbus or the pullup resistors on the mux/OLA/NAU; my first guess would be the combined pullup resistance of the bus is the problem. https://learn.sparkfun.com/tutorials/pull-up-resistors Try disabling all except 1 set of pullups (each product’s hookup guide will have a relevant section for such…you just cut them with something sharp) and see if that improves things

If not, check out the Qwiicbus hookup guide section regarding termination resistors

Hi Bernhard,

I think this is probably a power or voltage problem. I have never tried using the End Points with OpenLog Artemis, but I suspect the voltage drop over the End Point links could be a problem. If the voltage at the NAU7802’s drops too low, or is interrupted, the scale will lose its calibration. You normally see “NaN” (Not A Number) errors when that happens.

If possible, please try a test without the End Points and RJ45 cables. Connect only OLA->Mux->4xNAU7802. Does the system keep logging then?

I hope this helps,

Paul

TS-Russell:
… Try disabling all except 1 set of pullups (each product’s hookup guide will have a relevant section for such…you just cut them with something sharp) and see if that improves things

Hi TS-Russell,

thanks for your response. I cut all the pull-ups (on the scales and the endpoints) and left only the one on the mux. It seems I get the problem less often, but it still works not stable over a whole night. My next guess is that it might be a power issue.

Cheers, Bernhard

PaulZC:
I think this is probably a power or voltage problem. … If the voltage at the NAU7802’s drops too low, or is interrupted, the scale will lose its calibration. You normally see “NaN” (Not A Number) errors when that happens.

If possible, please try a test without the End Points and RJ45 cables. Connect only OLA->Mux->4xNAU7802. Does the system keep logging then?

Hi Paul,

thanks for your input. Yes, I now also suspect that it could be a power issue. Right now, all the endpoints (8 in total) are powered via the mux and also all the 4 scale sensors are povered via mux and RJ45. I will now see that I power the breakout boards separately and see whether this works better. Will post an update once I have done that.

(I don’t get NaN but just 0.00 or some random number). Initially I had it running without RJ45 connections --and that was fine. I will check agian, though. Problem is, that the sensors need to be 2m apart, and that was too long for the Qwiic bus.

Cheers, Bernhard