Graupner HoTT Telemetrie-Sensoren Eigenbau DIY | Telemetrie-Protokoll entschlüsselt

[Globe]

Hallo,

nachdem ich keine Informationen zu den GPS-Frames finden konnte, hab ich selber mal das Protokoll zerlegt. Hier das Ergebnis was ich auf die Schnelle raus gefunden habe:

typedef struct
{
uint8_t StartByte; // 0x7C
uint8_t Packet_ID; // HOTT_GPS_PACKET_ID (0x8a)
uint8_t WarnBeep; // Anzahl der Töne 0..36
uint8_t constPar; // muss immer 0xA0 sein
uint8_t label1; // Invertierte Darstellung einzelner Werte (bitcodiert)
uint8_t label2; // Invertierte Darstellung einzelner Werte (bitcodiert)
uint8_t direction; // Richtung zum Modell in deg/2
uint16_t v_kmh; // Geschwindigkeit in km/h
uint8_t w_e; // 0 = westliche / 1 = östliche Länge
uint16_t lon_deg_min; // Länge in Grad|Minuten
uint16_t lon_min_dec; // Dezimalstellen Minuten
uint8_t n_s; // 0 = nördliche / 1 = südliche Breite
uint16_t lat_deg_min; // Breite in Grad|Minuten
uint16_t lat_min_dec; // Dezimalstellen Minuten
uint16_t dist; // Entfernung in m
uint16_t alti_m; // Höhe in m (+500)
uint16_t vario_m_per_1s; // Steigen in m pro 1s (+30000)
uint16_t vario_m_per_3s; // Steigen in m pro 3s (+120)
uint8_t nullByte1;
uint8_t directionHome; // Richtung zum Startpunkt in deg/2
uint8_t nullByte2[17];
uint8_t EndByte; // 0x7D
uint8_t Crc; // CRC
}GpsPacket; //GPS Module

Vielleicht hat ja der ein oder andere noch ein paar Vorschläge zu den leeren Bytes?


Viele Grüße
Georg

[Evgenij]

Hier ist ein Link.
Da kannst Du versuchen die Skripte zu benutzen.

oder noch das:

typedef struct
{
unsigned char StartByte; //0 // 0x7C
unsigned char Packet_ID; //1 // 0x8A - GPS
unsigned char WarnBeep; //2 // Anzahl der Töne 0..36
unsigned char Heading; //3 // 1 = 2°
unsigned int Speed; //4+5 // in km/h
unsigned char Lat_North; //6
unsigned char Lat_G; //7
unsigned char Lat_M; //8
unsigned char Lat_Sek1; //9
unsigned char Lat_Sek2; //10
unsigned char Lon_East; //11
unsigned char Lon_G; //12
unsigned char Lon_M; //13
unsigned char Lon_Sek1; //14
unsigned char Lon_Sek2; //15
unsigned int Distance; //16+17 // 9000 = 0m
signed int Altitude; //18+19 // 500 = 0m
unsigned int m_sec; //20+21 // 3000 = 0
unsigned int m_3sec; // 120 = 0
unsigned int m_10sec; //
unsigned char NullByte; // 0x00
unsigned char NullByte1; // 0x00
unsigned char EndByte; // 0x7D
} GPSPacket_t;

Für alle die auch GPS bauen:
Ich habe HIER
GPS-Sensor gekauft(27€ mit Versand).
Es funktioniert schon die Daten über Arduino mit Softserial zu lesen.
Es bleibt NUR die Daten an HOTT zu übertragen.

[Globe]

Hallo Evgenij,

fürchte dein GPS-Frame ist noch V3. Kann das sein?

Gruß
Georg

[Evgenij]

Ja, das stimmt.
Ich habe noch V3, aber für Anfan es ist egal, ich versuche noch zu verstehen, wie das funktioniert.

[MeiT]

Ja, das stimmt.
Ich habe noch V3, aber für Anfan es ist egal, ich versuche noch zu verstehen, wie das funktioniert.

Hi,

dann ist es sinnvoll gleich auf V4 zu wechseln und V4 zu verstehen.

Grüße

[Mulder]

GPS läuft bei mir auch schon ansatzweise (HOTT V4), ich verwende das PA6C Modul von Trenz Elektronik (MTK3339 Chipsatz), der Empfang ist super, habe in der Dachwohnung 7Satelliten!

Als GPS Library für den Arduino 1.0 verwende ich TinyGPS: http://arduiniana.org/libraries/TinyGPS. TinyGPS erledigt die komplette Parser-Arbeit. Die GPS Daten werden seriell über die NewSoftserial eingelsen. Damit bin ich noch nicht glücklich... Schön wäre z.B. ein kleines ATMEGA 644p Board, da der 644p zwei UARTS hat.

Die gps.speed() Funktion von TinyGPS welche die Geschwindigkeit als unsigned long in Knoten/100 liefern sollte liefert bei mir nur Unsinn... Auf Float Variablen möchte ich verzichten (TinyGPS liefert alternativ die Geschwindigkeit auch in km/h als float). Die Entfernungsberechnung und Winkelbestimmung fehlt noch vollständig.

Hier gibt es noch ein paar Infos zum Original HOTT-GPS falls das jemand interessiert:
http://fpv-community.de/showthread.p...highlight=hott

Hier gibt es ein schönes GPS Projekt, wo man sich mal anschauen kann wie TinyGPS mit NewSoftSerial in Verbindung mit Arduino 1.0 verwendet wird.

http://code.google.com/p/phi-prompt-...rface-library/ -> GPS Logger V5


Grüße,
Jochen

[Evgenij]

Damit bin ich noch nicht glücklich...

Warum bist du damit nicht glücklich?
GPS und Softserial brauchen nur 9600 als Geschwindigkeit.
Ich habe erst testweise mit Adafruit gpslogger gebaut. es funktioniert.
Kannst du dein Projekt hier Veröffentlichen?
Wir könne zusammen das zum Laufendem bringen.

MfG
Evgenij

[Globe]

Hallo zusammen!

So mein Test-Aufbau spricht mittlerweile auch HOTT:



Als Basis dient ein STM32 Discovery Board. Daran angeschlossen ist ein GPS und ein 20bit Adc für den Drucksensor der Prandtlsonde. Der gemessene Staudruck wird in eine Geschwindigkeit umgerechnet und anschließend in die Hott Gps Frames gepackt.
Nächster Schritt wird noch ein Absolutdrucksensor um die Höhe messen zu können. Dann hätte ich eigentlich alles zusammen für mein TEK - Vario.

Viele Grüße
Georg

[Globe]

So nachdem es doch noch aufgehört hat zu regnen habe ich spontan einen kleinen Testflug gemacht.
Problem: Wind mit ~20km/h. Meine Messwerte schauen aber dennoch rech plausibel aus:



Hier noch ein Bild von einem FPV-TEST-Lastenträger:



Viele Grüße
Georg

[Evgenij]

Kann mir jemand von denen die ein GPS-Modul mit Arduino haben, nur den Datensatz welcher Arduino zum Empfänger schickt, zeigen.
z.B.
uint8_t message_array[45] = {
0x7c,0x8a,0x00,0xd0,0x00,
0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x7d,0x00}
Danke!
Evgenij

[Mulder]

So,

hab jetzt alles soweit herausgefriemelt, dass alle GPS Daten korrekt übertragen werden. Habe das GPS-Emulator-Tool vom "Remzibi" OSD zum Testen hergenommen, dann passt auch die Geschwindigkeit, ich vermute aber, dass es mit dem GPS Modul noch nicht hinhaut obwohl ich RMC und GGA am Modul aktiviert habe. Testen werden ich dann mal indem ich den Aufbau incl. Sender ins Auto lege und eine Testfahrt mache...

Der Arduino läuft mit 8Mhz, da ich die 3,3V Version wg. den Pegeln zum Empfänger verwende. Damit sind mit der Softserial und 9600 Baud maximal 4-5Hz Update-Rate möglich.

-> Evgenij hat gefragt warum ich damit nicht glücklich bin: Ganz einfach, wenn ich schon ein GPS-Modul im Modell habe (FPV Modell in Verbindung mit Remzibi´s OSD) bzw. für die GPS Navigation im MultiWiiCopter, das mit 10Hz und 38400 bzw. 115k Baud läuft würde ich gerne das Signal parallel abgreifen und über den Hott Telemetrie Kanal übertragen....Der DIY Sensor sollte dann neben GPS natürlich auch noch die Strom / Spannungswerte und Variodaten übertragen, d.h. das GPS und z.B. das EAM Packet bedienen. Ich habe noch ein Pollin Eval Board mit dem ATMEGA644p da liegen, vieleichte teste ich mal ob das bei der Verwendung von 2 Hardware-UARTS hinhaut.

Die Sache mit dem STM32 von Globe finde ich klasse, vor allem wenn man bedenkt, dass das FRSKY Telemetriesystem auch einen STM32 Controller einsetzt und das FR-SKY zeug sehr günstig beim Hobbykönig zu bekommen ist und es die Schaltpläne bei FRSKY zum herunterladen gibt...

http://www.rcgroups.com/forums/showt...=frsky&page=23

[MeiT]

Hi,

12s Sensor geht wohl auch.

Leider kann man die Spannungen nicht im Hott Manager anzeigen lassen.

Jetzt steht das Grundgerüst, aber die Menüführung und Warnungen hab ich noch nicht drin

Grüße

[adrock]

Hi,

ich habe mich ein wenig mit dem Telemetrie-Protokoll beschäftigt, bitte korrigiert mich wenn ich falsch liege:

- (Fast) alle Sensoren werden bisher nicht direkt angesprochen, sondern immer über ein "Zwischenmodul", z.B. das "general air module" etc.
- Im Protokoll sind für die Sensorkennung nur 4 Bit (=16 Werte) reserviert,wovon 4 schon belegt sind (GAM, EAM, GPS, Vario).

Ich sehe da ein ganz entscheidendes Problem im Protokoll, was den Betrieb von mehreren Sensoren mit einem Y-Kabel angeht:

Es gibt zuwenig IDs. Wie sollen andere Hersteller (oder DIY) Produklte für HoTT adaptieren, wenn es nur noch ~10 freie IDs gibt? Natürlich kann z.B. ein DIY Sensor sich als eines der bekannten Module ausgeben, aber das Gelbe vom Ei ist das irgendwie nicht.

Entweder müsste man die Anzahl der IDs deutlich erweitern (2 Byte) und an Hersteller zuweisen, oder ein Protokoll beim Starten des Empfängers vorsehen, wie die Sensoren erkannt bzw. enumeriert werden können. Da es auf dem Sensorbus aber keine echte Kollisionserkennung gibt, dürfte das mit dem 1-Draht-Protokoll schwer werden.

Oder habe ich da was mit der Sensor-ID grundsätzlich nicht verstanden?

Wenn meine HoTT-Funke endlich da ist, wird erstmal experimentiert...

Viele Grüße
Markus

[Globe]

Hi adrock,

ich versuche mal die Sache zu erklären: Die einzelnen Sensoren(GPS,Vario,GAM..) anworten auf eine Anfrage vom Empfänger. Werden also direkt angesprochen. Damit gibt es keine Probleme mit mehreren Sensoren an einem V-Kabel und Kollisionen gibt es so auch nicht auf dem Bus. Bei zu vielen Sensoren wird nur irgendwann die Bandbreite etwas eng werden.
Was die ID-angeht hast du recht, hier werden im Moment nur 4 bit verwendet. Allerdings befindet sich in den Daten-Frames nochmal eine ID. Vielleicht soll das mal eine Erweiterung geben...

Ich kenn ja die Taktik von Graupner nicht. Aber ich glaube ehrlich gesagt nicht, dass sie in Zukunft für jeden Drittanbieter eigene Daten-Frames implementieren wollen. Das hätte ja mit dem aktuellen Protokoll auch jedesmal eine neue Sender-Firmware zur Folge.

Ich finde auch man hätte das Protokoll etwas "dynamischer" bzw. flexibler implementieren können, wobei der zusätzliche Aufwand natülich auch nicht zu unterschätzen ist. Meiner Meinung nach kommt ganz gut mit den vorhandenen Frames zurecht und es bietet sich eine schöne neue Spielwiese für Experimente.

Viele Grüße
Georg

[ingo_s]

Hi Globe,

was setzt Du denn für einen Diff-Druck Sensor und ADC ein?

Im Moment habe ich eine Kombi-Lösung aus MP3V5004 und MS5611 (Vario) an einem ATtiny85 (19x25x13mm) mit Schnittstelle für MPX Sensor Bus. Mit einigen Tricks habe ich ca. 12 1/2 Bit ADC Auflösung mit dem AVR. Später will ich auch einen ARM Core uP einsetzen, (das STM32 Discovery Board liegt auch schon hier) für bessere Filter und TEK Berechnungen ist in dem AVR keine Luft mehr.

Grß Ingo