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

Thomas L schrieb:

Das bei einer Änderung auch die Sensoren neu eingelesen müssen versteht sich von selbst, das sollte aber kein Problem sein, eine automatische Ausblendung wäre super wird von Jeti aber wie Du schon schreibst nicht unterstützt.

Zum Vergrößern anklicken....

Hallo Thomas,

versteht man das wirklich, dass man die Sensoren nach einer Konfigurationsänderung im Sender neu einlesen muss ? Oder besser gesagt: Nimmt man das in Kauf ? Das Einlesen über die Auto-Funktion geht ja recht flott aber bis dann die Telemetrie-Displays aufgeräumt sind...

Thomas L schrieb:

Die aktiven Sensoren werden doch von Deiner Lib verwaltet, so sollte es doch mE kein Problem darstellen beim Start einen zusätzlichen Parameter mit zu übergeben der definiert welche Einträge in der Tabelle aktiv sind, oder was spricht dagegen ?

Zum Vergrößern anklicken....

Codetechnisch spricht da gar nichts dagegen, ich hatte es auch schon mal implementiert. Ich finde aber, dass der Nutzen des Features schwer zu vernmitteln ist. Am Ende ist es Code, der mitgeschleppt werden muss. Wenn sich solche Features "zusammenläppern" wird der Code auch schwerer zu verstehen und durch andere zu ändern. Hier würde ich mir noch etwas Input aus dem Anwenderkreis wünschen.

Thomas L schrieb:

Dann habe ich noch eine Merkwürdigkeit festgestellt. Im Sender alle Sensoren löschen (auto), dann Empfänger (in meinem Fall ein R9ex) einschalten. Der erste Sensor wird dann idR verzögert eingelesen, das dauert eine ganze Weile bis er im Telemenu angezeigt wird. Sensor 2-n erscheinen schnell.
Merkwürdig an der Sache finde ich das es auch stark verzögert wird wenn nur ein Sensor angelegt ist.
Die Erhöhung des Start Delay in Deiner Lib von 2000mS auf 3000mS schien zunächst zu helfen, hatte aber zwischendruch immer wieder Fälle wo es nicht klappte. Vielleicht hast Du ja eine Idee.

Zum Vergrößern anklicken....

Die Library sendet das "Sensor-Verzeichnis" grob alle 256 Nachrichtenzyklen. Ab und zu scheinen solche Nachrichten im Sender nicht richtig anzukommen. Eine Idee ist, das "Sensor-Verzeichnis" nach dem Systemstart nicht nur einmal zu schicken, sondern z.B. 30 Sekunden lang in verstärktem Maße. In dieser Zeit kommen die Telemetriedaten halt seltener. Ich habe das bisher nicht eingebaut, weil ich diese Probleme in meiner Umgebung (DS-16) nicht habe und es keine Möglichkeit für mich gibt nachzutesten, ob diese Änderung was bringt. Wenn Du den Effekt mehr oder weniger gut reproduzieren kannst, kann ich Dir mal eine Testversion bauen.

VG Bernd

Sepp62 schrieb:

versteht man das wirklich, dass man die Sensoren nach einer Konfigurationsänderung im Sender neu einlesen muss ? Oder besser gesagt: Nimmt man das in Kauf ?

Zum Vergrößern anklicken....

Da hast Du wohl Recht man kennt es halt so ...

Sepp62 schrieb:

Codetechnisch spricht da gar nichts dagegen, ich hatte es auch schon mal implementiert. Ich finde aber, dass der Nutzen des Features schwer zu vernmitteln ist. Am Ende ist es Code, der mitgeschleppt werden muss. Wenn sich solche Features "zusammenläppern" wird der Code auch schwerer zu verstehen und durch andere zu ändern. Hier würde ich mir noch etwas Input aus dem Anwenderkreis wünschen.

Zum Vergrößern anklicken....

Der große Vorteil ist mE das man recht einfach einzelne Sensoren akt/deaktivieren kann, so wie es vor dem Umzug der Tabelle ins Flash möglich war. Warum sollte man Sensoren im Sender anzeigen die gar nicht vorhanden sind. Kaum zu glauben das ich der Einzige bin der einen Multisensor baut und um das Ding individuell zu nutzen ist die gewünschte Eigenschaft für mich eigtl. unabdingbar. Es wäre mE nur "ungeschickt" wenn ich Deine tolle Lib auf meinen bedarf anpasse und dann später nicht mehr so einfach von weiteren Updates partizipieren könnte.

Sepp62 schrieb:

Die Library sendet das "Sensor-Verzeichnis" grob alle 256 Nachrichtenzyklen. Ab und zu scheinen solche Nachrichten im Sender nicht richtig anzukommen. Eine Idee ist, das "Sensor-Verzeichnis" nach dem Systemstart nicht nur einmal zu schicken, sondern z.B. 30 Sekunden lang in verstärktem Maße. In dieser Zeit kommen die Telemetriedaten halt seltener. Ich habe das bisher nicht eingebaut, weil ich diese Probleme in meiner Umgebung (DS-16) nicht habe und es keine Möglichkeit für mich gibt nachzutesten, ob diese Änderung was bringt. Wenn Du den Effekt mehr oder weniger gut reproduzieren kannst, kann ich Dir mal eine Testversion bauen.

Zum Vergrößern anklicken....

Ahh, ok das erklärt natürlich die lange Verzögerung. Mit den 2Sek. Starverz. kriege ich das immer hin das der 1. Sensor nicht direkt angezeigt wird. Habe eine DC16 mit R9 in der Testumgebung.

Anmerk: mit Jetibox meine ich übrigens die Emulation in meiner DC16

Tastenempfang

Tastenempfang

Hallo Bernd,

da ich bei meiner Bedienung über die JB auch rechts/links gleichzeitig gedrückt auswerten möchte habe ich Deinen Empfangsfilter etwas modifiziert. So werden nun alle Tastendrücke egal in welcher Kombination betätigt eingelesen.

ISR( USART_RX_vect )
{
// uint8_t status = UCSR0A;
// uint8_t bit8 = UCSR0B; // unused
uint8_t c = UDR;
// Left = 0x70, down = 0xb0, up= 0xd0, right = 0xe0, l+r == 0x60
alt:
// if( c == 0x70 || c == 0xb0 || c == 0xd0 || c == 0xe0)
neu:
if( c != 0xf0 && (c & 0x0f) == 0 ) // Tastencodes im oberen Nibble

Thomas L schrieb:

Der große Vorteil ist mE das man recht einfach einzelne Sensoren akt/deaktivieren kann, so wie es vor dem Umzug der Tabelle ins Flash möglich war. Warum sollte man Sensoren im Sender anzeigen die gar nicht vorhanden sind. Kaum zu glauben das ich der Einzige bin der einen Multisensor baut und um das Ding individuell zu nutzen ist die gewünschte Eigenschaft für mich eigtl. unabdingbar. Es wäre mE nur "ungeschickt" wenn ich Deine tolle Lib auf meinen bedarf anpasse und dann später nicht mehr so einfach von weiteren Updates partizipieren könnte.

Zum Vergrößern anklicken....

OK, ich krame meine Anpassung zu deinem Wunsch wieder raus und adaptiere die Library. Ich möchte das ungefähr so lösen:

a) Alle Sensoren sind im Default aktiviert.
b) Du kannst einzelne Sensoren gezielt deaktivieren, indem Du vor dem Aufruf von Start() eine Methode aufrufst, z.B. so:
ActivateSensor( int id, bool bActivate);

Damit bleibt die Änderung kompatibel zum bestehenden Code und wer die Funktion nicht braucht, sieht sie auch nicht. Gegenüber Deiner "Maskenvariante" hat die Methode den Nachteil, dass man die Funktion mehrfach aufrufen muss. Der Vorteil ist, dass man nicht auf 32 Sensoren beschränkt ist und auch nicht darauf angewiesen ist, dass die IDs fortlaufend von 1 bis 32 sind (die Länge des ID-Felds ist bei Jeti 8 Bit).

Hilft Dir das ?

VG Bernd

PERFEKT !!

Das ist eine absolut klasse Lösung, besonders gut das es keine Rückwirkungen auf bestehende Anwendungen hat, super Idee. Denke das ist schon eine sinnvolle Erweiterung für Deine Library, das kann mit Sicherheit der ein oder andere gebrauchen.

PS: Du meinst natürlich einen Aufruf ala DeactivateSensor( int id );

Frage: Gehts hier weiter?

Der letzte Beitrag ist schon eine Weile her.
Meine Bauteile trudeln langsam ein.

Gruß Volker

Variante für Jeti EX Bus

Variante für Jeti EX Bus

Es gibt nun eine Variante der Library für den Anschluss an EX Bus:

https://sourceforge.net/projects/jetiexbussensorcpplib/

Da das Thema ausschließlich Jeti betrifft, ist es sicher besser Fragen dazu im Jeti-Forum zu behandeln.

VG Bernd

JETI EX Bus Telemetrie nun auch auf ESP32

JETI EX Bus Telemetrie nun auch auf ESP32

Die Library funktioniert nun auch mit dem ESP32:

https://github.com/Sepp62/JetiExBus

VG Bernd

Hallo,

ich weiß nicht ob ich hier richtig bin, aber ich bin auf der Suche nach einer Möglichkeit, die Telemetriedaten eines Linearen Spannungsreglers JETI "MAXBEC 2D EX PLUS" in einen Frsky Empfänger G-RX8 - über den S.Port - einzuspeisen, um sie dann auf dem Senderdisplay anzeigen zu können.

Leider war bisher meine Suche nach einer funktionierenden Lösung ohne Erfolg. Aber mithilfe eines Arduino und der EX Telemetrie-Library müsste doch so etwas zu machen sein, zumal es ja auf der Frsky-Seite schon eine Lösung gibt (openXsensor), die Spannungs- und Stromwerte mit einem entsprechenden Adapter liefert.

Da ich kein Programmierer bin, würde es mich freuen, wenn Fachleute mir da weiterhelfen könnten. Sicherlich gibt es auch andere Modellbauer, die ähnliche Lösungen suchen.

Gruß Udo

Hi

Hier hat mal jemand sowas gebaut:
http://jopl.dlnet.us/jeti2frsky.php

Allerdings geht es da um die Übersetzung der Protokolle am Sender.
Du willst sowas ja Empfängerseitig realisieren wenn ich das richtig verstanden habe?
Vielleicht ist der Link ja dennoch eine Hilfe um die Übersetzung der Protokolle zu verstehen?

Ich denke jedoch, dass das besser in einem separaten Thread aufgehoben ist..

Hallo GP15,

danke für den Link. Den hatte ich bereits gefunden und wie du richtig feststellst, möchte ich die Jeti Daten extern über einen Konverter an den S.Port von FrSky - in diesem konkreten Fall an eine FrSky RB-20 Weiche - bringen. Werde dann Mal einen neuen Thread aufmachen.

Gruß Udo

Library auf Atmega1284P

Library auf Atmega1284P

Hallo zusammen,
ich versuche gerade, die Library (JetiExBus-master bzw. JetiExSensor-master) auf einem Atmega1284P zum Laufen zu bekommen. Ich habe das Ganze soweit auch zum fehlerfreien Übersetzen bekommen (auf einem Atmega328P habe ich schon einen Sensor gebaut, dieser läuft soweit auch). Allerdings habe ich nun mit dem 1284P das Problem, daß die Interruptroutinen im Programm nicht (mehr) bekannt sind. Aktuell habe ich nichts anderes gemacht, als daß ich die Stellen im Code, an denen die Preprozessor-Direktiven für den Atmega328P(B) auftauchen in entsprechender Weise (mit "&&" bzw. "||") auch noch den Atmega1284P eingefügt habe. Daß die Interruptroutinen nicht mehr ansprechbar sind fiel mir bei der Ursachensuche auf, es lässt sich dort kein Breakpoint einfügen (ich programmiere unter Atmel Studio 7 mit einem mkII JTAGICE), dies wird mit der Meldung "the breakpoint will not currently be hit" angezeigt. Wenn ich das bisher richtig verstanden habe, sollte nach dem Senden eines Zeichens das UDRE-Flag gesetzt sein und die Interrupt-Routine ("ISR(USART_UDRE_vect)") aúsgeführt werden. dort wird dann auch das BIT "m_bSending" wieder auf FALSE gesetzt. Da dies nicht passiert wird auch nichts gesendet. Kann mir da jemand weiterhelfen?

Grüßle Günni

Hat sich erledigt, die Exbus library läuft jetzt auch auf einem Atmega1284p
Grüssle Günni