SBUS-Frame Monitoring über SPort

Du hast den Ardu und den RB parallel am SPort des S8R. Wenn du einen zweiten Sender und dritten Empfänger hast, kann du den Ardu mal am S-Bus des RB lassen, aber den SPort (+GND) an den dritten Empfänger anschließen und im zweiten Sender schauen, ob da was ankommt. So schließt du aus, dass sich irgendwelche IDs in die Quere kommen.

Ist schon seltsam

Hab gerade mit der Horus und Drittem RX getestet, Ergebnis gleich, sobald der zweite RX an der RB steckt steht der Wert eingefroren auf 100, das Sternchen für Übertragung blinkt aber schön weiter.

Somit scheiden die ID´s schon mal aus.

Eine weitere Erkenntnis habe ich noch:

Wenn die Telemetrie verloren geht und dann wieder kommt habe ich kurzfristig einen Ansteigenden Wert der recht schnell bis auf 100 zählt und dann wieder stehen bleibt.

OK, das heißt, du hast mit zwei Empfängern immer 100% gültige frames. Muss man jetzt interpretieren - die RB macht scheinbar mit 2 Empfängern etwas anders, als mit nur einem Empfänger. Die interne Bearbeitung scheint bei zwei Empfängern immer einen frame auszugeben, vielleicht wegen eines internen hold, wenn umgeschaltet wird, oder kurzzeitige Aussetzer auftreten. D.h. mit dieser Methode lässt sich das Verhalten des RB nicht analysieren. Du müsstest ein Dreieckssignal auf einem Kanal übertragen und hinterher schauen, ob holds aufgetreten sind - aber ob das lohnt?

Ich hab den Sensor von Tadango per Y- Kabel am XM+ bevor ich dessen SBus-Signal in die RB10 einspeise.
Mit der RB10 läuft der Sensor auch normal ohne Überschneidung...
Ralf

@Ralf könntest du mal versuchsweise den Sensor an den S-Bus Out der RB-10 anschließen ? und an der RB-10 beide Empfänger anschließen also so wie von Frsky vorgesehen.

@ Mario

Sbus vor der RB10 abgegriffen, egal ob X8R oder XM+ liefert normale Werte , hinter der RB10 mit beiden RX aktiv dann 100.
War jetzt aber nur ein schneller Schreibtischtest ohne dass RSSI unter 85 war....
Ralf

habe das gerade auch mal an der RB-10 getestet, am S-Bus Out gleich wie an der RB dauerhaft 100 egal welcher RSSI, es kommt nur ein kleinerer Wert wenn die Telemetrie verloren und wieder gefunden der dann schnell auf 100 hoch läuft.
Da du das gleiche Ergebnis hast, bin ich schon mal beruhigt dann ist auch nichts kaputt.
Wenn ich am Eingang der RB abgreife ist das ja eigentlich wie wenn ich den Empänger ohne RB teste oder irre ich mich da?

Test ist dann wie Einzelempfänger, wollte damit mal prüfen ob man der RB10 irgendwie entlocken kann das Frames ausgefallen sind.
Deren LostFrame Signal hab ich bisher aber immer nur gleichzeitig mit dem Failsafe Signal provozieren können....
Ralf

Hab da was gefunden, Tadango hat aber ein Lua Script geschrieben was die Lost frames an der Rb zählt .

Habe ich aber noch nicht getestet.

hier mal die Beschreibung:

Das Skript läuft leider auf meiner Taranis mit OpenTx 2.18 nicht und auf der Horus mit OpenTx 2.2 blinkt der Bildschirm.

Hi
vergesst lua für diese art der auswertung
- hab das selber schon versucht -
Für eine grobe auswertung der framelosses ok, mehr aber auch nicht
Lua "ist" nicht echzeit, da huschen auch öfters die indikationen durch
failsafes kann man zählen, die losses nicht präzise

gruss
udo

Mario,

du berichtest ja quasi von Problemen mit dem Telemetriewert:
"sobald der zweite RX an der RB steckt steht der Wert eingefroren auf 100"

Andererseits sagst Du:
"das Sternchen für Übertragung blinkt aber schön weiter"

imho ist das kein Widerspruch:

Wenn zwei Empfänger angeschlossen sind, kann die RB bei fehlerhaften Signalen auf dem SBUS eines RX's das (falls vorhanden) gültige Signal des anderen RX's verwenden.
Lt meinem Kenntnisstand funktioniert das sogar "unterhalb" eines Frames als Signaleinheit,
anders ausgedrückt: auf Bitebene.

Erst wenn auf beiden Empfängern dasselbe Bit nicht korrekt übertragen wird, und eine mögliche Fehlerkorrektur fehlschlägt, würde am SBUS Ausgang, wo dein Arduino dranhängt, ein Frameloss erkennbar sein.

Solange einer der beiden Empfänger das Signal noch überträgt, wird am Ausgang alles OK sein.
Genau das misst du doch mit dem Wert "100".
Da "das Sternchen blinkt" sendet der Ardu noch gültige Werte, so interpretiere ich das jedenfalls.

Eigentlich ist deine Messung der Beweis, dass der RB genau das macht, wozu er konzipiert wurde.

Die Frameloss Flags, die du in der Telemetrie siehst (oder per lua angezeigt werden), sind ja die diejenigen, die auf dem SBUS eines einzelnen Empfängers erkannt werden.
Um die zu messen und gegenüberzustellen müsstest du beide Rx-SBUS Signale parallel verarbeiten (zwei Ardus parallel, einen Arudino halt mit anderer Adresse nutzen).
-Nicht das Signal am SBUS Ausgang des RB abzapfen-.
Tadango hat dieses "Huckepack" Duo ja schön dargestellt.....

Deine Problemstellung ist doch, dass der RB mit der neueren FW deinem Feeling nach häufiger FL angibt.
Dann müsstest du in den logs sehen können, das der RB "False flags" ausgibt, obwohl lt Arduinos auf dem Bus alles i.O war.

Dass die FrSky Firmwerker auf Bitebene zwei S-Bus Streams überwachen und dann daraus gültige Frames basteln, halte ich eher für unwahrscheinlich. Ich tippe auf ein simples Hold bei einem Error: der letzte Frame wird wiederholt.

Eine einfache Möglichkeit dies zu testen, habe ich schon genannt. Dreieckssignal mit OpenTX generieren und auf einem Kanal senden und dann diesen Kanal mit dem Logic-Analyzer loggen. Jede Dublette ist ein Hold, also ein Lost Frame. Nur an den Umkehrpunkten können unter Umständen natürliche Dubletten auftreten, je nach Timing.

Das sich das eigentlich widerspricht, gebe ich Dir durchaus recht.

Jetzt kommt das berühmte aber was mich an deiner Theorie zweifeln lässt, ist, wenn ich mit dem Sender im Range Mod soweit weg gehe das der Empfang bei niedrigen RSSI Werten abreist, müsste ja irgendwann mal ein Signal Verschlechterung kommen.
Denn im Einzeltest der Empfänger fällt der wert 100 ab RSSI 45 drastisch ab, den der Ardu misst (also die Signal Qualität) das kann ich mir nicht vorstellen das sich beide Empfänger so ergänzen das es immer 100% Signalqualität zur Verfügung steht, auch das angeschlossene Servo läuft lange nicht Ruckelfrei bis zum bitteren Ende mit, sonder stockt ruckt (das kennt ja jeder wenn der Empfang schlecht wird und kurz vor dem Abriss ist).
Die 100% habe ich bis zum Signal abriss.



an den zweiten Ardu habe ich auch schon gedacht werde noch einen zweiten frei machen.
Fakt ist die neue Firmware schaltet nicht erst beim Failsafe von RX1 zu RX2 um was wünschenswert und Sinnvoll wäre um, sonder wesentlich früher, das ist noch nicht gemessen nur was ich mit dem Auge sehen kann jedes mal bei einem Lost frame und das ist Schlecht.

Beispiel: Autolevel ist eingeschaltet Modell in Schräglage, RX versucht das Modell mit Querruder Ausschlag in die Horizontale zu bringen ohne eingaben am Steuerknüppel, jetzt kommt ein Lost und die RB schaltet auf RX2 um, jetzt fahren die Querruder Servos zurück in den Strack jetzt kommt wieder ein Lost auf RX 2 und es wird wieder auf RX 1 umgeschaltet der wieder versucht das Modell in die Horizontale zu bringen und das ergibt dann wildes Querruder Bewegungen auf und ab.

Wenn die Umschaltung erst bei Failsafe oder einem niedrigen RSSI oder Signal Qualität je nach dem was der RB auswertet erfolgen würde wäre die Sache ok und nutzbar. So könnte man Automatisch durch einen Logischen Schalter z.b unter RSSI 45 oder eben die Signal Qualität den Autolevel MOD deaktivieren und alles wäre gut, denke ich zumindest ???

Sollte ich da einen Denkfehler haben, sagt es mir, die Sache ist eh schon kompliziert genug und das auch noch nebenbei beim Modell fertig stellen.

@Bernd Dreieckssignal mit OpenTX generieren.

Bitte stell mal so eine Mischerzeile oder wie auch immer da deine Gedanken sind hier ein das ist gerade eine Nummer zu hoch für mich.

"Dreieck" mit oTx mache ich so:
LS definieren, der als "Flipflop" alle 3 Sekunden hin bzw herschaltet (also 6S Periodendauer)
in einem Kanal zwei Mischerzeilen, eine mit +100%offset, andere mit -100%offset, eine Zeile ist bei LS"Ein", die andere bei LS"aus" gültig
>> Geschwindigkeit einer jeden Zeile auf z.B. 3,5 Sekunden setzen, dadurch wird der extrempunkt nie angefahren, das Servo ist immer in hin oder her-Bewegung


@Mario:
Deine Begründung, das die Umschaltung besser erst bei FS durchgeführt werden sollte ist zwar nachvollziehbar, hat aber die Vorteile speziell & exklusiv in deinem Fall (S8R), und da war die Empfehlung von FrSky 2x S8R einzusetzen.
(Ich weiss, dafür ist bei dir kein Platz..)
Im Allgemeinen Fall (keine Gyro Empfänger im Einsatz) ist es für den Anwender sinnvoller das Signal in Echtzeit zu korrigieren.

Grund:
Schon lange vor dem FS geraten die Servos bei "Solo" Empfang durch die hohe Rate kurzer FLs ins Zittern, die Steuerbarkeit wird erheblich beeinträchtigt.
Durch die jetzige Funktionalität bleibt die Steuerbarkeit deutlich länger erhalten
FL's, die durch Abschattung und Laufzeitproblemen verursacht werden, also wo sich ein Flächenmodell noch im üblichen Empfangsradius befindet, werden komplett eliminiert.
Zudem könnte man durch die FL rate (z.B grobe Anzahl der Ausfälle binnen 10 Sekunden) einen Alarm geben lassen, der darauf hinweist, dass sich mindesten ein RX im "Randbereich" des Empfangs aufhält, ohne dass man deutliche Zucker erhält.

Bei Umschaltung erst im FS-Fall muss man auf diese Sicherheitsfeatures verzichten !
... dafür halt das durchgängige S8R Signal....


Gruß
Udo

Ich hätte auch Servotester schreiben können



@Udo geht auch kompliziert

... noch was,
dass auch bei niedrigen RSSI Werten und hohen FLs trotzdem keine "Störung" am SBUS out anliegt deutet darauf hin, dass die FW dann zumindestens plausible Frames dort ausgibt, könnte die letzte bekannte Posi sein, keine Ahnung....
Also arbeitet der RB dann so, dass er, solange es geht, aus zwei durchaus korrupten Signalpfaden noch das gültige Signal herausrechnet.
Wenn auch das nicht mehr geht, ggf "hold".

gerne, eine meiner Stärken

Mir ist jetzt nicht bekannt nach welchen Kriterien Frsky die Umschaltung zwischen den beiden RX veranlasst, was ich im Moment sagen/vermuten kann ohne weiter versuche unternommen zu haben, die Umschaltung geschieht viel zu früh, ich bin der Meinung Sinnlos. Es müsste ja nicht mal der Failsafe von RX 1 sein der die RB zum Umschalten bringt.
Ich könnte mir vorstellen das die RB das auch kann was Tadango´s Skript auf dem Ardu macht evtl tut sie das ja auch schon jetzt, die Lost frames werden ja auch per Telemetrie übertragen, da ist doch die Wahrscheinlichkeit groß das es so ist.



Meine Idee wäre:

1. Zwei Firmware Versionen, ein für normale X Empfänger und ein für S Empfänger (im Prinzip gibt es das ja jetzt schon, müsste nur auf den jeweiligen RX noch etwas angepasst werden )

2. Ich denke wenn die Auswertung der Signal Qualität dafür benutzt wird könnte man eine "Sinnvolle" fixe Grenze sagen wir mal 45% nehmen, wenn der zweite RX in diesem Moment das Qualitative bessere Signal liefern könnte, damit wird das ganze berechenbar, was wann und wo passiert.
Diese Werte könnte man dann auch weiter verarbeiten und z.b den Autolevel automatisch abschalten und z.b mal eine Warnung ausgeben.

3. warum so ? so kann man den S Empfänger ohne Wildes Servo hin und her fahren Problemlos nutzen, zumal an der RB10 scheint das ja auch so zu funktionieren (das muss ich aber auch noch mal testen, es waren einfach die letzten Tage sehr viele Probleme und Tests und zwischendurch muss ich auch noch mal Arbeiten das ich mir nicht mehr 100% sicher bin
So wird das ganze auch individueller wie jeder möchte konfigurierbar, so wie der Rest von Frsky auch, z.b mit Telemetrie Binden oder ohne so wie benötigt oder mit 18 ms oder was auch immer.

4. Frsky sollte wenn das so umzusetzen ist davon auch vorteile haben, das hat nicht jeder und Frsky versucht ja auch im Moment Rekorde auf zu stellen, wie viele Neue Anlagen und RX´se man in sehr kurzer Zeit auf den Markt bringen kann um mit den anderen mithalten zu können oder diese auszustechen.

Ich habe mal Carbo den Log gemopst, hab leider grad keinen zur Hand da sieht man das ganz gut.



Danke euch beiden noch mal für die Info mit dem Dreiecksignal, hätte man auch selbst drauf kommen können, wenn man kurz drüber nachgedacht hätte