Dragino LoRa shield with LMIC and 1-Wire sensor problem

[arjanvanb (Arjan)]

Ah, I missed that the long time between 19:05 and 20:04 clearly started after taking the measurements, and after calling LMIC_setTxData2 and some more logging:

// Präpariere Daten für das senden
prepareData();
delay(500);

// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, mydata, sizeof(mydata) - 1, 0);
Serial.println(F("Packet queued"));

// Show TX channel (channel numbers are local to LMIC)
Serial.print("Send, txCnhl: ");
Serial.println(LMIC.txChnl);

// Zeige länge und Daten
Serial.print("Length: ");
Serial.print(sizeof(mydata));
Serial.print("; Data: '");
for (int q = 0; q < sizeof(mydata); q++)  {
  Serial.print(char(mydata[q]));
}
Serial.print("'");
Serial.println();

Like, from the new logs with the blank line added by me:

07:35:29.090 -> Sensor 87b(#5): 19.50°C (19.50), 
07:35:29.678 -> Packet queued
07:35:29.678 -> Send, txCnhl: 0
07:35:29.678 -> Length: 37; Data: '10f6965ce690368695b17694fd569687b695'

08:35:01.677 -> 230534710|3688s: EV_TXSTART
08:35:02.775 -> 230602771|3689s: EV_RXSTART
08:35:03.769 -> 230665017|3690s: EV_RXSTART
08:35:08.442 -> 230957761|3695s: EV_TXCOMPLETE (includes waiting for RX windows)

(Beware: in your earlier log, the “Length: 37” line was printed or captured an hour late too, at 20:04:33.070, while the “Send” line was then captured at 19:05:03.489. Adding flush() ensures that the log is always printed right away.)

As things are fine without the sensor code, I’d assume it’s not the single-channel setup that is to blame. Enabling LMIC debugging might still be useful, of course.

While reading the sensors LMIC cannot do any of its housekeeping for almost 3 seconds:

07:35:26.770 -> Requesting measurements
07:35:27.092 -> Temperaturwerte: 
07:35:28.150 -> Sensor 10f(#0): 19.62°C (19.62), 
07:35:28.229 -> Sensor 5ce(#1): 19.00°C (19.00), 
07:35:28.378 -> Sensor 368(#2): 19.50°C (19.50), 
07:35:28.553 -> Sensor b17(#3): 19.37°C (19.37), 
07:35:28.796 -> Sensor fd5(#4): 19.62°C (19.62), 
07:35:29.090 -> Sensor 87b(#5): 19.50°C (19.50), 
07:35:29.678 -> Packet queued

I wonder if those 3 seconds make it fail to detect some overflow, but it seems its overflow detection is much more resilient than that, and only needs to be triggered once every 30 minutes or so:

@Amedee

Some theory…

os_time is based on millis , it is a scaled down version of millis to avoid to overflow too often.
To keep the os_time counter accurate, it needs to detect millis overflow, which happens after approx 71 minutes.
The detection algorithm looks at a flip of the most significant bit of millis .

Still then, if you really don’t have any other ideas, then maybe adding a few calls to os_runloop_once(); in the measurement code might help. (But I’d focus on the possible 1-Wire/SPI issues.)

But all above does not address the following:

@BoRRoZ

my first guess … it’s a one wire / spi timing conflict
change temp sensor for an I2C one and remove one wire lib

Not my cup of tea, but more wild ideas:

• Maybe using the recommended OneWire 2 helps?

  One Wire Library

  OneWire 2 - I recommend you use OneWire 2, a spiritual successor to the original OneWire library. PJRC has developed this library to fix many of the original bugs found in OneWire. If you find OneWire to be unreliable I would highly recommend this drop-in replacement.

• Maybe one can explicitly pause/disable 1-Wire after taking the measurements?

By the way, what is port 13 used for?

if ((now & 512) != 0) {
  digitalWrite(13, HIGH);
}
else {
  digitalWrite(13, LOW);
}