RadioNRF: better time based channel hopping

[SW-Niko]

Änderungen:

• Neue Methode für das Umschalten der Rx Kanäle
• Senden auf den Rx Kanal synchronisieren
• Beim Senden die Anzahl der Wiederholungen und die Wartezeit auf die Payload ausrichten

Siehe auch #2979

[SW-Niko]

Auf meinem System hat sich die Re-Request-Rate = TX Re-Request Fragment / RX Success von 132% auf 60% verringert.

Alt:

Re-Request-Rate = 132%

Neu:

Re-Request-Rate = 60%

Update 10.07.26

Re-Request-Rate < 10%

Beim Testen bitte noch folgendes beachten:

• Nach dem Installieren am besten die Inverter neustarten.
• Es dauert 1-2 Tage, bis die niedrigsten Re-Request Werte erreicht werden.

Das kann auch mit meinem alten HM-300 (Hardware / Software) zusammenhängen, aber ich habe festgestellt das der Inverter sich nach einem Neustart am schnellsten auf die DTU synchronisiert.

Im Prinzip versuche ich das Wechseln der Kanäle möglichst präzise mit 4ms einzuhalten. Und auch beim Senden von Befehlen an den Inverter versuche ich das.
Allerdings ist das nur bedingt möglich. Ich habe auch versucht das Wechseln der Kanäle über einen 4ms HW-Timer Interrupt zu machen, aber das hat nicht geklappt. Das Programm ist immer abgestürzt, wenn ich aus dem Interrupt den NRF24 angesprochen habe. Ich habe dann aufgegeben .... Meine Programmierfähigkeiten sind begrenzt. 😞

Ich denke die Kommunikation kann noch weiter verbessert werden. Vor allem habe ich Zweifel was die 4ms und die Reihenfolge der Kanäle betrifft. 🤔

Update 10.07.26
Verwende jetzt 5,152ms (Danke @znuh 👍 )

[Snusme83]

@SW-Niko : Wenn ich diese zwei Dateien bzw. die Texte davon in die Dateien reinkopiere und auf den ESP32-S3 flashe, dann sollte ich von besseren Re-Request -Raten profitieren.

Hab es nur kurz laufen lassen, da hab ich keine Besserung festgestellt.

Dann habe ich aber gelesen, dass es 1-2 Tage laufen müsse.

[SW-Niko]

Hab es nur kurz laufen lassen, da hab ich keine Besserung festgestellt.

Ja kurz nach dem Update gehen bei mir auch die Re-Request-Rate rauf. Darum habe ich oben auch beschrieben wie man das testen soll.

Beim Testen bitte noch folgendes beachten:

• Nach dem Installieren am besten die Inverter neustarten.
• Es dauert 1-2 Tage, bis die niedrigsten Re-Request Werte erreicht werden.

[Snusme83]

Ok, hab den ESP mit deinen zwei Dateien jetzt in Betrieb.

Die beiden TSUN sind von Anfang an > 90%,

der Hoymiles HM1500 22%!

Ich lass es mal laufen jetzt - Wechselrichter hab ich softwareseitig neu gestartet, nicht vom Netz genommen.

[SW-Niko]

Hallo @tbnobody ,

Ich konnte weitere Verbesserungen erzielen.

Auf meinem System ist die Request-Rate von 132% auf unter 10% gesunken.
Ich denke das Systeme mit mehreren HM-Invertern jetzt viel besser laufen, weil jeder Inverter sich gut auf die DTU synchronisieren kann und damit alle Inverter synchron zur DTU laufen.

Testen kann ich das leider nicht. Habe nur einen HM-300.

[Harisjems]

Hallo @SW-Niko
Und zuerst danke an euch Entwickler ( Coder) die uns Teil von eure Arbeit zum Verfügung stellt.
Ich habe deine Version heute zum Testen eingespielt.
Zunächst war keine Verbindung zum HM-Wechselrichter hergestellt worden, was mich anfänglich verwunderte.
Ich habe mir dann die Einstellungen /in der DTU Einstellungen angesehen und festgestellt, dass das Abfrageintervall auf 3000 Sekunden eingestellt war.Es ist also kein Wunder, dass es nicht kam. 😃
Habe es wieder auf 5 Sekunden umgestellt (war vorher auch so, ist meine Standard-Abfrage). Ich bin kein Freund von Hardware-Vergewaltigung. 😁 Ich verlange nur, dass es so schnell ist wie ich.des wegen 5 Sekunden.
Wäre es möglich, dass jemand dies gegentestet?
An sonsten ist Geschrei da.
Verwendete Hardware.
PCB Pro von Christian (glaube ich)
3WR HM-Serie (Tsun600, HM600, HM 1500)
OTA Flash
Mfg

[SW-Niko]

@Harisjems
Du hast aber jetzt nicht die Version von meinem Repro installiert, oder?
Hattest du vorher OpenDTU oder OpenDTU-OnBatterie installiert?

[Harisjems]

Hallo @SW-Niko
Ich habe deine Version, OpenDTU, verwendet von GitHub Seite,zuvor hatte ich onBatterie.
Habe erst jetzt bemerkt, dass es auch eine On-Batterie-Version davon gibt. Verdammt! ☺️
Meinst du liegt das da Problem.
Ich war die Meinung,das OTA Flash von onBatterie auf Standard OpenDTU Problemlos möglich ist.Anderes Rum aber nicht,wegen Partition Layout usw.

[SW-Niko]

Meinst du liegt das da Problem.

Ich denke ja. Das Problem liegt in der Konfigurations-Datei "config.json". Es gibt eine automatische Migration zu einer neueren Version. Aber keine zu einer älteren Version.
Vermutlich ist das auch so wenn man von OpenDTU-OnBattery zurück auf Open-DTU geht.

[xX-nichtlachen-Xx]

Ich werde den sauberen Gazelle Ansatz auch mal 1 zu 1 in meinem NRF24+ Utilities umsetzen/testen.
Da gibt es einige schöne Features :-]