FRSKY Vorsicht bei "Telemetrie verloren" mit Horus

[Carbonator]

Nach dem bisherigen Verfahren, ist der SBUS (bestehend aus 2 Frames) komplett blockiert, wenn jeder zweite Frame ein Loss ist.
Nach dem neuen Verfahren wird ein gültiger Frame aus den letzten drei Frames zusammengesetzt, wenn ein Frame nicht gültig war. Also bis drei Frames zurück, darüber hinaus nicht.
Das ist eine wesentliche Verbesserung der SBUS Latency.
Es erfordert natürlich etwas Hirschmalz das zu verstehen.

Ich habe mir große Mühe gegeben, aber ich bin zu doof. Ich bitte um Erleuchtung. Als kleine Hilfe die folgende Skizze.

Wir verfolgen die Übertragung von 13 Frames. Links die 8-Kanalvariante, bei der hoffentlich jeder einsieht, dass ein fehlendes Frame nicht rekonstruiert werden kann. Dann der funktionierende Fall mit 16 Kanälen, dann der Fall mit 4 Lostframes in jedem zweiten Frame. Jetzt kommt das Ergebnis mit der bisherigen Methode, bei der der letzte gültige Wert gehalten wird. Und ganz rechts möge jetzt bitte ein Hochbegabter das Ergebnis der Methode Ewald eintragen.

 

[nihonski]

Mit deiner Tabelle kann ich nichts anfangen.
Man nehme einen endlos Ringspeicher in dem Daten von 4 Frames laufend durchgeschoben werden.
Der aktuellste Frame steht immer auf 1:

1
2
3
4

1+3 enthalten die Daten für Ch1-8, 2+4 enthalten die Daten für CH9-16
Beim nächsten Frame ist es umgekehrt.

Ist 1+2 OK => SBUS
Ist 1 Loss, und 2+3 OK, dann kommen in den SBUS 2+3 ohne FL-flag.
Ist 2 Loss, und 1+4 OK, dann kommen in den SBUS 1+4 ohne FL-flag.
Ist 1+2 Loss, und 3+4 OK, dann kommen in den SBUS 3+4 ohne FL-flag.
In allen anderen Fällen wird das FL-flag gesetzt und die letzten gültigen SBUS Daten übernommen.

Kommt der nächsten Frame rein, beginnt das gleiche von vorne.
In der Praxis treten 90% der FL Fälle vereinzelt, nicht hintereinander auf.

 

[Carbonator]

Mit deiner Tabelle kann ich nichts anfangen.
Man nehme einen endlos Ringspeicher in dem Daten von 4 Frames laufend durchgeschoben werden.
Der aktuellste Frame steht immer auf 1:

1
2
3
4

1+3 enthalten die Daten für Ch1-8, 2+4 enthalten die Daten für CH9-16
Beim nächsten Frame ist es umgekehrt.

Ist 1+2 OK => SBUS
Ist 1 Loss, und 2+3 OK, dann kommen in den SBUS 2+3 ohne FL-flag.
Ist 2 Loss, und 1+4 OK, dann kommen in den SBUS 1+4 ohne FL-flag.
Ist 1+2 Loss, und 3+4 OK, dann kommen in den SBUS 3+4 ohne FL-flag.
In allen anderen Fällen wird das FL-flag gesetzt und die letzten gültigen SBUS Daten übernommen.

Kommt der nächsten Frame rein, beginnt das gleiche von vorne.
In der Praxis treten 90% der FL Fälle vereinzelt, nicht hintereinander auf.

Oh Mann, ich bin entsetzt FrSky hatte echt leichtes Spiel mit euch. SBus ist doch eigentlich ganz simpel:

- "über die Luft" kommen alle 9 Millisekunden 8 Kanäle
- alle 9 Millisekunden wird ein 16 Kanal SBus Frame ausgegeben

- werden nur bis zu 8 Kanäle im SBus benötigt, ist jeder SBus Frame aktuell
- die restlichen Kanalwerte sind Festwerte und bleiben einfach konstant
- ist ein "über die Luft" Frame ungültig, wird nicht aktualisiert und die alten Kanalwerte bleiben erhalten
- das Lostframe Bit wird gesetzt

- werden mehr als 8 Kanäle benötigt, werden abwechselnd 1-8 und 9-16 aktualisiert
- ist ein "über die Luft" Frame ungültig, werden 1-8 oder 9-16 nicht aktualisiert
- die alten Kanalwerte von 1-8 oder 9-16 bleiben erhalten
- das Lostframe Bit wird gesetzt

- nach einer bestimmten Anzahl von LostFrames wird zusätzlich das Failsafe Bit gesetzt

Das ist alles und alles andere ist Geschwurbel. Es gibt keine Hütchenspielertricks um den SBus zu verbessern. Fällt ein "über die Luft" Frame aus, bleiben einfach die letzten Werte gültig im SBus Frame. Zusätzlich muss das Lostframe Bit gesetzt werden, damit die angeschlossenen Geräte wissen, dass das SBus Frame nicht aktuell ist. Alles andere ist Betrug, sorry. SBus kann jeder verstehen, da gibt es keine Ausreden. Höchstens dass ich es blöd erklärt habe, dann bitte nachfragen.

 

[QuadCrash]

Zur SBUS-Funktionalität gibt es hier ausführliche Infos incl. Simulator:
Real-Time Graphical Representation | S.BUS Protocol - ROBOTmaker

 

[helle]

Kenne ich, habe ich im Details ausprobiert.
Das Ding taugt nichts um S. Bus Framelost in Echtzeit mitzuschreiben.
Es werden immer wieder Framelost verschluckt.
Da ist leider Prozessing zu langsam um in Echtzeit SBus inc lost mit zuschreiben.
Die Balken jucken nicht, da merkste nicht das die auch nicht in Echtzeit dargestellt werden.

 

[nihonski]

Ist Carbo eigentlich mit eigenem Wohnsitz gemeldet?
Oder kommen seine Nachrichten aus einer geschlossenen Anstalt?

 

[Carbonator]

Heute habe ich noch einen weiteren Log von @quax2011 bekommen, ebenfalls mit einem "schönen" Lockout in drei Flügen. Ich hoffe, wir können bald mal seinen Sender messen, ob da auch die Frequenztheorie passt.


Der Lockout war nicht mit einem Servoausschlag verbunden, @quax2011 ist sich sicher, dass das gesteuerte Querruder an der Stelle Zufall ist und keine Korrektur.

 

[Carbonator]

Mike Blandford wollte wissen, ob nur LBT getürkt ist oder FCC genauso.


Hier gibt es keine Diskriminierung Oben die V1 und unten die V2 beides FCC, gleicher Laufweg.

 

[Michael Faupel]

Mike Blandford wollte wissen, ob nur LBT getürkt ist oder FCC genauso.
Anhang anzeigen 179783
Anhang anzeigen 179784
Hier gibt es keine Diskriminierung Oben die V1 und unten die V2 beides FCC, gleicher Laufweg.

Bedeutet keine "unterdrückten" lost frames, interessant! Jetzt hab ich auch endlich die Grafik richtig verstanden!
Aber warum dieser Unterschied?
Meinen denn die Chinesen das die Europäer etwas eher "gereitzt" sind?
Jedenfalls lägen sie damit bei LBT richtig!

LG Michael

 

[Carbonator]

Keine Diskriminierung plus Smiley sollte heißen, dass FrSky mit FCC genauso fälscht, wie mit LBT. Das war unglücklich formuliert. Oben ist die ehrliche FCC Vorgängerfirmware zu sehen, unten die FCC V2.0.1.

 

[QuadCrash]

mit FCC genauso fälscht

Es ist zwar richtig, dass das LF-Bit korrigiert wird, aber ob das in der Praxis ins Gewicht fällt? Die Berichte der letzten Tage zu stattgefundenen Flügen mit der neuen Firmware sind in der Überzahl positiv, was Reichweite und Meldungen angeht. Noch ein paar Detailänderungen und die Updates für ISRM-Sender und dann sollte es auch gut sein.

 

[bendh]

für die alte Firmware waren die Berichte aber auch überwiegend positiv.

 

[Carbonator]

Ich war eh nie betroffen und kann jederzeit einen Lostframe Sensor mitfliegen lassen, der mir mit der alten Firmware genau zeigt, ob alles OK ist. FJH hat bei FrSky angeregt, diesen Sensor "serienmäßig" zu bekommen, was ihm auch zugesagt, aber noch nicht verwirklicht wurde. Aber im Vorgriff fälscht man jetzt schon mal die Information. Ein Schelm, wer Böses dabei denkt

Ich hätte gerne die ehrliche Anzeige zurück, weil die mir beim sicheren Betrieb hilft.
Generell finde ich auch, dass man sich gegen solche Manipulationen wehren muss. Die FCs und die RBs verlassen sich darauf, dass die Information korrekt ist. FrSky darf meiner Meinung nach damit nicht durchkommen, sonst kommt bald der nächste Mist.

Dem Platzrundenflieger kann es aber ziemlich egal sein, das ist korrekt.

 

[QuadCrash]

FrSky darf meiner Meinung nach damit nicht durchkommen, sonst kommt bald der nächste Mist.

Der Meinung bin ich bekanntlich auch, halte aber die copy protected Geschichte für schlimmer.

Meine FCs reagieren auch nur auf das Failsafe-Bit. Solange das ordnungsgemäß kommt, mach ich mir bei den (wenigen) Fliegern mit FrSky-HF keine Sorgen.

 

[Carbonator]

Der Meinung bin ich bekanntlich auch, halte aber die copy protected Geschichte für schlimmer.

Die Verschlüsselung der Kommunikation zwichen CPU und HF-Chip war sicher der Hauptzweck des Updates, Deswegen haben sie auch ACCST vorgezogen und ACCESS zurückgestellt. Wenn das richtig gemacht ist, ärgert es die "Konkurrenz". Wenn nicht, gefährdet es die FrSky Kunden. Man kann nur hoffen, dass damit keine neuen Fehler eingebaut wurden. Grundsätzlich darf FrSky das machen, der Kunde muss abwägen.
Wenn man dann noch sieht, dass manipuliert wird, erscheint mir das Update für Leute, die jahrelang noch nie Probleme hatten, als fragwürdig.
Wer von den Lockouts und Ausschlägen betroffen ist, hat aber gar keine andere Wahl. Das bedeutet, wer unter FrSky Murks leidet, darf sich dann anderen Murks auf Sender und Empfänger flashen. In der Hoffnung, dass der Betrieb sicherer wird.

Meine FCs reagieren auch nur auf das Failsafe-Bit. Solange das ordnungsgemäß kommt, mach ich mir bei den (wenigen) Fliegern mit FrSky-HF keine Sorgen.

Das Antennendiversity läuft über Lost Frames, das konnte FrSky schlecht manipulieren, deswegen blinkt die LED weiter "wahr" und die "Verbesserung" findet erst danach statt. Betaflight User sehen nach dem Update eine viel bessere Linkqualität, das könnte mit ein Grund für die Manipulation sein. Redundanzumschaltung in den Empfängern und RBs nutzt ebenfalls Lost Frames, da hat sich FrSky hoffentlich Gedanken gemacht.
Vertrauensbildende Maßnahmen sehen für mich anders aus.

 

[Carbonator]

Nach den Zugriffszahlen wird dieser Thread oft gelesen, aber es kommen leider wenig Beiträge. Ich möchte ausdrücklich ermuntern, Fragen zu stellen. Wenn jemand Angst hat, sich bloßzustellen, gerne auch per PN. Wobei es keine dummen Fragen gibt. Nur dumme Erklärungen.

Da im Händlerforum gerade wieder Nebelkerzen kombiniert mit wahnsinnig kompetent aussehenden Messungen geworfen werden, hier mal ein paar Bemerkungen zur PWM Ausgabe am Empfänger:

1. Fall 8-Kanal Empfänger mit 18ms PWM Framezeit (Standard), Sender sendet nur 8 Kanäle (9ms Anzeige)
- "über die Luft" Frame 1-8 kommt an
- ist gültig aber die 18ms sind noch nicht um
- "über die Luft" Frame 1-8 kommt an
- ist es ebenfalls gültig wird dieses Frame ausgewertet und die PWM Pulse ausgegeben
- ist es ungültig, wird das vorherige ausgeben
2. Fall 8-Kanal Empfänger mit 18ms PWM Framezeit (Standard), Sender sendet 16 Kanäle (18ms Anzeige)
- "über die Luft" Frame 1-8 kommt an
- ist es gültig wird es an 1-8 ausgegeben
- ist es ungültig, wird das vorherige an 1-8 ausgeben
- "über die Luft" Frame 9-16 kommt an
- das wird nicht gebraucht -> an der Stelle sollte man erkennen, wozu die Kanalzahl im Sender wichtig ist
3. Fall 8-Kanal Empfänger mit 9ms PWM Framezeit (HSModus) Sender sendet 8 Kanäle
- "über die Luft" Frame 1-8 kommt an
- ist es gültig, wird es ausgegeben
- ist es ungültig, wird das vorherige nochmal ausgegeben
4. Fall 8 Kanal Empfänger mit 9ms PWM Framezeit (HSModus) Sender sendet 16 Kanäle
- bitte selbst ausfüllen

Alles eigentlich ganz simpel und "furchtbar" logisch. Auf Wunsch mache ich gerne weitere Beispiele. So eine Übertragung ist übrigens auch für professionelle Zwecke geeignet.

 

[FJH]

Das Antennendiversity läuft über Lost Frames, das konnte FrSky schlecht manipulieren, deswegen blinkt die LED weiter "wahr" und die "Verbesserung" findet erst danach statt. ................ Redundanzumschaltung in den Empfängern und RBs nutzt ebenfalls Lost Frames, da hat sich FrSky hoffentlich Gedanken gemacht.

Da sehe ich eigentlich kein wirkliches Problem. Ob jetzt Antennenumschaltung oder Redundanzumschaltung 1/10 sek früher oder später kommt, dürfte für uns unerheblich sein (für mich jedenfalls ist es das). Oder übersehe ich da was?

 

[Carbonator]

Wenn sich der Fake auf 3 Frames beschränkt, ist es nur eine Falschinformation ohne große Sicherheitsnachteile bei der Redundanzumschaltung. Betaflight User sehen es vielleicht anders. Dort können bis zu 75% der Frames verloren gehen (worst case, theoretischer Fall) ohne dass der Pilot etwas anderes als perfekte Link Qualität im OSD sieht.

Welche Link Qualität würdest du gerne in dem von dir vorgeschlagenen LQ Sensor sehen? Die wahre, oder die gefakte?

Die entscheidende Frage ist: Warum wurde dies eingeführt? Hier wird es interessant. Die Erklärungen, die bisher vorliegen, sind lächerlich, um es höflich zu sagen.

 

[FJH]

Nach den Zugriffszahlen wird dieser Thread oft gelesen, aber es kommen leider wenig Beiträge. Ich möchte ausdrücklich ermuntern, Fragen zu stellen. Wenn jemand Angst hat, sich bloßzustellen, gerne auch per PN. Wobei es keine dummen Fragen gibt. Nur dumme Erklärungen.

Die wenigsten sind technisch so fit, um mit fundiertem Wissen da auch Beiträge beisteuern zu können. So zB geht es mir. Gewisses Basiswissen über die Jahre angeeignet, aber eben nicht genug. Da bleibt mir nur, mit Verstand und der Grunderfahrung als Ingeneur Probleme zu erkennen und Analysen und Argumente von Experten (bessere als ich es bin) zu bewerten.

 

[FJH]

Wenn sich der Fake auf 3 Frames beschränkt, ist es nur eine Falschinformation ohne große Sicherheitsnachteile bei der Redundanzumschaltung. Betaflight User sehen es vielleicht anders. Dort können bis zu 75% der Frames verloren gehen (worst case, theoretischer Fall) ohne dass der Pilot etwas anderes als perfekte Link Qualität im OSD sieht.

Welche Link Qualität würdest du gerne in dem von dir vorgeschlagenen LQ Sensor sehen? Die wahre, oder die gefakte?

Die entscheidende Frage ist: Warum wurde dies eingeführt? Hier wird es interessant. Die Erklärungen, die bisher vorliegen, sind lächerlich, um es höflich zu sagen.

Ganz klar, bezüglich Linkqualität möchte ich ausschliesslich die Wahrheit sehen und nicht die "korrigierte". Und auch der Nachteil für die FCs. also betaflight ist gelinde gesagt sehr unschön, die wären auch besser mit der Wahrheit bedient.