Sensor zur Messung der Qualität des Hin-Kanals

Sensor zur Messung der Qualität des Hin-Kanals
basierend auf VarioGPS-Sensor

Beim Versuch mittels des Arduino-Projekts Jeti_VarioGPS-Sensor von RC-Thoughts / nightflyer88 weitere Funktionen zu testen und über ein zusätzliches Servosignalkabel das Verhalten des Varios im Fluge zu ändern, haben wir festgestellt dass man bei der REX Empfängereinstellung Impulsgeschwindigkeit=AUTO die in der Senderkonfiguration "Tx Frequenz" eingestellte Sendefrequenz exakt am Servoausgang bei PWM-Signal messen kann. Stellt man zum Test die "Tx Frequenz" am Sender um (z.B. von 100Hz auf 50Hz), so kann man diese Änderung exakt am Servoausgang messen.

Deshalb stellen wir hier mal die These auf, dass der Sender in der eingestellten Frequenz jeweils Datenpakete mit allen Servopositionen versendet und diese beim Empfang auf dem Empfänger an die Ausgänge verteilt werden. Mit dieser Arbeitshypothese sollte es möglich sein, an der Servo-Signalfrequenz und einer festen Senderfrequenz die Qualität des Hin-Kanals hinreichend zu beurteilen. Der Rückkanal, geht nur noch in die Übertragung der unten gelisteten Telemetriewerte ein, nicht aber in deren Wertigkeit.

Diese Funktionalität mit diversen Telemetriewerten (siehe folgende Liste), zur Auswertungen des PWM-Signals eines Servoausganges, ist in einem Fork des VarioGPS-Sensors zum Test eingebaut ( github.com/Pulsar07/Jeti_VarioGPS-Sensor/tree/SpeedVario ):
ID_SV_SIG_LOSS_CNT/SigLossCnt/Signal Loss Count
Zähler der sich inkrementiert, wenn das Servo-Signal länger als 100ms ausbleibt. Sollte es zu kompletten Rückkanal-Signalverlusten kommen, wird der intern im Arduino gespeicherte Wert bei wiederkommendem Rück-Signal, übertragen
ID_SV_SIGNAL_DURATION/SigDura/Signal Duration
gemessene Zeit, zwischen 2 PWM Signalen des Servoausganges in ms
ID_SV_SIGNAL_DURATION_MAX/SigDuraMax/Signal Duration Max
maximal gemessene Zeit, zwischen 2 PWM Signalen des Servoausganges ms
ID_SV_SIGNAL_FRQ/Signal Freq/Signal Frequency
aktuelle gemessene Frequenz in Hz des PWM Signales des Servoausganges, mit dem Nachteil, dass bei Rückkanal-Signalverlust natürlich auch dieser schlechte Wert nicht übertragen wird
ID_SV_SIGNAL_FRQ_RETARDED/SigFreqRet/Signal Frequency Retarded
um bei Rückkanal-Signalverlust die Frequenz-Werte nicht zu verlieren, wird der obige aktuelle Wert in einem Ringpuffer gespeichert und mit einer Verzögerung von 18 Sekunden "nachgesendet", so dass bei schlechtem Empfangssituationen, auch die Werte im Empfangsloch beurteilt werden können.

Die Telemetriewerte die übertragen werden, berücksichtigen nur den Hin-Kanal. Der Rückkanal kann nur verhindern, dass Sensorwerte in "Echtzeit" zurückübertragen werden, geht aber nicht in die Werte ein. Durch geeignete Maßnahmen, werden die Sensorwerte dann jedoch 18 Sekunden später, in der Hoffnung dass dann wieder ausreichend Rückkanal zur Verfügung steht, nachträglich übertragen.

Wir haben mit diesen Sensoren > 100 Flüge und Auswertungen mit unterschiedlichen Modellen gemacht und die Funktion geprüft. Es funktioniert aus unserer Sicht wirklich sehr gut. Man kann sehr schön den Rückkanal eliminieren und bekommt ein Gefühl was wirklich an Empfangsleistung da ist. Sehr kurzzeitige Werte kann man leider nicht immer sehen, da die Telemetrieübertragung viel langsamer ist, als die Messwerte entstehen. Der ID_SV_SIGNAL_DURATION_MAX allerdings zeigt die wirklich maximal gemessene Zeit zwischen zwei aufeinanderfolgenden PWM-Servo-Signalen (vermutlich ähnlich dem von Graupner verwendeten V-Pack-Wert). Dies ermöglicht eine vernünftige Einordnung der Übertragungsqualität und kann bei der Antennenausrichtung im Modell helfen.

Als Beispiel haben wir hier mal die Ansichten (Detailausschnitt) des Jeti-Studios eines Flug mit einem 3.2m Swift von Fridayfly angefügt. Wir fliegen an der Schwäbischen Alb Kante. Das Besondere an dem Flug ist die große Entfernung >700m bei geringer Höhe ~100m, mit Wald und Obstbaumhindernissen, was relativ schwierigen Empfangsbedingungen entspricht. Hier sieht man bei ca. 16:05 einen Hin-Signaleinbruch, bei dem sowohl der Q-Wert auf ca. 30% einbricht als auch die gemessene SignalDuration einen 50ms Peak hat (normal wären bei 100Hz Tx Frequenz eben 10ms). Die ab 16:10 aufgezeichneten Q-Wert Down-Peaks finden sich kaum wieder als schlechte SignalDuration-Werte, da sie vermutlich auf dem Rückkanal entstanden sind. Die Frequenzmesssung (die über mehrere Zyklen mittelt) zeigt eine leichte Verschlechterung auf ca. 80Hz. Die angezeigten Q-Wert-Down-Peaks auf ca. 30% sind deshalb aus unserer Sicht hauptsächlich dem schlechten Rückkanal geschuldet.


Wir haben das Ganze natürlich auch nicht ganz ohne Leidensdruck gemacht, da wir mit einer neuen DS-24 (aus der allerersten Charge) von Anfang an sehr große Probleme mit schlechten Q-Werten, Warnmeldungen und angeblichen Umschaltungen auf den 900 Mhz-Backup hatten, obwohl wir diese Modelle mit der DS-16 jahrelang problemlos geflogen sind. Wir wussten einfach nie, ob es denn nun der Rückkanal ist der den Q-Wert schlecht aussehen lässt oder wir wirklich Empfangsprobleme im Modell hatten.

Ergänzend sei noch gesagt dass wir an den Sendern-Empfänger-Konfigurationen niemals echte Empfangsstörungen nachweisen konnten. Allerdings hatte wir teilweise eben massiv schlechte Q-Werte mit einem der DS-24 Sender; ganz extrem schlecht waren diese mit der FW4.24. Software-Updates bis zur 4.28 und auch eine komplette Hardware-Überprüfung bei Jeti im Werk brachte allerdings keine wirklichen Verbesserungen den Q-Wert oben zu halten.
Was auf unserer DS-24 allerdings geholfen hat den Q-Wert zu verbessern, war die Deaktivierung aller LUA-Apps (!!!). Bei unserer DS-24 (aktuell FW 4.28) waren danach die Q-Werte deutlich verbessert und Warnmeldungen waren praktisch nicht mehr vorhanden. Eine Erklärung könnte sein, dass die Rückkanalverarbeitung im Sender laufzeittechnisch nicht unabhängig von einer LUA-App-Last im Sender ist. Dies ist aber natürlich nur ein Erklärungsversuch und kann nicht verifiziert werden. Aber vielleicht hilft diese einfache Maßnahme dem ein oder anderen seine Q-Werte besser in den Griff zu bekommen.

Vielleicht hilft ja unser kleines Do-It-Yourself-Projekt, dem ein oder anderen bei der Einschätzung seiner Q-Wert-Probleme und bei der Erarbeitung eines Gefühls für den Hin-Kanal. Sollte es von allgemeinem Interesse sein, obige Funktion zu nutzen, wäre es ggfs. sinnvoll die entsprechenden Codeteile wieder in den Fork von nightflyer zu mergen. Wir werden sehen, wie sich die Lage entwickelt.

Viele Grüße
Rainer (Pulsar07) und Jochen

Hallo Jochen, hallo Rainer,
vielen Dank für Eure Bemühungen und die ausführliche Beschreibung!
Alle diese Informationen dienen hauptsächlich für die interne Beruhigung, dass das Modell immer steuerbar ist.
Einfacher wäre es, wenn Jeti hier mal nachbessern würde, zumindest für die neueren REX und Assist Empfänger.
Diese sollten ja auch etwas Speicher dafür an Bord haben. Alles andere ist lediglich Software im Empfänger und im Sender.
Entspricht Euer Aufbau ähnlich dem in rcgroups diskutierten?

VG Bernd

Ein "Qualitätsmerkmal" für den Hin-Kanal dient immer der Beurteilung der Steuerbarkeit des Modells. Das beruhigt natürlich.
Ein Q-Wert von Jeti nahe 0 und Warnmeldungen beunruhigen extrem, wie die hohe Resonanz in den einschlägigen Threads zeigt.

Wir glauben hiermit ein Merkmal gefunden zu haben, das einem ein gutes Gefühl für die Kontrollqualität seines Modells zu bekommen. Wenn man z.B. sieht, dass in bestimmten Situationen die Signalrate von 100 pro Sekunde auf 40 zurück geht (immer nur Sender nach Empfänger), dann sieht man dass es eben schlechter wird, aber man weit von einem Kontrollverlust entfernt ist.

Den Aufbau in rcgroups kenne ich nicht. Unser Aufbau entspricht dem von nightflyer gezeigten. Man benötigt jedoch keinerlei Sensoren und lediglich ein Signalkabel mit einem 40kOhm Widerstand von dem D2 Ein/Ausgang des Arduino zu einem Empfänger-Servoausgang.

Hallo Bernd,
die beiden Systeme sind nicht miteinander vergleichbar. Unseres basiert ja auf einem Arduino und das von John (cravenjw) ist eine komplett andere Hardwarebasis mit anderem Code. Allerdings bringen beide Systeme vergleichbare Messergebnisse; d.h. so falsch sollten die Werte dann nicht sein

Hier mal zwei Beispiellogs:

Unter VarioGPS findest Du die Messwerte des Arduinos (VarioGPS); unter RX1,2,3 und CB die des Loggers von John. Dabei war der Messpin des VarioGPS sowie RX1 des anderen Loggers am REX7A, RX2 war am REX3, RX3 am R900 und CB an der CB200.

Hier siehst Du wie ähnlich VarioGPS und RX1 am REX7A sind (nur Hinkanal) und wie im Vergleich der entsprechende Q-Wert aussieht (Hin- und Rückkanal):


Viele Grüße
Jochen

Hallo,
Habe das heute zufällig hier gesehen und finde das Projekt sehr interessant.
Ich wundere mich aber darüber wie gering das allgemeine Interesse daran ist.
Gibt es Neuigkeiten zum Projekt? Habt ihr die Details irgendwo dokumentiert?

Kann man das Modul nachbauen?

Gruß Volker

Hi Volker,
Neuigkeiten gibt´s eigentlich keine. Der Link zum Sketch sowie die bisherigen Erfahrungen sind im Eröffnungsthread und das Signalkabel kommt dann über einen 40k Widerstand zur Signalmessung an D2 am Arduino.Mehr brauchst Du eigentlich nicht.
Wenn Du einen Arduino flashen kannst ist der Nachbau kein Problem.

Gruß Jochen