Telemetrie-Konverter: HOTT->FrSky

[nachbrenner]

Hallo Zusammen,

mein Traum: FrSky-Telemetrie mit Produkten nutzen können die diese eigentlich nicht unterstützen. Konkret: Ich möchte einen Telemetrie-Konverter von HOTT -> FrSky schreiben. Im Prinzip ein kleiner Adapter den man zwischen das Telemetrie-Anschlusskabel steckt und der unsichtbar seine Arbeit verrichtet und die Telemetriedaten vom Hott-Format in Frsky umwandelt. Erledigen möchte ich das mit einem kleinen Microcontroller, möglichst auf eigener Platine um beim Gewicht im Bereich von 2g zu bleiben. Ganz doof anfangen möchte ich mit einem Atmega328 und der Arduino-Plattform.

Wozu?

Es gibt einige Produkte die zwar HOTT Telemetrie unterstützen, jedoch nicht FrSky. Weiterhin gibt es für HOTT schon beliebte Sensoren die man damit an FrSky anbinden könnte.

Zusätzlich möchte ich baldmöglichst auch die neue FrSky-Telemetrie via SmartPort unterstützen (geht aber erst wenn meine Taranis da ist (bin auf dem 2ten Batch))

Beispiele für Produkte die HOTT aber kein FrSky können:

-> Unilog2
-> Unisens E
-> Ardupilot for HOTT

Ganz grob stelle ich mir das Ganze wie folgt vor:

Schritt 1: Irgendwo eine HOTT Funke mit telemetriefähigem Empfänger leihen. Dort mein Unilog2 als "GAM" dran klemmen und mittels logical analyzer schauen wie das Request/Response-Verhalten ist. Details zum Protokoll gibt es ja auch hier:

http://www.rc-network.de/forum/show...genbau-DIY-Telemetrie-Protokoll-entschlüsselt

https://code.google.com/p/hott-for-ardupilot/source/browse/Hott.pde


Schritt 2: Mittels eigenem uC und Programm die Telemetrie-Abfragen des Empfängers simulieren und die Werte in Puffer in meinem Programm schreiben (und seriell ausgeben). Nach diesem Schritt bräuchte ich die Hott-Funke und den Empfänger nicht mehr.


Schritt 3: Ein Dummy-Programm zur Ausgabe von Daten auf die FrSky-Telemetrie schreiben. Basis:

https://github.com/disq/multiwii-firmware/blob/telemetry/Telemetry.ino


Schritt 4: Beides verbinden und Daten mit HOTT-Protokoll lesen sowie mit FrSky schreiben

Schritt 5: Platinen-Layout


Und sobald verfügbar: Optional Daten über das neue FrSky SmartPort (S.Port)-Protokoll senden. Die Empfangsseite gibt es hier im Code:

https://code.google.com/p/opentx/source/browse/trunk/src/telemetry/frsky_sport.cpp

Daraus müsste ich die Sensorseite ableiten.

Soweit mein Vorhaben. Nun meine Frage: Ist so ein Projekt auch für andere interessant oder eher weniger spannend?

Für mich selbst brauche ich es um die Unilog2-Daten auch in der FrSky-Telemetrie sehen zu können (seitens SM-Modellbau/Hersteller Unilog2 ist kein Support für FrSky geplant). Konkret möchte ich gern Einzelzellenspannungen überwachen und Alarme ausgeben wenn zu niedrig.

Ich kann aber nicht absehen ob so ein Protokollübersetzer auch für andere Zwecke interessant wäre. Hätte von euch noch jemand konkrete Anwendungszwecke oder ist das eher ein Exoten-Projekt?

 

[ripschemitkraut]

Interessant scho, nur ich hab kein Frysky sondern nur Hott und da benutze ich das Ioboard von Jdrones und das MAVtoHoTT Teil von den Usern des Autoquad. Evtl. kannst dir da was abschauen. Gruß.

 

[ApoC]

Wenn du irgendwelche Daten brauchst, sag mir was ich wann und wo für dich loggen soll. Hab ne MX-20 / MX-16 / GR-16 / GR-24 und n GAM Modul sowie das "muerzi DIY GPS".

 

[Butcher]

habe enebenfalls interesse, habe 2x mx16, empfänger, diy gps und bastel grad noch ein bisschen an meinem DIY HOTT antennentracker,.... das wird aber wohl noch etwas dauern ^^

also wie kan man helfen ???

 

[nachbrenner]

Update: Ich bin jetzt soweit dass ich Telemetriedaten an den FrSky S.Port senden kann (quasi der letzter Schritt in meiner Auflistung in Post 1). Dazu gibt es von FrSky zwar keine frei verfügbare Doku, aber hier ist ein FrSky S.Port-Sensor implementiert: https://code.google.com/p/openxvario/source/browse/branches/openxsensor/oxs_out_frsky.cpp

Jetzt muss ich mich um die Input-Seite der Daten kümmern. Im Prinzip kann ich alles nehmen was auch das Unilog2 ausgeben kann, also Hott oder M-Link oder Jeti. Das Doofe ist: Das Unilog macht zwischen den drei Protokollen ein Autodetection. Die Kriterien nach denen er entscheidet welches Telemetrie-Protokoll er auswählt sind mir nicht bekannt. Das wird das nächste Ziel ... und dann wie angepeilt Hott als Input bzw. falls mir dazu kompliziert wird dann eben M-Link.

 

[Boarder]

Sehr geil... .endlich das Unilog mit S.Port... da wäre wirklich fantastisch...

 

[nachbrenner]

Mal als Bemerkung: Für mich als Elektronik-n00b ist der Weg schon ziemlich steinig ;-)

Hab gestern netterweise noch Antwort von Stefan Merz (Hersteller Unilog2) zur Telemetrie-Autodetection bekommen und wie man sicherstellt dass das Unilog2 als Telemetrie MLink erkennt. "Einfach" während des Unilog bootet seriell 38400 die Werte Hex 00-15 in Intervallen von 5ms schicken (-> das sind die Sensor-Abfragen) und dann schaltet das Unilog2 um. Da ich noch auf meinen Hott-Empfänger warte habe ich das gleich probiert - mal schauen ob nicht M-Link einfacher geht.

Also schnell ein Arduino-Programm zusammen gestrickt dass auf SoftwareSerial die Befehle schickt.

Wichtig dafür: Die Telemetrie-Bus-Systems von Hott und MLink laufen auf 3.3V Pegel (danke mürzi), mein Arduino Uno hat aber 5V. Also einen Pegelwandler dazwischen geklemmt.

Ewig herum gefrickelt - es kommen einfach keine MLink-Daten vom Unilog2 sondern nur Grütze. Irgendwann entnervt mit dem Oszi dran und dann kam das große "Wääääh":

Erkenntnis 1: Die Signale vom SoftwareSerial sehen auf dem Oszi übelst aus: Keine sauberen Flanken sondern lauter übelst diagonale Linien und keine stabilen High-Pegel sondern Spitzen. Ein Wunder dass das überhaupt funktioniert! (das hat es z.B. Nachweislich mit FrSky S.Port auf 57600 baud).

Erkenntnis 2: Die Signale sind derart schlecht dass mein Pegelwandler sie einfach ignoriert: Da kommt nix durch.

Also Umstellen auf den "echten" seriellen Port des Arduinos. Das ist aber gar nicht so einfach, da die Telemetrie-Protokolle nur einen Signal-Pin haben wo Master(RC-Empfänger) und Slave(Sensoren/Unilog2) abwechselnd senden - also Half Duplex. Der Arduino hat aber getrennte RX und TX-Pins. Erst habe ich irgendwie mit Widerständen herum gefrickelt, ging nicht also, also halbe Stunde Google-Orgie. Dabei das hier gefunden:

Das werde ich als nächstes Probieren. Da war der Abend auch schon um und ich keinen Schritt weiter. Ich hoffe es geht beim Embedded-Kram nicht nur mir so dass ich wie der Ochse vor dem Berg stehe weil einfach nix funktioniert, man nicht einfach sagen kann warum und nur noch frickeln hilft ;-)

 

[nachbrenner]

Kleines Update: Der Hott-Empfänger pollt im Auslieferungszustand und ohne gebunden zu sein leider keine Sensoren . Jetzt muss ich jemanden suchen der mir für 3 Tage eine Hott-Funke leiht, mal schauen ob sich eine Gelegenheit in der Umgebung auf tut.

Wenn ich da nix finde dann wird es wohl M-Link als Quellprotokoll: Da kenne ich jemanden dem ich die Funke evtl. für 3 Tage abschwatzen kann (hallo ninjamic )

 

[sandmen]

Update: Ich bin jetzt soweit dass ich Telemetriedaten an den FrSky S.Port senden kann (quasi der letzter Schritt in meiner Auflistung in Post 1). Dazu gibt es von FrSky zwar keine frei verfügbare Doku, aber hier ist ein FrSky S.Port-Sensor implementiert: https://code.google.com/p/openxvario/source/browse/branches/openxsensor/oxs_out_frsky.cpp

Jetzt muss ich mich um die Input-Seite der Daten kümmern. Im Prinzip kann ich alles nehmen was auch das Unilog2 ausgeben kann, also Hott oder M-Link oder Jeti. Das Doofe ist: Das Unilog macht zwischen den drei Protokollen ein Autodetection. Die Kriterien nach denen er entscheidet welches Telemetrie-Protokoll er auswählt sind mir nicht bekannt. Das wird das nächste Ziel ... und dann wie angepeilt Hott als Input bzw. falls mir dazu kompliziert wird dann eben M-Link.

Ich habe auch gerade den openxvario mir angeschaut.
Wie hast Du deine Test's den gemacht?
Kannst Du vielleicht kurz ein Aufbauschema/connection description hier Bereitstellen?
Und musstest Du irgend welche Änderung im Script machen?
Gruß
peter

 

[nachbrenner]

Gern. Anschlusschema gemäß PDF:

Anhang anzeigen s-port.pdf

Code ist ein eigenes PDE, Snippets aus OpenXVario übernommen, Sensors-IDs und Einheiten aus dem S.Port parsing Code der Taranis hier.

Ist aber nur POC-Status bisher, ich schicke einfach eine Sensorinfo (RPM-Sensor oder Voltage)

Code liefere ich heute Abend, gerade keinen Zugriff.

Edit: Stolperstein: Der serielle Port ist invertiert (siehe OpenXVario Code hier). Deshalb hatte ich mit meinen anfänglichen Versuchen mit FTDI am PC keinen Erfolg.

 

[sandmen]

POC, ist bei mir vieles ;-)
Bis ich wirklich dran Arbeiten kann wird es zwar noch etwas dauern,
aber schön das Du schon mal angefangen hast.
Wäre nett wenn Daten über Mavlink -> 8bitter -> SPort -> Taranis klappen würde.
Danke im voraus für dein Code.

 

[nachbrenner]

Hier jetzt der Code. Er schickt einfach Random-Werte auf den RPM-Sensor.

// Sends random sensor data for RPM to FrSky S.Port. 
//
// Receiver X8R S.Port signal pin should be connected to Arduino pin 8
//
// Outputs everything that is written to S.Port to Serial console for debugging purposes


#include <SoftwareSerial.h>

#define START_STOP         0x7e

// FrSky PRIM IDs (1 byte)
#define DATA_FRAME         0x10

#define SENSOR_ID 0xA1 // ID of sensor. Must be something that is polled by FrSky RX
#define RPM_ID 0x0500 // value type

SoftwareSerial _mySerial(8, 8, true);
short crc;

void sendByte(uint8_t byte)
{
  _mySerial.write(byte);
  Serial.print(byte, HEX);
  Serial.print(" ");
  // CRC update
  crc += byte; //0-1FF
  crc += crc >> 8; //0-100
  crc &= 0x00ff;
  crc += crc >> 8; //0-0FF
  crc &= 0x00ff;
}

void sendCrc()
{
  _mySerial.write(0xFF-crc);
  Serial.print(0xFF-crc, HEX);
  Serial.print(" ");
  // CRC reset
  crc = 0;
}

void sendValue(uint8_t header, uint16_t id, uint32_t value)
{
  sendByte(header);
  uint8_t *bytes = (uint8_t*)&id;
  sendByte(bytes[0]);
  sendByte(bytes[1]);
  bytes = (uint8_t*)&value;
  sendByte(bytes[0]);
  sendByte(bytes[1]);
  sendByte(bytes[2]);
  sendByte(bytes[3]);
  sendCrc();
}

void setup() {
  _mySerial.begin(57600);
  _mySerial.listen();
  
  Serial.begin(115200);
}

void loop() {
  static uint8_t lastRx = 0;
  uint8_t data = 0;
  
  while (_mySerial.available()) {
    data = _mySerial.read();
    if (lastRx == START_STOP && data == SENSOR_ID) {
      Serial.print("Sending: ");
//      sendValue(0x00, RPM_ID, 0x00000000); speculation: Sending Frame type 00 signals: No change in value of sensor. 
      uint32_t rpm_value = 300 + random(0,200);
      sendValue(DATA_FRAME, RPM_ID, rpm_value);
      Serial.println();
    }
    lastRx = data;
  }
}

Den "richtigen" Konverter möchte ich in 3 Modulen aufbauen:

Eingabe -> Puffer -> Ausgabe

Eingabe soll andere Sensoren pollen, das soll frei erweiterbar sein indem man einfach ein Module schreibt, also z.B. für HOTT oder auch Mavlink.

Puffer soll die Telemetriewerte zwischenspeichern.

Ausgabe soll die Telemetriewerte aus dem Puffer auf den S.Port schreiben.

Der Plan ist das ganze auf einem Atmega328P-AU 3.3V (TQFP) auf einer sehr kleinen Platine laufen zu lassen. Diese kann man zwischen den Telemetrie-Ausgang der Sensoren und den S.Port des Frsky-Empfängers stecken. Die Platine sollte nicht viel größer sein als der Atmega selbst (hoffe ich brauche keinen externen Quarz)

Soweit der Plan, jetzt muss ich erst einmal mit der Eingabeseite zu Potte kommen ;-)


Hier noch ein Bild meines Testsetups (klar: ohne Taranis):




Edit: Hier nochmal ein Bild dass das Software-Serial-Signal vom Arduino im Vergleich zu einem echten UART zeigt. Links die Anfrage vom X8R-Empfänger (richtig auf 3.3V Pegel und gescheite Flanken) und rechts das Gezitter vom Software Serial das irgendwie nur auf einen niedrigeren Pegel kommt.

 

[sandmen]

Hmm, mal schauen.
Muss ich an der Taranis noch was aktivieren, das die Telemtry funktioniert?
Oder das der SmartPort gepollt wird?

 

[nachbrenner]

Der Smartport wird immer gepollt und die Telemetrie ist immer aktiv, auch im Failsafe (zumindest bei mir, Empfänger ist als D16 gebunden). Damit du die übertragenen Werte auch auf der taranis siehst: Auf Seite 12 der Modellsettings bei der Komfiguration der Telemetrieseite 1 den RPM-Sensor rein (für mein Beispiel oben)

 

[sandmen]

Hast recht, gerade mit nem Oszi nach gemessen.
Hmm, Softserial liest aber trotzdem nicht.
Oszi, Hintergrundbeleuchtung defekt :-(


Standard Softserial Library?

 

[nachbrenner]

Softserial-Lib von Arduino 1.05. Es könnte sein dass alte Versionen kein invertiertes Serial konnten.

GND von Arduino und Empfänger verbunden?

 

[sandmen]

Hmm, ja, der X8R wird vom Arduino board gespeist, wenn ich mit dem Oszi ran gehe (PWM8 Eingang) , dann messe ich mit dem Oszi auch das Signal vom Receiver.

Hmm, höchstens noch PIN's, habe hier ein alten Mega 1280, sollte aber genau so funktionieren.

 

[nachbrenner]

Leider keine Idee, sorry. Eventuell ist mein Code nicht stabil oder es gibt auf dem Mega ein Problem wenn bei Softserial RX und TX-Pin gleich sind.

 

[sandmen]

Ok, bei meinem Seeeduino Mega 1280, hat der Port 8 halt kein Int.
Somit funktioniert der Pin nicht.
Ganz schön lange her, das mit den 8-bittern, und Arduino.
Aber ganz witzig wieder.

 

[nachbrenner]

Oh das wusste ich nicht - dann mag er jetzt auf einem anderen Pin?

Tja ich würde gern STM32 lernen, befürchte aber dass das für dieses kleine Projekt Overkill ist und ich erstmal laufen lernen sollte