Link Quality Sensor von Tadango

[Carbonator]

@FJH lass uns ein einfaches Beispiel für 16 Kanäle machen. Das SBus Frame setzt sich also aus einem A (1-8) und einem B (9-16) 'über die Luft' Frame zusammen.

Jetzt ist das letzte A Frame ungültig. Das LF Bit wird gesetzt. Im SBus bleiben die letzten A und B Frames logischerweise erhalten, was denn auch sonst. Es geht nichts verloren, denn das letzte B Frame ist ja nach wie vor gültig. Es gibt nur keine neue A-Information. Die kann man sich auch nicht im Flieger backen, die ist einfach verloren gegangen.
Du machst denselben Fehler wie Waldemar . Wenn du dir mal eine Skizze machst und alle möglichen Kombinationen durchspielst und den resultierenden SBus anschaust, dann siehst du, dass die aktuelle Variante perfekt funktioniert. Wir brauchen keine andere. Das Andere ist nämlich Hütchenspielerei und Besch!ss

 

[nihonski]

Hy,

und dann kommt jetzt noch eine neue EN 300328 V2.2.2 rein,
gültig ab sofort, Übergang 1,5 Jahre

Darin müssen die Empfänger besser, d.h schmalbandiger werden und besser fangen bei externen Störungen (LTE) ..... bessere Fehlerkorrekturen...... usw.

Hallo Helmut,
ich wundere mich, daß man den Nebenwellenabstrahlungen des LTE mit einer schärferen Selektivität im WLAN Bereich entgegnen will. Das bringt nur sehr begrenzt was.
Vielmehr wäre eine besser Filterung der Ursache, sprich LTE, angebracht.
Ist das den Leuten klar, welche sich damit befassen?
Wenn ja, dann frage ich mich welche Lobby die Vertreter des Modellflugs eigentlich unterstützen.

 

[FJH]

@FJH lass uns ein einfaches Beispiel für 16 Kanäle machen. Das SBus Frame setzt sich also aus einem A (1-8) und einem B (9-16) 'über die Luft' Frame zusammen.

Jetzt ist das letzte A Frame ungültig. Das LF Bit wird gesetzt. Im SBus bleiben die letzten A und B Frames logischerweise erhalten, was denn auch sonst. Es geht nichts verloren, denn das letzte B Frame ist ja nach wie vor gültig. Es gibt nur keine neue A-Information. Die kann man sich auch nicht im Flieger backen, die ist einfach verloren gegangen.
Du machst denselben Fehler wie Waldemar . Wenn du dir mal eine Skizze machst und alle möglichen Kombinationen durchspielst und den resultierenden SBus anschaust, dann siehst du, dass die aktuelle Variante perfekt funktioniert. Wir brauchen keine andere. Das Andere ist nämlich Hütchenspielerei und Besch!ss

Vielleicht habe ich das ja falsch verstanden. Um bei deinem Beispiel zu bleiben, übertragenes Frame A ist ungültig während der ergänzende Frame B gültig ist und neue, aktualisierte Daten erhält. Das gemeinsame FL-Bit wird gesetzt und nach meinem Verständnis beide Frames damit als ungültig deklariert und verworfen bzw nicht weiter verwertet. Ist das also nicht so??

Wäre ja schön, wenn nur Frame A verworfen wird und Frame B weiterverarbeitet wird, sprich die Werte der Kanäle 9-16 mit aktualisierten Daten ausgegeben/verwertet werden während die Werte der Kanäle 1-8 per Hold gehalten werden. Ich wüsste jetzt ehrlich gesagt nicht, wie das eine Firmware erkennen und umsetzen soll in einem Datenstream mit sowohl ungültigen als auch gültigen Datenpaketen, wenn nicht denn jedes Frame sein eigenes FL-Bit hat. Und bei einem aus zwei Frames zusammengesetzten 16-Kanal-Stream gibt es doch offenbar nur das gemeinsame FL-Bit. Oder wird der ungültige Frame A garnicht erst in den SBus Stream reingepackt, sondern per Hold mit letztem gültigen Frame ersetzt und bildet somit zusammen mit dem aktuellen Frame B eine bereits "korrigierte" Kombi für die 16 Kanäle? Das würde dann aber auch bedeuten, dass das FL-Bit im Grunde genommen keine Funktion bezüglich weiterer Verarbeitung des Streams hat.

 

[Carbonator]

Vielleicht habe ich das ja falsch verstanden. Um bei deinem Beispiel zu bleiben, übertragenes Frame A ist ungültig während der ergänzende Frame B gültig ist und neue, aktualisierte Daten erhält. Das gemeinsame FL-Bit wird gesetzt und nach meinem Verständnis beide Frames damit als ungültig deklariert und verworfen bzw nicht weiter verwertet. Ist das also nicht so??

Du denkst zu kompliziert. Der A-Frame war ungültig. Jetzt kommt der neue B-Frame, der ist gültig, also wird ein neues SBus Frame gebildet mit dem letzten gültigen A-Frame und dem neuen B-Frame. Dieses SBus Frame ist gültig. Sonst würde ja die neue Information verloren gehen. Der A-Frame ist nicht falsch, er ist nur "alt".

Für eine FC Firmware ist das doch kein Problem. Die muss nur immer wissen, dass die Informationen im SBus Frame nicht aktuell sind. Ob der theoretische Fall abgefangen wird, dass 100 A-Frames immer falsch sind und alle B-Frames durchkommen, weiß ich nicht. Aber das passiert in der Praxis mit Sicherheit so nicht.

Auf keinen Fall darf man behaupten, das letzte OTA und damit das SBus Frame ist in Ordnung, wenn es in Wirklichkeit keine neue Information gibt. Darüber muss man doch eigentlich nicht diskutieren. Und darüber dass man die letzten als gültig empfangenen Daten im SBus und als PWM ausgibt, auch nicht. Was denn sonst?

 

[FJH]

Du denkst zu kompliziert. Der A-Frame war ungültig. Jetzt kommt der neue B-Frame, der ist gültig, also wird ein neues SBus Frame gebildet mit dem letzten gültigen A-Frame und dem neuen B-Frame. Dieses SBus Frame ist gültig. Sonst würde ja die neue Information verloren gehen. Der A-Frame ist nicht falsch, er ist nur "alt".

Okay, das ist der Kernpunkt. Demnach enthält eine SBus Stream keine ungültigen Frames, sonder höchstens "alte" mit nicht aktualisiertem Inhalt. Und jeder nachfolgende Prozess zur Weiterverarbeitung muss nicht mehr unterscheiden zwischen gültigem und ungültigem Frame. Damit wird das FL-Bit in der Tat vollkommen irrelevant.

Auf keinen Fall darf man behaupten, das letzte OTA und damit das SBus Frame ist in Ordnung, wenn es in Wirklichkeit keine neue Information gibt. Darüber muss man doch eigentlich nicht diskutieren. Und darüber dass man die letzten als gültig empfangenen Daten im SBus und als PWM ausgibt, auch nicht. Was denn sonst?

Mit obigem Sachverhalt und Verständnis der Irrelevanz des FL-Bit für die Weiterverarbeitung ist auch das dann logisch und eine Korrektur/Manipulation des FL-Bit völlig unnötig. Hab's jetzt hoffentlich auf Dauer verstanden und nicht nächste Woche wieder vergessen , danke.

 

[nihonski]

Das ist eh klar, der SBUS enthält nie ungültige sondern nur alte Daten.
V1: Der SBUS kann alten Daten enthalten, aber man weiß nicht welche und wie alt.
V2: Der SBUS kann alte Daten enthalten, aber höchsten 1 Frame alt.

 

[FJH]

Das ist eh klar, der SBUS enthält nie ungültige sondern nur alte Daten.

Mir war das eben nicht klar, bin halt nur ein alter Maschinenbauer ...

 

[Carbonator]

Das ist eh klar, der SBUS enthält nie ungültige sondern nur alte Daten.
V1: Der SBUS kann alten Daten enthalten, aber man weiß nicht welche und wie alt.
V2: Der SBUS kann alte Daten enthalten, aber höchsten 1 Frame alt.

Mach doch mal ein schönes Beispiel mit A und B OTA Frame und dann erklärst du den revolutionären Ansatz.
Dass es bei der 8-Kanal Variante null Sinn macht, weißt du inzwischen. Die 16-Kanal Sache kriegen wir auch noch gemeinsam in den Griff. Du musst nur von den Schlagwörtern und Parolen weg. Bleistift und und ein Stück Papier reichen vollkommen.

 

[QuadCrash]

V1: Der SBUS kann alten Daten enthalten, aber man weiß nicht welche und wie alt.

Das FL-Bit bzw. eine ggfs. aufsummierte Anzahl des Bits zeigt das an. Den Durchschnitt des FL-Bits nutzt man gern zur LQ-Bestimmung.

V2: Der SBUS kann alte Daten enthalten, aber höchsten 1 Frame alt.

Das FL-Bit wird manipuliert und damit ist "immer alles in Ordnung" ... Der Flightcontroller kann nicht reagieren, LQ geht auch nicht. Was soll daran also gut sein?

 

[nihonski]

Die Frames kommen so rein, (aktuellster steht zuerst): A1, B1, A2, B2, alt, älter, carbo ...
Für die Kreisfrequenz eines FC PID Reglers fällt ein einfach-alter Frame (also A2 anstatt A1, oder B2 anstatt B1) noch kaum ins Gewicht.
Kritisch wird es, wenn mehrfach-alte Daten anliegen und diese nicht gekennzeichnet sind.
Dann kommt es zu abrupten Sprüngen in den Daten-Werten und der D-Anteil des PID macht einen unangemessenen Satz, d.h. korrigiert zu stark.
Das mögen die DrohnenRacer nicht.

Der FC kann nicht beurteilen wie alt alte Daten sind und kann das nicht abfangen.
Für die Profis ist nicht die Latenz das Problem (sonst wäre die X9D+ mit ihren 30-40ms schon lang nicht mehr im Einsatz), sondern große Änderungen der Latenz.

 

[Carbonator]

Du sollst doch die Parolen weglassen. Jetzt machen wir ein ganz einfaches Beispiel:

Wir sind die Kanalbeauftragten im Empfänger und kümmern uns um 16 Kanäle. Es kommen immer 8 Kanäle neu rein.

- die Kanalwerte sind gültig, dann sortieren wir sie in die passenden Kanal-Fächer ein und geben ein SBus Frame raus und die 16 Kanäle über PWM. Wir wedeln nicht mit der Lost Frame Flagge
- die Kanalwerte sind ungültig. Wir haben nichts einzusortieren und geben die letzten Kanal-Werte im SBus und über PWM raus. Diesmal wedeln wir natürlich wahrheitsgemäß mit der Lost Frame Flagge

Das ist wirklich alles, mehr muss man überhaupt nicht wissen.

Wie würdest du denn als Kanalarbeiter vorgehen?

 

[nihonski]

Das sind keine Parolen, sondern Grundlagen der Regelungstechnik.
Carbo, du hast selber aufgezeigt, daß es imV1 Verfahren zu älteren SBUS Daten kommen kann.
Die Situation A1alt, B1neu, A2alt, B2neu, kommt durchaus vor, und hängt mit der Hoppingtabelle zusammen, (vor, zurück, vor, zurück...)

Ich kann nur wiederholen, daß diese V2 Änderung von den FCs bei FrSky angestoßen wurde, vielleicht schon länger, aber jetzt hat man es flächendeckend reingepackt.

 

[QuadCrash]

Der FC kann nicht beurteilen wie alt alte Daten sind und kann das nicht abfangen.

Die FC kann das beurteilen, wie man dem Code für Betaflight entnehmen kann. Dort werden die LostFrames anhand des FL-Bits gezählt und auch die Zeit seit dem letzten Setzen des Bits berücksichtigt.

 

[Carbonator]

Das sind keine Parolen, sondern Grundlagen der Regelungstechnik.

Ich kann nur wiederholen, daß diese V2 Änderung von den FCs bei FrSky angestoßen wurde, vielleicht schon länger, aber jetzt hat man es flächendeckend reingepackt.

Damit kommst du überall durch, nur nicht in diesem Forum Lass dich doch mal auf dieses simpelstmögliche Beispiel ein. Du hast dann gar keine andere Wahl, als exakt so vorzugehen, wie ich es beschrieben habe. Du kannst dich auch selbst nicht mehr durcheinanderbringen. Es gibt genau nur diese zwei Möglichkeiten einen SBus Frame auszugeben.

 

[nihonski]

In unserem Beispiel oben (A1alt, B1neu, A2alt, B2neu, ....) erhält der FC jeden zweiten SBUS ohne FL, also kein Grund zu reagieren. Aber, die B Daten können über mehrere Frames alt sein und plötzlich machen sie einen Sprung beim nächsten gültigen B-frame, als hätte der Pilot eine schnelle Steuerbewegung gemacht. In Wirklichkeit hat der Pilot nur langsam gesteuert.
Das nimmt ein Renn-optimierter Regler übel.

 

[QuadCrash]

Das nimmt ein Renn-optimierter Regler übel.

Du solltest Dir doch mal den Betaflight-Code näher ansehen … betaflight/betaflight

 

[Storchy]

Gibt es eine Möglichkeit einen fertig gelöteten "Link Quality Sensor" zu kaufen wenn man nicht mit einem Lötkoben umgehen kann? wenn ja wo
Danke

 

[Carbonator]

Ich hab noch Material für fünf Stück. Eingeschrumpft, mit Kabeln, Steckern, getestet, beschriftet, Verpackung und Porto für 15€/Stück. Einfach PM schicken.

 

[ReinhardZ]

Ich habe eine neue SW für den @Tadango Sensor mit @bionicbone Verfahren hier eingestellt.
Damit gibt es jetzt eine recht gute Übereinstimmung der Tadango-Werte (5100) mit den bionicbone Werten (5103).

Hier ein Beispiel eines Tests im Range Modus zu Hause, wo auch ein Failsafe auftritt:


Danke nochmal an @helle für sein Servotester Beispiel, das ich jetzt für die Erzeugung der Dreiecksfunktion benutze.

 

[Storchy]

Ich habe gestern einen Sensor von Carbo erhalten und heute einen ersten Test gemacht. Keine Ahnung wie aussagekräftig das ist. Bin durchs Haus gelaufen und hab hin und wieder die Antennen angefasst. Sender war ein X12s und Empfänger ein X8R V2.01. Anbei die Logdatei. Vielleicht kann man ja was erkennen. Bin für jede Hilfe dankbar
Ciao
Jörg