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

Holger Lambertus · 16. Oktober 2017

Hallo Chris
Ich kenne Dein Projekt ja nicht, aber wenn es um richtig sparsam geht, bei einen 3,3V Arduino braucht es auch die Diode und den R nicht, direkt vom Pin zum Empfänger.

Extrem sparsam: die Empfänger haben auch 3V Stabis drauf, da kommt man an dem gelben Elko an 3V Plus recht gut drann. für einen Attiny z.B: 44/84 441/841 45/85 reicht das aus, am Attiny braucht es dann nur noch einen 100n Cap zwischen Plus und Minus (funzt auch ohne, ist zum entstören

), rennt super. Ich habe das so an einem GR12 mit abgelöteter Steckleiste so.

Die Attiny 45/85 als DPI8 sind auch gut ohne Platine lötbar, wiegen 0,5g, kosten unter 1€ und ersetzen den kmpl. Arduino, allerdings nur 4 Eingänge für Sensoren nutzbar (einer der 5 geht ja direkt zum Hott-T).

Für die Attiny 44/84 bzw 441/841 gibt es in der Bucht so kleine Adapterplatinen auf DIP, ist auch superklein und leicht unter 1g, und es bleiben 10Eingänge für Sensoren nutzbar.

Chris1212 · 16. Oktober 2017

Da tun sich ja ganz neue Welten auf

Mein Projekt lehnt an dem openXsensor an. Ich will mit einem Barometer und Beschleunigungssensor ein Vario bauen. Ontop soll mit HC12-Modulen eine eigene Funkstrecke vom Arduino im Modell zu einen Arduino am Boden mit Buzzer aufgebaut werden, um einen Varioton am Boden zu haben, welcher alle 20ms aktualisiert werden kann. Mal schauen was raus kommt, hab ja einen Winter Zeit

Gruß Christoph

Holger Lambertus · 16. Oktober 2017

Du meinst sowas?
http://www.modelbouwforum.nl/threads/poor-mans-vario.199904/

Chris1212 · 16. Oktober 2017

Genau, sowas

Nur mit einem Gy86 Modul, um auch noch einen Beschleunigungssensor mit einzubinden und einen aktuellen Drucksensor zu haben.

Weiß einer wie viel Reichweite so ein günstiges RF433 Funk Modul hat?

Holger Lambertus · 16. Februar 2018

Falls jemand daran Interesse hat, ich habe das 2millisekündliche Schreiben in einen Interrupt verlagert, der Timer läuft alle 2048uS über, haut dann ein Byte raus, und schiebt immer ein Byte weiter, wenn alle 45Bytes durch sind, legt er sich schlafen. Trockentest rennt es schonmal super.(Für exakte 2000uS kann man Waveform mit ICRtop 250 konfigurieren, scheint Hott aber nicht zu jucken).
So ist nicht die ganze Zeit der Prozessor blockiert, und kann z.B. GPS Barometer u.s.w. auszulesen, oder was man auch immer mit der Zeit anstellen möchte.

Also Beta1 Übungs-Version....

Code:

#define T_Pin 8                     //TelemetriePin
#include "SoftwareSerial.h"
SoftwareSerial HOTT(T_Pin,T_Pin);
uint8_t i, test;  
uint8_t GPS[45] = { 0x7C,0x8A,0x00,0xA0,0x00,0x00,0x00,0x00,0x00,0x00, 
                    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
                    0x00,0x00,0x00,0x00,0x00,0x00,0x04,0x00,0x00,0x00,
                    0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
                    0x00,0x00,0x00,0x7d,0x00};
void setup() {
TCCR2A = 0b00000000;
TCCR2B = 0b00000101;                                        //Overflow alle 2048uS
TIMSK2 = 0b00000001;                                        //Overflow aktivieren
sei();

HOTT.begin (19200); 

}
void loop() {
pinMode(T_Pin, INPUT_PULLUP);
if(HOTT.available() >= 2){
if((HOTT.read() + HOTT.read()) == 0x10A){                    // 0x80+0x8x
delay(3); GPS[44] = 0; i=0; TCNT2=0; TCCR2B = 0b00000101;    //Timer starten
}}

test++;     GPS[7] = (uint8_t)(test&255); 
            GPS[8] = (uint8_t)(test >>8);                    
}



ISR(TIMER2_OVF_vect) {
if (i==45){TCCR2B=0b00000000;}                               //Timer schlafen legen wenn fertig
pinMode(T_Pin, OUTPUT);                                      //Pin auf senden
HOTT.write(GPS[i]);                                          //HOTT Byte schreiben
GPS[44] = GPS[44] + GPS[i];                                  //Checksumme bilden
i++;                                                         //Ein Array-Bit hochschieben
pinMode(T_Pin, INPUT_PULLUP);                                //Pin auf Empfang    
}

edit, ist für 328p mit 16MHz und GPS-Modul

Holger Lambertus · 16. Februar 2018

Spielerei, wie wenig Code ist nötig das sich ein Arduino zu einer arbeitsfähigen Telemetrie meldet (Kampf den Bläähhhcodes

)

Code:

#include "SoftwareSerial.h"
SoftwareSerial HOTT(8,8);
uint8_t ESC[45] = {0x7c,0x8c,0x00,0xc0};

void setup() {HOTT.begin (19200);}

void loop() {
pinMode(8, INPUT_PULLUP);
if (HOTT.available() >= 2){ 
if((HOTT.read() + HOTT.read()) == 0x10C){
pinMode(8, OUTPUT); ESC[44] = 0; delay(5);
for(int i = 0; i < 45; i++) {HOTT.write(ESC[i]); ESC[44]=ESC[44]+ESC[i]; delay(2);}
}}}

EDIT
Doch es geht noch weniger, 3,3V Board ohne Spannungsteiler und Diode, Hardwareserial, 1,2-1,5K Widerstand zwischen RX/TX, T-Pin auf RX.

Code:

uint8_t ESC[45] = {0x7c,0x8c,0x00,0xc0};

void setup() {Serial.begin(19200);}

void loop() {
if (Serial.available() >= 2){ 
if((Serial.read() + Serial.read()) == 0x10C){
ESC[44] = 0; delay(5);
for(int i = 0; i < 45; i++) {Serial.write(ESC[i]); ESC[44]=ESC[44]+ESC[i]; delay(2);}
}}}

Holger Lambertus · 18. Februar 2018

Moin (da ich hier ja so einen schönen Monolog führe

)
Habs heut morgen mal in C und ausschließlich per Interrupts ohne bussyloops gebastelt, rennt so auf dem attiny841 (ist ja fix auf nen AT328p angepasst, wenns sein soll, aber der hat ja nur einen Uart...).
3,3V Widerstand 1k5 zwischen rx/txm, T-Port am RX.
Sind aktuell 354KB

Code:

#define F_CPU 8000000
#include <util/delay.h>
#include <avr/io.h>
#include <stdio.h>
#include <avr/interrupt.h>
#include <stdlib.h>

volatile uint8_t i,TX,ESC[45]; 

int main(void){
TCCR0A  = 0b00000000; 
TCCR0B  = 0b00000011;       //prescale 1/8, OVF alle 2mS
TIMSK0  = 0b00000001;       //INT OVF aktiv
UCSR1B  = 0b10011000;       //INT RX aktiv
UBRR1L  = 0b00011001;       //19200baud                                         
sei();
    ESC[0] = 0x7C;        //immer 7C
    ESC[1] = 0x8D;        //ändern in: 8A=GPS 8C=ESC 8D=GAM 8E=EAM 89=VARIO 
    ESC[3] = ESC[1]<<4;   //ID wird berrechnet
while(1){   
    ESC[28]++;      //ein bissl Bewegung auf dem Display (Ampere) 
}}

ISR(USART1_RX_vect){
if ( UDR1 == ESC[1] && TX == 0){   
  TX=1; 
  _delay_ms(5);
  ESC[44]=0; 
  TCNT0=1; 
  i=0;
}}

ISR(TIMER0_OVF_vect){ 
if(i>44){i=45; TX = 0;}
else {while (!(UCSR1A & (1<<UDRE1))){}                             
      UDR1 = ESC[i];                                                       
      ESC[44] = ESC[44] + ESC[i]; i++; 
}}

Holger Lambertus · 19. Februar 2018

Frage; Ineressiert das überhaupt jemanden, oder doch nur "Kochrezepte" ?

BTW, GPS-Hott, für einige GPS Module (GTop Sierra Mediatec...) gibt es das binary-Protkoll:

http://docs.mirifica.eu/GlobalTop_Technology/features/binary_sentence/binary_protocol.html

Es ist quasi das RMC in Hex

Das kommt einem so seltsam bekannt vor, wenn man das mit dem Hott-GPS Protokoll vergleicht. Ich würde sagen, tschüss- GPS-Parser, kann man (fast) 1zu1 an Hott weiterleiten, wenn ich das richtig sehe.
(denke da würde dann der Attiny102 für ausreichen, um dann ein GPS Modul zu bauen).

Um das zu aktivieren, schreit man das GPS-Modul einfach seriell an, hier die wichtigsten MTK Commandos gebrauchsfertig:

// Serial.write("$PMTK251,115200*1F\r\n"); // baud 115200
// Serial.write("$PMTK251,57600*2C\r\n"); // baud 57600
// Serial.write("$PMTK251,38400*27\r\n"); // baud 38400
// Serial.write("$PMTK251,19200*22\r\n"); // baud 19200
// Serial.write("$PMTK251,9600*17\r\n"); // baud 9600
// Serial.write("$PMTK251,4800*27\r\n"); // baud 4800
// Serial.write("$PMTK220,1000*1F\r\n"); // 1Hz
// Serial.write("$PMTK220,500*2B\r\n"); // 2Hz
// Serial.write("$PMTK220,200*2C\r\n"); // 5Hz
// Serial.print("$PMTK220,100*2F\r\n"); // 10Hz
// Serial.write("$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n"); //nur RMC
// Serial.write("$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n"); //nur RMC + GGA
// Serial.write("$PMTK314,0,1,0,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*2C\r\n"); //RMC jedesmal-- GGA alle 5x
// Serial.write("$PGCMD,16,0,0,0,0,0*6A\r\n"); //Binär Code
// Serial.write("$PMTK187,1,1*3C\r\n"); // startet locus mit 1Hz (interner Logger im Modul)

lastdownxxl · 19. Februar 2018

Holger Lambertus schrieb:
Frage; Ineressiert das überhaupt jemanden, oder doch nur "Kochrezepte" ?

Hallo Holger,

m. E. gibt nur noch sehr wenige, die sich mit DIY Elektronik befassen. Ich hab zusammen mit meinem Vater 2010 das FrSky-Protokoll
untersucht und beschrieben. Das Dokument wurde fleißig heruntergeladen, ansonsten aber kaum eine Reaktion. Inzwischen
kann man fasst alles kaufen, da ist das Interesse für DIY Elektronik inzwischen verschwindend gering.

Gruß Micha

Sepp62 · 19. Februar 2018

Da ich auch einige Freizeit in diese Art des "Community-Entertainment" stecke (Jeti-Telemetrie-Library), schildere ich mal meine Eindrücke:

1. Der "DIY-Elektroniker" ist oft von der stillen Sorte, dafür aber auch gerne hartnäckig und frusttolerant. Bevor er etwas schreibt oder fragt, probiert (und löst) er oft selbst. Wer ab und zu im Mikrocontroller.net-Forum liest und den Tonfall dort kennt (nicht nett), wird das gut verstehen.

2. DIY-Projekte gehen in den seltensten Fällen zeitlich synchron zur Veröffentlichung von Projekt/Code. Da das Netz aber nichts vergisst, ist es oft sehr hilfreich auch nach Jahren noch Informationen zu finden.

3. Nicht alle DIY-Projekte treffen 100% den Zweck eines veröffentlichen Projektes/Codes. Aber trotzdem sind Informationen aus ähnlichen Projekten sehr hilfreich (siehe auch 2.).

Was ich damit sagen will: Auch wenn es aktuell kein Feedback gibt, macht das Ganze Sinn und ich denke, dass es beim Einen oder Anderen honoriert wird.

Also nur Mut und weiter publizieren !

VG Bernd

hsh · 21. Februar 2018

Das sehe ich ähnlich wie Bernd. Auch wenn ich mehr aus der Jeti-Ecke komme, finde ich solche Beiträge immer sehr interessant. Vor Jahren konnte ich einem motivierten µC-Einsteiger bei einem Sensor-Projekt auf Arduino-Basis für Jeti weiterhelfen. Das Resultat für die Allgemeinheit war eine nette Beispielimplementierung von Jeti-Protokoll und Expandermenüführung auf AVR Basis.
Dieser Thread ist bei mir zumindest einmal abonniert, auch wenn ich aus heutiger Sicht nicht weiß, ob ich einmal auf die hier veröffentlichen Erkenntnisse zurückgreifen werden. Auf jeden Fall finde ich die Informationen spannend, bedanke mich für die Veröffentlichung und wünsche weiterhin viel Erfolg bei der Umsetzung!

mfg Harald

Holger Lambertus · 21. Februar 2018

Moin Leute
Danke für die Worte. Mein Ziel ist es, neben dem basteln als solches, einen leichten Logger für die Solarflugwettbewerbe zu bauen, ich möchte gegen den Unken des höherem Stromverbrauchs per Telemetrie loggen, da ein Akku im Modell, auch wenn es nur ein winziger für den GPS-Logger für mich kein richtiges Solarmodell mehr ist. Der Vorteil ist ja nebenher das man jeden Flug später auf der Karte hat, und die "Modellflindoption" im Fall der Fälle. Darum teste ich im Moment enorm viel, zum einem kommt das eine oder andere nette Ergebnis bei raus, es macht Spaß, und man lernt die Programmiereier. Mittlerweile wiegt mein leichtester GPS-Logger inkl allem dumm und dran 0,8g.

Üblicherweise wird für den Zweck das OPenlog genommen, das ist ein gebrauchsfertiger "Arduino" mit Micro-SD-Kartenslot, lustig blinkenden LEDs und fertiger Log-Firmware für knapp 4€ beim Chinamann inkl Porto. Dort klemmt man an die RX-TX Buchse ein GPS Modul an (um die 10€), fertig ist der super-leichte und saubillige und trotzdem sehr gute GPS Logger (ca. 6g). Man steckt einmal kurz die Karte rein, OPenlog erkennt das es eine "neue" Karte ist, und schreibt dann dort eine CONFIG.txt drauf. Diese öffnet man einmal, dort ist default 9600Baud eingetragen, das ändert man auf seine Baudrate die mal loggen will, speichern, und Karte wieder rein. Einfacher geht es nicht.

Ab jetzt wird es optional

(wer mehr als nur stumpf loggen möchte)

Als Bastler kann man da natürlich nicht seine Finger von lassen, Openlog hat einen Atmega 328p 16MHz und einen 3,3V Stabi. Es gibt es in vier Farben, blau und lila haben einen ordentlichen ISP Anschluss, Rot und Schwarz sind da etwas "fummeliger".
Als erstes muss natürlich ein ordentlicher One-Wire Bootloader drauf, damit man jederzeit über das Strom/Servo/Telemetriekabel per Hott-Update Adapter bzw auch Jeti Update Adapter jederzeit mal fix und easy die Firmware neu flashen kann.
Dazu nutze ich den AVRrootloader (ist derselbe wie er für z.B: BLHeli verwendet wird).
Zuerst löte ich ein Servokabel an das Openlog:
Braun-GND
Rot-VCC
Orange direkt an den Prozessor, das Kabel an PD7/PB0, ruhig beide Pins mit dem Kabel in der Lücke, dann ist es nicht so friemelig.
Das/Der Openlog hat einen 3,3V Stabi drauf, so das wir das Dioden/Widerstandsgebastel nicht brauchen, nebenher können wir auch 3,3V für das GPS Modul abzapfen.

(Im Gegensatz zum Bild ist es natürlich besser RX und TX zum Openlog zu verbinden, dann kann das GPS-Modul über die Software konfiguriert werden (die Befehle in meinem vorigem Beitrag))

Nun den Bootloader per ISP drauf, das sind die vier Pins am Kartenlot, (genaue Belegung findet sich zuhauf in der Google Bildersuche).
Nun brauchen wir den AVRootloader https://github.com/damadmai/AVRootloader
Den fertig komplierten Bootloader habe ich als avrootloader_openlog_38400_PB0.hex.txt angehängt, ohne .txt wollte das Forum den Upload nicht zulassen.
Fuse-Bits auf: L: 0xFF H: 0xDA E: 0xFD
Hierfür benutze ich am liebsten das Tool AVRDUDESS http://blog.zakkemble.co.uk/avrdudess-a-gui-for-avrdude/

Im Avrootloader nun auswählen:
USB-Adapter: (Comport)
Baudtŕate: 38400
Signatur: openlog
Das Hexfile für das Update auswählen, und ab dafür, Sekunden später ist es auf dem Openlog.

Die 38400 Baud haben einen Grund, bei 19200Baud kommt der Bootloader mit Hott ins Gehege.
Der angehängte Bootloader rennt natürlich auch auf dem Nano und jeden anderen AT328p Board mit 16MHz. (im Arduino ist das Pin8)

Zum testen habe ich ein Blink/Hott file angehängt, das meldet sich beim Sender als ESC, beide LEDs blinken hektisch im Wechsel, sobald Hott aktiv blinken sie ungleich.
Und zum wiederherstellen die fertig kompilierte Openlog-HEX. (auch das ist OpenSource, man kann/darf es auch auf seine Belange hin anpassen)

Bisher getestet auf dem Openlog: GPS Hott Software vom Mürzi (Arduino / fpv community) sowie die (hervorragende) GPS-Hott-Software vom Herbert Dingfelder (in C), die aber minimal etwas angepasst werden muss.
An meiner Eignen bastel ich ja noch, cool wäre ja 10Hz SD-Card loggen und Hott zugleich, evtl IGC-Files u.s.w. darum versuche ich gerade per Interrupt gesteuertes Hott die "Loop" freizuschaufeln.

Ich wette, das funzt so auch mit Jeti...

edit,
AVRrootloader rennt auch wunderbar in Linux, entgegen unzähliger Antworten in Foren kann Wine sogar sehr gut den USB-Port durchreichen:
sudo ln -s /dev/ttyUSB(X) ~/.wine/dosdevices/com(9)
Die Klammern weglassen, und seine Ports wählen. Der User muss Mitglied der Gruppe dialout sein.

Sepp62 · 21. Februar 2018

Cooles Projekt.

Danke für die Mühe bei der Dokumentation. Damit ist das Know-How "verewigt" und man findet die Infos wieder, wenn man so etwas bauen will.

Und ja: Die Hardware wird auch für Jeti funktionieren !

VG Bernd

Holger Lambertus · 21. Februar 2018

So wieder ein Schritt weiter, habe den GPS Parser vom Herbert Dingfelder mal extrahiert, einmal umgewürfelt und arduinisiert. Trockenstest mit GPS-Modul am Fenster funzt gut, mit Sicherheit noch einiges an Verbesserungspotential.
TinyGPS und Co sind mir zu schwergewichtig, einige die im Umlauf sind funzen nicht gut (zählen die Stellen aus, statt die Kommas), und das Ganze soll nachher auch auf dem Attiny841 funzen, der wiegt nix, verbraucht wenig, und hat 2,5 Uart-Schnittstellen.
Liest Seriell über Interrupt ein, und spuckt es dann direkt in die Telemetrie-Bytes.

Code:

#define BSE 75 //Buffersize
uint8_t RMC[BSE];
uint8_t GGA[BSE];
volatile uint8_t HOTT[45];

void setup() {
UBRR0L  = 0b00011001; 
UCSR0B  = 0b10011000;                      
sei();         
}

void loop(){                         //     while (!(UCSR0A & (1<<UDRE0))){} UDR0 = HOTT[15];   //Serial-Debug ein Byte senden
char *string;                                                                                                                                                                                                          
string = memchr(RMC,      ',', BSE);           
string = memchr(string+1, ',', BSE);    if( string[1]=='A' )                    HOTT[5]  = 0x01; else HOTT[5]=0x00;         
string = memchr(string+1, ',', BSE);    uint16_t lat_ddmm = atof(string+1);     HOTT[10] = lat_ddmm &255;  
                                                                                HOTT[11] = lat_ddmm >>8;                              
string = memchr(string+1, '.', BSE);    uint16_t lat_mmmm = atof(string+1);     HOTT[12] = lat_mmmm &255;
                                                                                HOTT[13] = lat_mmmm >>8;
string = memchr(string+1, ',', BSE);    if(string[1]=='N' )                     HOTT[9]  = 0x00; else HOTT[9]=0x01;         
string = memchr(string+1, ',', BSE);    uint16_t lon_ddmm = atof(string+1);     HOTT[15] = lon_ddmm &255;  
                                                                                HOTT[16] = lon_ddmm >>8;                 
string = memchr(string+1, '.', BSE);    uint16_t lon_mmmm = atof(string+1);     HOTT[17] = lon_mmmm &255;
                                                                                HOTT[18] = lon_mmmm >>8;       
string = memchr(string+1, ',', BSE);    if( string[1]=='W' )                    HOTT[14] = 0x01; else HOTT[14]=0x00;
string = memchr(string+1, ',', BSE);    uint16_t kmh = (atof(string+1)*1.852);  HOTT[7]  = kmh &255;  
                                                                                HOTT[8]  = kmh >>8;                                                                                        
string = memchr(string+1, ',', BSE);    uint16_t DIR = (atof(string+1)/2);      HOTT[6]  = DIR;                                                                  
string = memchr(GGA,      ',', BSE);
string = memchr(string+1, ',', BSE);
string = memchr(string+1, ',', BSE);
string = memchr(string+1, ',', BSE);
string = memchr(string+1, ',', BSE);
string = memchr(string+1, ',', BSE);                                            HOTT[27] = atof(string+1); // Fix quality
string = memchr(string+1, ',', BSE);                                            HOTT[26] = atof(string+1); // number of sats 
string = memchr(string+1, ',', BSE);
string = memchr(string+1, ',', BSE);    uint16_t alti = (atof(string+1))+500;   HOTT[21] = alti &255;        
}


ISR(USART_RX_vect){  static uint8_t RMC_on, GGA_on, pos=0;  
    
    uint8_t received_gps_byte  = UDR0; 
    
    if(received_gps_byte=='$'){ pos = 0; RMC_on = GGA_on = 1; }       
    
    if(RMC_on){ RMC[pos] = received_gps_byte;
        if(pos==5 && (received_gps_byte!='C')) {RMC_on = 0;}}  
    
    if(GGA_on){GGA[pos] = received_gps_byte;
        if(pos==4 && (received_gps_byte!='G')) {GGA_on = 0;}}   
pos++;                  
}

Im Bild das GPS Modul, MT3333 Chip, mit 1/4Lamda Dipol Antenne, "Depronplatine" mit Tesa und Katzenfuss. Wiegt 0,8g, Hat einen internen Logger (LOCUS) mit 1Hz für 2h. Seriell an der Schnittstelle kann ich bis 10Hz und 115200baud auslesen, da soll der Attiny dann drann. Merkwürdigerweise habe ich mit der ollen Dipolantenne einen wesentlich besseren Empfang als mit den Keramik-Klingeln, ich möchte parallel auch noch 1/2Lambda testen, hinten auf dem Rumpfrücken ist ja genug Platz.

Ededisson · 10. März 2018

DIY GPS-Logger

DIY GPS-Logger

Hallo Leute...

An Holger.
Spitzen Idee mit dem GPS- Logger!
Habe vor den nach zu Bauen.
Einen lila Openlog hab ich Geordert und bis auf das GPS habe ich alles da. Aber welches GPS Nimmt man am besten? Bin noch nicht so drin in der Materie und muss mich noch Einarbeiten ;-)
Gruss Milan

Chris1212 · 14. Juni 2018

GR-12L Textmodus klappt ned

GR-12L Textmodus klappt ned

Hallo zusammen,

ich habe mir für einen Sensor zum konfigurieren den Textmodus nachgebaut.

Format sieht so aus:

0x7B, //Start ASCII
0,
0, //Warnungen
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, //1. Zeile ASCII
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, //2. Zeile ASCII
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, //3. Zeile ASCII
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, //4. Zeile ASCII
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, //5. Zeile ASCII
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, //6. Zeile ASCII
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, //7. Zeile ASCII
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, //8. Zeile ASCII
0x7D, //End Byte
0 //Parity Byte
};
*/

Nachdem der Empfänger 7F EF schickt, wartet der Sensor 5ms und schickt dann im Abstand von jeweils 1,5ms die 173 Bytes. Das letzt Byte ist die Summe aus allen Bytes davor.

Das klappt mit meinem GR-18. Allerding weigert sich der GR-12L das zu übertragen.

Der Normale Sensormodus funktioniert tadellos.

Hat jemand ne Idee was dem GR-12L ned passt?

Gruß Christoph

Dieter B · 14. Juni 2018

Hast du den Eingang 5 des GR-12 auf Sensor gestellt?

Chris1212 · 14. Juni 2018

Ja, hab ich!

Spannung, Strom und Höhe wird auch übertragen. Nur der Textmodus klappt ned!

Chris1212 · 14. Juni 2018

Habs gefunden: Auf Byte 1 muss die ID des Sonsors...

Scavanger · 20. Juni 2018

Servus,

die neuen Firmwares für die HoTT Empfänger bieten jetzt ein neues Feature: SUMD V3.
Hier z.b. für den Gr-12: https://www.graupner.de/News/Empfaenger-GR-12-HoTT-Version-3a71-und-Beta-7a05/

Hab jetzt mal heute kurz ein paar Frames geloggt.

Code:

A8 03 12 2F 20 2F 38 32 28 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 F7 78 
A8 03 12 2F 20 2F 38 33 60 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 01 B3 
A8 03 12 2F 20 2F 38 34 98 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 B8 C6 
A8 03 12 2F 20 2F 38 34 98 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 01 00 00 8F F6 
A8 03 12 2F 20 2F 30 36 E0 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 2F 0B 
A8 03 12 2F 20 2F 30 37 E8 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 47 81 
A8 03 12 2F 20 2F 30 38 F8 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 50 98 
A8 03 12 2F 20 2F 30 39 E0 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 5B 8A 
A8 03 12 2F 20 2F 30 3A 90 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 8A A9 
A8 03 12 2F 20 2F 28 3B 08 2E B0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 2E E0 00 00 00 00 DF B4

Ausser das jetzt in Byte 2 0x3 (wohl für V3) steht, sehe ich keinerlei Unterschied zum normalen SUMD, auch die Baudrate ist unverändert bei 115200! :eek:

Kann das mal jemand bestätigen?

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

User

User

User

User

User

User

User

User

User

User

User

User

Anhänge

User

User

User

User

User

User

User

User

Ähnliche Themen