Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

Reinhard.M · 14 Mai 2020, 10:04:51

Zitat von: Ralf9 am 14 Mai 2020, 09:11:40
Wenn sich dies ändert wird die config im EEPROM zurückgesetzt
Code Auswählen Erweitern
#define VERSION_1 0x41 #define VERSION_2 0x0d
Entweder eine Version mit geänderten VERSION_x Werten compilieren oder eine a-culw flashen

Jetzt habe ich mir scheinbar alles zerschossen. Mit einem CREA oder CREB kommt folgendes:

Zitatraw: detect A: timeout, no cc1101

Mit einem bA1 oder bB0 wird nichts bewirkt. Ein bA schaltet nicht auf Modul A:

Zitatraw: radio is not aktive!

Was übersehe ich? Habe übrigens die aktuellste Version verwendet:

Zitatraw: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A- B-*) - compiled at May 14 2020 09:50:49

Ralf9 · 14 Mai 2020, 10:08:02

Das sieht nach der Version für den MapleCul aus

Reinhard.M · 14 Mai 2020, 10:14:05

Ganz richtig, ich arbeite mit der MapleCUL Version.

Ralf9 · 14 Mai 2020, 10:36:51

Du testet demnach an einem MapleCul.
Wenn die MapleCul firmware nicht auf dem Maplecul funktioniert, bitte eine Version davor testen

Nachtrag:
Die MapleCul firmware kann wegen den vertauschten SPI auf einen MapleSduino nicht funktionieren

Reinhard.M · 14 Mai 2020, 12:54:13

Zitat von: Ralf9 am 14 Mai 2020, 10:36:51
Nachtrag:
Die MapleCul firmware kann wegen den vertauschten SPI auf einen MapleSduino nicht funktionieren

Ganz richtig

Ich hatte alle Anpassungen bezüglich Watchdog im neuen ino File nachgezogen. Nur die Umschaltung auf MapleCUL hatte ich vergessen. Peinlich. Jetzt läuft jedenfalls alles wieder wie am Schnürchen

Mal sehen welche Uptime ich zusammenbekomme.

Reinhard.M · 15 Mai 2020, 08:12:27

Guten Morgen Zusammen!
Mit der Uptime war es nicht so dolle, letzte Nacht hatte ich gleich mehrere Aussetzer nacheinander. Innerhalb einer halben Stunde hat der Watchdog insgesamt 5 Mal zugeschlagen:

Zitat
2020-05-14_12:42:39 myMaple state: opened
2020-05-15_01:57:28 myMaple DISCONNECTED
2020-05-15_01:58:31 myMaple CONNECTED
2020-05-15_01:58:33 myMaple state: opened
2020-05-15_02:00:06 myMaple DISCONNECTED
2020-05-15_02:00:39 myMaple CONNECTED
2020-05-15_02:00:42 myMaple DISCONNECTED
2020-05-15_02:01:07 myMaple CONNECTED
2020-05-15_02:01:19 myMaple state: opened
2020-05-15_02:03:15 myMaple DISCONNECTED
2020-05-15_02:04:21 myMaple CONNECTED
2020-05-15_02:04:23 myMaple state: opened
2020-05-15_02:12:42 myMaple DISCONNECTED
2020-05-15_02:13:45 myMaple CONNECTED
2020-05-15_02:13:47 myMaple state: opened
2020-05-15_02:20:35 myMaple DISCONNECTED
2020-05-15_02:20:38 myMaple CONNECTED
2020-05-15_02:20:40 myMaple DISCONNECTED
2020-05-15_02:21:08 myMaple CONNECTED
2020-05-15_02:21:10 myMaple state: opened
2020-05-15_02:22:10 myMaple DISCONNECTED
2020-05-15_02:23:10 myMaple CONNECTED
2020-05-15_02:23:12 myMaple state: opened
2020-05-15_02:24:16 myMaple DISCONNECTED
2020-05-15_02:25:18 myMaple CONNECTED
2020-05-15_02:25:20 myMaple state: opened

Davor war ca. 13 Stunden und danach is bislang Ruhe. Den Watchdog habe ich auf ~5 Sekunden Trigger eingestellt. Das Ganze führe ich auf einem MapleCUL mit der Firmware "version: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 14 2020 10:47:57" durch. Hat eventuell jemand eine Idee wie ich hier mehr Informationen herauziehen kann um dem Fehler auf die Schliche zu kommen?

Ralf9 · 15 Mai 2020, 20:21:03

Beim Maple Mini gibt es debug Möglichkeiten, damit kenne ich mich aber nicht aus.

Ich mache gerade ein Dauertest mit dem BananaPI als fhem Testserver.

Nach ca 1 Tag und 19 Stunden hatte ich einen Absturz, die LED ist aus geblieben, ich konnte ihn mit dem upload-reset Program reseten.
Nun habe ich eine uptime von 2 Tagen und 22 Stunden.
Um die changen für einen Absturz zu erhöhen, und damit den Fehler evtl ein wenig eingrenzen zu können, habe ich vor mit 2-3 MapleSduino parallel zu testen.

Mich interessiert folgendes:

- lässt sich bei jedem Absturz der MapleMini mit dem upload-reset Program reseten?

- gibt es Abstürze, wenn nur das Radio A (FSK) aktiv ist?

- gibt es Abstürze, wenn nur das Radio B (SlowRF) aktiv ist?

- gibt es Abstürze, wenn anstatt USB das RX/TX verwendet wird? z.B. mit einen USB Seriell Wandler
Dazu muß bei Arduino IDE folgendes konfiguriert werden:
USART Support: generic Serial
USB Support: keine

Hängt der Maple an einem Testsystem oder am Produktivsystem?
Werden beim SlowRF besonders viele Sensoren (auch von Nachbarn) empfangen?

Ich habe 9 Temperatursensoren und die WH3080 Wetterstation.
Bei FSK Mode1 habe ich nur ein Sensor

Reinhard.M · 16 Mai 2020, 10:50:52

Auf dem FSK Mode 1 habe ich ebenfalls nur einen Sensor, auf dem SlowRF laufen bis zu 3 Temperatursensoren auf. Als der Watchdog zugeschlagen hat waren es aber nur ein oder zwei Sensoren. Der Mode1 Sensor sendet etwa alle 4 Sekunden, die anderen bestenfalls alle 30 Sekunden. Overload sollte da eigentlich nicht auftauchen. In einem Reset Fall war der Mode1 Sensor bereits seit mehreren Minuten ruhig, hat also nicht mehr aufgezeichnet. Das geschieht bei mir ja immer wieder mal und kann Stunden dauern (mit einem XQ/XE konnte ich heute das Modul wieder reaktivieren). Könnte das eventuell ein Indiz sein, dass das SlowRF Modul für den Ärger sorgt? Ich habe jedenfalls verbose auf 4 gesetzt und warte jetzt auf den nächsten Aussetzer. Eventuell zeigt sich ja unmittelbar davor etwas in der Aufzeichnung. Wenn ich es hinbekomme werde ich auch mal das RX/TX Interface testen.
Ganz am Rande, ich würde mir gerne einen MapleSduino zusammenbauen. Kann mir jemand sagen wie ich an das Material komme?

killah78 · 16 Mai 2020, 22:08:26

Hi,
hier meine Info:
ich habe den MapleSduino an meinem Testsystem. Ist ein Docker Container auf dem gleichen System wie meine Produktivumgebung.
Ich habe 7 eigene Temperatursensoren, empfange aber noch ein paar andere aus der Nachbarschaft. Daneben habe ich auch noch eine 1080 Wetterstation. Lacrosse Mode 2 habe ich nur einen Temperatursensor.
Ich hatte den MapleSduino in Betrieb nur mit Radio A installiert, zur Zeit mit A FSK und B SlowRF.
Er läuft jetzt seit 9 Tagen ohne Absturz (Hatte bisher noch nie einen).
Lediglich diese Aussetzer, mal besser mal schlechter.
Ich habe den Bootloader 2.0, nicht gepatched.

Wie meinst du das mit zusammenbauen? Platine? Die bekommst du von Ranseyer. Die 868 und 433 Stamps habe ich von Ali und den Maple auch. Ich denke es handelt sich da bei mir um einen Maple Clone. Gehäuse habe ich noch nicht dafür.
Gruss

Ralf9 · 17 Mai 2020, 11:56:12

mittlerweile habe ich eine uptime von 4 Tagen und 14 Stunden.

Zitatmit einem XQ/XE konnte ich heute das Modul wieder reaktivieren

Welches der Module Radio A (FSK) oder Radio B (SlowRF) musst Du ab und zu reaktivieren?
Zu kannst die auch einzeln mit XQA / XEA oder XQB / XEB reaktivieren

Hast Du schon mal das ccmode=4 getestet, gibt es eine Verbesserung?

Gruß Ralf

Reinhard.M · 17 Mai 2020, 14:36:06

Zitat von: Ralf9 am 17 Mai 2020, 11:56:12
Welches der Module Radio A (FSK) oder Radio B (SlowRF) musst Du ab und zu reaktivieren?

Es ist immer das A-Modul. Meistens habe ich mit bA auf das Modul geschaltet und mit WS36/WS34 zurückgesetzt. Mit XQA/XEA kann ich es aber auch mal versuchen.

Ralf9 · 17 Mai 2020, 14:39:48

ZitatEs ist immer das A-Modul.

Passiert dies auch mit ccmode=4

Reinhard.M · 17 Mai 2020, 15:04:26

Habe ich gerade aktiviert und teste jetzt Modul A mit ccmode=4:

Zitat

Bank__ 0 1 2 3 4 5 6 7 8 9
Radio_ B A*- - - - - - - -
N_____ 0 0 2 3 4 - - - - -
ccmode 0 4 3 3 2 - - - - -

Reinhard.M · 18 Mai 2020, 09:47:15

Zitat von: Ralf9 am 17 Mai 2020, 14:39:48
Passiert dies auch mit ccmode=4

Modul-A lief mit ccmode=4 und hat heute Morgen wieder den Empfang eingestellt. Nach 1:20 Stunde habe ich das Modul-A mit XQA/XEA "zurückgesetzt", seitdem läuft der Empfang wieder problemlos. Weiterhin Lacross Mode-1 mit ccmode=4.

juergs · 18 Mai 2020, 09:59:37

Hallo Reinhard.M,

versuche mal für das SignalDuino-Attribut "verbose" auf 5 zu stellen und den Zeitpunkt des Aussetzens mit dem Log zu "synchronisieren"
und das Ergebnis hier einzustellen. (Als Auszug oder als gesamtes Log im Anhang.)

Da mit Aussagen wie: ".. hat ausgesetzt" uns bei der Fehlersuche nicht unbedingt bei der Fehlereingrenzung geholfen ist.

Ist in etwa gleichzusetzen wie: ... es ist ein Fehler passiert!...

Vielleicht ist es ein bestimmter Typ von Sensor oder Telegramm, evtl. überlagert mir mehreren gleichzeitigen Sendeversuchen, die nicht dekodiert werden konnten, wie z.B. bei mir:

Zitat2020.05.01 01:41:09 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data B1DF8, code B1D
2020.05.01 01:42:46 3: sduino: Unknown code u40#327B0110, help me!
2020.05.01 01:43:17 3: sduino: Unknown code u19#327B00, help me!
2020.05.01 01:44:07 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data C77E1, code C77
2020.05.01 01:44:19 3: sduino: Unknown code u19#93D80, help me!
2020.05.01 01:44:19 3: sduino: Unknown code u40#4F600, help me!
2020.05.01 01:46:46 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 0B0BF, code 0B0
2020.05.01 01:51:21 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 00000, code 000
2020.05.01 01:51:32 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data FC380, code FC3
2020.05.01 01:51:32 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data E01A6, code E01
2020.05.01 01:58:16 3: sduino: Unknown code u40#327B010B34, help me!
2020.05.01 02:07:34 3: sduino: Unknown code u19#0213E0, help me!
2020.05.01 02:07:51 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 058EF, code 058
2020.05.01 02:07:51 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 38068, code 380
2020.05.01 02:08:05 3: sduino: Unknown code u40#327D0, help me!
2020.05.01 02:08:05 3: sduino: Unknown code u19#0427C, help me!
2020.05.01 02:11:11 3: sduino: Unknown code u19#0106DC, help me!
2020.05.01 02:16:45 1: sduino: SD_UT_Parse UNDEFINED sensor unknow

Ich habe hier viele "Nachbarschafts"-Sensoren die "unsynchronisiert" in der Gegend herumfunken und sich ggf. auch nicht an die Sendepausen-Regel halten
und ggf. auch gegenseitig stören.

Das ist im 443Mhz beim mir ebenfalls häufig der Fall. Dann registriere ich Aussetzer von einigen Minuten bis Stunden bis der Sendezeitpunkt bei den Sensoren wieder auseinanderläuft.
Sehr selten kommt der Sduino oder auch mal der RASPI ins "Stocken", aber ob man von einer generellen "Instabilität" reden kann, wage ich zu bezweifeln.

Grüße,
Jürgen

Als Beispiel habe ich mal ein MapleCUL-Plot von einem CUL_TX-Sensor auf 433MHz, der ca. 20cm von der Antenne entfernt ist.

Ich glaube solche "Situationen" lassen sich nicht verhindern, da die Sensoren nur nach festgelegtem Schema senden und nicht "horchen", ob gerade jemand anderes funkt,
wie es z.B. bei einem (CAN)-Bus gemacht wird...

Allerdings grenzt das die Möglichkeit eines oder mehrerer Bugs auch nicht aus. ;-(