Link Quality Sensor von Tadango

[nihonski]

Deine Ansicht ist nicht schwer zu verstehen.
Aber mir genügt das nicht und für eine ganzheitliche Betrachtung kommt leider keine Info hier.
Die Regelkreis Parameter kann man auch so abschätzen. Sagen wir einfach, die Kreisfrequenz der Regelstrecke Stick-TX-RX-Drohne-Auge-Gehirn-Stick kann auf keinen Fall größer sein als ein gutes Servo. Und wo liegen wir da? Bereits bei einem vielfachen von 36ms.
Das SBUS bit als Anpassung für den PID Regler einer Race-Drohne herzunehmen ist eine Notlösung.
Alleine schon deshalb, weil ich nur 0 oder 1 habe.
Wer soweit geht dem bleibt nur die genaue Auswertung der LQ Werte des HF-teils, wenn das was taugen soll.

Ich habe mir die 19er mit einem G-RX8 nochmals angeschaut. Es wird über 12 Frames gefiltert.
Nicht akzeptabel, das streite ich nicht ab.
CRC Fehler sind ohne viel Mühe messbar, macht keinen Sinn an dieser FW noch nachzubessern.

 

[Carbonator]

Hör auf dich selbst immer wieder zu verwirren. Es geht hier nicht um Regelkreise. Schon gar nicht um PID Regler. Von Drohnen will ich gar nicht anfangen

Es geht schlicht und ergreifend um einen Empfänger mit SBus/FPort, der das Lost Frame und Failsafe Bit nach Standard wahrheitsgemäß setzen muss. Das ist alles. Alles andere sind Nebelkerzen.

Was am SBus/FPort angeschlossen wird, geht dich nichts an. Was die Firmware der angeschlossenen Geräte mit den Bits macht, auch nicht.
Falls du an Regelkreisen mitarbeiten willst, sind die Betaflight Entwickler der richtige Kontakt. Ich könnte mir vorstellen, dass die dich gut gebrauchen können.

 

[Carbonator]

OK, so please answer this time: Why is it good to hide lost frames in the SBUS stream, when the whole point of the lost frame flag is to be informed that a frame was lost?

Jetzt sind auch international die paar Leute, die verstehen, um was es bei dem Lost Frame Bit geht, auf Waldemars Antwort gespannt.
Dann kann man vielleicht zur nächsten Frage kommen. Warum?

 

[Sigimann]

OK, so please answer this time: Why is it good to hide lost frames in the SBUS stream, when the whole point of the lost frame flag is to be informed that a frame was lost?

Jetzt sind auch international die paar Leute, die verstehen, um was es bei dem Lost Frame Bit geht, auf Waldemars Antwort gespannt.
Dann kann man vielleicht zur nächsten Frage kommen. Warum?

Nachtrag: Hab irgendwelche Probleme bekomme, meine Antwört ist sicher irgendwo in der Cloud ... oder als LF auf dem SBus.

Sigi

 

[heikop]

Stand im Posting davor, kommt noch etwas eigenes?

 

[Sigimann]

Eigentlich wollte ich mir keine Lumpen-Firmware mehr auf meine RX machen, aber für dich mache ich noch mal eine Ausnahme. G-RX8 mit der 18er Firmware und dann auf die 19er umgeflasht. Vom Dachgeschoß in den Keller mit der X9D LBT. Dort habe ich mit der 19er dann versucht, doch mal einen Frame zu verlieren - keine Chance. Ich nenne das Betrug. Blau sind die Lost Frames, die mit der LQBB4 Methode ermittelt wurden (Kanalholds). Der RSSI wird übrigens mit der 19er Firmware nicht mehr auf 100 limitiert, das ist OK, nur die Ogottogotts müssen jetzt mit den % umdenken
Anhang anzeigen 180264

Ein beeindruckendes Ergebniss. Ich habe versucht die neue LQBB4 auf einem Alten Tadango LF zu bringen, anscheinend kann der alte Nano des nicht.
Carbo, gibt es bei die noch ein Fertigteil? (Bin aber erst mal weg)

Sigi

 

[Carbonator]

Ich habe versucht die neue LQBB4 auf einem Alten Tadango LF zu bringen, anscheinend kann der alte Nano des nicht.

Doch, das kann jeder Nano. Hast du die Infos am Anfang der LQBB4.ino gelesen?

 

[nihonski]

RC Groups - View Single Post - Important Firmware Update ACCST D16 2.0.0 - ACCESS also affected

 

[FJH]

Die Ausführungen dazu von Dir kennen wir doch hier schon im Thread.

 

[nihonski]

Wenn Kilrah zitiert wird, dann bitte auch meinen Thread.

Sag mal ehrlich, hast du den V2 Vorteil verstanden, und vor allem was bei schlechten Empfangsbedingungen passiert?
Gleichzeitig wird hier über unerklärliche Lock-Outs gequatscht.

 

[FJH]

Ewald, die aktuellen Posts im RCG Thread sind ausschliesslich bezüglich des manipulierten FL-Bit, nichts anderes. Deine Ausführungen zum Frame-Handling (Ringbuffer) waren bislang überhaupt kein Thema im RCG Forum. Und die liefern auch überhaupt keine Begründung für eine Notwendigkeit, das FL-Bit zu manipulieren.

Und ja, AFC Fenstererweiterung, CRC-Verbesserung und Data Whitening habe ich auch als positive v2 Verbesserung verstanden. Nur verstehe ich nicht, warum das FL-Bit manipuliert werden muss. Aber du hast ja bereits geschrieben, dass das von FrSky kommt und nicht von dir. Darum brauchst du auch keinen der Kommentare bzgl dieser Manipulation als Kritik an dich zu interpretieren und verteidigen musst du eine solche Manipulation auch nicht.

 

[FJH]

Warum schreibst du nicht einfach als Antwort auf die Frage von Kilrah, dass die Manipulation des FL-Bit nicht von dir kommt und dass du auch keine Erklärung für die Notwendigkeit einer solchen Manipulation hast oder erkennen kannst.

 

[nihonski]

Daß das nicht vom mir kommt weiß er.
Leider finde ich das neue Verfahren für 16 Kanalübertragung besser.
Deshalb wäre mein Vorschlag das Verfahren für 8 und 16 Kanalübertragung zu differenzieren.
Also 8 wie bisher und 16 als 2 Frames aus 4.

 

[FJH]

Habe ich von dir auch verstanden. Das kann man aber alles ohne eine FL-Bit-Manipulation machen, und nur darum geht es in der aktuellen Diskussion auf RCG. Ich glaube, dass deine erweiterten Ausführung zum 16-Bit-Frame-Handling die Leute da nur zusätzlich verwirrt. Das FL-Bit wird verstanden als Indikation der Datenübertragungsqualität OverTheAir, hat also nix mit der Verarbeitung durch die Empfängerfirmware zu tun, darum soll es eben nicht angetastet werden.

Du schreibst auch, dass du kein Mandat von FrSky hast und eben deine Posts nicht in dem Sinne verstanden werden sollen. Alles gut, aber ... du könntest sicherlich Engel alles dies klarmachen und Engel könnte dann auch bei FrSky dazu Position beziehen. Vielleicht passiert das ja auch und wir wissen es nur nicht.

 

[Sigimann]

RC Groups - View Single Post - Important Firmware Update ACCST D16 2.0.0 - ACCESS also affected

Ewald, du schreibst hier: According to FrSky, this is a request from Flight Controll Manufactures.

Wenn ich das mit der jetzt mit der neuen Erkenntniss, " In FW 191115 wird das FL über 12 Frames gefiltert" bewerte, dann ergibt der Wunsch der Flight Controll Manufactures einenSinn. Die wollten von den 12 Frams Filter weg.
Weis man denn wie lange das schon in so mancher Firmware drinn ist?

Sigi

 

[Sigimann]

Doch, das kann jeder Nano. Hast du die Infos am Anfang der LQBB4.ino gelesen?

KAnn ich am Sonntag nochmal dran.
Aber wenn du noch einen fertigen für mich hast, haben möchte ...

Sigi

 

[FJH]

Ewald, du schreibst hier: According to FrSky, this is a request from Flight Controll Manufactures.

Wenn ich das mit der jetzt mit der neuen Erkenntniss, " In FW 191115 wird das FL über 12 Frames gefiltert" bewerte, dann ergibt der Wunsch der Flight Controll Manufactures einenSinn. Die wollten von den 12 Frams Filter weg.
Weis man denn wie lange das schon in so mancher Firmware drinn ist?

Sigi

Es gab zu dem Zeitpunkt ein Firmware-Update für den G-RX8 und den R-XSR und für keinen weiteren Empfänger. Demnach sollte das nur in der letzten v1-Firmware der beiden Empfänger zu finden sein.

 

[nihonski]

Habs gerade nochmal mit 2017 FW und einem RX8R gemessen.
Ist nur in der FW 191115 drin.

 

[Carbonator]

Gleichzeitig wird hier über unerklärliche Lock-Outs gequatscht.

Es gibt hier keine Denk- und Schreibverbote.

Ich sehe die Gefahr, dass die eigentliche Ursache des Problems noch gar nicht beseitigt ist. Betroffene Kombinationen zeigen alle keinen 100% LQ, auch nicht bei optimalen Bedingungen. Die Tatsache, dass Frsky bei V2 grundsätzlich den LQ schönt, ist in diesem Zusammenhang nicht vertrauenerweckend.
Vermutlich sind die Symptome Lockout und Breakdance mit V2 beseitigt, aber ist auch der Frameverlust dieser betroffenen Kombinationen beseitigt?
Die meisten User hatten mit ACCST D16 übrigens null Probleme, wie ich auch.
Hypothese: mit dem Lost Frame Sensor kann man feststellen, ob man betroffen ist. Denn alle, die Lockouts hatten, hatten auch den unruhigen LQ (Frameverlust) bei optimalen Bedingungen.

 

[nihonski]

Übrigens, beim RX8R (ohne Pro) haben sie den Filter vergessen. (Also FL wie V1).
Wer also die V2.0.1 für den X8R/X6R/X4R und den RX8R herunterlädt, kann den Unterschied testen.