Entwicklung SIGNALduinoAdv Empfänger Firm- und Hardware V4 für Raspi Pico

[DerD]

Eine Frage zur LAN Version. Der sDuino hngt direkt an der FB, der Rechner mit dem Modul ist eine Zeit lang offline. Wenn er dann wieder da ist, klappt die Neuverbindung nicht recht. Auch ein Reset geht nicht.
Schlußendlich geht er auf disconnected, dann muss ich Spannung kurz trennen um ihn wieder ans laufen zu bekommen. Vermutlich würde ein Reset am Pico reichen, ist derzeit aber nicht vorgesehen.

Ping auf die IP antwortet.

2026.04.14 17:17:52 1: 192.168.1.88:23 disconnected, waiting to reappear (MySignalPicoLAN)
2026.04.14 17:17:52 1: MySignalPicoLAN/define: 192.168.1.88:23
2026.04.14 17:17:52 1: MySignalPicoLAN/init: 192.168.1.88:23
2026.04.14 17:17:52 1: 192.168.1.88:23 reappeared (MySignalPicoLAN)
2026.04.14 17:17:55 3: MySignalPicoLAN/init: disable receiver (XQ)
2026.04.14 17:17:55 3: MySignalPicoLAN/init: get version, retry = 0
2026.04.14 17:18:05 3: MySignalPicoLAN/init: get version, retry = 1
2026.04.14 17:18:45 3: MySignalPicoLAN/init: get version, retry = 2
2026.04.14 17:19:55 3: MySignalPicoLAN/init: get version, retry = 3
2026.04.14 17:19:55 2: MySignalPicoLAN/init retry count reached. Reset
2026.04.14 17:19:55 3: MySignalPicoLAN reset
2026.04.14 17:19:55 3: Opening MySignalPicoLAN device 192.168.1.88:23
2026.04.14 17:19:55 1: MySignalPicoLAN/define: 192.168.1.88:23
2026.04.14 17:19:55 1: MySignalPicoLAN/init: 192.168.1.88:23
2026.04.14 17:19:55 3: MySignalPicoLAN device opened
2026.04.14 17:19:58 3: MySignalPicoLAN/init: disable receiver (XQ)
2026.04.14 17:19:58 3: MySignalPicoLAN/init: get version, retry = 0
2026.04.14 17:20:08 3: MySignalPicoLAN/init: get version, retry = 1
2026.04.14 17:20:48 3: MySignalPicoLAN/init: get version, retry = 2
2026.04.14 17:20:50 3: MySignalPicoLAN reset
2026.04.14 17:20:50 3: Opening MySignalPicoLAN device 192.168.1.88:23
2026.04.14 17:20:50 1: MySignalPicoLAN: Can't connect to 192.168.1.88:23: No such file or directory
2026.04.14 17:20:50 1: MySignalPicoLAN: Can't connect to 192.168.1.88:23: 192.168.1.88: Verbindungsaufbau abgelehnt (111)
2026.04.14 17:20:50 3: MySignalPicoLAN: 192.168.1.88: Verbindungsaufbau abgelehnt (111)
2026.04.14 17:21:58 3: MySignalPicoLAN/init: get version, retry = 3
2026.04.14 17:21:58 3: MySignalPicoLAN/init: get version aborted because of STATE = disconnected!

[Ralf9]

Muss ich mir anschauen, bei kurzem fhem offline hatte ich bis jetzt beim neuverbinden noch keine Probleme

[DerD]

In dem Zusammenhang noch eine Frage, wie bekomme ich ihn wieder verbunden nach einem?

Code Auswählen Erweitern

set sDuino close

Code Auswählen Erweitern

DevState
   
closed
Ein "set open" finde ich leider nicht.

[Ralf9]

es gibt dafür "set sDuino reset"

[denis.robel]

Ich finde das Projekt sehr interessant und würde es ebenfalls aufbauen wollen. Ich habe aber dazu noch eine Frage:

Welche CC1101 Module genau werden denn auf die Platine aufgelötet bzw. wo bekomme ich die beschafft?

Das sieht aus wie komplette SMD Module, die ich aber nirgend wo finde.

[Ralf9]

E07-900MM10S und E07-400MM10S z.B. bei aliexpress

Ich finde die cc101 Module E07-400M10S und E07-900M10S recht interessant, da müsste man doch durch die Abschirmung schwächere Signale besser empfangen können.
Hat die schon mal jemand gekauft?

das scheinen auch andere bemerkt zu haben: externer Link
Interessant auch die Ergebnisse für die kleineren E07-900MM10S, die aber kein IPEX onboard haben

[Ralf9]

Wenn kein LAN benötigt wird, gibts alternativ auch den RP2040-Zero (Pinout siehe Anlage). Wer eine LED benötigt, der muss diese mit Vorwiderstand an GP25 anlöten.

[DerD]

Die Teile hatte ich mir bei Ali auch schon mal angeschaut. Wenn 2 Module reichen, könnte das ja so wie im Bild aussehen. Auch GPIO22 steht bei den Modulen nicht direkt zur Verfügung, damit würde Bank D auch wegfallen.

Falls Interesse besteht, route ich ich das aus. Hilfreich wäre auch die Info, ob jeweils für doppeltes Modul mit break-out-board oder einfach E07-x00MM10S reicht.

[DerD]

Muss ich mir anschauen, bei kurzem fhem offline hatte ich bis jetzt beim neuverbinden noch keine Probleme

Hi Ralf,
hattest du schon Zeit dir das mal anzusehen? Passiert zwar selten, aber doch ab und an mal

[Ralf9]

Alle wieviele Tage kommt es ungefähr vor?

Hast Du den Watchdog aktiviert?

Per default ist der Watchdog nicht aktiv. Er hat einen Timer von 8 Sek.
Es gibt dafür die folgenden Raw-Befehle:
TW1 - Watchdog enable (erst nach Reset wirksam)
TW0 - Watchdog disable (erst nach Reset wirksam)
TWZ - zum Rücksetzen des WDT Markers bei get Version
TWT - delay 10 Sek zum Testen des watchdogs
TWR - Software Reset

Bei "get Version" wird folgendes angezeigt:
w - watchdog enabled
WDT - Watchdog hat ausgelöst
rr - resetreason, wenn ungleich 1

[DerD]

"get version" gibt ein "version: V 4.2.4-dev260212 SIGNALduinoAdv PicoLAN cc1101 (R: B0*) - compiled at Feb 12 2026 13:40:09", daran ändert auch ein "set raw TW1" nichts

nur im logfile bei verbose=4 finde ich dann ein "2026.10.30 08:13:20 4: set MySignalPicoLAN raw TW1
2026.10.30 08:13:20 4: MySignalPicoLAN/msg READ: watchdog_enable FSKdebug=0"

das ist nicht regelmäßig, sondern nur mein fhem server kurz vom Netz war. Anpingen kann ich die IP dann noch, aber es erfolgt keine weitere reaktion

[Ralf9]

Der Watchdog ist erst nach einem Reset aktiv.

das ist nicht regelmäßig, sondern nur mein fhem server kurz vom Netz war. Anpingen kann ich die IP dann noch, aber es erfolgt keine weitere reaktion

Lässt sich das reproduzieren?

Ich kann es bei mir nicht reproduzieren.
Ich habe mit fhem restart eine kurze und mit shutdown eine etwas längere Unterbrechung getestet.

[DerD]

Hallo Ralf,

im Testbetrieb hatte ich das ja reproduzierbar immer dann, wenn mein fhem Rechner schlafen gegangen ist, siehe post vom April. Das macht mein Lifesystem ja aber nicht.

Anhand des Fehlerbildes und der Codebasis des SignalDuino habe ich mal Claude befragt. Wenn ich mal davon ausgehe, dass es da wenig Änderungen gab. Dazu habe ich folgendes erhalten:

Hauptverdacht: ein toter Client blockiert neue Verbindungen

Code Auswählen Erweitern

cpp
void ethernetLoop()
{
  if (server.available()) {
    if (!client || !client.connected()) {
      if (client) client.stop();
      client = server.available();
      ...

Ein neuer Client wird nur akzeptiert, wenn der alte laut client.connected() getrennt ist. Bricht die Verbindung zu fhem ohne sauberen Abschluss weg (fhem-Neustart, Netzwerkausfall, Kabel gezogen), bekommt der W5500 kein FIN und meldet den Socket weiter als ESTABLISHED. Der W5500 hat TCP-Keepalive standardmäßig aus, daher bleibt dieser Zustand sehr lange bestehen. In dieser Zeit wird jeder neue Verbindungsversuch von fhem ignoriert. Das passt zu ,,nicht immer ein sauberes Reconnect".

Fix, neue Verbindungen sollen Vorrang haben und den alten Client ersetzen:

Code Auswählen Erweitern

cpp
void ethernetLoop()
{
  EthernetClient newClient = server.accept();   // neue Verbindung annehmen
  if (newClient) {
    if (client) client.stop();                  // alten (evtl. toten) Client verwerfen
    client = newClient;
    MSG_PRINT(F("New client:"));
    MSG_PRINTLN(client.remoteIP());
  }
}

server.accept() gibt es in der Ethernet-Library ab Version 2.0 (Arduino-Pico-Core bringt sie mit). Dann nimmt die Firmware die neue fhem-Verbindung immer an und wirft die alte weg. Zusätzlich würde ich den Keepalive-Timer des W5500 setzen, damit tote Verbindungen auch ohne Reconnect erkannt werden (Sn_KPALVTR, Einheit 5 s, z. B. Wert 6 = 30 s). Je nach Library-Version geht das über client.setConnectionTimeout() oder direkt über das Register.

Zum Reset-Puls

Code Auswählen Erweitern

cpp
digitalWrite(PIN_WIZ_RST, LOW);
delayMicroseconds(500);          // exakt das Datenblatt-Minimum
digitalWrite(PIN_WIZ_RST, HIGH);
Ethernet.begin(...);             // sofort danach, ohne Wartezeit

Das ist knapp. Ich würde auf 10 ms LOW und danach 100 bis 150 ms Wartezeit ändern. Allein das erklärt aber nicht, dass nur ein Hardware-Reset hilft, denn setup() macht den Puls bei jedem Neustart.


Weiterhin hat er folgendes festgestellt, was aber in meinem Fall als Ursache mit ziemlicher Sicherheit ausgeschlossen werden kann, obwohl der W5500 bei mir die IP über DHCP bekommt.

Ein weiterer Verdacht: DHCP

Der Quelltext hat zwei Betriebsarten: feste IP oder DHCP (ip[3] == 0). Im gesamten Code findet sich kein Ethernet.maintain(), und das wird für DHCP-Lease-Verlängerung benötigt.


Sind nur Vermutungen, klingt aber für mich zumindest plausibel.

Edit, ich bin noch einen Schritt weiter und konnte es nun sauber mittels Scripten reproduzieren:

Reproduktion ohne fhem: Ein Skript baut 30 bis 45 Mal eine TCP-Verbindung auf, sendet "V" und wartet bis zu 5 s auf die Versionszeile, danach schließt es sauber. Ergebnis in Abhängigkeit von der Zeit zwischen Verbindungsaufbau und dem Senden von "V":

- sofort (0 s): 45 von 45 OK
- 0,3 s: 24 von 30 OK
- 0,6 s: 22 von 30 OK
- 1 s: 17 von 30 OK
- 2 s: 16 von 30 OK
- 3 s (so wie fhem es macht): 19 von 30 OK

Die Fehlschläge treten fast immer paarweise auf (zwei Versuche hintereinander, dann einige Erfolge). Auch mit 15 s Wartezeit kommt keine verspätete Antwort. Ob die Verbindung beim Pico also gar nicht als Client übernommen wird, kann ich von außen nicht sehen.

Verdacht (nur aus dem 4.2.3-Quelltext, den 4.2.4-PicoLAN-Code kenne ich nicht): ethernetLoop() übernimmt einen neuen Client nur, wenn !client || !client.connected(), und server.available() liefert nur Verbindungen, bei denen schon Daten anliegen. Eine halb offene oder noch nicht übernommene Verbindung könnte dann weitere blockieren. Ein möglicher Ansatz wäre server.accept() und den alten Client bei jeder neuen Verbindung zu verwerfen.

Kannst du die Stelle prüfen oder mir sagen, wo der Quelltext der PicoLAN-Version liegt (Repo oder Branch)? Skript und Logs stelle ich gern zur Verfügung, und ich teste auch eine Testfirmware.

[Ralf9]

Hallo Dieter,

kannst Du bitte mal das Script posten?

Der W5500 hat TCP-Keepalive standardmäßig aus, daher bleibt dieser Zustand sehr lange bestehen. In dieser Zeit wird jeder neue Verbindungsversuch von fhem ignoriert. Das passt zu ,,nicht immer ein sauberes Reconnect".

Kannst Du bitte mal Claude befragen wo das steht, daß beim W5500 das TCP-Keepalive standardmäßig aus ist?
Hier steht, daß es standardmäßig mit 1000 ms ein ist.
https://docs.arduino.cc/libraries/ethernet/#Client%20Class

Falls das TCP-Keepalive beim W5500 standardmäßig aus ist, reicht es evtl schon das TCP-Keepalive zu aktivieren.


Zum Reset-Puls:
Das Datenblatt-Minimum bei Low sollte doch ausreichend sein.
Steht im Datenblatt was über die minimale Wartezeit zwischen high und Ethernet.begin(...);?

Gruß Ralf

[DerD]

Hallo Ralf,

das sagt er nach Rückfrage, der Reset war ja auch mehr erwähnt denn als Grund angegeben. Das script im Anhang.

1. TCP-Keepalive

Belegt: Das Register Sn_KPALVTR hat den Standardwert 0x00, und bei 0 läuft die automatische Keepalive-Funktion laut Datenblatt nicht. ,,Standardmäßig aus" stimmt also.
Zu stark war ,,daher bleibt dieser Zustand sehr lange bestehen". Ein Keepalive-Paket wird nach den WIZnet-Forenbeiträgen erst gesendet, nachdem über die Verbindung mindestens einmal Daten gelaufen sind. Vor allem aber erkennt der W5500 eine tote Verbindung auch ohne Keepalive, sobald er selbst Daten sendet: Er wiederholt das Paket (Standard laut WIZnet-Mitarbeiter: Wartezeit 200 ms, 8 Versuche), meldet dann einen Timeout und schließt den Socket. Die genaue Dauer folgt aus der Formel auf S. 39 des Datenblatts, die ich nicht nachgerechnet habe.
Folge für unsere Analyse: Ein toter Client bleibt nur dann lange bestehen, wenn der Pico nichts an ihn sendet, etwa bei ausgeschaltetem Empfänger (XQ) oder funkstiller Umgebung. Bei laufendem Empfang und Funkverkehr wäre die Verbindung nach einem Rechnerausfall vermutlich nach kurzer Zeit freigegeben. Meine erste Erklärung (PC offline, alter Client blockiert) ist damit weniger sicher, als ich sie dargestellt habe. Besser belegt ist der Befund aus deinen Messungen: eine neue Verbindung, die erst still offen steht und dann Daten schickt, wird gelegentlich nicht bedient. Das haben wir direkt reproduziert.

2. Reset-Zeiten

Das Datenblatt sagt:

RSTn muss mindestens 500 µs auf LOW gehalten werden (Reset Cycle Time T_RC, Minimum).
Von RSTn bis zum Einrasten der PLL (T_PL) vergehen höchstens 1 ms.

Daraus folgt:

Mein ,,danach ca. 50 ms warten" steht nicht im Datenblatt. Das war falsch bzw. unbelegt.
Meine Empfehlung ,,10 ms LOW und 100 bis 150 ms warten" ist ein vorsichtiger Erfahrungswert und keine Anforderung. Formal genügt ≥ 500 µs LOW und danach etwas mehr als 1 ms.
Der Pulscode der Firmware (500 µs) liegt genau am Minimum. Das ist knapp, aber konform. Als Ursache deines Fehlers halte ich ihn für unwahrscheinlich, besonders weil der Fehler mit einem funktionierenden Reset trotzdem reproduzierbar ist.


Aufruf des Scriptes mit

Code Auswählen Erweitern

python3 pico_connect_test.py 192.168.1.xxx --runs 30 --delays 1 --send-delay 1
python3 pico_connect_test.py 192.168.1.xxx --runs 30 --delays 1 --send-delay 2
python3 pico_connect_test.py 192.168.1.xxx --runs 30 --delays 1 --send-delay 3 --wait 15