Einfache Jeti EX Telemetrie-Library für Arduino Mini Pro 328

[Sepp62]

Man muss klar unterscheiden zwischen "EX" und "EX-Bus" (warum auch immer das "Bus" genannt wurde):

1. "EX": Die hiesige Library unterstützt nur EX. Der Sensor (nur einer pro Port!) haut seine Daten einfach auf die Leitung, d.h. der Empfänger pollt die Daten nicht. Nachdem der Sensor sein Paket weggeschickt hat, schaltet er die Sendeleitung aus und lauscht auf Tastendrücke von der Jetibox. Nach x Millisekunden (bei dieser Library rund 150) sendet er einfach das nächste Paket. Die Datenrate ist 9600 Bit/s.

2. "EX-Bus": Der Empfänger haut seine Kanaldaten auf die Leitung und lässt dem Sensor dann eine definierte Zeit, damit dieser seine Daten los wird. Der Vorgang ist also genau umgekehrt. Die Datenrate ist 125 kBit/s bzw. 250 kBit/s. Für dieses Protokoll ist mir keine simpel zu bedienende Open-Source-Library bekannt. Eine solche wäre sicher nicht schwerer zu programmieren, als die EX-Library.

"Remote Commands" --> Hier kann ich auch nur vermuten:
Wahrscheinlich ist das eine aufgebohrte Variante des alten Jetibox-Protokolls. Ich denke, es arbeitet ungefähr so wie Du schreibst: Ein "Sensor" wird vom Sender aufgefordert seinen "Parameter-Tree" zu schicken. Dieser dürfte in einem speziellen Format programmiert sein. Jedes Gerät bekommt auf dem Sender eine "BIN"-Datei hinterlegt, die beschreibt, wie der Sender diesen Parameter-Baum anzeigen soll und welche Eingabewerte zulässig sind. Ich stelle mir das so vor, wie bei "XML": Es gibt die XML-Daten und das zugehörige Schema. Das Schema beschreibt die "Bedeutung" der Daten (=Anzeigenamen) und deren Wertebereiche. Auf dem Sender gibt es einen Parameter-Editor, der die Daten des Sensors anhand der BIN-Datei in einer "Maske" anzeigt, deren Veränderung zulässt und nach der Änderung wieder zum Sensor zurückschickt. Dieses Format ist aber nirgendwo öffentlich dokumentiert.

Das ist nur meine grobe Vermutung, vielleicht weiss es jemand anderes besser.

Weiterhin vermute ich, dass dieser Weg nicht so 100% für Dich geeignet ist, weil man das "Gerät" (=Sensor) über den Sender in diesn speziellen Modus versetzen muss. Im Prinzip ist das genauso unschön, wie die Jetibox zu aktivieren. Im Flug die "F-Tasten" zu bedienen, wollte ich jedenfalls nicht machen (hab aber auch keinen Kopter).

 

[pastaclub]

Ah okay, so langsam wird mir das etwas klarer - danke für die Erläuterungen. So ein grundlegendes Konzeptdiagramm hat Jeti irgendwie vergessen und die Benennung ist auch nicht ganz intuitiv. Ich glaube ich muss einfach mal lauschen was so über den EX-Bus geht. Und die Sache mit den Remote Commands vergesse ich am besten.

A propos "nur ein Sensor pro Port": es wäre sicherlich sinnvoll, gleich eine Hub-Funktionalität in die Sensoren zu integrieren, d.h. über einen UART auf einem zusätzlichen Port die Nachrichten eines anderen Sensors zu empfangen und diese dann über den eigenen Ausgang weiterzuleiten, natürlich sinnvoll in den eigenen Datenstrom eingebettet, so dass sich keine Pakete überschneiden. Hat aber gerade (zumindest bei mir) keine Priorität.

 

[Sepp62]

Die REX-Empfänger haben diesen "Hub" bereits an Bord. Nennt sich dann Expander. Du kannst drei Sensoren anschließen. Nachdem man sich aber seine Telemetrie sowieso selbst machen kann, packt man meist eh schon mehrere Sensoren auf einen Arduino und hat mit einem Port schon genug Werte. Die Notwendigkeit des Expanders wird damit immer kleiner.

Wenn man "alte" Empfänger hat vielleicht noch eher, aber so richtig motivierend finde ich das nicht, viele Stunden in ein solches Projekt zu stecken, wenn man einen neuen Empfänger für 60 Euro bekommt.

 

[Sepp62]

Version 0.99 ist released

Version 0.99 ist released

Die Version 0.99 ist nun online.

Sie enthält die von AlexM_1977 aus dem Jetiforum eingebrachten Änderungen und Fixes:

- Es sind nun mehr als 15 Sensoren möglich. Das Limit steht nun auf 32. Der Wert MAX_SENSORS kann in JetiExProtocol.h auf max. 255 erhöht werden. Der DemoSensor erzeugt nun 18 Demowerte.

- Ein Bug in Verbindung mit dem Datentyp TYPE_6B ist behoben.

Download wie immer hier:
http://sourceforge.net/projects/jetiexsensorcpplib/?source=directory

Viele Grüße
Bernd

 

[onki]

Hallo Bernd,

da ich noch weitere Stromsensoren am Start habe, wollte ich mich nun einmal mit dem miniPro versuchen, weil ich davon noch welche hab.
Ich hab den Code von der Teensy-Lösung in ein neues Projekt geschaufelt und in der Arduino IDE das Board und den Port geändert.
Leider wird das nicht kompiliert.

Muss ich da noch was in den Serialports umstellen, weil der miniPro ja "nur" zwei davon hat?
Fehlermeldung des Compilers kann ich noch nachliefern.

Gruß
Onki

 

[onki]

Hallo,

hier noch die Fehlermeldung im Fenster der Arduino IDE:

C:\Users\onki\AppData\Local\Temp\build8615fa7a21d9c739bf6478b5261e8b21.tmp/core\core.a(HardwareSerial0.cpp.o): In function `__vector_18':

C:\Users\onki\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.11\cores\arduino/HardwareSerial0.cpp:48: multiple definition of `__vector_18'

libraries\JetiExSensor\JetiExSerial.cpp.o:C:\Users\onki\Documents\Arduino\libraries\JetiExSensor\src/JetiExSerial.cpp:272: first defined here

C:\Users\onki\AppData\Local\Temp\build8615fa7a21d9c739bf6478b5261e8b21.tmp/core\core.a(HardwareSerial0.cpp.o): In function `__vector_18':

C:\Users\onki\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.11\cores\arduino/HardwareSerial0.cpp:48: multiple definition of `__vector_19'

libraries\JetiExSensor\JetiExSerial.cpp.o:C:\Users\onki\Documents\Arduino\libraries\JetiExSensor\src/JetiExSerial.h:133: first defined here

collect2.exe: error: ld returned 1 exit status

exit status 1
Fehler beim Kompilieren für das Board Arduino Pro or Pro Mini.

Gruß
Onki

 

[Sepp62]

Hallo Onki,

der Arduino Mini Pro hat nur eine serielle Schnittstelle.

Wenn man das Arduino-Board in der IDE ausgewählt hat, wird der vorhandene Port des Mini Pro ausgewählt.

Den Fehlermeldungen kann ich leider nichts entnehmen.

VG Bernd

 

[onki]

Hallo Bernd,

alles klar. Mir war nicht bewusst, das die beiden UART Anschlüsse auf der Platine nur parallel geschaltet sind.
Dann brech ich da einfach ab und mach mit dem TeensyLC weiter. Ist eh besser wiel ich dann eine durchgängige Plattform habe.
Ist nur einen hauch größer und ich kann mir dieses umständlche gepfriemel mit dem FTDI-Board sparen.
Die MiniPros werden dann für andere Dinge herhalten müssen (BID-Reader etc.).

Gruß
Onki

 

[onki]

Hallo,

Ich möchte gern meinen Code für beide Platinen (Teensy und miniPro) ohne große Änderungen verwenden.
Um den Teensy abzufragen gibt es ja "#ifdef CORE_TEENSY". Wie schaut die Systemvariable denn beim Pro mini aus?

Dann könnte ich ADC-Auflösung und Verrechnungsfaktoren gemeinsam verwalten.

Gruß
Onki

 

[nichtgedacht]

Moin

Ich finde die Beschreibungen von Jeti auf dieser Seite: http://www.jetimodel.com/en/Telemetry-Protocol/JETI-Telemetry-Communication-Protocol/

Die Software hier im Thread verwendet als serielles Protokoll ja 9o2 mit 9600 Baud, wenn ich das richtig sehe. Also das was hier beschrieben ist unter Telemetry Protocol : http://www.jetimodel.com/en/show-file/26/

Dann gibt es aber bei Jeti noch das EX-Bus Protokoll das hier beschrieben ist: http://www.jetimodel.com/en/show-file/642/ Da wird 8n1 als serielles Protokoll verwendet mit 125 resp, 250 kBaud.

Offenbar können die beiden Protokolle also nicht auf den gleichen USART Schnittstellen gleichzeitig unterwegs sein.

Kann mir jemand von den Experten erklären, welches Protokoll von welchen Bausteinen gesprochen wird?
Kennt jemand Beispiele wir man mit dem EX-Protokoll Telemetrie machen kann. Das scheint ja bidirektional zu sein.
Man sollte also mit dem Sender über den Empfänger ein Gerät sowohl beeinflussen als auch abfragen können.
Oder hab ich das falsch verstanden?

Gruß
Dieter

 

[c.radi]

Hallo Dieter,

aus meiner Sicht sind das zwei verschiedene Dinge.

Das Protokoll, welches 9o1 spricht ist auf der Senderseite, und füttert die JeitBox oder den Sender mit Telemetriedaten.

Das andere Protokoll beschreibt das Erzeugen von EX Nachrichten auf der Empfängereite, und muss dort am Ext. angeschlossen sein.

Gruß
Christian

 

[nichtgedacht]

Das Protokoll, welches 9o1 spricht ist auf der Senderseite, und füttert die JeitBox oder den Sender mit Telemetriedaten.
Das andere Protokoll beschreibt das Erzeugen von EX Nachrichten auf der Empfängereite, und muss dort am Ext. angeschlossen sein.

Moin Christian,

das würde ja heißen, dass man an das senderseitige Protokoll gar nicht ran kommt, außer man betreibt einen Fremdsender mit Jetimodul und benutzt eine Jetibox.
Außerdem will das hiesige Projekt, das seriell (9o1) EDIT: 9o2 sendet, doch offenbar den Selbstbau von Sensoren ermöglichen. Die müssen aber doch im Modell mit dem
Empfänger kommunizieren. Ist es vielleicht so, dass z.B. ein RSAT2 auf dem mit PPM beschrifteten Port EX-Bus sprechen kann und auf dem mit EX beschrifteten
Port gleichzeitig oder alternativ das "Telemetry communication protocol" empfangen kann? In beiden Dokumenten von Jeti ist u.a. ein Empfänger zu sehen der einen Sensor
oder, über Expander, mehrere Sensoren connected. Im "Telemetry communication protocol" sind die Sensoren Master im "EX Bus communication protocol" sind die
Sensoren Slaves. Das serielle Protokoll ist jeweils anders. Gibt es zwei Arten Jeti Sensoren?

Jetzt bin ich endgültig verwirrt.

Gruß
Dieter

 

[Sepp62]

Hallo,

in diesem Post habe ich es grob erklärt:

http://www.rc-network.de/forum/show...Mini-Pro-328?p=4046772&viewfull=1#post4046772

Ich vermute, Du interessierst Dich für das Protokoll aufgrund Deiner Aktivitäten im Jeti-Taranis-Thread. Daher gebe ich Dir noch ein paar weitere Infos, die ich im Laufe der Zeit gesammelt habe. Zunächst noch mal zu EX und EX-Bus (mein Wissensstand):

1. EX-Bus gibt es nur auf Empfängerseite. Es ist eine Alternative zu einem "PPM-Summensignal" oder zu einer UDI-Schnittstelle. Das Protokoll gibt die empfangene Information digital an geeignete Geräte, z.B. Flybarless-Systeme, Flight-Controller oder die Jeti-Central-Boxen. Im Gegensatz zu PPM-Summensignal oder UDI-Schnittstelle ist der EX-Bus auch telemetriefähig. Es handelt sich um ein Halb-Duplex-Protokoll, d.h. die Datenleitung wird zu bestimmten Zeiten in der Richtung umgeschaltet. Beim EX-Bus ist der Empfänger der "Master", er bestimmt wann der Telemetrie-Zeitslot aktiv ist.

2. Das EX-Protokoll gibt es ebenfalls auf der Empfängerseite. Es ist ein reines Telemetrieprotokoll, d.h. Du erfährst dort nicht, was der Sender sendet. Der Master ist der Sensor. Man kann einen Sender mit einem "Sensor" verbinden, wobei "Sensor" im Sinne des Protokoll-Masters zu sehen ist. Das Übertragungsprotokoll ist 9O2, wobei 9O1 auch funktioniert (den Teensy könnte man sonst gar nicht verwenden).

3. Zudem geben die DC/DS-Sender die empfangenen Telemetriedaten auch per EX-Protokoll an einem speziellen Pin am Sender aus. Das Protokoll scheint sehr ähnlich dem zu sein, was Ihr am TU-Modul bekommt. Mit 9O1 kann man den Datenstrom empfangen. Ich habe mal ein PC-Programm geschrieben, das grob Eurem Logger entspricht (allerdings nur mit 8N1, woraufhin mir das wichtige 9.Bit gefehlt hat). Mangels Anwendungsfall habe ich das nicht mehr weiterverfolgt. Aber von der Sache her ist es das umgekehrte, was die in diesem Thread besprochene Library macht. D.h. zusammen mit der Jeti-Spezifikation für das EX-Protokoll und dem Quell-Code für die hiesige Library müsstet Ihr in der Lage sein, den Datenstrom zu dekodieren.

Zu deinen Fragen:
a) Der RSAT2 gibt die empfangenen Daten auf PPM aus und ermöglicht den EX-Telemetrie-Anschluss an EXT. Wenn er EX-Bus macht, dann auf dem EXT-Anschluss. D.h. EX und EX-Bus gehen nicht gleichzeitig (wie gesagt: Mein Wissensstand)

b) Ja, es gibt zwei Arten von Sensoren. Die "Normalen" sind "EX" und einige wenige (z.B. das Jeti-Vario MVario2) sind "EX-Bus".


Viele Grüße
Bernd

 

[nichtgedacht]

Ich vermute, Du interessierst Dich für das Protokoll aufgrund Deiner Aktivitäten im Jeti-Taranis-Thread.

Moin Bernd

Nein nicht wirklich. Da hab ich nur vorbei geschaut.
Ich entwickle ja zum Spaß einen Flight Controller. Für das Einstellen der PID Werte verbrauche ich jetzt mal eben 3 Kanäle und habe die Anzeige auf dem Display vom Flight Controller.
Es wäre schön, wenn ich sowas auf meiner DC16 im Display sehen und per EX-Bus einstellen könnte. Außerdem ist die Schnittstellenkonfiguration vom Jetischen Telemetrie Protokoll ja sowas von weird.

Ich will also ein EX-Bus kompatibles Gerät bauen.
Hoffentlich braucht man dafür kein NDA mit Jeti.

Und nochwas: Du sagst, das man für EX Telemetrie mit dem Teensy einfach 9O1 nehmen kann. Gibt das nicht Frame Errors. Die STM32 haben ja auch das Leiden, dass man nur max 9 Datenbits incl. Parity einstellen kann.
9O2 geht also gar nicht. Ich nehme an, dass das die gleiche Einschränkung wie beim Teensy ist? Da sitzt aber ein anderer ARM Chip drauf, oder?

Gruß
Dieter

 

[Sepp62]

Hallo Dieter,

im Teensy werkelt ein MK20DX64, der einen Cortex M4-Kern besitzt.

Eigentlich müsste es Framing-Errors geben, wenn man mit 9O1 arbeitet, die HardwareSerial-Library scheint diese aber nicht besonders schwer zu bewerten ;-), denn man bemerkt sie als Programmierer nicht (ich frage die Framing-Errors aber auch nicht explizit ab). Ich habe den Teensy längere Zeit ignoriert, eben weil er kein "O2" kann. dann habe ich ihn einfach mal verwendet und es hat funktioniert. Am Anfang dachte ich, dass das vielleicht auch eine Eigenart der REX-Empfänger ist, die ja nun auch einen 32-Bit-Prozessor mit UARTs von denen ich auch vermute, dass sie kein "O2" können. Aber der Teensy arbeitet auch an einem RSAT2 einwandfrei.

Für die Implementierung von EX-Bus solltest Du kein NDA brauchen, da die "Spec" ja prinzipiell verfügbar ist. Was nicht öffentlich ist, ist die Beschreibung, wie man ein solches Gerät per Sender konfigurieren kann. Die Jeti-Box-Emulation ist dabei eine Notlösung. Für einen Flight-Controller ist das allerdings mühsam, wenn da wirklich jeder Parameter durch soll.

Grüße
Bernd

 

[wkorosec]

Jetisensor mit Attopilot - Spannung, Strom, Leistung, Energieverbrauch

Jetisensor mit Attopilot - Spannung, Strom, Leistung, Energieverbrauch

Liebe Jeti-Eigenbausensor-Interessierte,
Code hier:
https://github.com/wifff/VOSS_Power/

und mehr dazu im Nachbarforum ...
http://www.jetiforum.de/index.php/2...ry-fuer-jeti-ex-eigenbau-telemetrie?start=126


Herzliche Grüsse,
Wolfgang

 

[astrofly]

Hallo Dieter,

im Teensy werkelt ein MK20DX64, der einen Cortex M4-Kern besitzt.

Eigentlich müsste es Framing-Errors geben, wenn man mit 9O1 arbeitet, die HardwareSerial-Library scheint diese aber nicht besonders schwer zu bewerten ;-), denn man bemerkt sie als Programmierer nicht (ich frage die Framing-Errors aber auch nicht explizit ab). Ich habe den Teensy längere Zeit ignoriert, eben weil er kein "O2" kann. dann habe ich ihn einfach mal verwendet und es hat funktioniert. Am Anfang dachte ich, dass das vielleicht auch eine Eigenart der REX-Empfänger ist, die ja nun auch einen 32-Bit-Prozessor mit UARTs von denen ich auch vermute, dass sie kein "O2" können. Aber der Teensy arbeitet auch an einem RSAT2 einwandfrei.

Hallo Dieter,
ich weiß nicht, ob dieser Thread noch lebt und ob ich vielleicht nicht ganz auf dem Laufenden bin, aber ich habe hier einen Teensy 3.5 mit dem MK64FX512 in Aktion, der sowohl 9O2 kann (kleiner Zusatz in Arduino HardwareSerial.h, alles andere ist in der "Teensyduino1.30" Bibliothek schon drin) als auch einen "single wire UART" mode hat, bei dem man nicht mehr Rx und Tx des UART "aneinanderwursteln" muss, sondern bei dem man mit einem Bit im UARTX_C1 Register zwischen Tx und Rx hin- und her schaltet. Der Tx-Pin wird dabei automatisch auf input (bei Rx-Betrieb) oder output (Tx-Betrieb) geschaltet. Ich habe dazu Deine schönen JetiExSensor-Routinen etwas umgestrickt bzw. erweitert. Ich habe es bisher nur im "NonEx" Testmodus mit einer Jetibox mini ausprobiert, wo das inklusive Tastenrückgabe zu funktionieren scheint. Bei Interesse kann ich meine Änderungen mal zusammenstellen. Den single wire UART mode hat übrigens auch der MK20DX64 (Teensy 3.2) schon, die 9O2 aber anscheinend nicht.
Grüße und Dank für die schöne JetiEXSensor Software,
Karl

 

[astrofly]

Sorry, ich meinte natürlich Bernd. Und der Teensy 3.0 hat nach meinen Unterlagen einen MK20DX128 an Bord, die 3.1 und 3.2 einen MK20DX256. An den Aussagen in Beitrag #98 ändert das nichts.
Karl

 

[M_O_B]

Development Platine für EX Telemetrie-Library

Development Platine für EX Telemetrie-Library

Hallo Zusammen,

zuerst einmal vielen Dank für die Arbeit die in der Library steckt. Ich weiß wie viel Zeit bei so was drauf geht und bin dankbar, dass die Lib hier zur Verfügung gestellt wird.

Ich habe die Library im Einsatz als Protokollwandler von LTM zu ExBus. Die Entwicklung habe ich auf einem Arduino Mini gemacht. Diese Platine ist mir aber zu groß und ich plane eine Platine zu entwickeln. Das Herstellen und Bestücken ist aber sehr teuer bei kleinen Stückzahlen. Deshalb hier die Frage, ob noch von anderen Interesse an einer kleinen development Platine besteht die wir zusammen gestalten können.

Freue mich über euer Feedback egal wie es ausfällt.

Grüße Marc

 

[Sepp62]

Guten Abend zusammen,

kaum schaut man hier ein paar Monate nicht rein, schon tut sich was .

@Karl: Cool, dass Du den Teensy verwendest. Poste doch mal Deine Code-Anpassungen hier, wenn Du magst. Meine Recherchen gingen seinerzeit so aus, dass der Teensy automatisch einen digitalen Ausgangs-Pin steuern kann, um z.B. einen RS-485 Transceiver umzuschalten. Dass er direkt den TX-Pin abschalten kann, war mir nicht klar.

@Marc: Ich gebe zu, dass ich mit den vorhandenen Boards ganz gut klarkomme. Ich wünsche mir zwar auch manchmal eine komplette Platine, aber nur um die weitere Sensorhardware mit auf ein Board draufzuhauen und keinen "Lochrasterverhau" zu haben. Da aber alle meine Sensoren unterschiedliche Hardware haben, käme ich mit einer Platine nicht hin. Ein kleines CPU-Board universell (a la Breakout-Board) zu machen wird man wohl kaum hinbekommen, denn dann ist man schnell wieder in der Größe eines "Pro Mini" (Spannungsregler braucht man ja auch noch). Dennoch fände ich es sehr interessant mehr davon zu hören. Was ich spannend fände ist, wenn Du beschreibst, wo man die "nackten" CPUs herbekommt und wie man den Arduino-Bootloader flashed (oder wie immer Du das Boot-Loader-Problem löst).

@Alle: Ich habe die Library für die AtMega32u4-CPU erweitert. Man kann nun die "Pro Micro" (nicht zu verwechseln mit "Pro Mini") verwenden. Der Vorteil ist, dass die eine vom UART unabhängige USB-Schnittstelle haben. Man kann also einen Sensor mit dem Jeti-Empfänger verbinden und gleichzeitig über USB debuggen. Das ist verglichen mit den ATMega 328-CPUs schon sehr komfortabel. Zudem ist das Board auch noch ein wenig kleiner als das vom "Pro Mini". Mit rund 3,5 bis 10 Euro kostet es ungefähr gleich viel.

Viele Grüße
Bernd