OTX Details zur Receiver Redundancy - GitHub issue #8515

[Merak]

Hallo Leute!
Mir ist gerade das geschlossene Issue auf dem OTX Repository im Github aufgefallen:
--> Can only select RSSI warning from one receiver in a redundancy system · Issue #8515 · opentx/opentx

Es geht um die Problematik, dass ich 2 redundate Empfänger habe, aber nur ein RSSi Signal.
Das wirft ein paar Fragen auf, die vielleicht jemand beantworten kann ...

Wenn ich mit einem RB10 (oder RB20) 2 Empfänger redundant habe, was bedeutet das den im Detail?

*
Welcher der beiden Empfänger sorgt für den Betrieb? Derjenige der aktuell das bessere Signal liefert oder einer der beiden bis er nicht mehr kann, schließlich ausfällt und der andere Empfänger übernimmt? Wenn der erste wieder voll Empfang hat, würde er dann wieder übernehmen oder bleibt die Signalversorgung beim zweiten Empfänger?

*
Ich habe nur ein RSSI Signal. Da beim binden der Empfänger einer ohne Telementrie gebunden wird, vermute ich dass das RSSI Signal vom Empfänger mit Telemetrie kommt, richtig?

*
In Abhängigkeit von oben gesagtem ... welche Bedeutung hat das RSSI-Signal für mich überhaupt noch in einem solchen Setup?

Vielen Dank für ein paar erklärende Worte!

 

[r41065]

Ich habe nur ein RSSI Signal. Da beim binden der Empfänger einer ohne Telementrie gebunden wird, vermute ich dass das RSSI Signal vom Empfänger mit Telemetrie kommt, richtig?

unter D16 hast du recht, da darf nur ein Empfänger mit Telemetrie gebunden werden.
Es geht hier um die von FrSky versprochene Funktion Trio Control unter ACCESS:
Dabei werden alle RX mit Telemetrie gebunden. ( und entsprechend per SPort verbunden )

Die Umschaltung der Redundanten Empfänger geschieht durch die Auswertung der Failsafe und Lost Frame Bits im SBus Stream. Es geht bei diesem Feature darum die RSSI Signale von allen RX im Sender zu haben um daran zu erkennen welcher RX gerade aktiv seine Steuersignale bereitstellt.
Das ganze sollte auch mit der Kopplung 2er Redundanzfähigen Empfängern funktionieren und ist nicht an eine RB gebunden.

Leider wieder ein Punkt wo FrSky seine Werbeversprechen nicht einhält und selbst OpenTx das nicht geradebügeln kann.

 

[FJH]

unter D16 hast du recht, da darf nur ein Empfänger mit Telemetrie gebunden werden.
Es geht hier um die von FrSky versprochene Funktion Trio Control unter ACCESS:
Dabei werden alle RX mit Telemetrie gebunden. ( und entsprechend per SPort verbunden )

Die Umschaltung der Redundanten Empfänger geschieht durch die Auswertung der Failsafe und Lost Frame Bits im SBus Stream. Es geht bei diesem Feature darum die RSSI Signale von allen RX im Sender zu haben um daran zu erkennen welcher RX gerade aktiv seine Steuersignale bereitstellt.
Das ganze sollte auch mit der Kopplung 2er Redundanzfähigen Empfängern funktionieren und ist nicht an eine RB gebunden.

Leider wieder ein Punkt wo FrSky seine Werbeversprechen nicht einhält und selbst OpenTx das nicht geradebügeln kann.

Der Sender sieht bei TrioControl immer nur die Telemetrie von einem Empfänger (dem aktiv geschalteten eben). Das Umschalten unter ACCESS von einem Empfänger auf einen anderen (Aktivieren der Telemetrie) geschieht dann, wenn die Telemetrie des aktiven Empfängers nicht mehr beim Sender ankommt (das kann durchaus unterschiedliche Gründe haben).

 

[Carbonator]

Der Sender sieht bei TrioControl immer nur die Telemetrie von einem Empfänger (dem aktiv geschalteten eben). Das Umschalten unter ACCESS von einem Empfänger auf einen anderen (Aktivieren der Telemetrie) geschieht dann, wenn die Telemetrie des aktiven Empfängers nicht mehr beim Sender ankommt (das kann durchaus unterschiedliche Gründe haben).

Hmm, ich mache zwar nichts mehr mit ACCESS, verfolge aber die Sache mit einem Auge. @RayX / Mario schildert hier ja eindeutig, dass drei Empfänger gleichzeitig ihre Empfangsdaten mit verschiedenen ID schicken können. Ich vermute, dass die drei RX S-Port seitig verbunden waren, das steht aber leider nicht explizit in dem Text, da steht nur "connected", aber das kann alles heißen ....

Ich schließe nicht aus, dass die Funktion mittlerweile firmwareseitig möglich ist. Es müsste einfach mal jemand am S-Port capturen, ob dort die Empfänger-Sensoren mit der neuen Firmware anliegen. Das war bisher nicht der Fall, deswegen machte ja ein Durchverbinden des S-Port nie Sinn. Ich schließe auch nicht aus, dass 3djc diese Möglichkeit noch gar nicht mitbekommen hat. Und ich schließe nicht aus, dass ich es komplett falsch verstanden habe

 

[helle]

Es sendet aber immer er nur ein Empänger alle Telemetriedaten
Je nach Empfangsproblemen wird dann auf einen anderen Empfänger umgeschaltet.

Außer bei 2,4GHZ UND 868MHZ da wird auf beiden Systemen gesendet

 

[Carbonator]

Das ist der vermutete Status quo. Die konkrete Frage ist aber, sieht der aktive RX mit der neuen FW und verbundenem S-Port die anderen RSSI und LQ Werte und sendet sie über seine Telemetrie.

 

[Elyot]

Sollte man den S.Port tatsächlich verbinden? Der S.Port wird doch gepollt. Wenn 3 Empfänger auf der selben Leitung gleichzeitig pollen, kann das doch nicht gut gehen ...
Ob die RB-xx da vermitteln, wäre interessant. Aber ohne sieht das (vermutlich) eher schlecht aus.

 

[FJH]

Hmm, ich mache zwar nichts mehr mit ACCESS, verfolge aber die Sache mit einem Auge. @RayX / Mario schildert hier ja eindeutig, dass drei Empfänger gleichzeitig ihre Empfangsdaten mit verschiedenen ID schicken können. Ich vermute, dass die drei RX S-Port seitig verbunden waren, das steht aber leider nicht explizit in dem Text, da steht nur "connected", aber das kann alles heißen ....

Ich habe nur 2 ACCESS-fähige Empfänger, einen G-RX8 und einen RX6R, beide mit letzter aktueller FCC-Firmware. Habe lange nix mehr mit ACCESS gemacht, weil eben selbst mit ersten Tests festgestellt, dass mit simultaner Telemetrie, insbesondere beider RSSI-Werte von 2 registrierten und gebundenen Empfängern nix ist. Habe jetzt nochmal beide vorgenannten Empfänger mit letzter, aktueller ACCESS-FCC-Firmware geflasht, registriert und gebunden. Habe dann jeweils getrennt für jeden Empfänger die Sensorsuche gemacht (halt nur einen Empfänger mit Spannung versorgen). Wenn ich mir dann den Sensor anschaue, dann finde ich für RSSI die ID F101 25 und für den VFR die ID F010 27, und zwar sind diese gleich bei beiden Empfängern, also kein Unterschied. Wenn ich dann einen der ID-Werte verändere, dann ist der Sensor weg und ich habe keinen Empfang des Sensors mehr. Ich verstehe also nicht, wie die Sensor IDs unterschiedlich sein oder gemacht werden können. Wenn da jemand weiterhelfen kann??

Muss mir noch ein Verbindungskabel zurechtlöten, um beide SPorts dann miteinander zu verbinden, werde ich aber erst später machen. Muss jetzt erst mal in den Garten zum Rasenmähen ...

 

[r41065]

Das ist ja gerade der Gag bei ACCESS und Trio Control das die SPort Leitungen verbunden werden und die externe Telemetrie ( z.B. FLVSS oder GPS ) immer aktiv ist.
Lediglich von den internen Sensoren der einzelnen Empfänger ( RSSI,VFR, A2 ) wird nur einer angezeigt, nämlich der, der gerade aktiv ist und sendet.
Zu sehen an den unterschiedlichen ID:
Für RSSI z.B 24 für den ersten , 56 für den 2. und 88 beim 3.RX. ( Offset je 32 )
Man kann daran erkennen welcher gerade aktiv ist aber es ist nicht möglich von allen 3 RX den RSSI Wert gleichzeitig zu sehen.
( was in meinen Augen aber das Werbeversprechen von FrSky zu TrioControl war....)
um damit z.B ungünstige Antennenpositionen zu finden.

@ FJH: nicht die Sensor ID im Sender ändern, sondern am einfachsten einen RX abschalten, dann sieht man auf der Seite im Sender die umgeschalteten IDs... getestet hab ich mit 2.1.6 am Sender und 2.1.7 am Empfänger

Ralf

 

[Carbonator]

Man kann daran erkennen welcher gerade aktiv ist aber es ist nicht möglich von allen 3 RX den RSSI Wert gleichzeitig zu sehen.

Das wäre ganz einfach möglich, wenn der RX, der keine Telemetrie sendet, seine internen Sensoren am S-Port zur Verfügung stellt und diese vom "Master" mitgepollt werden. Wird er aktiv und "Master", pollt er selbst und das Spiel beginnt neu.

 

[r41065]

Das wäre ganz einfach möglich, wenn der RX, der keine Telemetrie sendet, seine internen Sensoren am S-Port zur Verfügung stellt und diese vom "Master" mitgepollt werden. Wird er aktiv und "Master", pollt er selbst und das Spiel beginnt neu.

Ich glaube so hatten auch alle die Funktion erwartet.

So wie es jetzt ist fehlen nämlich z.B. das interne Vario in den Daten.

Aber wie du an anderer Stelle schon geschrieben hast: Die Funktion / das Protokoll des SPort ist die "Erfindung" von FrSky und nicht alles was diese damit machen hat Sinn...

Da ich SPort aber eh so einschätze das dort nichts mehr weiter entwickelt wird sondern vermute das demnächst neue Sensorik für FPort2 erscheint warte ich gelassen ab.

 

[FJH]

@ FJH: nicht die Sensor ID im Sender ändern, sondern am einfachsten einen RX abschalten, dann sieht man auf der Seite im Sender die umgeschalteten IDs... getestet hab ich mit 2.1.6 am Sender und 2.1.7 am Empfänger

Ralf

Tut mir Leid, vielleicht bin ich heute ziemlich blind, aber ich sehe keine umgeschalteten IDs. Wo genau soll ich die sehen? Ich bin auf der vorletzten Menüseite vom Modell und sehe immer dieselben Sensor-IDs beim RSSI als auch beim VFR, egal wie oft ich zwischen beiden umschalte (jeweiligen Empfänger spannungslos mache).

 

[r41065]

@ FJH
Auf der Seite wo auch die Sensorsuche gemacht wird, sprich die blinkenden Sternchen anzeigen ob Daten kommen.
( Sender X9 mit OpenTx 2.3.11, Rx6R + RXSR )
wenn der 1.RX aktiv ist wird für RSSI ID 24 angezeigt, beim 2. 56.

Mario ( RayX) hat dazu schon Fotos eingestellt, finde ich im Moment aber nicht und an meine Anlage komm ich gerade wieder nicht dran....

 

[FJH]

Okay, genau da schaue ich mir den internen Sensor RSSI, VFR mit "Zeile Editieren" an und finde immer dieselben, identischen IDs jeweils für RSSI und VFR usw., so wie im Beitrag #8 bereits geschrieben. Egal, was ich mache, die Sternchen blinken und die Werte kommen rein von dem gerade aktiven Empfänger. Ich sehe natürlich, dass bei Alt und VSpd nix reinkommt, wenn nur der RX6R aktiv ist. Auch sehe ich unter RSSI Quelle entweder "(Normal)" oder ich kann den "RSSI Rxxx" wählen, wobei Rxxx dann entweder RX6R oder G-RX8 ist. Das sind also die einzigen Merkmale, an denen ich sehe, welcher der beiden gerade der mit aktivierter Telemetrie ist. Wenn ich also zwei gleiche Empfänger so betreibe, dann habe ich überhaupt keine Unterscheidungsmöglichkeit mehr.

 

[r41065]

Ich habe den ersten mit Uid0 und den 2. mit Uid1 Registriert und gebunden.....

 

[FJH]

Auch das habe ich gemacht, hat nix bewirkt

 

[FJH]

Mit welchen Empfängern siehst du die unterschiedlichen Sensor-IDs?

 

[r41065]

Dann hab ich im Moment keine weitere Idee warum das bei Mario und mir so angezeigt wird
RX6R + RXSR, beide auf 2.1.7...

 

[FJH]

Okay, ich versteh's auch nicht, ist bei mir aber so, wie ich beschrieben habe. Identische Sensor IDs, egal von welchem Empfänger die Telemetrie kommt, egal ob beide mit derselben Uid=0 registriert oder der zweite dann mit Uid=1. Da brauch ich auch nicht weiter, was auch immer versuchen. Schade.

 

[Merak]

Wow! Zunächst vielen Dank für Eure Beiträge! Ich merke wieder, dass es noch ziemlich viel zu lernen gäbe ... ich versuche mal Eure Beiträge für mich zu übersetzen bzw. zwischen den Zeilen zu lesen ...

*
In dem Issue auf GitHub geht es um ACCESS. Da ich nur ACCST betreibe - unwichtig für mich. Jedenfalls jetzt. Korrekt?

*
Bei ACCST und Empfänger-Redundancy über einen RB, wird zu jedem Zeitpunkt das Signal des Empfängers genutzt der den besseren Empfang hat, richtig?

*
Die Anzeige RSSI im Sender zeigt mir aber die Signalstärke vom ersten, mit Telemetrie gebundenen, Empfänger. Damit ist ein "Low RSSI" nicht so sehr kritisch, da eine realistische Chance besteht, dass sowieso der andere Empfänger "in Betrieb" ist. Richtig?

Nochmals vielen Dank für Eure Expertise!