Link Quality Sensor von Tadango

nihonski · Feb 9, 2020

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.

Carbonator · Feb 9, 2020

quax2011 hat gesagt.:

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.

ReinhardZ · Feb 9, 2020

nihonski hat gesagt.:

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.

ReinhardZ · Feb 9, 2020

quax2011 hat gesagt.:

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

ReinhardZ · Feb 9, 2020

Carbonator hat gesagt.:

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 · Feb 10, 2020

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-

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 · Feb 10, 2020

quax2011 hat gesagt.:

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 · Feb 10, 2020

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.

Carbonator · Feb 10, 2020

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?

ReinhardZ · Feb 10, 2020

Sieht aus, als ob die Telemetrieausgabe periodisch aussetzt. Wackelkontakt im Empfänger?

nihonski · Feb 10, 2020

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.

FJH · Feb 10, 2020

Carbonator hat gesagt.:

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.

Carbonator · Feb 10, 2020

@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 :

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

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 · Feb 10, 2020

Carbonator hat gesagt.:

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.

Carbonator · Feb 10, 2020

FJH hat gesagt.:

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 · Feb 10, 2020

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.

Carbonator · Feb 10, 2020

"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 · Feb 10, 2020

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.

bendh · Feb 10, 2020

und das wo FrSky gerade alles Neue breitbandiger macht.

FJH · Feb 11, 2020

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.

Link Quality Sensor von Tadango

Ewald

Allerhopp ;)

Benutzer

Benutzer

Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Allerhopp ;)

Benutzer

Ewald

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Allerhopp ;)

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer