Feature Request: add RPD bit (Report Power Detector) from radio module to the frondend to assess receive signal strength

[Teggemann]

Hi friends,
it might be nice to report the status of the RPD bit (Report Power Detector) of the radio module under System -> Radio (and MQTT). This might give a glimpse about the signal strength of received transmissions.

The RPD bit indicates if the received signal strength is above or below -64dBm. It might already be used as carrier detect (as it was called in the nRF24l01 the predecessor).

The information is not very precise but might give a hint about radio connection problems.

See datasheet section 6.4 page 24 (and 56). https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf

[beegee3]

thank you for the hint.
Currently I'm working on hmRadio trying to improve the quality. My experience with RPD is that calling mNrf24.testRPD() always returns false (i.e. signal strength is below -64dBm). Unfortunately there is no possibility to get the strength value itself.

[knickohr]

Ich verlinke hierzu mal Issue #1050

Das Ganze ist umgesetzt, aber leider kommt nur äußerst selten ein true/good Signal.

[lumapu]

ist das auch in der @oberfritze Version so?

[knickohr]

Nein, die Version von @oberfritze macht eine Heuristik die auf guten oder schlechten Abfragen basiert. Er generiert damit also einen Pseudo-Empfangsqualität (die im übrigen sehr gut funktioniert und sich immer den besten Kanal raus fischt).

[beegee3]

das sind zwei verschiedene Sachen: RDP ist eine Aussage über die Signalstärke und scheint nicht wirklich gut zu funktionieren. Vielleicht weil in der Regel nur Nachbauten vom Nordic nRF24L01+ eingesetzt werden?
Die @oberfritze Version bewertet die einzelnen Kanäle und bevorzugt für das Senden den, der am Häufigsten Antworten erhält (wie @knickohr schon beschrieben hat, ist das eine Qualitätsaussage, keine zur Signalstärke).
Das ist sicher eine gute Methode, wenn man im Umfeld länger anhaltende oder dauerhafte Störsignale hat, die den Empfang auf einzelnen Kanälen vermiesen. Ich denke nur, den meisten Anwendern bringt das keinen Vorteil, kann mich aber auch irren.
Daher die Frage an @knickohr: hast du das Gefühl, deine ohnehin guten Statistiken haben sich mit der @oberfritze Version noch verbessert?

[knickohr]

@beegee3
Ich mußte gerade schmunzeln ! 😁

Meine guten Statistiken sind durch diese Heuristikversion mehr als besser geworden. Ich hatte vorher so ca. 1 bis 3% no answer, jetzt habe ich vielleicht mal insgesamt über den ganzen Tag 30 bis 50 no answer was ca. 0,5% oder weniger entspricht. Was aber noch viel grasser ist, ich hab bis zu der Version mit 3 DTUs gearbeitet weil ich eben immer wieder Empfamgsprobleme zu gewissen Invertern habe. Jetzt kann ich das wieder in einer einzigen DTU machen und habe trotzdem bessere Statistiken.

Hier mal die Statistik über einen Tag :

19:07:06 I: (#0) Quality: -6 -6 -6 4 -6, Cnt 36, Fail 16
19:07:11 I: (#1) Quality: -6 -6 -6 -6 2, Cnt 30, Fail 15
19:07:16 I: (#2) Quality: 4 0 -2 -2 -1, Cnt 32, Fail 2
19:07:21 I: (#3) Quality: 0 0 -2 0 4, Cnt 7, Fail 1
19:07:26 I: (#4) Quality: 0 0 -2 4 0, Cnt 30, Fail 0
19:07:31 I: (#5) Quality: 0 -1 -2 0 4, Cnt 31, Fail 2
19:07:36 I: (#6) Quality: -6 1 -6 -6 4, Cnt 6, Fail 1
19:07:41 I: (#7) Quality: -4 -4 3 -6 -4, Cnt 5, Fail 2
19:07:46 I: (#8) Quality: 0 0 -2 4 0, Cnt 30, Fail 1
19:07:51 I: (#9) Quality: 0 0 0 -1 4, Cnt 2, Fail 0
19:07:56 I: (#10) Quality: -2 -3 0 4 -2, Cnt 34, Fail 1
19:08:01 I: (#11) Quality: -6 -3 -5 -5 -6, Cnt 6, Fail 3
19:08:06 I: (#12) Quality: 0 0 0 4 0, Cnt 30, Fail 0

13 Inverter, jeweils mit den 5 Sendekanälen. Die Cnt und Fail kannste erst mal ignorieren. Man erkennt das nicht die gleichen Kanäle für die unterschiedlichen Inverter gut sind. Ach ja, je höher der Wert, umso besser. Eine 4 bedeutet das Optimum für diesen Kanal. #11 hatte gerade ein Problem, war kurz weg und hat den Kanal gewechselt, deshalb auch der grottenschlechte Wert. Oder der Inverter wollte sich schon mal schlafen legen 😉

Und am spannendsten diese Grafik:

Das sind die Stati der neuen State-Machine in Ahoy. Man erkennt das Morgens die Inverster aus ihrem Schönheitsschlaf erwachen und über den ganzen Tag sauber gearbeitet haben, nicht ein einziger Aussetzer. Heißt sie haben sich also immer bei jeder Abfrage gemeldet. Natürlich nicht immer beim ersten Mal, aber noch innerhalb des Abfrageintervalls, es ging also kein Datenpaket verloren. Leider fehlt das Ende des Tages, aber da war nur ein Ausfall drin, eben der besagte #11.

Zum Vergleich mal die DEV 48 von Lukas (Sorry, ich will da nichts mies machen, es ist halt die alte Senderoutine) :

4518 und 4519 sind die beiden letzten Testversionen mit der Heuristik. In nur wenigen Minuten stiegen die Inverter mit der DEV 48 mehrmals aus, mit der Heuristikversion machen sie das nicht oder nur sehr selten.

Ach ja, wir haben hier @riker18 der mit einem HM-600 über 80m funkt. Mit den Testversionen hat er damit Traumwerte erhalten, konnte sogar mit dem Power Level runter gehen und hat nochmals bessere Werte erhalten. Das Senken des Power Levels brachte bei mir leider keine weitere Verbesserung, ganz im Gegenteil, einzelne Inverter antworteten dann gar nicht mehr. Soviel zum Thema Allgemeinheit 😉

Kann natürlich sein, das ein „Normalfunker“ über 5m mit nur einem einzigen Inverter ohne besondere Empfangsprobleme keinen Nutzen von dieser Version hat, aber schlechter wird es auf jedem Fall nicht.

[beegee3]

Wow, das sieht ja super aus. Werde ich auch testen. Habe seit einiger Zeit eine Funkentfernung von ca. 20m und entsprechend ist die Statistik schlechter geworden. Das hier ist schon sehr überzeugend (!), mal sehen, ob da was geht 😄.

[knickohr]

Natürlich geht da was. Aber aufpassen, es geistern einige Versionen rum, nicht alle haben diese Heuristik aktiviert. Aber dazu kann vielleicht @rejoe2 was sagen. Ich habe mit der 4518 die besten Werte erhalten. Bei der 4519 wurde etwas mit einem Ack gemacht, was nach meinem Gefühl nicht mehr so rund läuft. Können aber auch blöde Zufälle sein bei meinen jetzigen wenigen Aussetzern.

[rejoe2]

@beegee3: Der "reine" Heuristik-Teil sollte im hm-Zweig von https://github.com/rejoe2/ahoy/tree/Heuristics_51 enthalten sein.

Eigentlich wollte ich noch untersuchen, welchen Anteil da welcher Teilaspekt hat, v.a., die "erste Wiederholung", die mAn. so oder so eingebaut werden sollte.
Komme aber voraussichtlich erst kommende Woche dazu, mich damit zu befassen.

[beegee3]

@knickohr @rejoe2 Danke für eure Hinweise. Hab' ich leider erst jetzt gelesen, nachdem ich die ahoy-all-in-one von @oberfritze installiert hatte. Aber voll überzeugend👍(wenn auch nicht lange getestet), hier die Statistiken (heute, nacheinander innerhalb 1 Stunde getestet):

bisherige Version

@oberfritze Version

Beide mit der ansonsten identischen Konfiguration.
@lumapu: von meiner Seite eine klare Einbauempfehlung für die Heuristik!

[rejoe2]

@beegee3 : Danke für deine Einschätzung. Meine eigene Statistik (allerdings 0.7.511=0.7.51 mit eingebauter Heuristik) sieht besser aus als "Ahoy pur", ist aber immer noch verbesserungsfähig. Die serielle Ausgabe sieht irgendwie "unruhiger" aus, als bei der "pur"-Version. Ich weiß aber noch nicht so richtig, was in meinem setup (6x1500-3rd gen+1xMI-600) auf welche Ursache zurückgeht.

TX count	4996
RX success	4233
RX fail	269
RX no answer	495
RX fragments	18647
TX retransmits	9547

Es gab übrigens auch die Überlegung, ob man nicht den TX-Level inverterspezifisch festlegen können sollte. @knickohr hat z.B. 8 von 14 (?) Inverter, die eigentlich sehr gut min "MIN" klar kämen, und braucht nur wegen einem oder 2 "HIGH"...
Bei mir ist das evtl. ähnlich, weil 1-2 von den 1500ern funktechnisch etwas "abgeschattet" sind und auch der MI-600 ist etwas weiter weg wie 4 der anderen... Mit "LOW" ist es erträglich, was an "Löchern" da ist....

[knickohr]

511 verhält sich bis jetzt nicht anders als die 4518/4519. ist ja an der Heuristik nichts verändert, nur auf den neuesten Ahoy-Stand gebracht ?

Deine Werte sind aber nicht sehr pralle 😲

@beegee3 die Oberfritze-Version ist noch 0.6.9, aber hat bei mir, oder andersrum gesagt, die neuen Versionen auf 7 basierend, waren ähnlich gute Werte. Also von daher nicht wirklich falsch oder richtig, was man für eine unterliegende Ahoy-Version nimmt. Meine Meinung aber, damit es auch @lumapu einfacher hat, den neuesten zu nehmen, zumal ja Lukas da auch neue Sachen rein bastelt. Ansonsten laufen wir irgendwie auseinander 😵

[rejoe2]

Zur Info meine aktuelle Statistik - die ist in der Tat gar nicht "pralle":

Statistics
TX count	16801
RX success	9051
RX fail	823
RX no answer	6923
RX fragments	40502
TX retransmits	23854

Habe aber keine Zeit grade danach zu fahnden, woran das im Detail liegen könnte, Sonne für alle sollte jedenfalls da sein, und zumindest eben wurden alle als "producing" gemeldet...

[knickohr]

Ich kann bis jetzt nich klagen, als im Rahmen.

[rejoe2]

Tendenz ist hier weiter nicht positiv; mehr als 50% "kaputte Kommunikation" hatte ich ewig nicht:

TX count	27670
RX success	11641
RX fail	1214
RX no answer	14809
RX fragments	52998
TX retransmits	35421

[rejoe2]

Auch hier die Info: Wie es ausschaut, liegt das daran, dass sich die Inverter neuerdings in die Quere kommen, also z.B. #4 irgendeine Anfrage macht, dann kommt #3 nochmal dazwischen, oder auch #2. Da die rx-channels abweichen, geht alles "den Bach runter". Unschön. Kann sein, dass Auslöser der MI ist, aber sicher bin ich mir da nicht...

[knickohr]

Der Tag ist zu Ende. Sieht für mich ganz vernünftig aus.

Was halt auffällt, wenn ein Inverter aussteigt, dann steigt er für mindestens 5 Minuten aus. Und hier schlägt die State-Machine zu und markiert den Inverter mit Status 4. Ist aber bei meiner Zykluszeit von 13x5s auch irgendwie erklärbar. Meine Theorie ist, das er nach den 5 Kanalwechseln eben wieder auf den alte, vorher funktionierenden Kanal wechselt und dann funktioniert es wieder.

Ich weiß jetzt nicht, wie die Logik genau funktioniert, gehe aber in der Annahme das wenn er auf dem letzten Kanal keinen Erfolg hatte beim nächsten Zyklzs auf einen anderen Kanal wechselt.

Hier mein Vorschlag : Ich nenne die 5 Kanäle jetzt einfach mal A bis E. Der letzte funktionierende Kanal war bisher Kanal A. Jetzt kommt der Fall das wir nach all den Retries und Resubmits auf Kanal A keine Antwort bekommen. Also springt die Logik beim nächsten Zyklus auf Kanal B.

Wie wäre es wenn wir trotzdem beim nächsten Zyklus nochmal Kanal A ausprobieren und erst dann, wenn es nicht erfolgreich war, sofort noch auf Kanal B probieren ? War das auch nicht erfolgreich, dann beim nächsten Zyklus erst wieder Kanal A und wenn nicht, Kanal C. Der nächste Zyklus wäre dann A und D, der letzte Zyklus dann eben A und E.

Ich denke das der Inverter dann auf mindestens einem Kanal geantwortet hat. Hier brechen wir das Spielchen ab und machen dann mit dem erfolgreichen Kanal weiter. Das kann nach meiner Logik dann auch wieder der alte Kanal A sein 😉

Ich hoffe ich habe das verständlich rüber gebracht.

Ach ja, man könnte auch gleich bei der ersten nicht erfolgreichen Abfrage es sofort auf den nächsten Kanal probieren, würde uns einen Zyklusdurchlauf ersparen.
Vorausgesetzt natürlich, das wir soviel Zeit zwischen den Intervallen haben.

Was denkt ihr ?

[beegee3]

zu @rejoe2 Statistk: die MI haben doch immer schon zu einer "falschen" Statistk geführt, weil ein kompletter Datensatz erst mit mehreren Abfragen erzeugt wird. Ich fürchte, dass führt die Heuristik in die Irre, so dass eigentlich "gute" Kanäle als "schlecht" bewertet werden. Allerdings sehe ich nicht, wieso sich die Inverter in die Quere kommen können. Das Zeitmanagement beim Abhorchen der Kanäle ist m.E. unverändert, so dass Antworten des vorherigen Inverters bei Abfrage des nächsten nicht mehr kommen dürften. 🤔 sehr merkwürdig.
@knickohr: erst müsste man die Funktionsweise der Heuristik richtig verstehen (das geht nicht auf die Schnelle). Da noch eine AB, AC, ... Kanalswitch Variante einbauen macht es nicht leichter (auch wenn die Idee grundsätzlich nicht schlecht ist). Aber sofort den nächsten Kanal probieren kann den Ablauf blocken, was wahrscheinlich zu Mqtt- und sonstigen Problemen führt.

[knickohr]

Das habe ich befürchtet 😢 Wäre ja zu einfach gewesen.

[beegee3]

@rejoe2 hab' mir die Routinen näher angeschaut. Glaube, die Inverter kommen sich in die Quere durch die erweiterte build Funktion in hmPayload.h bzw. miPayload.h. Da wird ggfs. eine Variable fastNext auf true gesetzt, was bewirkt, dass die nächste Abfrage des Inverters direkt gesendet wird. Allerdings wechselt app::tickSend den Inverter und sendet dessen Abfrage bevor auf Antwort gehorcht wird. So kann noch eine Antwort vom vorherigen Inverter kommen. Klemm das *fastNext = true; überall in den build Funktionen ab, dann wird es kein Durcheinander mehr geben. Grundsätzlich wäre es ja kein Problem, da die empfangenen Pakete dem richtigen Inverter zugeordnet werden. Aber hmRadio ist dafür nicht ausgelegt und interpretiert den Ausstieg aus der loop über getReceived ggfs. falsch.

[rejoe2]

zu @rejoe2 Statistk: die MI haben doch immer schon zu einer "falschen" Statistk geführt, weil ein kompletter Datensatz erst mit mehreren Abfragen erzeugt wird. Ich fürchte, dass führt die Heuristik in die Irre, so dass eigentlich "gute" Kanäle als "schlecht" bewertet werden. Allerdings sehe ich nicht, wieso sich die Inverter in die Quere kommen können. Das Zeitmanagement beim Abhorchen der Kanäle ist m.E. unverändert, so dass Antworten des vorherigen Inverters bei Abfrage des nächsten nicht mehr kommen dürften. 🤔 sehr merkwürdig.

Hmmm, wenn der Inverter noch sendet, kann Ahoy das auch noch empfangen und gibt es an den passenden iv zur Auswertung weiter. Wenn dann da die nächste Abfrage gemacht wird, weil noch nicht alles da ist, überlappen sich die Anfragen uU. gegenseitig (mein Invervall ist mit 2 sec. aber unverändert kurz!).

Diesen Effekt hatte ich teilweise aber auch schon zu Zeiten gesehen, in denen das fastNext noch nicht drin war. Werde mir das aber nochmal ansehen, weil ich einige komische Effekte sehe, die irgendwie auch mit der fastNext-Geschichte zusammenhängen könnten. Andererseits ist es "nur" eine Ausweitung des "retransmit"-Requests, und damit müßte app::tickSend eigentlich klar kommen. Aber vermutlich übersehe ich noch irgendwas.

Für die Heuristik werden die MI-Messages anders behandelt. Z.B. wird "beide Teilmessages empfangen" als "besonders gut" weitergegeben, unabhängig davon, was vorher passiert war. Das kompensiert zumindest zum Teil die tendenziell "kritischere" Behandlung von "unvollständigen" Messages in der Heuristik. Aber optimal ist es noch nicht!
Allgemein hat die Heuristik mit Typen noch Probleme, die mehrere Kanäle haben: auch die 3rd-gen-1500er sehen "unruhiger" aus und scheinen mehr retransmissions zu brauchen.

[knickohr]

RPD scheint mit der DEV 58 wieder (besser) zu funktionieren. Ich habe jetzt bei mehreren Invertern ein good 😎

Und ja, es scheint plausibel, das sind die Inverter die relativ nahe an der DTU sind.