Gleichzeitige Ausfälle von Sensordaten

Ich habe meine Sensoren seit etwa 3 Jahren problemlos in Betrieb. Vor einiger Zeit musste ich die Batterien erstmals wechseln.
Seit dieser Zeit beobachte ich, dass 2 der 4 Sensoren immer gleichzeitig nicht verfügbar sind. So, als ob sie gleichzeitig senden und sich gegenseitig stören würden. Habe auch immer wieder mal Garbage-Msgs. Da die Ausfölle aber nicht dauerhaft sind ist es schwer das entsprechend in Log festzumachen.

Any ideas?

Hallo :slight_smile:

Deine Vermutung, dass gleichzeitig gesendet wird oder etwas mit dem LBT (Listen Before Talk) Algorithmus nicht passt, könnte tatsächlich stimmen.

Der Easy Fix ist: Von einem Sensor die Batterie herausnehmen, dann 40s warten (dann sind die Kondensatoren leer genug, um einen Reset auszulösen), und wieder einsetzen.

Der aufwändigere Fix wäre: Auf das Sensor Label klicken, Firmware Revision heraussuchen, und dann kann ich nachsehen, ob bei dieser Firmware ein Problem mit dem LBT existiert hat.

Das ist ungewöhnlich. Hat die Batterieanzeige leer angezeigt?

liebe Grüße,
Can

Hi Can,
danke für die Antwort.
Ich habe den Easy Fix befolgt. Relativ bald nach dem Wiedereinsetzen der Batterie in hatte ich das selbe Verhalten zwischen dem Stromlos-gemachten und einem anderen Sensor wie zuvor. Seit dem war dann aber Ruhe. Ich denke es ist noch zu früh um wirklich etwas sagen zu können.

Unabhängig davon habe ich die FW-Versionen meiner Sensoren ausgelesen: Die drei zuerst gekauften haben die Version 12258, der eine später gekaufte die Version 12280.

Betreffend der Batterie: Das waren keine Log-Life aus dem Shop sodern normale Alkaline. Und eine davon war zum Ende des Winters dann schon ziemlich am Ende. Im März hab ich sie dann gleich alle getauscht. Zunächst auf Duracells und dann nochmal auf normale Alkalines da mit den Duracell auch so ausfälle wie jetzt zu beobachten waren nur habe ich das da auf die Batterien zurück geführt.

lg günter

Bei Versionen vor 12307 gibt es das Problem, dass wenn ein 2ter Sensor bereits sendet, der erste Sensor, der das bemerkt, manchmal resettet anstatt zu warten.
Das müsste eigentlich zu einem anderen Verhalten führen (der 2te Sensor sollte ungestört senden können). Nichtdestoweniger, gab es in diesem Code Bereich Änderungen seither.
Die aktuelle stabile Version ist 12572. Ich habe hier keine Probleme jemals gesehen. Das Verhalten bei Dir - das kenne ich aus der entfernten Vergangenheit, kann aber nicht genau sagen bei welcher Version es auftrat.

Was ich machen kann, ist ein FW Update auf die neueste Version. Dazu kannst Du es einsenden. (Eventuell geht es auch mit einem Raspberry.)
Ich mache es normalerweise über einen USB zu Seriell Konverter (UART). Dann lasse ich ein Python Skript laufen, gebe ihm die FW Datei und das Bootloader Passwort des jeweiligen Sensors und das Update wird über UART auf dem Sensor installiert. Das eigentliche Update dauert keine 10 Sekunden.

Ich hab in einem Sensor eine abgelaufene Alkaline Batterie vom DM (No Name). Immer noch über 1,4V seit Jahren. In den anderen habe ich Alkaline Energizer Industrial. Ich weiß von Verwandten, die auch Sensoren seit 2020 von mir haben, dass sie nie getauscht haben. Soweit ich weiß sind dort Alkaline Varta Industrial verbaut.

Das beschrieben Problem mit dem gleichzeitigen temporären Ausfall von 2 Sensoren hatte ich jetzt auch vor ein paar Tagen.

Hier die Beobachtungen:

  • Es waren nur 2 Sensoren betroffen (von 8 aktiven)
  • Bei einer Analyse, wann genau die beiden senden, ist aufgefallen, dass es mit 40-50ms Zeitunterschied passiert, also fast zeitgleich.
  • Die Störungen traten vorwiegend abends auf, wenn andere Elektronik in der Nähe auch eingeschaltet war.
  • Die Störungen waren etwa 2-8 Minuten lang, meist 2.

Schlussfolgerungen:

Normalerweise haben die 40-50ms Zeitunterschied ausgereicht, d.h. es war genug Zeitversatz da, dass nicht gleichzeitig gesendet wird. Wenn aber in der Nähe eine Störquelle eingeschaltet war (Fernseher z.B.), dann wurden Re-Transmits ausgelöst, d.h. der Sensor hat, weil er die Bestätigung vom Gateway nicht erhalten hat, erneut gesendet. Dadurch kam es dann zeitlich zu einer Überlagerung mit dem anderen Sensor.

Lösung:
Ich hab bei einem der 2 Sensoren die Batterie entfernt + 2 Minuten gewartet. Danach wieder eingesetzt. Seither tritt das Problem nicht mehr auf.
Zuerst habe ich es mit ~40 Sekunden Warten probiert, das hat nicht ausgereicht. Die Sensoren haben immer noch in der gleichen Sekunde jeweils gesendet. Dadurch, dass sie sehr stromsparend sind, braucht es länger, bis die interne Spannung ohne Batterie ausreichend abfällt.
Empfehlung also: 2 Minuten warten vor dem neu Einsetzen.

Das Problem wäre vermutlich irgendwann von selbst verschwunden (das kann aber lange dauern), weil jeder Sensor einen Zeitdrift hat. Es ist keine Atomuhr verbaut, und von daher kann man mit 2-20ppm Zeitfehler rechnen. Deswegen werden die Sendezeiten immer etwas auseinanderdriften.

Ich teste gerade eine neue Firmware, die mit einigen essentiellen Änderungen kommt.

Problem

Bei mehreren Sensoren passiert es irgendwann, dass sie gleichzeitig senden. Ich nenne das hier mal “Synchronisation”. Das kommt dadurch zustande, dass ihre internen Uhren einen Zeitdrift haben: eine minimale Abweichung im Takt der Echtzeituhr, im Bereich von wenigen “Parts Per Million” (ppm). Dieser Zeitdrift verschiebt den Aufwach-/Sendezeitpunkt. Angenommen ein Sensor A wacht auf um 09:01:25, 09:01:55, 09:02:25 usw., dann wird man feststellen, dass nach 10 Tagen, die Aufwachzeitpunkte verschoben sind, z.B. 09:01:26/56 usw. Der Zeitdrift ist von Sensor zu Sensor verschieden und auch temperaturabhängig. Wenn man große Zeiträume nimmt, z.B. ein Jahr, versuchen die Sensoren durch die kleinen Zeitverschiebungen irgendwann zeitgleich zu senden.
Paradoxerweise ist es sogar so, dass je kleiner der Zeitdrift zwischen 2 Sensoren ist, d.h. je synchroner ihre internen Uhren zueinander sind, umso länger kann es dauern, bis ein einmal erreichter Synchronisationszustand wieder aufgelöst werden kann. Die Sensoren bewegen sich zeitlich durch den sehr kleinen Fehler dann langsamer aufeinander zu, und auch wieder langsamer voneinander weg. Prinzipiell ist der Zeitdrift bei Canique Sensoren mit Temperatursensor sehr klein, weil Canique Sensoren den Zeitdrift der durch Temperaturänderungen entsteht (der Taktgeber ist temperaturabhängig), algorithmisch berechnen und den Takt entsprechend korrigieren. Das ist eigentlich ein qualitativ sehr hochwertiges Vorgehen und zeigt die Liebe zum Detail, aber in diesem Kontext schadet es, weil je kleiner der Zeitfehler zwischen den Sensoren, umso hartnäckiger bleiben die Probleme, wenn mal 2 Sensoren gleichzeitig senden.
Auch ein LBT (Listen Before Talk) ist hier keine 100%ige Lösung, denn im schlimmsten Fall, kann es sein, dass 2 Sensoren gleichzeitig den Kanal abhören, um festzustellen, ob ein anderer sendet, und beide zu dem Ergebnis kommen, dass der Kanal frei ist…

Lösung

Die neue Firmware hat folgende Änderungen:

  1. 1x täglich wird ein zeitlicher Offset beim Aufwachen genutzt, zwischen -1,25 Sekunden und +1,25 Sekunden. D.h. der Aufwach- und damit auch der Sendezeitpunkt, wird um diesen Offset versetzt. Das entspricht vom Konzept her ungefähr dem Herausnehmen/Wiedereinsetzen der Batterie. Dieser Offset führt zu einer Desynchronisation, für den Fall, dass sich 2 Sensoren synchronisiert haben.
  2. Wenn ein Kanal belegt ist (das wird vor dem Senden geprüft), wird jetzt ein exponentieller Backoff Algorithmus genutzt, um erneut die Kanalbelegung zu prüfen. D.h. die Zeiträume von Prüfung zu Prüfung werden größer, aber immer noch zufällig gewählt. Außerdem wird jetzt mit Time Slots gearbeitet. Kurzum: die Prüfung der Kanalbelegung ist jetzt zeitlich gesehen ausgefuchster.
  3. Der Zufallszahlen Generator ist jetzt sehr ausgefeilt und dramatisch verbessert im Vergleich zu früher. Nicht nur der Seed wurde verbessert, sondern auch der Zufallszahlen Generator selbst. Er ist jetzt auf dem modernsten akademischen Stand der Technik (Xoshiro128plusplus). Das dient dazu, zu verhindern, dass es eine Häufung bei bestimmten Zufallszahlen gibt. Zufallszahlen kommen in Punkt 2 und 4 zur Anwendung.
  4. Wenn eine Bestätigung seitens des Gateway fehlt, nach einem Sendeversuch, wird eine kurze zufällige Zeit gewartet bevor ein erneuter Versuch unternommen wird. Früher wurde der nächste Sendeversuch sofort unternommen (wenn der Kanal frei war).

Die Änderungen zusammen genommen führen dazu, dass sich 2 Sensoren nicht mehr einfach synchronisieren können, und wenn doch, dass dieser Zustand nicht gehalten werden kann.