Weak NRF Signal #1129
Comments
|
Ahhh, da war jemand schneller 😉 Ja, es kommt immer „weak“, obwohl, ich nur ein paar Zentimeter durch eine Wand muß. Und es scheint wohl so, das es nur für einen Inverter gemacht wird. Was ist bei mehreren Invertern ? Eigentlich müßte man das für jeden Inverter abfragen 🤔 Korrekt müßte es :
heißen 🤓 |
Da fehlt eigentlich das Minus Zeichen, oder irre ich mich? Aber das Selbe zeigt er bei mir auch, drei Meter Entfernung mit externer Antenne. |
|
Es muß heißen < -64dbm |
|
Korrekt, es fehlt eigentlich nur das - Ach so, das Power-Level hat nichts mit der Empfangsstärke zu tun. Das ist nur wie stark die DTU sendet. Das andere ist die Empfangsrichtung (WR zur DTU), und das soll dieses Feature anzeigen. |
|
Also ich finde die Bezeichnung etwas unglücklich gewählt. Somit steht hier eine verwirrende Information "-" fehlt und es ist ein "Sehr gut" statt "Weak signal". |
|
@lumapu |
|
😉
Ob die Anzeige stimmt oder nicht, steht auf einem anderen Blatt. Aber sie funktioniert im Prinzip. Und Ja, es kommt mir auch zu wenig „Strong“. Das obige Bild stammt von einem Fusion Board, offenbar hat es eine bessere Empfangsempfindlichkeit als ein EByte Modul. |
|
-75dBm heißt
|
|
Wo kommen die -75 her ? Ich dachte es gibt nur die Fallungerscheidung < -64 und > -64 😲 |
|
@lumapu
|
|
ja die habe ich definiert, Vorschläge sind willkommen. Ich könnte auch -65 hinschreiben |
|
@rmayergfx ja Version |
|
Nein, bitte keine Werte da rein interpretieren. Die Funktion liefert nur die Aussage <-64dBm oder >-64dBm, siehe bitte den PR #1050 Alles andere ist gequirlte Sch… ! |
|
auf der anderen Seite haben wir aber auch ein gegebenes Konstrukt (von den HMS / HMT Wechselrichtern). Es gibt extra ein Feld RSSI für jeden Inverter, das würde ich gerne auch verwenden. Ich weiß dass absolute Werte falsch sind, in der WebUI wird es auch korrekt dargestellt:
|
|
@lumapu |
|
Es gibt keinen Wert zurück, im Prinzip nur gut und schlecht, nein sogar nur true/false. In der NRF24 Lib ist das als >-64dBm und <-64dBm definiert. Der WR gibt nichts zurück, das macht das NRF-Modul. |
|
Ahhh sooo, jetzt verstehe ich das. Nur in der seriellen Konsole kommt das mit -75 und -64 🫣 Akzeptiert. Jetzt noch in MQTT und API 🙉🙈🙊 |
ok |
|
Ich seh den Wert nicht, warum? Ab welcher FW Version wird das angezeigt? |
|
ab |
|
Ich seh nun mit der 0.7.44 im System keine Info mehr, dafür im Live:
Erklärt mir doch bitte mal, was nun genau hier abläuft. Werden hier nun realistische Werte von irgendwas zurück geliefert oder wie soll das funktionieren. Ich habe mit der 0.7.44 nun verschiedene Punkte im Haus "abgemessen" und in der Anzeige ändert sich nichts, selbst wenn ich direkt neben den WR in 1m Luftlinie positioniere. |
|
Es ist eine experimentelle Funktion in der Library vom NRF. Warum liest Du den betreffenden Issue #1050 dazu nicht, bzw. den PR #1119 ? Ob es real ist, oder ob es richtige/falsche Werte sind, das kann Dir nur der Author der Library sagen. Wir versuchen das nur hier mal zu implementieren. Ich bin auch noch nicht so glücklich damit, weil bei meinen 13 Invertern nur hin und wieder mal ein gutes Empfangssignal kommt. Da kann aber weder @lumapu noch die Library noch Ahoy was dafür. |
|
Mir ging es doch darum zu verstehen was da passiert, habe nun etwas weiter gegraben und es ist wohl so, das es sich um den Wert -64 dBm dreht, der irgendwo auf einem Register verfügbar ist und 0 oder 1 zurückgibt. Da ein genauer Wert hier wohl nicht ausgelesen werden kann, versteckt es bitte gerne wieder im System Menü, damit man sich nicht an einem Wert festklammert, der nicht wirklich aussagekräftig ist. Anscheinend hat der Entwickler des Chipset da nur mit WLAN "gut" und "schlecht" experimentiert. Wenn es keine wirklich nachvollziehbaren realen Werte gibt, würde ich dieses Goodie erstmal auf Eis legen. |
|
im System Menü hat's nichts verloren, da es wechselrichterspezifisch ist. |
|
die Lösung von @oberfritze hat nichts mit der Signalstärke zu tun. Bei ihm geht es darum, auf welchen Kanälen vorrangig gesendet werden soll. Dazu wird eine Sende-Erfolgs-Statistik angelegt, um die Kanäle mit den meisten Antworten bevorzugt zu nutzen. Das ist sicher hilfreich, wenn man eine permanente Störquelle in der näheren Umgebung hat, entspricht aber nicht dem von den Invertern genutztem Gazell-channel-hopping, wonach der Empfänger für eine gewisse (feste) Zeit auf einem Kanal horcht bevor er auf den nächsten wechselt. Dabei werden immer alle Kanäle benutzt! Der Sender hingegen startet laut Gazell-Protokoll zunächst mit einem zufälligen Kanal und versucht die Empfänger Wechsel nachzubilden, sobald er eine Antwort erhält. Aufgrund von Asynchronität wird dieses Nachbilden aber nicht lange durchgeführt (höchstens 2 Sek), dann nimmt der Sender wieder einen zufälligen Kanal. Daher ist dieses Nachbilden für uns uninteressant. Die Zeiträume zwischen zwei Sendevorgängen würden in der Regel zur Auswahl eines zufälligen Kanals führen. Wegen meiner kann ich den Gazell-Pseudo-Random-Algorithmus raussuchen (ist ein 5-Zeiler) und für hmRadio aufbereiten. Hilft vielleicht, wenn man mehrere Ahoy ESPs im Einsatz hat, so dass die sich weniger in die Quere kommen können. |
|
Schon, er hat aber auch eine Bewertung der Kanäle durchgeführt. In der Heuristik kann man eine Art Pseudo-rssi errechnen. Ist zwar kein echtes rssi, aber immerhin. |
|
gehört für mich irgendwie zu issue #718, glaube hier geht es nicht mehr weiter |
|
Die #718 ist doch closed, kann man dieses Issue auch closen? |
Hardware
Modelname: Wemos D1 mini
Retailer URL: ______
nRF24L01+ Module
Antenna:
Power Stabilization:
connected between +3.3V and GND (Pin 1 & 2) of the NRF Module
Version / Git SHA:
Version: 0.7.42
Github Hash: _______
Build & Flash Method:
Debugging:
Hallo,
super in v0.7.42 kann nun mit Anzeige der Signalstärke die Position zum Wechselrichter optimiert werden!
Klappt bei mir aber leid nicht……
Abstand zum HM 1500 circa 4 Meter.
Auch eine Änderung des Power Levels auf HIGH, oder MAX zeigt unverändert „Weak signal < 64dBm“.
Stärkeres Netzteil mit 2,5 A macht keine Änderung.
Übrigens, müsste es nicht heißen (größer) > 64dBm?
Danke!
The text was updated successfully, but these errors were encountered: