OpenXSensor für Telemetriesensoren

onki

User
Hallo,

ich denke das Thema macht sich hier sehr gut, auch wenn es woanders schon erwähnt wurde.
Daher hab ich mal diesen Fred aufgemacht um Probleme oder Lösungen rund um das Thema zu diskutieren.
Ich selber habe schoin mehrere Sensoren mit OXS realisiert (Jeti-Protokoll). Zu den anderen Protokollarten kann ich nur wenig beitragen da sind aber sicher auch Nutzer hier am Start.
Aktuell gibt es eine neue Codeversion die beispiesweise einen Bug bei der Drehzahlmessung behebt, der beim Jeti-Protokoll aufgetreten ist. Dort wurde immer der Wert 1000 angezeigt, was von einem Testwert im Code verursacht wurde.
Ich hoffe das Projekt entwickelt sich noch weiter denn es bietet wirklich viele Möglichkeiten für viele verschiedene TM-Protokolle.

Hier der Ordnung halber noch der Link zur Projektseite:
https://github.com/openXsensor/openXsensor/wiki/OXS_Build_Vario
Es gibt zwar in einem anderen Forum eine Seite, wo auch der Entwickler unterwegs ist und Probleme schnell löst, aber es soll ja doch einige Menschen geben, die des Angelsächsischen nicht so mächtig sind.
http://openrcforums.com/forum/viewforum.php?f=86

Gruß
Onki
 

kalle123

User
Schön, das du den thread hier aufgemacht hast. ;)

Bin schon lange mit oXs unterwegs. FrSky und MPX mit Vario, Strom, Spannung, Drehzahl und GPS.

Es lohnt sich, sich mit oXs zu beschäftigen!

Grüße KH
 
Hallo,

ich hab mir vor Jahren ein Vario mit einem MPX4115A Drucksensor für die FrSky D8 Serie gebaut. Ich verwende für
die Datenübertragung allerdings ein eigenes Protokoll innerhalb vom Frsky Telemetrie Protokoll. Die eigentliche Berechnung
des Variosignals wird über einen analogen Differenzierer erledigt und dann mit einem PIC 12F683 gemessen und gefiltert. Mit dieser Methode
erreiche ich ein schnelles Variosignal (schnelle Sprungantwort). Zudem ist die Schwankungsbreite vom Variosignal verglichen mit Digitalsensor
basierenden Varios sehr klein. Die Daten (Serout) Höhe, Vario und Akkuspannung gehen dann in die serielle Schnittstelle vom D8R Receiver.

Gruss Micha
 

Anhänge

  • vario_new_1.asc.pdf
    14,9 KB · Aufrufe: 562

onki

User
Hi Micha,

das hat aber nix mit dem OXS zu tun.
Oder hast du vor den Sensor auf OXS zu portieren?

Ich persönlich verzweifle gerade etwas mit der Sequenzerfunktion.
In meiner FuncubXL soll OXS auch die Steuerung der Beleuchtung übernehmen aber ich bekomme es einfach nicht richtig zum laufen.
Der 3V3 Arduino liefert mir problemlos die entsprechenden Signale, ich hab aber noch keine gescheite Power-LED Konstantstromquelle (Fertigbaustein) gefunden die diese TTL-Signale vernünftig akzeptiert.
Nutze zur Zeit Bausteine auf Basis des XL 4001 und dessen Enable-Eingang zur PWM Steuerung. Die Logik ist invers (Hi = Aus) was ja in OXS nur eine etwas nervige Fingerübung ist. Jedoch "glimmen" die Power LEDs noch, wenn sie "abgeschaltet sind.
Ich nutze die 6S Versorgung über den Akku über einen Stepdown-Wandler auf rund 12V (hab beim ACL 3 weiße LED in Serie daher benötige ich über 10V Versorgung).

Hat jemand mit OXS und Power LEDs schon Erfahrung gesammelt und kann einen LED-Treiber (für 350mA und 700mA LEDs empfehlen)?

Gruß
Onki
 

onki

User
Hallo Kalle,

Die Sequenzerfunktion hab ich mir soweit schon eingetrichtert und das Ganze funktioniert auch schon prima (ACL/Beacon/Posilicht/Landelicht), wenn ich einfache LED mit Vorwiderstand dranhänge.
Nur suche ich noch vernünftige, per TTL-Signal steuerbare LED-Konstantstromquellen. Daran hapert es noch etwas. Die bisher von mir getesteten sind leider nicht so ganz toll geeignet.
Es gibt in der Bucht welche von Anvilex, die basieren aber auf einer analogen Dimmung und das ist bei 2,5V Endspannung etwas blöd.
Die auf dem XL4001 basierenden haben umgekehrte Logik was auch etwas unglücklich ist.
Die im vorigen Projekt verwendeten sind leider nicht mehr erhältlich. Worauf die Basierten hab ich gerade nicht auf dem Schirm.
Klassische Vorwiderstände möchte ich wegen der zu verbratenden Leistung nicht einsetzen.

Ich überlege mir gerade ob ich nicht mal einen Magazinbeitrag dazu mache wenn ich Zeit und Muse finde. Damit könnte man ggf. bei einigen Anwendern die Hemmschwelle etwas senken.
Programmierer bin ich keiner, daher kann ich zum Projekt selbst auch nix beitragen.

Gruß
Onki
 
Hallo zusammen,

ohne zu wissen, dass es OpenXSensor gibt, habe ich seit einiger Zeit etwas vergleichbares, was auf Basis eines AtMega328PB auf einem eigenen Board, auch so einiges Messen und Steuern kann:

- beliebig viele Temperatursensoren
- 2 x 3-zellige Akkus
- 2 x Drehzahl
- 2 x Strom +-30A
- generelle I2C-Schnittstelle
- 2 x PPM-Out
- 2 x PWM/Dir-Out für VNH2S30
- Multiswitch über I2C
- LED-Strang mit bis zu 128 RGB-Leds (WS2812-Protokoll)
- I2C-Led-Modul für andere Beleuchtungseffekte

Das ganze ist hauptsächlich für den Schiffsmodellbau ausgelegt, denn das Modul ist, obwohl in SMD, nicht super klein ;-)
 

kalle123

User
Dann setzte ich hier mal ein Bild aus 2016 von einem oXs Equipment von mir rein.

Modular aufgebaut. Kann also nur mit einem Vario fliegen, oder schließe an das Vario noch das GPS Modul an oder flieg nur mit Strom/Spannungsüberwachung.

Inzwischen nutze ich kleiner GPS Module ;) So, wie auf dem Bild, Kosten ~ 30€

Grüße KH


9k9hpXal.png
 
Hallo zusammen,

ich habe einen openXsensor (für Jeti) für einen alten Methanoler gebaut auf der Basis vom Arduino Pro Mini 5V.
folgende Messwerte habe ich realisiert:

- Spannung das Glühakkus (1S NiMh) Direkt angeschlossen
- Glühstrom über 5A Hallsensor Typ: ACS712 / 5A
- verbrauchte Kapazität Glühakku
- Spannung des Empfänger LiPos (Empfänger wird hinter einem 5V BEC betrieben) Anschluß über Spannungsteiler
- Drehzahl über Magneten in der Spinner Rückplatte und einem Hallsensor Typ: TLE4905L

Das ganze sieht schon gut aus und funktioniert auch super:
Datei_001.jpg

Aktuell habe ich allerdings ein Problem, die Speicherung der mAh soll auch möglich sein im eeprom.
Diese Funktion hätte ich gerne, aber bei mir fangen die mAh nach Aus und erneuten Einschalten wieder bei 0 mAh an.
Hat das mit der Speicherung schon einer geschafft?

Viele Grüße
Gunnar
 

onki

User
Hallo Gunnar,

Damit hab ich mich auch schon beschäftigt und bin noch zu keiner Lösung gekommen.
Wenn man den FlowSensor mit EEPROM verwendet, werden die Restmengen gespeichert. Das bedeutet es sollte grundsätzlich funktionieren.
Soweit ich weiß wird immer nur alle paar Sekunden gespeichert, wenn keine Veränderung mehr eintritt. Vielleicht liegt es daran.
Lade dir noch die neueste Version herunter, da du laut Dispay auch noch den 1000rpm Bug hast (Festwert im Code vergessen).

Gruß und ein schönes WE

Onki
 

onki

User
Hi Kalle,

wieso? Der Wert für die Kapazität ist doch global und wird sicher nicht protokollspezifisch im Speicher abgelegt.
Daher wäre es toll, wenn es gelingt, dass der ermittelte Wert bei Aktivierung der EEPROM-Funktion korrekt gespeichert und beim Neustart übernommen werden würde.
Noch genialer hingegen wäre die Handhabung wie beim UniSens-E wo die Rücksetzung noch feiner festgelegt werden kann (Nie, immer, Auto bei neuem Akku).
Von all dem Lua-Zeug halte ich nicht viel auch wenn viele es über den grünen Klee loben. Es war schon immer blöd Firmwareunzulänglichkeiten mit externer Software zu lösen.

Gruß
Onki
 

kalle123

User
Onki, wolltest du die Stromwerte jetzt in oXs speichern?

Na gut, ich bin ja bei der Diskussion in openrcgorums dabei. Nur m.E. soll oXs Sensorwerte liefern und solche speziellen Wünsche können dann vom Sender geleistet werden. Ob LUA oder wie auch immer. Ich hab persönlich keine Ahnung von LUA, nur es klappt halt einwandfrei.

Welche Möglichkeiten die JETI Sender da bieten, Null Ahnung. Meine verbliebene MPX Royal Pro kann das nicht, halt veraltet. Daher haben wir auch die "Klimmzüge" gemacht und die ganze MPX Telemetrie mittels Konverter auf die Taranis konvertiert.

Nix für ungut - KH
 
Hallo,

es geht ja um ein oXs Problem.
Der oXs bietet ja die Funktion im Programm an, man kann in deroXs config die eeprom Speicherung einschalten:
// --------- 8 - Persistent memory settings --------- ( see also oXs_config_advanced.h - used mainly when a flow sensor is connected )
#define SAVE_TO_EEPROM YES


Dann kann man in der advanced config noch definieren, welchen Digital Eingang man für den Reset Schalter nutzen möchte:
// --------- 8 - Persistent memory settings ---------
#define PIN_PUSHBUTTON 2 // default is 10 but my own device is 2


Der Reset Schalter funktioniert bei mir, ich kann im laufenden Betrieb die Werte für die Kapazität wieder nullen, nur die Speicherung funktioniert bei mir leider nicht.
Nach Aus und wieder Einschalten das Sensors fängt er wieder bei Null an.
Die SM Modellbau Sensoren kann man z.B. konfigurieren, was sie machen sollen (Nie, immer, Auto bei neuem Akku), dass wäre natürlich das Optimum.

Eventuell wäre ein Workaround ein LUA Programm, damit habe ich bisher nichts gemacht.

@Onki, das mit dem Festwert Bug hatte ich behoben, hier steht ja der Hinweis:
- * fieldValue = 1000 ;
* dataType = JETI22_0D ;
https://github.com/openXsensor/openXsensor/commit/41bad8c3c159cee54301fa9c76ad825d53790e6e

Viele Grüße
Gunnar
 
Hallo Gunnar,

Damit hab ich mich auch schon beschäftigt und bin noch zu keiner Lösung gekommen.
Wenn man den FlowSensor mit EEPROM verwendet, werden die Restmengen gespeichert. Das bedeutet es sollte grundsätzlich funktionieren.
Soweit ich weiß wird immer nur alle paar Sekunden gespeichert, wenn keine Veränderung mehr eintritt. Vielleicht liegt es daran.
Lade dir noch die neueste Version herunter, da du laut Dispay auch noch den 1000rpm Bug hast (Festwert im Code vergessen).

Gruß und ein schönes WE

Onki

Hallo Onki,

es hat etwas gedauert, ich habe nochmal mit dem aktuellen Programm von vorne angefangen.
Ich hatte doch schon einiges geändert, diese Änderungen musste ich erst einmal alle in dem aktuellen Programm durchführen und dann auf den Arduino flashen.
Leider ist das Resultat das selbe, die Kapazität fängt noch immer bei 0 mAh an, wenn man den Sensor aus und wieder einschaltet.

Diese Änderungen musste ich durchführen, damit mein Sensor so funktioniert, wie ich das möchte:
oXs_config_basic.h
Zeile 23 #define PROTOCOL JETI // select between FRSKY_SPORT , FRSKY_HUB , FRSKY_SPORT_HUB , MULTIPLEX , HOTT, JETI
Zeile 71 #define FIRST_BARO_SENSOR_USE BMP280 // select between NO_BARO , MS5611, GY86 , BMP085 , BMP180 , GY87, BMP280
Zeile 94 #define NUMBEROFCELLS 1
Zeile 99 #define ARDUINO_MEASURES_A_CURRENT YES
Zeile 105 #define CALCULATE_RPM YES
Zeile 108 #define SAVE_TO_EEPROM YES
Zeile 62 #define VOLTAGE_SOURCE VOLT_2 // select between VOLT_1, VOLT_2, VOLT_3 , VOLT_4, VOLT_5 , VOLT_6
Zeile 63 //#define TEMPERATURE_SOURCE NTC // select between MS5611 and NTC

oXs_config_advanced.h
Zeile 116 //#define USE_INTERNAL_REFERENCE // uncomment this line if you use 1.1 volt internal reference instead of Vcc (voltage divider mst be used to reduce voltages to 1.1 volt max)
Zeile 118 #define REFERENCE_VOLTAGE 5022 // set value in milliVolt; if commented, oXs will use or 1100 (if internal ref is used) or 5000 (if internal ref is not used)
Zeile 121 #define PIN_VOLTAGE 0 , 1 , 8 , 8 , 8 , 8 // Fill 6 values; set to 0 up to 7 for analog pins A0 up to A7 ; set the value to 8 for the voltage(s) not to be measured.
Zeile 122 #define RESISTOR_TO_GROUND 0 , 10 , 10 , 10 , 0 , 18 // set value to 0 when no divider is used for a voltage; can contains decimals
Zeile 123 #define RESISTOR_TO_VOLTAGE 0 , 10 , 22 , 27 , 0 , 47 // set value to 0 when no divider is used for a voltage; can contains decimals
Zeile 124 #define OFFSET_VOLTAGE 0 , 0 , 0 , 0 , 0 , 0 // optionnal, can be negative, must be integer, in principe in mv
Zeile 125 #define SCALE_VOLTAGE 1.0 , 1.0 , 1.0 , 1.0 , 1.0 , 1.0 // optionnal, can be negative, can have decimals
Zeile 143 #define MVOLT_AT_ZERO_AMP 2526 // in millivolt
Zeile 143 #define MVOLT_PER_AMP 135 // in milliVolt per Amp
Zeile 159 #define PULSES_PER_ROTATION 4
Zeile 162 #define PIN_PUSHBUTTON 2 // default is 10 but my own device is 2

oXs_out_jeti.cpp
Zeile 437 * fieldValue = currentData->consumedMilliAmps.value ; // mAh with 0 decimals
Zeile 438 * dataType = JETI14_0D ;
Zeile 749 mergeLabelUnit( textIdx, "Glueh NiMh", "V" ) ;
Zeile 794 mergeLabelUnit( textIdx, "Empf LiPo", "V" ) ;
Zeile 821 mergeLabelUnit( textIdx, "Glueh Strom", "A" ) ;
Zeile 824 mergeLabelUnit( textIdx, "Kapazitaet", "mAh" ) ;
Zeile 880 mergeLabelUnit( textIdx, "Drehzahl", "UpM" ) ;

Datei_001 (1).jpg

Viele Grüße
Gunnar
 

I3uLL3t

User
Hi,
Heute habe ich dann auch endlich mal mein erstes OXS Vario in 5min zusammengelötet, 10min einrichten an der Funke...WOW!!!!
Echt krass wie einfach und gut das ding funktioniert. Geflogen bin ich damit noch nicht aber ich bin erstaunt, das eine DIY lösung so easy und einfach funktioniert.
Als nächstes werde ich mir die Einzelzellenüberwachung einbauen, mal gucken ob das auch hin haut.

Wenn ich mir jetzt, nur als Beispiel, einen zweiten Arduino mit der Einzelzellenüberwachung baue, könnte ich denn dann einfach in den Smart Port mit rein hängen? Ja oder? Ist ja ein Bus.

Gruß Marcel
 

kalle123

User
Hi,
Heute habe ich dann auch endlich mal mein erstes OXS Vario in 5min zusammengelötet, 10min einrichten an der Funke...WOW!!!!
Echt krass wie einfach und gut das ding funktioniert. Geflogen bin ich damit noch nicht aber ich bin erstaunt, das eine DIY lösung so easy und einfach funktioniert.
Als nächstes werde ich mir die Einzelzellenüberwachung einbauen, mal gucken ob das auch hin haut.

Wenn ich mir jetzt, nur als Beispiel, einen zweiten Arduino mit der Einzelzellenüberwachung baue, könnte ich denn dann einfach in den Smart Port mit rein hängen? Ja oder? Ist ja ein Bus.

Gruß Marcel

Das Bild in #8 hast du gesehen? ;)

Gruß KH
 

onki

User
Hallo,

OxS hat den Vorteil, für nahezu alle Systeme offen zu sein, auch wenn es aus der OpenTX Ecke kommt (der ich nicht angehöre).
Ich habe mehrere Sensoren hiervon im Einsatz und bin sehr zufrieden.
Es gibt aber auch insbesondre für Jeti-User ein schönes Sensorprojekt, das mehrere Sensoren auf einem Arduino-Board vereinbart.
https://github.com/nightflyer88/Jeti_VarioGPS-Sensor
Der Vorteil dieses Projektes ist die Auswahl bzw. Aktivierung der Sensortypen über die Jetibox. Man braucht also nicht wie bei OxS für jede Sensorkombi ein eigenes HEX-File zu kompilieren.
Aktuell wird an einer neuen Version gearbeitet, die neben der Unterstützung des EX-Bus (das ist nicht das Fahrzeug der ehemeligen Freundin;)) auch TEK kann, allerdings über einen zus. Speedsensor bzw. GPS (was ich als nicht wirklich zielführend ansehe). TEK geht für mein Verständnis am einfachsten mit einer entsprechenden TEK-Düse. Die durch die TEK-Düse verfälschte Höheninformation kann bei Bedarf mit einem zusätzlichen Höhensensor korrekt ausgegeben werden. So wird es bei OxS ja auch gemacht.
Hinsichtlich EX-Bus Unterstützung bei OxS bin ich skeptisch weil der Fokus , wie schon erwähnt, eher bei OpenTX liegt.

Ich persönlich kann den Jeti-Einzelsensoren nichts abgewinnen und setze sie auch nicht ein, da dies wohl eher eine Maßnahme zur Steigerung des Expander-Verkaufs sein soll;).

Gruß
Onki
 
Ansicht hell / dunkel umschalten
Oben Unten