Telemetrie Daten Ausreißer in Log-Datei

Status
Nicht offen für weitere Antworten.
R

ReinhardZ

Benutzer
#1
#1
Hallo zusammen,

Ich habe jetzt erstmals Telemetrie Daten von meinem Nano Talon mit R9MM Empfänger geloggt.
Dabei erkennt man in der Log-Datei bei diversen Daten Ausreißer. Das sind mit Sicherheit keine echten Daten, sondern Übertragungsfehler oder Fehler beim Speichern der Daten auf der SD-Karte im Sender.

Hier mal ein Screenshot vom Companion Log-Viewer
Screenshot.jpg

Der Strom Verlauf ist normal, aber auf der Höhe sind Ausreißer.
Man erkennt auch auf dem Telemetrie-Screen des Senders, dass die Daten ab und zu falsch sind.

Im Nano Talon ist ein F411Wing mit INAV V2.2.1 verbaut und die Telemetrie Ausgabe erfolgt über SoftSerial an den SPort des R9MM. Im Sender (X9D SE 2019) steckt ein R9M2019 Modul mit aktueller ACCESS Firmware. Übertragungsmodus ist 25mW LBT mit Telemetrie.

Im Anhang nochmal die komplette Log-Datei (GPS-Pos überschrieben)

Hat jemand ähnliche Effekte beobachtet oder eine Erklärung dafür ?
 

Anhänge

Zuletzt bearbeitet:
Carbonator

Carbonator

Allerhopp ;)
#2
#2
Die Ausreißer gibt es bei den meisten Sensoren. Sieht fast so aus, als ob FrSky wieder mal das Byte Stuffing vergesssen hat. Da müsste mal jemand mit R9M2019 ACCESS gegenchecken, hab ich nicht am Start.
 
R

ReinhardZ

Benutzer
#3
#3
Ich habe gerade nochmal einen Test am Schreibtisch gemacht.
Es sieht für mich jetzt eher so aus, als ob der Effekt etwas mit der Spannungsversorgung im Modell zu tun hat.

Auf dem Screenshot erkennt man, dass die Ausreißer auf 'Alt' beginnen, wenn die Spannung VFAS einbricht.
Screenshot2.jpg
Der Original Regler im Nano Talon ist nur mit AWG18 Leitung mit dem Akku verbunden.
Vielleicht hilft es ja auch, einen Kondensator an der FC über den Ubat Anschluss zu löten.

Edit: Der Regler ist natürlich mit der FC verbunden (mit AWG18) und ich habe das Akkukabel deshalb auch mit AWG18 an die FC angeschlossen. Das ist wohl eher das Problem...

Im Anhang nochmal die Log-Datei
 

Anhänge

Zuletzt bearbeitet:
R

ReinhardZ

Benutzer
#4
#4
So, das Problem scheint gelöst!

Ich habe mal einen 220u/35V Ko über den Ubat Anschluss des F411W FlightControllers gelötet und einen 330u/16V Ko auf die 5V am Servostecker der F411W gehängt (was so da war an Kos). Die Daten sehen jetzt am Schreibtisch OK aus.

Screenshot3.jpg

Der F411W Controller scheint doch recht empfindlich zu sein, was die Spannungsversorgung angeht!
Ich würde jedem F411W Nutzer empfehlen auch die Spannungsversorgungen (besonders die 5V) mit Kondensatoren zu stabilisieren.

F411Wing_mitKo.jpg
 

Anhänge

R

ReinhardZ

Benutzer
#6
#6
Ist dieser Regler
NT_Regler.jpg

Das BEC wird ja nicht genutzt, aber kann natürlich sein, dass der Regler auf der Ubat Leitung Störungen erzeugt...
 
Carbonator

Carbonator

Allerhopp ;)
#7
#7
Ich tippe immer noch auf byte stuffing, mit der Versorgung tue ich mich schwer. Bei AccZ, A4 und GAlt sieht man auch immer noch Ausreißer. Byte stuffing Fehler fallen nur bei bestimmten Zahlenwerten an (0x7E, 0x7D) , deswegen gibt es unter Umständen große Abschnitte ohne Fehler.
 
R

ReinhardZ

Benutzer
#8
#8
Die Kondensatoren haben aber definitiv was gebracht. Ich hab nochmal Low ESR Typen bestellt und werde den Ko über Ubat dann nach dem Strommesswiderstand einlöten, da wo auch der Regler angeschlossen ist. Der Regler hat offensichtlich keinen (großen) Kondensator im Eingang, was eigentlich üblich ist.

Die Ausreißer bei A4 passieren aber auch genau da, wo Strom fließt. A4 ist doch normalerweise der Spannungseingang am Empfänger? Der R9MM hat keinen A4 Eingang rausgeführt, ist also eigentlich undefiniert/offen. Die Ausreißer auf Galt fangen auch an, wenn Strom fließt.
Screenshot4.jpg

Der Ausreißer auf AccZ erfolgt genau zu dem Zeitpunkt, wo es auch Ausschläge auf AccX und AccY gibt (die habe ich durch Bewegen des Modells erzeugt. Wegen der 1s Abtastrate sehen sie etwas spitz aus). Das deutet auf ein Übersprechen in dem Sensor hin, eventuell auch wegen unsauberer Versorgungsspannung.
Screenshot5.jpg

Zu dem Byte Stuffing: Wie funktioniert das genau?
Könnte man nicht eine Dreiecksfunktion erzeugen, die alle Werte durchläuft um hier einen Effekt nachzuweisen?
 
Zuletzt bearbeitet:
Carbonator

Carbonator

Allerhopp ;)
#9
#9
ReinhardZ hat gesagt.:
Zu dem Byte Stuffing: Wie funktioniert das genau?
Könnte man nicht eine Dreiecksfunktion erzeugen, die alle Werte durchläuft um hier einen Effekt nachzuweisen?
Zum Vergrößern anklicken....
0x7E darf im Datenstrom nie vorkommen, es ist als Startsignal für den SPort Frame reserviert. Jeder SPort Frame beginnt mit 0x7E und die Sensoren antworten darauf (wenn ihre ID im nächsten Byte kommt).
Wenn man den FC langsam um die Achsen dreht, sollte man such die kritische Situation erzeugen können.

Der Fehler kann in der FrSky Firmware stecken, in der FC Firmware, oder wie du vermutest, in der Hardware.
 
R

ReinhardZ

Benutzer
#10
#10
So, ich habe mal weiter getestet und habe
- einen X4R Empfänger in den Nano Talon eingebaut und mit dem X9D 2019 Sender im ACCST Mode gebunden
- die Kondensatoren auf Ubat und 5V wieder rausgenommen

Ergebnis: Keine Ausreißer in der Log-Datei!

Das Problem hat also schon mit dem R9-System zu tun.
Ich vermute jetzt, dass der R9MM-Empfänger empfindlich auf unsaubere Versorgungsspannung reagiert, da er doch sehr klein ist und wenig Platz für Abblockkondensatoren bietet.

Die Forschungen gehen weiter ...
 
Carbonator

Carbonator

Allerhopp ;)
#11
#11
Der R9MM stabilisiert die vom FC bereits auf 5V stabilisierte Spannung nochmal auf einem niedrigeren Niveau. Ein Spannungsproblem kann man fast sicher ausschließen, FC Firmware nach deinem Test auch. Bleibt nur noch .... ;)
Mach doch mal den Test mit den langsam bewegten Acc Sensoren am Schreibtisch, dann kannst du die Spannung als Ursache ausschließen, wenn auch so Ausreißer in den Acc Daten kommen.
 
Zuletzt bearbeitet:
R

ReinhardZ

Benutzer
#12
#12
So, nächste Versuchsreihe:

Tabelle.jpg

Die Kondensatoren bringen hier nichts. Am Oszi sieht man zwar weniger Ripple, aber es gibt immer noch Aussetzer.
Was auffällt, ist, daß fast immer die gleichen Werte betroffen sind. Das kann natürlich mit der Position des Wertes im Datenframe zu tun haben.

Als nächstes werde ich dann mal den R9-Empfänger und das R9-Modul auf eine nicht ACCESS Firmware flashen...
 

Anhänge

R

ReinhardZ

Benutzer
#13
#13
Ich habe jetzt das R9-Modul und den R9-Empfänger auf die 'normale' (nicht ACCESS) SW geflasht.

Keine Telemetrie Ausreißer mehr am Schreibtisch !

@Carbonator : Du hast also doch Recht gehabt. FrSky hat ein SW-Problem in der R9 ACCESS SW

Hier nochmal die Übersicht
Tabelle.jpg

Als nächstes folgt die Felderprobung...
 

Anhänge

Carbonator

Carbonator

Allerhopp ;)
#18
#18
Wenn man nicht binden kann, kommen auch keine Spikes in der Telemetrie ;) Das wird schon .....
 
R

ReinhardZ

Benutzer
#19
#19
Ich denke auch, daß das Problem gelöst wird.
Die Kommunikation dauert nur immer etwas wegen der Zeitverschiebung, da ich auch nicht so der Frühaufsteher bin :)
 
R

ReinhardZ

Benutzer
#20
#20
Das mit dem Problem beim Binden war mein Fehler!
Bei ACCESS Empfängern darf man ja nicht den Bindeknopf am Empfänger drücken bei Power On.
Wenn der Empfänger einmal registriert ist, reicht es am Sender die Bindefunktion aufzurufen und dann den Empfänger einzuschalten (ohne Drücken des Bindeknopfs am RX). Ist ja eigentlich auch einfacher.

In der Telemetrie gibt es aber immer noch Spikes auf manchen Signalen.
Ich warte auf die nächste SW Version ...
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten