Telemetrie Daten Ausreißer in Log-Datei

[ReinhardZ]

So, mal ein update zum Stand der Forschungen:

FrSky kann mein Problem nicht reproduzieren, es mangelt offensichtlich an geeigneter Hardware.
Die neue ACCESS SW, die ich von FrSky bekommen habe, zeigt das gleiche Verhalten / Problem.
Ich habe die SPort Kommunikation zwischen dem F411W Flight Controller und dem R9MM Empfänger mit dem Logik Analysator untersucht. Das sieht sauber aus. Die Ausreißer bei den Telemetriewerten sind nicht auf dem SPort Bus zu finden, d.h. die Werte werden korrekt vom F411W gesendet. Daraus folgt, dass es ein Problem von FrSky oder von OTX ist. Da ich mit der ACCST Version der R9 Software keine Ausreißer beobachte (heute nochmal probiert), bleibt für mich ein FrSky ACCESS SW Problem über.
Ich werde von der ACCESS SW bis auf weiteres die Finger lassen.

 

[FJH]

Die Ausreisser gibt es auch beim GRX8 mit ACCST Firmware. Da war man öfter schon mal auf mehreren hundert Kilometer Max. Höhe, auch im Log.

 

[ReinhardZ]

Am Schreibtisch gibt es aber schon einen deutlichen Unterschied zwischen ACCST und ACCESS. Bei ACCST sind keine Werte gestört, bei ACCESS mehrere.

Hier mal eine Übersicht:

 

[ReinhardZ]

Die Analyse mit dem Logik Analysator (Saleae clone) ergibt gute Einblicke in die Funktion des SPort Bus:


Das Bild zeigt das Timing auf dem SPort. Alle 12ms fragt der Empfänger (Master) eine der definierten Sensor IDs ab. Wenn ein Sensor mit der entsprechenden ID am Bus angeschlossen ist, antwortet er mit einem Datenpaket. Hier ist nur der F411W Flight Controller angeschlossen. Der Empfänger fragt dann alternierend eine definierte Sensor ID ab und dann den F411W (ID 0x1B).


Hier sieht man erst die Abfrage des Empfängers an den 'Sensor' F411W (0x7E 0x1B) und dann die Antwort mit dem Datenpaket vom F411W:
0x10 Datenpaket folgt
0x00 0x07 Sensorwert AccX folgt (jeder Sensorwert hat einen 16Bit Identifier LSByte MSByte)
0xFF 0xFF 0xFF 0xE8 signed 32Bit Sensorwert (-0,024g) > Korrektur: 32Bit Wert FF FF FF FF = -1 bzw. -0,001g
0xE8 Checksumme


Hier sieht man die Abfrage eines nicht angeschlossenen Sensors (ID 0x6A), da erfolgt dann keine Antwort.

Da die Abfrage des F411W alternierend zu den anderen IDs erfolgt, kann er alle 24ms einen 32Bit Wert senden. Der F411W kennt 16 verschiedene Sensorwerte, also wird jeder Wert im Telemetrie Log alle 16*24ms = 384ms aktualisiert.

Es macht also hier keinen Sinn, mit einer sample rate kleiner 0,2s das Log aufzuzeichnen.

edit: hier noch die Einstellung für den LA

 

[Bussard]

Hier sieht man erst die Abfrage des Empfängers an den 'Sensor' F411W (0x7E 0x1B) und dann die Antwort mit dem Datenpaket vom F411W:
0x10 Datenpaket folgt
0x00 0x07 Sensorwert AccX folgt (jeder Sensorwert hat einen 16Bit Identifier LSByte MSByte)
0xFF 0xFF 0xFF 0xE8 signed 32Bit Sensorwert (-0,024g)
0xE8 Checksumme

Müsste dann der Sensorwert nicht nicht 0 nach dem Bild sein (ein 0xFF mehr)?
0xFF 0xFF 0xFF 0xFF 0xE8 signed 32Bit Sensorwert1

 

[ReinhardZ]

Ja, da bin ich wohl etwas im Bild verrutscht und habe mit der Checksumme (0xE8) gerechnet

Der Wert ist aber dann nicht Null, sondern FF FF FF FF = -1 entsprechend -0,001g

signed 32Bit bedeutet eine Vorzeichenbehaftete 32Bit (4 Byte) Zahl.
Am Beispiel mit einem Byte ist es vielleicht einfacher zu erklären:
Ein Byte kann Werte von 00 bis FF in Hexadezimal Darstellung annehmen, bzw. 0 bis 255.
Wenn man auch negative Zahlen darstellen will, teilt man den Wertebereich in der Mitte und nimmt dann 0..127 für die positiven Zahlen und 255..128 für die negativen Zahlen (2er Komplement)

Hab mal eine Skizze dazu gemacht


Wenn du dann FF hast entspricht das -1.
Kann man rechnen indem man einfach 256-255(FF) rechnet und dann das Ergebnis negativ nimmt.

Auf dieser Seite gibt es einen Rechner dafür.

 

[ReinhardZ]

mal wieder ein update:
Nach der 4. Test-SW Version von FrSky scheint die ACCESS Telemetrie mit dem R9MM Empfänger jetzt zu laufen. Beim Test am Schreibtisch habe ich keine Ausreißer mehr.

Ich bin gespannt, ob es jetzt bald ein offizielles SW update gibt...

 

[ReinhardZ]

So, nach kleiner Anfangsschwierigkeit läuft jetzt die ACCESS Telemetrie mit der neuen 1.2.0 SW, die heute veröffentlicht wurde, einwandfrei. Es gibt keine Ausreißer mehr in den Telemetriedaten!

Dieses Thema ist damit erledigt.