Link Quality Sensor von Tadango

Status
Nicht offen für weitere Antworten.
#81
Der ATMage328P hat eine SPI Schnittstelle.
Warum nicht direkt die eingehenden Datenpakete mitlesen und den LQ-Wert am Ende der Pakete direkt auswerten. Dann ist die FrSky FW komplett aus dem Spiel.
Das ließe ich sich gleichermaßen für uplink und downlink machen. Also auch im Sender die Telemetrie Qualität auswerten.
 
Zuletzt bearbeitet:
#82
So, jetzt habt ihr mich absolut angehängt. Ich versteh jetzt nix mehr. Aber nach der Weisheit:.Wissen ist Macht, nix wissen macht auch nix stell ich mich als Wertelieferant zur Verfügung. Dazu zwei Fragen: Wenn ich einen meiner Sensoren umflashe muss ich das Kabel zum RX wieder ablöten, denke ich? Richtig?. Zweite Frage: der Kanal 8 muss frei sein ? Kein Servoausgang oder so? Die Auswertung der Logs überlasse ich dann Carbo oder einem anderen der davon mehr versteht.
Da mit der trojanischen Pferdefirmware 2.0 die echten Lost nicht mehr auf dem SBus sind, muss man eine andere Methode finden, um die Wahrheit zu sehen. Wer noch mit der ehrlichen Firmware fliegt, braucht nix zu ändern, es gibt keinen Erkenntnisgewinn.

Erst mit der 2.0 braucht man den neuen Ansatz von @bionicbone bzw. @ReinhardZ.
 
#83
Der ATMage328P hat eine SPI Schnittstelle.
Warum nicht direkt die eingehenden Datenpakete mitlesen und den LQ-Wert am Ende der Pakete direkt auswerten. Dann ist die FrSky FW komplett aus dem Spiel.
Das ließe ich sich gleichermaßen für uplink und downlink machen. Also auch im Sender die Telemetrie Qualität auswerten.
Da müsste man aber am Empfänger oder Sender rumbasteln. Das ist sicher für tiefergehende Forschungen OK aber für diesen Anwendungsfall zu aufwändig.
 
#84
Die Leitungen zu SBus und SPort sind auch bei.mir gesteckt. Es würde allerdings irgendwo erwähnt daß die Verbindung Inverter zum RXi des Arduino erst hergestellt werden darf nachdem der Arduino geflasht wurde ?? Die Verbindung ist bei mir direkt vom Drain des Fet zum RXi.
Wenn der FET ausgeschaltet ist, kann das Drain des FET beim Programmieren ruhig mit dem RX-Pin des Arduino verbunden bleiben. Der 10k Pull-Up Widerstand stört nicht. Ein sicheres Ausschalten des FET bei abgezogener Verbindung zum SBus erreicht man, wenn man vom Gate des FET einen 47k Widerstand an Masse (Source des FET) lötet.

Ich habe bei mir einen SMD Widerstand zwischen die FET-Beine gelötet
1581273136519.png
 
Zuletzt bearbeitet:
#85
Da mit der trojanischen Pferdefirmware 2.0 die echten Lost nicht mehr auf dem SBus sind, muss man eine andere Methode finden, um die Wahrheit zu sehen. Wer noch mit der ehrlichen Firmware fliegt, braucht nix zu ändern, es gibt keinen Erkenntnisgewinn.

Erst mit der 2.0 braucht man den neuen Ansatz von @bionicbone bzw. @ReinhardZ.
Der Nachteil der neuen Lösung ist, dass Kanal 8 nicht mehr zur Verfügung steht. Es ist also nur für besondere Messeinsätze (mit FrSky 2.x Software) sinnvoll, den Sensor mit der neuen Software einzusetzen.
Man könnte noch eine SW machen, die nur zusätzlich den FrSky Lost Frame Zähler als Absolutwert ausgibt, ohne die Kanal 8 Auswertung.
 

quax2011

Erfahrener Benutzer
#86
Ich hab die Inverter mit einem BS170 im SOT23 Gehäuse aufgebaut. Von daher ist es für mich einfacher das Drähtchen am RX Pin zu kappen und wieder anzulöten. Hat sich aber vorerst eh erledigt da ich nicht vorhab die Be-:poop: Firmware auf meinem Sender zu installieren. Eine Firmware die mir die Möglichkeit gibt Fehler zu erkennen ist mir allemal lieber als eine die mir vorgaukelt es gäbe den Fehler nicht mehr obwohl es nicht so ist.
 

QuadCrash

Erfahrener Benutzer
#87
Hat sich aber vorerst eh erledigt da ich nicht vorhab die Be-:poop: Firmware auf meinem Sender zu installieren.
Der Unterschied ist: mit der alten Firmware fällt Dein Flieger vom Himmel und Du kannst im Log das Problem evtl. sehen. Mit der neuen Firmware passiert das nicht mehr, das Log gaukelt Dir dafür 'ne heile Welt vor.

Was ist Dir lieber? Ein heiler Flieger oder die Wahrheit im Log? Schwierige Entscheidung ... :engel:.
 

quax2011

Erfahrener Benutzer
#88
Das die neue Firmware die Problematik beseitigt ohne neue andere Probleme zu generieren zweifle ich jetzt einfach mal an. Wenn ich in einem halben Jahr nur noch höre das alles bestens ist dann wechsele ich. Betatester mach ich erst mal nicht.
 
#89
ich habe hier zwei Bilder von einem Sensortest bekommen, auf die ich mir keinen Reim machen kann. Es handelt sich um eine QX7, die definitiv Lockouts und Breakdance verursacht hat. Dieses periodische Verhalten habe ich noch nie gesehen, was kann das sein?

andrew1.png
andrew2.png
 
#91
Ohne Angaben zur HW und FW kann man zu einem "internen" Problem kaum etwas sagen, außer daß es nach einer "Schwebung" aussieht (z.B. nicht synchrone Abtastrate).
Ein "externes" Problem wäre z.B. ein Radar Beam oder anderes periodisches Störsignal.
 
Zuletzt bearbeitet:

FJH

Erfahrener Benutzer
#92
ich habe hier zwei Bilder von einem Sensortest bekommen, auf die ich mir keinen Reim machen kann. Es handelt sich um eine QX7, die definitiv Lockouts und Breakdance verursacht hat. Dieses periodische Verhalten habe ich noch nie gesehen, was kann das sein?
Dem Filenamen nach muss es eine QX7/QX/S Access sein mit internem ISRM-N Modul, also nicht die "alte" QX7 mit internem XJT Modul.

Edit: Dem Filenamen nach schreibt er iXJT, eine solche QX7 gibt es aber nicht. Entweder ist es eine alte QX7 und die hat ein internes XJT verbaut, oder es ist eine neue QX7 Access und die hat ein internes ISRM-N verbaut.

Das erste für mich deutlich Erkennbare ist die Auswirkung der Link Quality auf den RSSI-Wert aufgrund der von FrSky angewandten Mischkalkulation, also rechnerische Verkoppelung von einem sauberen RSSI mit einem Wert der Link Quality. Diesen "Mist" habe ich neben anderen Dingen in einer aktuellen Mail an FrSky angesprochen und FrSky aufgefordert, die sowieso notwendige Überarbeitung der v2 Updates zu nutzen und uns dann einen sauberen, unvermatschten RSSI zusammen mit einem sauberen Link Quality Wert zu geben, so wie es zB TBS Crossfire mittlerweile macht. Sauber und leicht verständlich von Oscar Liang hier beschrieben:
=> LQ and RSSI in TBS Crossfire - Oscar Liang
Das würde dann auch die aktuelle Unvergleichbarkeit der RSSI-Werte zwischen ACCST und ACCESS bereinigen. FrSky hat es bisher eben nicht hingekriegt, in ACCESS eine gleichwertige Mischkalkulation wie unter ACCST hinzukriegen. Darum auch hatte FrSky bereits verlauten lassen, dass bei ACCESS die kritischen RSSI-Werte tiefer liegen und dementsprechend auch den Usern empfohlen, die Warnwerte runter zu setzen.
 
Zuletzt bearbeitet:
#93
@FJH Der Wahnsinn ist ja, dass die neuen RX, wie der G-RX8 um den es bei Andrew geht, tatsächlich einen sauberen RSSI übermitteln, also ohne Einfluss von Lost Frames/LQ bis in den Failsafe :
G-RX8.png
Die alten RX haben diese Mischkalkulation, hier wird bei beginnenden Frameverlusten der RSSI stark nach unten gezogen. Ich habe versucht, den wahren RSSI grob durch die Linie zu markieren, die Zacken nach unten sind die Vermischung RSSI mit LQ. Hierher kommt auch das weitverbreitete Missverständnis, dass man die RSSI Warnschwellen ohne weiteres herabsetzen kann. Die alten Warngrenzen bedeuteten einfach: Achtung, ab jetzt beginnt der deutliche Frame-/LQ-Verlust. Das ist dann ein Grund für Antennenoptimierung oder einen gescheiten Sender ;)
RX8R_lost.png
Wenn FrSky wenigstens eine Methode durchziehen würde, wäre man ein Stück weiter. Stattdessen kommt mit ACCESS die nächste schräge Nummer. Zuerst war er zu hoch, dann habe ich darauf hingewiesen, jetzt ist er zu tief. Vergleichbarer RSSI + LQ, das wäre das Optimum. Und wenn's irgendwie geht auch noch ehrliche Werte.
 

FJH

Erfahrener Benutzer
#94
@FJH Der Wahnsinn ist ja, dass die neuen RX, wie der G-RX8 um den es bei Andrew geht, tatsächlich einen sauberen RSSI übermitteln, also ohne Einfluss von Lost Frames/LQ bis in den Failsafe :
Anhang anzeigen 180062
Die alten RX haben diese Mischkalkulation, hier wird bei beginnenden Frameverlusten der RSSI stark nach unten gezogen. Ich habe versucht, den wahren RSSI grob durch die Linie zu markieren, die Zacken nach unten sind die Vermischung RSSI mit LQ. Hierher kommt auch das weitverbreitete Missverständnis, dass man die RSSI Warnschwellen ohne weiteres herabsetzen kann. Die alten Warngrenzen bedeuteten einfach: Achtung, ab jetzt beginnt der deutliche Frame-/LQ-Verlust. Das ist dann ein Grund für Antennenoptimierung oder einen gescheiten Sender ;)
Anhang anzeigen 180063
Wenn FrSky wenigstens eine Methode durchziehen würde, wäre man ein Stück weiter. Stattdessen kommt mit ACCESS die nächste schräge Nummer. Zuerst war er zu hoch, dann habe ich darauf hingewiesen, jetzt ist er zu tief. Vergleichbarer RSSI + LQ, das wäre das Optimum. Und wenn's irgendwie geht auch noch ehrliche Werte.
Wenn das beim G-RX8 wirklich ein unvermatschter, sauberer RSSI ist, dann muss mir jemand mal erklären, wie die doch eindeutige Auswirkung des LQ-Verlaufs auf den RSSI-Verlauf (erstes Bild) zustande kommt, wenn denn nicht durch irgendeine Mischkalkulation.

Ich möchte für LQ und für RSSI jeweils saubere, unvermatschte Werte haben. Vergleichbar müssen bei den Empfängern dabei nur die kritischen Werte sein, also Alarmwerte und FS-Werte und zwar jeweils separat für LQ und für RSSI. Und ja, der saubere RSSI muss natürlich als ebenfalls sauberer dB-Wert ausgegeben werden. FrSky hätte jetzt mit dem sowieso anstehenden v2 Update die Chance, dies umzusetzen und den Usern das auch als Verbesserung und neuen "Standard" zu erklären. Dasselbe könnte FrSky dann auch bei ACCESS durchziehen.
 
#95
Wenn das beim G-RX8 wirklich ein unvermatschter, sauberer RSSI ist, dann muss mir jemand mal erklären, wie die doch eindeutige Auswirkung des LQ-Verlaufs auf den RSSI-Verlauf (erstes Bild) zustande kommt, wenn denn nicht durch irgendeine Mischkalkulation.
Du meinst den Log von Andrew weiter oben? Genau das verstehe ich auch nicht, genausowenig wie die Periodizität. Bei diesem RSSI müsste er ständig um die 100% Linkqualität haben. Das ist entweder ein äußerer Einfluss oder deutet auf die Ursache für Andrews Schwierigkeiten hin. Keine Ahnung. Er muss jetzt mal weit weg von Störquellen den Test wiederholen.

Stell dir bei meinem G-RX8 Log einfach vor, dass der LQ am Schluss bei 0 ist (Failsafe), trotzdem gibt es diese Zacken wie beim RX8R nicht. Also gibt es keinen Einfluss LQ auf RSSI beim G-RX8, wenn alles OK ist.
 

FJH

Erfahrener Benutzer
#96
Ja genau den Log im ersten Bild meine ich. Der Kollege müsste vor allem mal angeben, wo und was er da gemacht hat. Ein Fluglog kann es ja nicht sein, sieht eher danach aus, als wenn er in seinem Haus über verschiedene Stockwerke/Etagen gewandert ist. Müsste sich bei den Höhenwerten auch ablesen lassen.
 
#97
"One thing that struck me right away from the two screenshots you included, was that my QX7 might be very badly tuned (as you first suspected). My best results still show significant variation in link quality. The plot below shows four tests here in my apt:
1. Full power, ~4m range
2. Range test power, ~4m range
3. Range test power, ~12m range
4. Full power, ~12m range."

Dieses Verhalten ist niemals Standard und entweder durch extreme Störstrahlung oder durch einen Defekt zu erklären. Ich wollte nur mögliche Ursachen diskutieren, den Log selbst muss man nicht weiter analysieren, der fällt total aus dem Rahmen. So könnte es zum Beispiel aussehen, wenn das Tuning krass danebenliegt. Andrew wartet auf ein MPM, dann kann er zumindest den Empfänger im Vergleich zu anderen beurteilen.
 

helle

Erfahrener Benutzer
#98
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.
 

FJH

Erfahrener Benutzer
Eine Frage grundsätzlicher Natur, die mir (leider) bei all der Hektik und Aufregung um das manipulierte FL-Bit im SBus Stream erst diese Nacht durch den Kopf gegangen ist. Wozu genau dient eigentlich dieses Bit?

Wird durch dieses Bit nicht die Weiterverarbeitung der entsprechenden Frames gesteuert? Also zB bei einer RB oder bei einem SBus=>PWM Adapter oder auch bei einem FC? Woher erhalten denn die nachfolgenden Prozesse die notwendige Information, ob entsprechende Frames im SBus Stream gültig oder ungültig sind, wenn nicht durch dieses FL-Bit?

Offensichtlicher Nachteil des Verfahrens ist wohl, dass bei 16-Kanal-Übertragung, welche aus 2 Frames besteht, es nur ein gemeinsames FL-Bit für jedes Framepäärchen gibt. Daher durchaus mit dem Verwerfen von beiden Frames auch ein im Grunde genommen intakter zweiter Frame mitverworfen wird. Dieser Zustand des eigentlich unnötigen Verwerfens des intakten Frames hat FrSky in der v2 Firmware durch ihr Korrekturverfahren soweit verbessert, als es den ungültigen Frame ersetzt durch den letzten gültigen und damit dann ein durchaus verwertbares 16-Kanal- Framepaar schafft, dessen eine Hälfte (Kanäle 1-8 oder 9-16) keine alten Werte, sondern neue Werte enthält. Und das Verfahren dann wohl appliziert für bis zu maximal drei FLs in Serie. So weit so gut.

Wenn jetzt aber diese korrigierten Frames auch von den RBs, den Adaptern und den FCs genutzt werden sollen und wenn die Nutzungssteuerung nun denn genau durch dieses FL-Bit erfolgt, dann muss mit der Framekorrektur leider auch das FL-Bit "mit-korrigiert" werden.

Dies leider mit den bekannten und diskutierten nachteiligen Folgen für eine LinkQuality-Ermittlung anhand genau dieses FL-Bits. Ein Dilemma, aus dem es aber drei Auswege gibt:

1. Man verzichtet auf eine Framekorrektur bei 16-Kanal-Übertragung
2. Man Modifiziert den Tadango FL-Sensor nach dem Verfahren von Reinhard
3. FrSky gibt uns bei den Empfängern einen LQ Sensor zusätzlich zu einem unvermatschten RSSI

Letzteres wäre für mich der richtige Weg.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten