THEMA:

Hallo zusammen,

ich habe eine neue Version bereitgestellt. Das hat sich geändert:

- Bugfixes für Jetibox-Tasten und Morse-Alarme (Vielen Dank an Ingmar für die Bereitstellung seiner Verbesserungen !)
- Optimierte Sendekontrolle für Halb-Duplex-Betrieb für AVR CPUs in der JetiExHardwareSerialInt Klasse (verbessertes Verhalten für Jetibox-Tasten)
- Reduzierte Größe des seriellen Sendepuffers (128-->64 words)
- Geänderte Bitraten für die serielle EX-Kommunikation für AVR CPUs (9600-->9800 bps)
- Die EX-Verschlüsselung wurde entfernt. Als Folge musste die "Manufacturer-ID" angepasst werden: 0xA409

*** Bei Verwendung der Library ab 1.0.0 muss daher leider die Telemetrie im Sender neu eingerichtet werden ***

- Verzögerung beim Systemstart auf 2 Sekunden erhöht, so dass die Sensordaten erst gesendet werden, wenn der Empfänger sicher initialisiert hat.
- Neue HandleMenu()-Funktion im Beispiel JetiExSensor.ino (inklusive Morse-Alarm-Test)
- JETI_DEBUG und BLOCKING_MODE entfernt, so dass der Code lesbarer wird.

Download-Link: sourceforge.net/projects/jetiexsensorcpp...iles/latest/download

Weitere Infos im nächsten Beitrag.

Viele Grüße
Bernd

Noch ein paar Infos zur Version 1.0.0:

- Die Verschlüsselung der Telemetrie-Pakete habe ich nun entfernt. Damit entspricht das Verhalten dem, was die Jeti-Spec vorgibt. Und siehe da: Der Manufacturer-ID-Bereich, den Jeti vorgibt 0xA400 bis 0xA41F funktioniert nun. Damit sind nun alle "Unbekannten" aus dem Code entfernt. Der Preis ist, dass für bestehende Projekte die Telemetrie im Sender neu eingelernt werden muss. Leider geht das nicht anders.

- Weiter habe ich den Code etwas aufgeräumt und veraltete Betriebsarten entfernt (JETI_DEBUG, BLOCKING_MODE). Dadurch wird alles übersichtlicher.

- Die Behandlung der Jetibox-Tasten ist nun verändert. Ingmar hat mir freundlicherweise seine Änderungen bereitgestellt. Ich habe das Ganze am Ende zwar etwas anders gelöst, aber sein Code war für mich der "Benchmark", wie gut das funktionieren kann. Leider gibt es für die Jetibox-Tasten keine perfekte Lösung. Es kommen ab und zu "Extra-Tastendrücke" oder aber es fehlen mal welche, aber so einigermaßen hat es nun hin.

- Was ich für 1.0.0 noch nicht geschafft habe: Die Texte (Name/Einheit) für die Sensordefinitionen sollten im PROGMEM liegen können, um kostbares RAM zu sparen. Norbert hat einen "Mega-Sensor" gebaut, der mehr als 30 Sensordefinitionen besitzt. Allein für die Texte gehen schon ein paar Hundert Bytes drauf. Das kommt aber leider erst später.

Wie immer:

Ich kann den Code leider nicht erschöpfend testen. Behaltet also lauffähige Versionen Eurer Sensoren immer bei. Es kann durchaus sein, dass die Version 1.0.0 noch Mucken hat. Dann bitte im Forum melden.

Nun viel Spaß damit.

Viele Grüße
Bernd

Hallo Bernd

Machst du irgentetwas mit der LED Pin13 in deiner Library?
Die Blinkt seit dem Sensorwechsel immer!

Gruß Micha

Ja, Mist. Da war Code für die LED zum Debuggen drin. Hatte ich übersehen. Habe gerade die Datei im Archiv ausgetauscht.

Kannst es neu runterladen. Versionsnummer habe ich (nach guter alter Jeti-Manier ) nicht geändert.

Ein nettes Hallo an die Experten hier im Forum. Ich bin neu hier und wollte gern ein paar Fragen stellen.
Zum Hintergrund: Ich bin Modellflieger seit '79 und Elektronikbastler seit den 80ern. Ich fliege mit Jeti-Empfängern+Sensoren seit ca. 10 Jahren, bisher mit einer MC-24 mit TU-Mudul, seit kurzem wegen Versagens der Alten mit einer Jeti DS-16. Ich habe in 2009 schon mal mit PIC-Prozessoren die Kommunikation zur Jeti-Box "erforscht", damals in Assembler, dann mit Atmega und C einen Fesselflug-Timerbaustein gebastelt, den ich mit der JetiBox programmieren konnte (wie einen Sensor), habe dann aber lange nichts neues mehr daran gemacht. Jetzt habe ich mit Arduinos angefangen und durch meinen neuen Sender nun wieder zu EX-Telemetrie zurückgefunden...
Nun tue ich mich ein wenig schwer mit der Arduino-IDE und mit C++, auf dem das alles da wohl basiert. Kämpfe mich durch verschiedene Beispiele und Tutorials. Als Target habe ich mir den ProMicro ausgesucht mit dem Mega32U4. Den kann ich auch schon aus der IDE her proggen und habe mal den RPM-Sensor vom Tero Salminen draufgeschrieben, das funktioniert soweit via Empfänger am Sender, aber mit der JetiBox will er noch nicht reden. Vielleicht liegt's an der HW.Verbindung, ich erinnere mich, daß die JetiBox da immer etwas "zickig" war (im Moment 2,2k zw TX+RX, TX direkt an Jeti).

Nun bin ich auf die Library hier vom Bernd (u.a.) gestoßen und hab da mal 'ne Frage: Der ProMini (meldet sich auch als Leonardo) hat ja zwei Hardware-UARTs. Über den ersten kommuniziert er über USB an den PC, der zweite wäre frei. Die Biliothek hier benutzt aber zur Verbindung mit Jeti genau den UART0. Kann ich - wenn dann wo- die Routinen auf UART1 umstellen? Dazu muß ich wahrscheinlich in der JetiExSerial.cpp eingreifen, oder? ( C++ )
Wäre schön beide gleichzeitig nutzen zu können, UART0 an den PC zum debuggen und den anderen für Jeti-Kommunikation.
Außerdem ist mir noch nicht klar wie hier die HW-Anbindung an Jeti's einen Draht passiert. Welche Widerstände nehmt ihr zwichen RX-TX und welchen Wert in Reihe?

Als nächstes frage ich dann nach I2C-Routinen, wie man Interrupt-Routinen hinbringt usw. Der ferne Plan ist ein Kombi-Sensor, der im Prinzip den MULI und den MUI (mit 7xINA219-Frontend) und den RPM an einen Stecker bringt, aber bis dahin ist's noch weit.

Wäre nett, wenn Ihr mir den ein oder anderen Schubs in die richtige Richtung geben könntet.
Danke schon mal und bis bald,
Holger

Hallo Holger,
willkommen hier im Forum. Der ProMini hat (wie auch der Nano) eine Atmega328-CPU. Die hat leider nur einen UART, der im Falle des Nano auch mit dem USB-Transceiver verbunden ist (der Leonardo hat einen Atmega32u4-Prozssor). D.h. um die Jeti-Telemetrie zu verwenden, muss die USB-Verbindung ausgesteckt sein. Umgekehrt muss bei Verwendung von USB der Jeti-Empfänger ausgesteckt sein.

Das ist ausgesprochen lästig, wäre aber nur über eine Implementierung der seriellen Schnittstelle per Software änderbar. Alternative ist der (teure) Teensy 3.x, der 3 UARTs hat und auch sonst Schnittstellen ohne Ende bietet.

I2C ist ohne Probleme zusätzlich zur Jeti-Schnittstelle mit dem Atmega328 machbar.

Viele Grüße
Bernd