Telemetrie-Konverter: HOTT->FrSky

hillflyer · Jan 12, 2014

@ Nachbrenner

Ein tolles Projekt!
Ich habe ein paar Fragen dazu: Geht es auch mit dem Original Unilog? (Mit M-Link Firmware update)
Was bewog dich dazu den Teensy3 zu nehmen? die 3 Hardware UARTs?
Ich habe mal bei Stefan Merz angefragt, ob er evtl. eine FrSky Firmware plant. Falls ich was höre, sag ich Bescheid.

Gruß, hillflyer

Heino · Feb 2, 2014

Hallo Nachbrenner

Ich bin hier neu und habe gleich mal eine Frage.

Ich besitze ein Unilog2 mit dem ich folgende Daten auslesen kann:
Strom, Spannung, Einzelzellenspannung und GPS Daten.

Können diese Daten mit Deinem Telemetrie-Konverter
auf das FrSKY, HF-Modul DHT-U Version 2.0 übertragen werden ?

Gruß
Heino

xray · Feb 16, 2014

Hallo,

sehr interessantes Projekt! Ich habe ebenfalls vor, die Frsky-Telemetrie etwas zu erweitern. Allerdings möchte ich versuchen, aus dem NAZA-GPS einige Daten zu übertragen. Das habe ich mit dem Teensy 3.1 vor.
Als erstes habe ich die leere Pollingsequenz des X8R (ungebunden) aufgzeichnet:

7E 00 7E A1 7E 22 7E 83 7E E4 7E 45 7E C6 7E 67 7E 48
7E E9 7E 6A 7E CB 7E AC 7E 0D 7E 8E 7E 2F 7E D0 7E 71
7E F2 7E 53 7E 34 7E 95 7E 16 7E B7 7E 98 7E 39 7E BA
7E 1B 7E 00

Was da aber zu sehen ist, sind offensichtlich Sensor-IDs und hat mit dem FrSky DATA IDs nichts zu tun?

Ich habe mal zum Beispiel mit einem S.Port to UART Converter getraced:

7E 00
7E A1
7E 22
7E 83
7E E4
7E 45
7E C6 10 01 FD 08 00 00 00 E8
7E C6 10 01 FD 08 00 00 00 E8
7E 67
7E C6 10 01 FD 08 00 00 00 E8
7E 48
7E C6 10 01 FD 08 00 00 00 E8
7E E9
7E C6 10 01 FD 08 00 00 00 E8
7E 6A
7E C6 10 01 FD 08 00 00 00 E8
7E CB

Dieser meldet sich auf die ID C6. Wo und wie werden die DATA IDs eingesetzt?
Kann mir da jemand weiterhelfen?

Beste Grüße
Reinhard

nique · Feb 17, 2014

Lies dich mal hier ein:
http://openrcforums.com/forum/viewtopic.php?f=86&t=4433 (sehr aktuell, was die Umsetzung auf Smart Port angeht, jedoch für eigene Sensoren)
https://code.google.com/p/telemetry-convert/ (könnte für Dich besser passen, weil es um einen Telemtrie-Konverter geht)

nachbrenner · Feb 17, 2014

Hi Reinhard, deine Diagnose zu den Sensor- und Data-IDs ist korrekt. Du findest Beispiele für Data-IDs hier (als Value Types)

https://code.google.com/p/telemetry-convert/wiki/FrSkySPortProtocol

Dort ist auch ein Link in den Taranis-Sourcecode wo noch mehr von den Data-IDs aufgelistet sind.

wkorosec · Feb 17, 2014

Hallo Nachbrenner,
könntest Du bitte einen kleinen Hinweis geben, wie Du den MSB-Sensor an den Teensy angeschlossen hast ?
Ich krieg den Single-Wire Modus nicht zum Fliegen

Gruss & Dank
Wolfgang

xray · Feb 17, 2014

Hallo nique und Nachbrenner,
vielen Dank für die Hinweise. Diese Links habe ich teilweise schon angesehen.
Es gibt immer wieder Widersprüche.
Nur zum Beispiel von oben (S.Port to UART Converter).
Den Data-ID "01 FD" findet man nirgends. Wird da noch irgendwas "verwurstelt"

Beste Grüße

Edit: Es ist wieder mal einfacher als ich dachte. Der Sensor-ID ist völlig egal! Entscheidend ist immer nur der Value-ID. Das vermute ich jetzt. Ist es korrekt?

nachbrenner · Feb 18, 2014

wkorosec hat gesagt.:

Hi ich hab ein Unilog2 dran und keinen Multiplex-Sensor. Müsste aber auch mit Multiplex-Sensoren gehen.

Anschlusschema findest du ja hier: https://code.google.com/p/telemetry-convert/ (Die Handzeichnung)

Den Single-Wire-Modus für den Eingangsport (also der wo das Unilog dran hängt) stelle ich in der setup-Routine des Codes ein:

Code:

_input_C1 |= 32+128; // Single wire mode

Um auf diesem Port etwas zu senden muss man erst ein Register umschreiben (hab vergessen was es war, glaube von Input auf Output stellen), dann schreiben, warten bis der write durch ist und das Register zurück schreiben:

Code:

_input_C3 |= 32;		    
_inputSerial.write(i); // send sensor address
_inputSerial.flush(); // make sure send is complete
_input_C3 ^= 32;

Kompletten sourcecode findest du ja hier:

https://code.google.com/p/telemetry-convert/source/browse/telemetry_convert/telemetry_convert.ino

Den notwendigen Code habe ich aus dem Manual des MK20DX128 - das ist der auf dem Teensy 3.0 verbaute Chip. Manual ist hier verlinkt: http://www.pjrc.com/teensy/datasheets.html

Viel Erfolg!

xray hat gesagt.:

Korrekt, jeder Sensor kann beliebige Wertetypen (Value-IDs) schicken, da ist nichts festgelegt. Ein Sensor kann dabei auch mehrere Value-IDs versenden: Er antwortet einfach auf jeden Poll nach seiner Sensor-Id mit einer anderen Value-Id. Das macht z.b. das OpenXVario so, siehe Sourcecode hier: https://code.google.com/p/openxvario/source/browse/branches/openxsensor/oxs_out_frsky.cpp

xray · Feb 18, 2014

Hallo Nachbrenner,

danke für deine Bestätigung. Nun ist die Sache klarer.

Der Teensy 3.x ist ein Superteil für S.Port, da er One Wire und Invert UART direkt unterstützt. Von den 32Bit-Features ganz zu schweigen.
Neben den freien UART's für die Protokoll-Konverter kann er noch nebenbei über den 16Bit ADU die Lipospannung übermitteln, was der teuere S.Port to UART Converter von FrSky (24EUR) z.Zt.nicht kann! Teensy 3.1 ca.17EUR!
Hier mal ein Bild das zeigt, wie einfach die Anschaltung ist. (@hillflyer)
Zur Zeit nur die Lipospannung (das wichtigste), Konverter kommt später.

Beste Grüße

dl7uae · Feb 23, 2014

Moin!

Ich bin Tom, Entwickler des JLog (vielleicht bekannt), auch des HTI (Herkules Telemetry Interface), Multicopter-Ecke, in der FPV-Szene vielleicht eher bekannt.

Egal. Habe eben angefangen, die FrSky Telemetrie "auszubaldovern", um sie als #8 in JLog zu tun. Leider ignorieren die FrSky-Leute im entsprechenden Forum meinen NDA Antrag standhaft, das geht ja offenbar indirekt via Aufnahmeantrag in die "Developer Community".

Bin auf Euch gestossen, - well done!

Auf die Gefahr hin, Eulen nach Athen zu tragen.. Hab' mal schnell den LA angeschmissen. Das sind die 28 Adressen, die offenbar random im zeitlichen Abstand von 12ms durch den Empfänger auf seinem S.Port abgeklappert werden:

0x00
0x0D
0x16
0x1B
0x22 FCS-40 (FAS)
0x2F
0x34
0x39
0x45
0x48
0x53
0x67
0x6A
0x71
0x83
0x8E
0x95
0x98
0xA1
0xAC
0xB7
0xBA
0xC6
0xCB
0xD0
0xE4
0xE9
0xF2

Ciao. Tom

dl7uae · Feb 23, 2014

Sorry, korrigiere mich: Die Reihenfolge ist fix (s.u.), nicht random:

0x00
0xA1
0x22 FCS-40 (FAS)
0x83
0xE4
0x45
0xC6
0x67
0x48
0xE9
0x6A
0xCB
0xAC
0x0D
0x8E
0x2F
0xD0
0x71
0xF2
0x53
0x34
0x95
0x16
0xB7
0x98
0x39
0xBA
0x1B

Was war noch mal 0x00?

Die Sensoradresse ist ja offenbar schnuppe, sie muss nur eine sein, die gepollt wird, - die Value ID, die der Sensor für ein Datum zurückgibt, ist wohl allein kriegsentscheidend.

Habe noch nicht genug mit dem Sender (X9D) gespielt. Ist denn die Sensorauswahl für's Display ebenso wahlfrei? Auf jeden Fall kreiert der Sender für den FCS-40 automatisch auch eine eigene Compilation von Displays, darunter auch "Pwr" und "mAh", die er selbst berechnet, - also neben den user-defined Displays, hier auf "Curr" und "Vfas".

Nun will man aber nicht mit Sensoren von FrSky kollidieren. Lt. HP von FrSky gibt es bisher nur 4 S.Port Sensoren. Einen habe ich da, FCS-40, der hört eben auf 0x22.

Was ich nicht verstehe: Der Waschzettel ("Manual"), den es dazu gibt, sagt:
"The physical ID for this sensor is 03. The ID number could be changed by FrSky Servo Channel Changer..."
Wo korrespondiert denn "03" mit 0x22? (Den "Servo Channel Changer" habe ich auch noch nicht gefunden.)

Hmm.. Werde es dann notgedrungen wohl so machen, dass man in der Config von JLog/HTI aus den 28 Adressen wählen kann, abzüglich der bekannt besetzten, was aus meinem Wissenswinkel bisher nur die 0x22 ist.

Wie sieht's denn mit Sensoralarmen aus, flogen die gänzlich raus?

-----
Entschuldigung, ich bin mal so frech und kippe noch mehr momentane Fragen aus meinem Kopf in den Post:

CRC: Ist das tatsächlich so, dass man von CRC16 auf so ein ulkiges Pseudo-CRC8 ging? Ist ja nutzloser als das halbechte CRC8 von JETI und JR bzw., die Krönung, die "Checksumme aus dem Spielzeugland", die HoTT verwendet.
In der Source zum RPM Sensor fällt mir auch das "short crc" auf. Wirklich gewollt signed?!

Ich frage zum CRC, weil: Nicht, dass FrSky da momentan im Rx gar nicht auswertet (bzw. im Tx). JETI hatte uns ja zum Jahreswechsel 2012 auch so ein Ei gelegt, indem sie vorher das CRC auf Sensordefinitionen (Text+) nicht auswerteten in EX.

Zusatzfrage dazu: Das dritte Byte vom Ende ist immer noch fix 0x00, - bzw. jetzt auch das zweite, weil CRC nur noch ein Byte besetzt?

Zweitens, Idle Line Protocol: Das gibt es ja hier gar nicht. Stattdessen gab es so eine Definition zum Umschreiben von Steuerbytes, was hier 0x7E wäre. Sinn ist, zu vermeiden, dass ein Sensor das Datum eines anderen Sensors versehentlich als seine Adressierung versteht, --> Kollision auf dem Bus.

Gibt es diese Umschreibung noch, wenn ja, wie?

xray · Feb 23, 2014

Hi Tom,
schön, dass hier noch jemand mit macht.

dl7uae hat gesagt.:

Ist korrekt so, entscheidend ob und wie ein Wert dargestellt wird, ist der Value-ID

Ich verstehe überhaupt nicht warum FrSky so ein Geheimnis um das S.Port-Protokoll macht.
Es ist im Prinzip sehr einfach, aber wenn nicht dargelegt wird, wie die Sensor-ID's vergeben werden sollen oder können, sind Kollisionen nicht auszuschliesen. Das hast du richtig erkannt.

Die Idee, die S-ID's konfigurierbar zu machen, ist sehr gut. Aber wie soll ein Modellbaufreund, der mit Protokollanalyse nichts am Hut hat erkennen, das ein Adresskonflikt besteht?
Hier muss generell eine Regelung her.

Der S.Port to UART Converter antwortet auf C6. A1 und 1B werden auch in verschiedenen Projekten verwendet. Mit dem 22 sind es schon vier, die reservirt sind.
Vieleicht kennt jemand noch andere ID's?

Es wird tatsächlich ein "Spielzeug-CRC" verwendet. So wie ich das verstanden habe, ist die Sensor-Antwort wie folgt:
1. Byte = DataFrameHeader (0x10)
2. - 3. Byte = Value-ID
4. - 7. Byte = Value 32 Bit
8. Byte = CRC

Bei den anderen Frage muss ich passen.

Beste Grüße

nachbrenner · Feb 23, 2014

Kurzer Zwischenruf für alle die Unisens E verwenden: FrSky S.Port ist dort jetzt ab Firmware 1.07 voll supported. Ich könnte mir vorstellen dass auch der Support für das Unilog2 nicht mehr fern ist.

dl7uae · Feb 23, 2014

Der liebe Stephan..

Das mit der Checksum schnalle ich nicht:

// CRC update
crc += byte;
crc += crc >> 8;
crc &= 0x00ff;
crc += crc >> 8; //das high byte ist doch immer Null, s.o...
crc &= 0x00ff; //...ergo wirkungslos

VikiN · Feb 23, 2014

nachbrenner hat gesagt.:

danke für die Info
- passt! dann weiss ich jetzt was in meine 2 neuen segler reinkommt

jetzt nur noch schaun wo ich schnellstmöglich die frsky x8r herbekomm

dl7uae · Feb 24, 2014

Moin!

Hatte leider nicht viel Zeit heute..
Auch wenn es jetzt niemand mehr interessieren sollte, kurze Info:

1. CRC (zu meiner Frage oben)
// CRC update
crc += byte;
crc += crc >> 8;
crc &= 0x00ff;
crc += crc >> 8;
crc &= 0x00ff;
Die beiden rot markierten Zeilen sind überflüssig, weil wirkungslos.

2. Byte Stuffing, weil kein Idle Line Protocol
Output (Sensor):
Byte in frame has value 0x7E --> is changed into 2 bytes: 0x7D 0x5E
Byte in frame has value 0x7D --> is changed into 2 bytes: 0x7D 0x5D
Das Byte wird tatsächlich hinzugefügt, also ein's mehr im Frame.
In's (sog.) CRC geht aber NUR der ursprüngliche Wert, also 0x7E oder 0x7D.
Macht man das Byte Stuffing nicht, zeigt das zugehörige Display Null bzw. friert auf dem letzten gesehenen guten Wert ein, wenn ein Datenbyte 0x7E oder 0x7D ist.

3. Timing
a) Apropos "guter Wert": Sieht der Rx einen dekodierbaren Wert unter einer Sensoradresse (einer reicht, also eine mögliche ValueID), dann pollt er diese Adresse jedes zweite Mal. In meinem Fall ist das im augenblicklichen Testzustand nur eine Sensoradresse X. Er klappert also die 28 Adressen wie oben ab, jeder zweite Poll ist aber Adresse X, weil er die mal richtig lesen konnte (Frame und CRC stimmten).
Dadurch sinkt die Latenz gewaltig, vorher alle 28x 12ms, dann alle 2x 12ms.

b) Der FrSky Sensor FCS-40 hier lässt eine Lücke von 4.59ms zwischen dem Ende seines Adressbytes im Polling des Rx und seiner Antwort (Frame). - Das ist nicht notwendig, ich musste aber vorerst 100us Lücke lassen, werde aber damit noch experimentieren.

Tom

dl7uae · Feb 24, 2014

Die o.g. Lücke zwischen Adressbyte vom Rx und Anwort (Frame Header) des Sensors kann minimal 8 Mikrosekunden betragen, besser 10. K.A., wieso sich die MCU im Rx bei der Tx/Rx-Umschaltung auf dem 1-Wire so lange an den Füßen spielt.
(Für meine Devices ist das doof, weil 8us zuviel sind, um sie per Warten abreißen zu können, - führt daher zu verschachtelten Interruptroutinen, weil ein Timer bemüht werden muss, der einen hinter den Wartepunkt zurückführt.)

Kann mir einer auf's Pferd helfen?
Ich habe mehrere Spannungen auszugeben, mehrere Ströme etc. Nun dachte ich, das ginge per ValueID innerhalb einer Werteklasse. Die Taranis scheint aber nix davon zu wissen, weder im Telemetrie-Setup, noch in der Auswertung. Gebe ich zwei verschiedene Spannungen, z.B., auf unterschiedlichen ValueIDs aus (0x0210, 0x0211), dann flimmern beide Werte in einem Display rum.

Tom

P.S. Scheinen wohl noch nicht implementiert zu sein, die ValueID Ranges..

Weder Cels (0x0300) noch (geraten) 0x0310 für Cell kommen bei mir.

Was viel "witziger" ist, sollte ja gehen lt. dem Projekt hier im Thread, 0x0830, GPS Speed, kommt bei mir auch nicht..
Galt kommt nicht, ALT kommt nicht..

Verstehe ich das richtig, dass der User Alarme nur auf A1 und A2 setzen kann (RSSI noch), sonst gar nicht?! Auweia, was ist mit UbatMin, mAh, Temperaturen etc?
Alarme, die Sensoren senden, gibt es nicht?

(Tschuldigung für den Monolog

)

nachbrenner · Feb 24, 2014

Hi zur Anzeige des GPS-Speeds auf der Taranis habe ich glaube ich Spd im Telemetrie-Display ausgewählt. Alt klappt bei meinem Projekt definitiv. Weiter oben habe ich ein Foto meiner Telemetrie-Seite auf der Taranis eingestellt das passt zu meinem Code.

Mehrere Spannungen etc: Damit habe ich nicht rumprobiert, ich meine aber es gibt da Code in Opentx damit man Max/Min/Avg mehrerer Werte angeben kann, allerdings wird meiner Erinnerung nach nur einer ausgegeben.

Weiter viel Erfolg!

dl7uae · Feb 24, 2014

Danke.

Nö, auf Spd kommt auch nix.

Du hast weiter oben ein Vid eingestellt. Machst irgendwas an der SM Prandtl Probe, das Display Vfas reagiert.

Ich habe jetzt 9 Werte im Display, von Jlog kommend. Das reicht eigentlich soweit, nur mit dem Alarming hadere ich.
Alarme kann man offenbar nur im Sender setzen (Schwellen), bleibt nur A1 und A2, RSSI vergessen wir mal, die Alarmschwelle auf SWR ist fix, die Range ist eh nur 00..70. Mein Rx ist ein X8R, der hat nur A1. Ich gebe extra in A2 aus, funktioniert, aber es kommt kein Alarm auf die Schwellen, auf A1 schon.

Inzwischen waren die Chinesen gnadenvoll. Muss zugeben, bin schon wieder ziemlich pissed off. Kartoffelenglisch, unvollständig, teilweise falsch, insgesamt wie immer weitgehend unverständlich. Ob man die Protokollbeschreibung hat oder nicht hat, macht ergo wieder mal kaum einen Unterschied.

"OpenTx", dass ich nicht lache.. Von Innovation sehe ich nix. Wie kommt es nur, dass ausgerechnet solche Implementatoren in Bezug auf Modellbau offenbar völlig blind sind. Warum guckt man sich nicht mal um, wie es andere machen, lernt aus deren Fehlern, nimmt sich das Gute heraus? Stattdessen erfindet man auf der grünen Wiese erneut Schrott! Dachte schon, mein Spezialfreund in Nippon bei Futaba wäre die Krönung, aber das hier landet sogar noch darunter.

Vergnatzte Grüße
Tom

nachbrenner · Feb 24, 2014

Hey Tom,

Kann dich zu 100% verstehen, unverständlich warum jeder meint das Rad selbst erfinden zu müssen und es ja anders lösen muss als die Konkurrenz. Aber als Embedded-Coder siehst du das sicher nicht zum ersten mal. Ohren Steif halten und durch!

p.s.
Stell dir vor wie es mir ging als ich den Mist von fast Null auf erstmal dazu bekommen müsste überhaupt etwas zu tun, ich saß ewig wie der letzte Dummy vor dem LA-Logs bis ich ansatzweise kapiert habe was abging

Telemetrie-Konverter: HOTT->FrSky

Neuer Benutzer

Neuer Benutzer

Benutzer

Legal-LongRanger

Erfahrener Pfuscher

Wolfgang

Benutzer

Erfahrener Pfuscher

Benutzer

Anhänge

Neuer Benutzer

Neuer Benutzer

Benutzer

Erfahrener Pfuscher

Neuer Benutzer

Flying Wing Freak

Neuer Benutzer

Anhänge

Neuer Benutzer

Erfahrener Pfuscher

Neuer Benutzer

Erfahrener Pfuscher