Jeti Duplex mit EX Analyse des Protokolls am Sendemodul

Mein TU 2 Modul lässt sich nicht updaten! Hab es gerade probiert ....

Dazu aus dem Hauptmenü mit der Anzeige des Duplex Artikelnames 1x abwärts klicken , dann
die Rechtstaste betätigen bis zur Anzeige "Firmware - x.xx". Wird die FW angezeigt ist dieser Duplexartikel updatefähig

Zum Vergrößern anklicken....

Quelle: http://www.hacker-motor.com/daten/anleitungen/de/ANLEITUNG_JETI_AUF_DUPLEX_EX.pdf

Hallo Kollegen,
zurück zum eigentlichen Thema
ich hab eindlich etwas Zeit gehabt, die Messreihen mal durchzuziehen.

Saleae LLC Logic 1.2.10, gemessen auf Kanal 0, parallel zur Jetibox am TX-EX-TG2-Modul.

Die erste 1MHz ist bei eingeschaltetem RX, danach Sender eingeschaltet, sample läuft los, gedrückte Tasten nacheinander: Rechts, Rechts bis ins MX-Menue, dann Pfeilrunter, Pfeil runter. Sample gestoppt

Die zweite Messung ist dann:
8MHz, Sender und Empfänger aus.
Sender ein, Sampler startet über positiven Trigger, Empfänger einschalten, nach Bindung Taste rechts, rechts, im MX-Menue Pfeil runter, Softwareversion vom UNISENSE wird angezeigt, Pfeil runter. Sample gestoppt.

Mal sehen, was Ihr daraus macht.
Ich hatte übrigens die Samples auch mit anderen Abtastraten gefahren, die Ergebnisse sind recht gleich.

Grüsse auf dem Weg nach Polska, Gruni

PS: Ich hab mal das TMe und die beiden TU-Module versucht upzudaten, geht nicht. @Kalle: das hatten wir doch schonmal vor etlicher Zeit ausprobiert.... grrrr. Auch die Empfänger verhalten sich störrisch, ausser einem RSat (noch im Schrumpfschlauch) lies sich updaten, das wars. Der Rsat im Gehäuse geht natürlich. Das update brauchte ich zum Anschluss einer Powerexpander SRS, was übrigens ne wirklich geile Sache ist.
Jetzt ist das Teil drin und ich komm zu nix...

Dateien

Dateien

Hallo nochmal,

keine Ahnung, warum die erste Datei nicht hochladbar ist...zu gross mit 210kb...

Ok, die zweite sollte auf jeden Fall gehen, ist auch die Aussagekräftigere, denke ich mit meinem gefährlichen Halbwissen.

Bitte umbenennen im DOS-Modus (über "Ausführen" im Windows-Startmenue.

Mal sehen, was rauskommt.

Grüsse, Gruni

Aha, einfach die Datei in DAT enden lassen, dann klappts auch mit dem hochladen... merkwürdig, Herr Merkwürden.

Grüsse, Gruni

Hi Gruni,

ich war neugierig und hab mich gleich mal über Deine Daten hergemacht.
(Zuerst einmal das Saleae Logic installiert...)

Deine 1MHz-Datei konnte ich dann auch öffnen und anschauen; Daten als CSV exportiert, dann habe ich in Excel weiter gemacht.
Die "simple Text"-Daten konnte ich daraufhin erkennen, alles paletti. Nur als ich die Initialisierung (Firmware-Meldung) vom Unisens-gesucht habe, ist die nicht aufgetaucht (oder ich habe es überlesen...). Da kommt gleich nach dem MX-Menü die "Strom Alarm"-Meldung... ???!!!

Dann habe ich versucht, die 8MHz-Datei zu öffnen (die Aussagekräftigere ?!), aber dabei stürzt das Salae-Programm sofort und reproduzierbar ab... hmmmmmm.

Nun mach ich erst mal Schluss.
Am Wochenende gehts weiter, vorher hab ich leider keine Zeit.

Gruß
Jan

Hallo,

die 8MHz Datei bringt auch bei mir Logic zum Absturz (auf dem Mac)
Ansonsten kann ich in der 1MHz Datei noch nichts wirklich erkennen, da muss ich mich erst mal in Ruhe mit auseinandersetzen.
Ich sehe immer 0x120, also 3stellige Hex Werte, eigentlich sollten das nur zweistellige sein.

Gruß
Christian

Hallo Gruni.

Hab mich gestern Abend auch an deinen beiden Dateien versucht.

Mit dem Namen "1 MHz, 20 M Samples Jetibox TX-RX-MX-DOWNKEY.logicdata" stürzt bei mir 1.2.10 sofort ab.

Reduziert auf "1 MHz, 20 M Samples.logicdata" funktioniert 1.2.10.

Dein 8 MHz "Machwerk" stürzt immer ab.

Was machste da nur immer ????

Grüß KH

Hallo

Hier unter Linux 64 Bit mit der entsprechenden Version von Saleae 1.2.10 gibt es ein Segfault (Speicherzugriffsfehler) mit beiden Dateien.
Wenn ich erlaube den Fehler Report zu senden (beim nächsten Start) geht die Datei mit 1 MHz immer und die Datei mit 8 MHz ging auch einmal zu öffnen.

Gruß
Dieter

Hi

In der 8 MHz Datei kann ich immerhin diesen String identifizieren:
Tx ->
"54 78 20 2d 3e // bei EDIT 1Sek 17ms erstes Auftreten

Das 9te Bit bommelt jeweils davor, also:
"154 178 120 12D 13E"

Jetzt hab ich keine Lust mehr.

Gruß
Dieter

Hi

In der angehängten Datei sind alle Zeichen nach ASCII gewandelt.

Gruß
Dieter

Hallo Jungs,

ich glaube, mit der Dateiendungsumstrickung klappt was nicht.
Hier der zweite Versuch.

Grüsse, Gruni

PS: Unter Dos umbenennen, das heisst die Endung "dat" löschen.

Hallo,

Willkommen Dieter, schön, dass noch jemand mit uns versucht das Protokoll zu verstehen.

Ich habe heute mit einem angepassten Sketch von Jan getestet. Ich habe dort auch wieder einen Debug Ausgang eingebaut, und lasse alle eingelesenen Daten direkt ausgeben.
Da ich noch keine Jetibox habe übernimmt der Sketch das Drücken der Knöpfe.

Ich habe einen Mitschnitt vom UnisensE und vom MVario2 gemacht. Beim Unisense E habe ich das mal in Excel in verschiedene Zahlenformate gebracht. Mit bedingter Formatierung habe ich mal Textbeginn und Ende markiert. Die Textbereiche sind immer 32Byte lang, also wie im alten Protokoll.
Auch kann man zumindest beim MVario2 schön sehen, wenn es bewegt wird, dass sich die Zahlen im Textbereich ändern. Es geht dort also wie früher, an bestimmten Stellen in den 32Byte stehen definiert zu interpretierende Werte.

Inhaltlich gleicht sich die Ausgabe meines UnisensE mit der in Ascii umgewandelten von Dieter.

Gruß
Christian

Hi

Hier die Ergebnisse aus der letzten Datei

Ne geht leider nicht, wird zu groß.

Also so vorgehen:

1. als CSV exportieren.
2. Die Überschrift und die ersten Zeilen 0xFF (Frame Error) oben löschen.
3. ./filter.pl < CSVDATEI.csv > time_proto_value_ascii.txt

EDIT:
Das Ergebnis sieht dan auszugsweise so aus:
6.049078125000000 Async Serial 0x52 "R"
6.050531750000000 Async Serial 0x78 "x"
6.054880125000000 Async Serial 0x20 " "
6.056333750000000 Async Serial 0x2D "-"
6.058412250000000 Async Serial 0x3E ">"
6.059866000000000 Async Serial 0x20 " "
6.061281375000000 Async Serial 0x20 " "
6.062875375000000 Async Serial 0x20 " "
6.064341875000000 Async Serial 0x20 " "
6.066076000000000 Async Serial 0x20 " "
6.067542500000000 Async Serial 0x20 " "
6.068996125000000 Async Serial 0x20 " "
6.070590125000000 Async Serial 0x20 " "
6.072094875000000 Async Serial 0x20 " "
6.075053250000000 Async Serial 0x20 " "
6.076762000000000 Async Serial 0x20 " "
6.078228375000000 Async Serial 0x76 "v"
6.079656625000000 Async Serial 0x20 " "
6.081250500000000 Async Serial 0x20 " "
6.082678750000000 Async Serial 0x20 " "
6.084413000000000 Async Serial 0x20 " "
6.085879375000000 Async Serial 0x20 " "
6.087333125000000 Async Serial 0x20 " "
6.088952500000000 Async Serial 0x20 " "
6.090406250000000 Async Serial 0x20 " "
6.092166000000000 Async Serial 0x20 " "
6.093683375000000 Async Serial 0x20 " "
6.097011625000000 Async Serial 0x20 " "
6.098439750000000 Async Serial 0x20 " "
6.100072000000000 Async Serial 0xFF "377"
6.105291875000000 Async Serial 0xE0 "340"
6.122894000000000 Async Serial 0x7E "~"
6.124373125000000 Async Serial 0x9F "237"
6.126107375000000 Async Serial 0x10 "^P"
6.127573875000000 Async Serial 0x02 "^B"
6.129027500000000 Async Serial 0xA3 "243"
6.130659750000000 Async Serial 0x03 "^C"
6.132126125000000 Async Serial 0x46 "F"
6.133873125000000 Async Serial 0x07 "^G"
6.135326875000000 Async Serial 0x6C "l"
6.136793250000000 Async Serial 0x2F "/"
6.138400000000000 Async Serial 0x02 "^B"
6.139930125000000 Async Serial 0x7A "z"

Gruß
Dieter

Hallo,

ich habe mir jetzt den Code von Jan unsere Mitschnitte und die Protokollbeschreibung von Jeti noch weiter angeschaut.
Nach meinem Verständnis werden in dem 32Byte Textblock die gleichen Informationen wie bisher übertragen. Nur das Start- und Endzeichen verändert sich auf 0xFE und 0xFF.

Ich werde dies mal im Code ändern und morgen einen Versuch starten.

Gruß
Christian

Hallo,

ich verstehe zwar nicht ganz warum, aber mit der Erkennung des Start- und Endzeichen scheint alles zu funktionieren. Es wird zuverlässig der Textblock im EX Protokoll erkannt.

Ich habe am Code jetzt mal folgendes geändert:
- zusätzlicher serieller Ausgang für Debug-Ausgaben (damit muss man in der Einleseroutine sehr sparsam sein, sonst stimmt das Timing nicht mehr)
- Ich generiere einen String, der den kompletten Textbereich enthält, und gebe ihn am Debug-Port aus.
- Ich habe über Debug-Ausgaben gekennzeichnet, ob wir in der Setuproutine sind.
- Ich habe als möglichen Sensor ein MVario2 eingefügt, aber dessen Werte noch nicht in Variablen gelesen und an FrSky gesendet.


Aus meiner Sicht scheint alles zu funktionieren. Derzeit wird aber beim UnisensE nur eine Menüebene ausgelesen.

Es ist also noch etwas Fleißarbeit, für jeden Sensor die vollständigen Werte zu erfassen.
Wenn ich heute Abend etwas Zeit habe, werde ich den Code noch mal etwas strukturieren, so dass klar wird an welcher Stelle man neue Sensoren eintragen muss.

Aus meiner Sicht haben wir hiermit eine super Grundlage, um die Sensoren von Jeti zu verwenden.
Was ich noch nicht getestet habe, ist die Übergabe von Werten an die Taranis. Ich habe das Kabel einfach noch nicht fertig gemacht.

Zum Beispiel bei MVario2 sieht der Text wie folgt aus:


Über die Pfeile wird die Intensität des Steigens und Fallens angezeigt. Die restlichen Werte muss ich interpretieren.


In dem Bild des UnisensE sieht man, wie er angeschlossen wurde, aber es wird nur Ebene A ausgelesen (mehr ist im Code auch noch nicht drin).


Gruß
Christian

Hallo Christian,

ich lese mal wieder etwas mit....
bedeutet das nun, dass mein Sketch auch mit EX-Transmitter-Modul funktioniert, d.h. selbständig ins Unisens-Menü A manövriert und dort die Daten ausliest ?
Das war ja das Problem bei Gruni... (ich frage deshalb, weil ich mir die 8Mhz-Datei angeschaut habe und dort eigentlich nichts gefunden habe, was inkompatibel zum bisherigen Sketch sein sollte.)

Sollten weitere Daten parallel zur Strommessung benötigt werden (Vario z.B.), dann sollte man meiner Meinung doch weggehen vom Auslesen des simple-Text-Protokolls....

Gruß
Jan

Hallo Jan,

ja es funktioniert, aber nicht zuverlässig. Ich habe heute noch etwas probiert, und mal geht es, und mal nicht.
Wenn es geht, dann werden auch die Daten des Unisense und des Mario angezeigt, so wie im Bild zu sehen.

Es scheint so, als ob der Tastendruck nicht immer zur richtigen Zeit übertragen wird. Denn ich bekomme teilweise ewig die Textausgabe "Tx v " (Kurzform) da muss doch vermutlich die Taste "runter" gedrückt werden.

Kannst Du mir erklären, warum Du Start und Ende Zeichen mit "-1" und "-2" abfragst, und warum das funktioniert. Eigentlich ist das doch ein 0xFE und 0xFF.

Gruß
Christian

Hallo Christian,

das liegt am Datentyp "char" :

The char datatype is a signed type, meaning that it encodes numbers from -128 to 127. For an unsigned, one-byte (8 bit) data type, use the byte data type.

Zum Vergrößern anklicken....

https://www.arduino.cc/en/Reference/Char

Ich habe einen Verdacht, warum es nicht zuverlässig funktioniert... mein Modul reagiert spontan auf einen Tastendruck, selbst wenn dieser nur einen Anzeigezyklus erfolgt. (also sende ich nur einmal z.B. Taste runter 0xB0, beim nächsten Zyklus wieder 0xF0). Sollte aufgrund des komplexeres EX-Protokoll das System träger geworden sein, dann reicht dieser kurze Impuls vielleicht nicht immer zuverlässig... ich werde mal drüber nachdenken, dies im Programm anzupassen. sollte kein großer Aufwand sein.

Gruß
Jan

c.radi schrieb:

Hallo Jan,

ja es funktioniert, aber nicht zuverlässig. Ich habe heute noch etwas probiert, und mal geht es, und mal nicht.
Wenn es geht, dann werden auch die Daten des Unisense und des Mario angezeigt, so wie im Bild zu sehen.

Es scheint so, als ob der Tastendruck nicht immer zur richtigen Zeit übertragen wird. Denn ich bekomme teilweise ewig die Textausgabe "Tx v " (Kurzform) da muss doch vermutlich die Taste "runter" gedrückt werden.

Kannst Du mir erklären, warum Du Start und Ende Zeichen mit "-1" und "-2" abfragst, und warum das funktioniert. Eigentlich ist das doch ein 0xFE und 0xFF.

Gruß
Christian

Zum Vergrößern anklicken....

Hallo Christian, Jan,

Bei meinen Jeti-Modulen in Verbindung mit Jetibox Quadrat und Mini klappt das Durchtasten durch die Menues übrigens auch nicht immer, speziell das Tg2EX in Verbindung mit alten DuplexRXen kommt es oft vor, dass nach Einstieg ins Mx oder RX-Menue nicht mehr auf eine Ebene höher gesprungen werden, zurück auf die Haupt-Verteilerebene geht oft nur mit Pfeil hoch laaaaange drücken.

Muss also alles nicht am Sketch liegen, sondern eher im System selbst.

Grüsse aus Polska, Gruni

Hallo,

für meine Begriffe ist das neue Protokoll etwas zeitkritischer. Auch das Fenster für den Tastendruck ist zeitlich sehr klein, und muss direkt nach dem Datenempfang erfolgen.

-------Auszug aus der Protokollbeschreibung von Jeti ------------------
Accessing shared data bus
The only one active element of a network at a time, and which initiates all communications, is a “master”. It sends a packet and then releases the bus for at least 20ms. At this time, “slave” is allowed to respond. This situation repeats periodically. “Slave” doesn't have to respond immediately and it doesn't have to respond at all.
After transmission, the bus is released in the following way. The TX line is reconfigured as an input with use of an additional internal pull-up resistor. After timeout has passed, the TX line returns into output state. “Slave” (JETIBOX) sends information about buttons pressed within specified time.
------------------------------------------------------------------------------

Da wir seriell aber über einen Buffer empfangen stimmt der Zeitpunkt für das Senden des Tastendruckes nicht, man müsste also erst den Buffer leeren, und direkt nach einem Packet senden. Ein Paketende wird nach meinem Verständnis mit 0xFF beendet. Das kann an auch im Mitschnitt und der Aufbereitung in Excel (einige Post höher) sehen.

Nur bin ich leider nicht in der Lage das in SW um zu setzen.

@Jan:
Danke für die Erklärung zum Datentyp, da hätte ich auch selbst drauf kommen können. Sorry.


Gruß
Christian