Hy,
Ja, der S-Bus Ausgang am Empfänger hat nicht nur die 16 (18) Servowerte sondern auch noch ein paar extra Bits.
z.B. ein Rahmen-Fehlerbit, das gesetzt wird wenn ein Datenrahmen (Empfangsdaten) fehlerhaft war und nicht regeneriert werden konnte (9ms/18ms-Timing).
Das S-Bus Protokoll und der Protokoll-Aufbau ist in den tech. Spezifikationen von Futaba im Detail veröffentlicht worden.
Da gibt es schon seit Jahren Arduino-Programme wo man das S-Bus Protokoll im Detail mitlesen/auslesen und am PC mitschreiben kann.
In RCG geht es nun darum ob jeder Datenrahmenfehler zu eine Failsafe führt oder nur wenn
>=3 Datenrahmenfehler hintereinander kommen (3x9ms= 27ms oder 3x18ms= 54ms oder noch mehr/Länger).
Lt Futaba ist selbst eine Fehlerrate von 1,8% ein normales, gutes Ergebnis.
Aber 1,8% von was?
Von jedem Rahmenfehler oder nur wenn >= 3 Rahmenfehler hintereinander kommen.
Hallo Helle
Dann kann man am S-Bus ja ganz hervorragend die Übertragungsqualität überwachen. Viel besser als mit der RSSI.
Das wäre doch auch das Richtige Element die LostDaten pro Zeiteinheit (Lost/Sekunde) zu zählen und über den S-Port per Telemetrie an den Piloten zu senden.
Ich denke so meinst du es mit Futaba, dass die einen Lost nur Zählen, wenn es drei LostDaten hintereinander gibt. Eine übliche Entstörung bei der Messwerterfassung, nur hier völlig fehl am Platz, weil mit "LostData" ja gerade die Störfälle gezählt werden.
Sinnvoll ist die Zählung ja intern im Empfänger. Ich bin ja davon überzeugt, dass es diesen Zähler im Empfänger gibt, aber nur für Inseider und Entwickler. Es wäre schön, wenn dieser Zähler die RSSI ergänzen würde.
Aber wenns denn offiziell von FRSky kommt, weis auch wieder niemand was die denn nun als "Lost" Zählen, jeden oder ebend nur 3, 4 oder 5 aufeinanderfolgende als ein Ereignis.
@Carbo: Wenn es denn nach 100 Lost (aufeinander folgenden 100) endlich zu einem Fail kommt. ist der Krieg doch meist schon beendet. Die Überwachung einzelner Datenpakete ist sehr viel, FailSave Zählen eher eine Verzweiflungstat.
Sigi
