Probleme mit HM-LC-Sw1-Pl-DN, stochastische längere Kommunikationsausfälle

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

papa
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

Beitrag von papa » 15.03.2023, 07:53

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
Anfragen zur AskSin++ werden nur im Forum beantwortet

Horbi
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

Beitrag von Horbi » 16.03.2023, 19:07

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:

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
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,

papa
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

Beitrag von papa » 16.03.2023, 21:03

Da bin ich mal auf die Ergebnisse gespannt.
Anfragen zur AskSin++ werden nur im Forum beantwortet

jp112sdl
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

Beitrag von jp112sdl » 16.03.2023, 21:56

Horbi hat geschrieben:
16.03.2023, 19:07
Ach ja, die Paketlänge habe ich auf 23 bytes begrenzt:
Die max. Paketlänge (ohne Preamble und ohne Syncword) bei Bidcos inkl CRC ist 29 Byte
Bildschirm­foto 2023-03-16 um 21.56.50.png
Horbi hat geschrieben:
16.03.2023, 19:07
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.
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

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Horbi
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

Beitrag von Horbi » 16.03.2023, 22:16

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.

Matsch
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

Beitrag von Matsch » 16.03.2023, 22:37

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!

Horbi
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

Beitrag von Horbi » 17.03.2023, 07:42

jp112sdl hat geschrieben:
16.03.2023, 21:56
Die max. Paketlänge (ohne Preamble und ohne Syncword) bei Bidcos inkl CRC ist 29 Byte
....
Das sind jetzt über 500 Byte mehr als vorher (30374 Byte), selbst ohne #define RADIOWATCHDOG
Danke Jerome. Die Paketlänge habe ich korrigiert und ein paar Debug-Meldungen auskommentiert.

papa
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

Beitrag von papa » 17.03.2023, 09:05

jp112sdl 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
Darum kümmern wir uns, wenn es funktioniert :-)
Anfragen zur AskSin++ werden nur im Forum beantwortet

HMSteve
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

Beitrag von HMSteve » 17.03.2023, 10:29

Hab auch mal den Steckdosensketch auf ein Testboard geflasht und schalte es per Programm minuetlich. Laeuft erstmal.

Matsch
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

Beitrag von Matsch » 17.03.2023, 10:33

HMSteve hat geschrieben:
17.03.2023, 10:29
Hab auch mal den Steckdosensketch auf ein Testboard geflasht und schalte es per Programm minuetlich. Laeuft erstmal.
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.

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“