Probleme mit HM-LC-Sw1-Pl-DN, stochastische längere Kommunikationsausfälle
Moderator: Co-Administratoren
-
- Beiträge: 705
- Registriert: 22.05.2018, 10:23
- Hat sich bedankt: 24 Mal
- Danksagung erhalten: 120 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Wir könnten doch mal das Stateregsiter alle 500ms auslesen und wenn FIF0_AVAIL_BYTES > 0 ist das READ-Flag in der Radio-Klasse setzen. Das sieht dann für den Rest so aus, als wäre ein IRQ aufgetreten.
Edit: Oder vielleicht aus FIFO_AVAIL_BYTES >= MindestPaketgröße
Edit: Oder vielleicht aus FIFO_AVAIL_BYTES >= MindestPaketgröße
Anfragen zur AskSin++ werden nur im Forum beantwortet
-
- Beiträge: 199
- Registriert: 29.05.2019, 12:51
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 65 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Ich habe eben ein Update vom dev-trilu branch auf den git geladen.
In dem Update enthalten ist ein anderes Handling in der Send Funktion und einen Radiowatchdog der alle 500ms RX_BYTES im Status Register monitort und das READ Flag setzt. Falls wir ein Problem mit dem setzen des GDO0 haben, sollte der Watchdog das lösen.
Bei mir funktionieren die Änderungen ganz gut, vielleicht hat ja jemand Lust zum testen.
Der Radiowatchdog wird mit einem define im Hauptsketch eingeschaltet:
#define RADIOWATCHDOG
Im log kommt dann von Zeit zu Zeit sowas:
RX0B heißt, es wurden 11 bytes gefunden und das READ flag gesetzt.
CRC passt natürlich nicht wenn wir eine unfertige Übertragung hatten.
Ach ja, die Paketlänge habe ich auf 23 bytes begrenzt:
CC1101_PKTLEN, 0x17,
In dem Update enthalten ist ein anderes Handling in der Send Funktion und einen Radiowatchdog der alle 500ms RX_BYTES im Status Register monitort und das READ Flag setzt. Falls wir ein Problem mit dem setzen des GDO0 haben, sollte der Watchdog das lösen.
Bei mir funktionieren die Änderungen ganz gut, vielleicht hat ja jemand Lust zum testen.
Der Radiowatchdog wird mit einem define im Hauptsketch eingeschaltet:
#define RADIOWATCHDOG
Im log kommt dann von Zeit zu Zeit sowas:
Code: Alles auswählen
ignore 0C 41 84 70 4DEB9B 000000 00 B6 31 - 369864
RX0B
CRC Failed
ignore 0C 3F 86 5A 515D57 000000 24 C8 2A - 378826
CRC passt natürlich nicht wenn wir eine unfertige Übertragung hatten.
Ach ja, die Paketlänge habe ich auf 23 bytes begrenzt:
CC1101_PKTLEN, 0x17,
-
- Beiträge: 12085
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 847 Mal
- Danksagung erhalten: 2139 Mal
- Kontaktdaten:
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Die max. Paketlänge (ohne Preamble und ohne Syncword) bei Bidcos inkl CRC ist 29 Byte
Github Actions kompiliert einen Sketch nicht mehr wegen Größenüberschreitung.Horbi hat geschrieben: ↑16.03.2023, 19:07Ich habe eben ein Update vom dev-trilu branch auf den git geladen.
In dem Update enthalten ist ein anderes Handling in der Send Funktion und einen Radiowatchdog der alle 500ms RX_BYTES im Status Register monitort und das READ Flag setzt. Falls wir ein Problem mit dem setzen des GDO0 haben, sollte der Watchdog das lösen.
Error: error sketches/HB-RC-2-PBU-LED/HB-RC-2-PBU-LED.ino: Sketch uses 30896 bytes (100%) of program storage space. Maximum is 30720 bytes.
Das sind jetzt über 500 Byte mehr als vorher (30374 Byte), selbst ohne #define RADIOWATCHDOG
-
- Beiträge: 199
- Registriert: 29.05.2019, 12:51
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 65 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Die Größe lässt sich wieder reduzieren, ich habe in der Dimmer.h einiges an Debugausgaben eingefügt. Radiowatchdog dürfte nicht so viel ausmachen.
Zum testen sollte es aber im dev-trilu passen.
Zum testen sollte es aber im dev-trilu passen.
-
- Beiträge: 5359
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 113 Mal
- Danksagung erhalten: 722 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Hab mal eine der Steckdosen damit geflasht, werde aber die nächste Zeit kaum zum Überprüfen kommen, erst Ende nächster Woche wieder.
Spannend!
Spannend!
-
- Beiträge: 199
- Registriert: 29.05.2019, 12:51
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 65 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Danke Jerome. Die Paketlänge habe ich korrigiert und ein paar Debug-Meldungen auskommentiert.
-
- Beiträge: 705
- Registriert: 22.05.2018, 10:23
- Hat sich bedankt: 24 Mal
- Danksagung erhalten: 120 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Darum kümmern wir uns, wenn es funktioniertjp112sdl hat geschrieben: ↑16.03.2023, 21:56
Github Actions kompiliert einen Sketch nicht mehr wegen Größenüberschreitung.
Error: error sketches/HB-RC-2-PBU-LED/HB-RC-2-PBU-LED.ino: Sketch uses 30896 bytes (100%) of program storage space. Maximum is 30720 bytes.
Das sind jetzt über 500 Byte mehr als vorher (30374 Byte), selbst ohne #define RADIOWATCHDOG
Anfragen zur AskSin++ werden nur im Forum beantwortet
-
- Beiträge: 537
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Hab auch mal den Steckdosensketch auf ein Testboard geflasht und schalte es per Programm minuetlich. Laeuft erstmal.
-
- Beiträge: 5359
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 113 Mal
- Danksagung erhalten: 722 Mal
Re: Abhängigkeit Ergebnis FreqTest von Atmega-Takt? Probleme mit HM-LC-Sw1-Pl-DN
Mein Teststeckdose ist bereits nach 6 h für eine knappe Stunde in bekannter Weise taub gewesen. Monitor hatte ich aber zu dem Zeitpunkt nicht dran.