Arduino Library für Jeti EX Eigenbau-Telemetrie

ThLehmann wrote: ... Ziel war die für mich wichtigen Sensoren für den Motorbetrieb (Schlepper) zusammenzufassen....

Da wundert es wohl nicht das es für Segler und Elekto nicht brauchbar ist

VOBO wrote: Schön das es bald weitere Alternativen gibt.
Allerdings sind die von dir erwähnten Sensoren für Segelflieger und Elekrosegelflieger größtenteils unbrauchbar.

Ich benötige:
1. Vario
2. Rel. Höhe
3. Eine Spannungsmessung für die Empfängerspannung vor dem BEC
4. Strommessung
5. Verbrauchte Kapazität
6. Optional Einzelzellenüberwachung des Flugakkus (bei mir max. 4S)
7. Optional eine weitere Spannungsmessung für die redundante Empfängerspannungsversorgung oder die Gesamtspannung der Flugakkus, wenn man keine Einzelzellenüberwachung machen möchte.

Es gibt viel zu tun.

Gruß Volker

Ich habe folgendes selber schon in einem Sensor realisiert:
1. Rel. Höhe mit MS5611 (Auflösung ca. 0.1 m, wobei die Telemetriedaten auf 1 m Genauigkeit gerundet werden)
2. Vario natürlich ebenfalls mit MS5611 (Auswertung der Höhenänderung über lineare Regression, Auflösung ca. 0.05 m/s fast verzögerungsfrei, funktioniert top!)
3. Zweimal Spannungsmessung bis 10V per Spannungsteiler (für Empfängerakkus vor Weiche oder BEC gedacht)
4. Spannungsmessung bis 55V ebenfalls per Spannungsteiler (für Antriebsakku gedacht)
5. Strommessung mit ACS758 bis 200A
6. Verbrauchte Kapazität mittels Integrierung des Stroms über Zeit
7. Antriebsleistung aus Spannung- und Strommessung
8. Zur Zeit arbeite ich an einer echten Geschwindigkeitsmessung mit Pitot-Rohr. Die Tests am Boden haben schon mal super funktioniert. Die Erprobung in der Luft kommt noch.
9. Die Jetibox-Unterstützung zum Einstellen und Kalibrieren ist auch fast fertig.

Die Hardware ist zusammengebastelt aus fertig gekauften Modulen. Alles auf einer Platine wäre natürlich eine feine Sache.
Was leider noch fehlt ist die Einzelzellenüberwachung. Da muss ich mir noch ein paar Gedanken machen. Evtl. versuche ich mal mit dem Teensy 3.2 was zu machen, da 21 Analogeingänge vorhanden sind und der ADC höher auflöst.

Den Code für das Arduino Nano reiche ich später noch nach.

Gruss Lukas

Hört sich gut an.
An dem Code wäre ich sehr interessiert.
Bin noch in der Lernphase.

Gruß Volker

Auch wenn auf den letzten Seiten alles Wesentliche schon gesagt wurde, hier noch ein paar Anmerkungen von meiner Seite:

Die JetiEX-Library ist der kleinste sinnvolle Umfang, der bezüglich der Aufgabenstellung „Sensoren für Jeti“ geliefert werden kann.

D.h. mehr geht auf jeden Fall. Doch wie soll dieses „mehr“ aussehen ? Mein ursprüngliches Ziel war, mehrere (auch exotische) Sensoren an eine CPU anzuschließen, ohne einen Verhau von Modulen und Kabeln zu bekommen. Ich habe mir seinerzeit ein paar kleine Designregeln aufgestellt, um so etwas wie einen „Baukasten“ zu bekommen. Inzwischen habe ich bestimmt 10-15 Sensoren (auch für einige meiner Freunde) gebaut. Ich hatte die Hoffnung, dass sich dadurch eine Art „Abstraktion“ ergibt, die dazu führen kann, so etwas wie einen „Sensorbaukasten“ draus zu machen.

Inzwischen bin weg davon. Der Hauptgrund ist fehlende Zeit (wie Onki schon so treffend schrieb). Aber es gibt auch eine Reihe von anderen Gründen, warum ich hierfür nichts mehr gemacht habe. Hier nur drei Beispiele:

• Generelles Sensorverhalten: Wie lange darf ein Sensor die CPU blockieren ? Beispiel Spannungsmessung: Der Wandler wandelt von allein. Man könnte den Wandlungsvorgang starten und die CPU wieder anderen Sensoren geben (kooperatives Multitasking); in einem weiteren Schritt holt man sich den Wert wieder ab. Dann kann man aber die Standard-Library-Funktionen nicht mehr verwenden. Für jede zusätzliche Hardwareplattform muss dann neue AD-Wandler-Klassen schreiben. 90% der Projekte brauchen das aber vermutlich nicht, weil die CPU-Last dort einfach keine Rolle spielt. Gleiches Thema beim I2C-Bus, auch dort kann synchron arbeiten (ist fast immer ausreichend) oder asynchron (dann nicht mehr mit Standard-Libraries).


• Speicher: Investiere ich in „Komfort“ (z.B. datengesteuerte Sensor-Konfiguration über Config-Files) ? Oder ist es besser dem Anwender einen minimalen Speicherverbrauch zu geben ?


• „Sensor-Virtualisierung“: Man könnte versuchen, den Code für Sensoren zu kapseln. Dann könnte man diese leichter kombinieren. Auch die Konfiguration könnte man darüber abdecken. Ein Sensor-Entwickler müsste „nur“ den Code für eine solche Klasse schreiben. Aber will man das wirklich ? Viele Stunden Aufwand nur um z.B. einen AD-Wandler-Wert einzulesen, der ansonsten ein Einzeiler in loop() ist ? Eine Schnittstelle definieren, die für den einen zu wenig leistungsfähig, für den anderen zu komplex ist ? Einem Dritten gefällt sie dann aus anderen Gründen nicht.

Wenn man sich ein Herz fasst und diese Ding einfach angeht, wird man zu einer ähnlichen Lösung kommen wie OpenXSensor. Warum also das Rad nochmals erfinden ?

Aus meiner Sicht wird es demnach dabei bleiben eine einfache (für die meisten Anwender nutzbare) Library zu pflegen. Aber natürlich würde es mich freuen, wenn sie Grundlage für Erweiterungen der „Community“ wäre. Ein schöner Sensorbaukasten für Jeti ohne Kabelverhau, nur minimalem Platzbedarf und mit stets aktueller Sensortechnik wäre schon was Feines.

Viele Grüße
Bernd

Hallo Bernd,
Vielleicht wäre es eine gute Idee, wenn diejenigen die schon erfolgreich Sensoren mit deiner Bibliothek gebaut haben, ihren Code dazu irgendwo (hier im Forum?) ablegen. Dann könnten Anfänger in der Programmiersprache C++ davon profitieren und ev. auch ohne vordefinierten, configurierbaren code erfolgreich ihre Sensoren aufsetzen.
Mit OXS bin ich zur Zeit auch unterwegs, stelle aber fest das für Jeti noch einiges nicht richtig läuft.
Eine Änderung des Codes dort ist nicht ganz so einfach/überschaubar, weil er universell für alle Systeme (FrSky, Multiplex, Hott, Jeti) geschrieben wurde.
Mir wäre es Recht, mit deiner Bibliothek zu arbeiten, bräuchte dafür aber konkrete Beispiele realisierter Sensoren, im Sinne von Applikationsbeispielen.

Gruß Volker

Hallo Volker,

ich stelle gerne alle Sensor-Codes zur Verfügung, die ich habe.

In einem Thread wird es natürlich schnell unübersichtlich (Diskussionen, Code-Updates, etc.) aber es ist sicher besser als nichts. Bei den Sendern gibt es bereits die "Lua-Ecke", unter "Do It Yourself" lässt sich sicher leicht die "Sensor-Ecke" einrichten.

Jürgen ist sicher gerne behilflich, wenn Du ihn ansprichst.

Viele Grüße
Bernd