Stimmt so natürlich nur bzgl. fertiger plug&play Telemetrie, sei es bereits im Emfänger verbaut (Vario, Spannung) oder als käuflicher Sensor. Per openXsensor ist fast alles möglich und auch ohne grossen Aufwand zu recht geringen Kosten machbar.
ELRS 2.4 Vorteile
- Ersteller defender67
- Erstellt am
wimalopaan
User
OpenXSensor kann aber eigentlich auch nur die Sensortypen weiterleiten, in in CRSF definiert sind. Z.B. RPM oder Temperatur. Es sei denn OpenXSensor macht ein tunneling via CRSF 0x7f (ala ArduPilot) und ein Script entpackt das auf dem Sender.
Peter Stegemann
User
Du vergisst Linux auf dem Smartphone. Milliarden von Endusern benutzen es. Genauso koennte es hier kommen. Dafuer muesste nur passieren, was ich weiter oben beschrieben habe. Waere ich Multiplex, ich wuerde mir ueberlegen, hier mit meinem guten Namen einzusteigen.
BZFrank
User
Nachdem du mich anscheinend damit meinst - ok, ich bin dann mal weg. Noch frohes Vorteileverkünden.
ELRS wird dann interessant wenn ich ein Modul am meine Anlage stecken kann und die Empfänger die Sensoren wie z b unisens verarbeiten können. Am besten noch als Stabi Empfänger und vom Sender aus einstellbar. Das ganze pnp ohne löten. Geht das aktuell und wenn nicht ab wann geht das?
Torsten
Torsten
Spannung, Strom. Akkuverbrauch (über einige ESCs), baroHöhe, VSpd (sogarTEK, wenn man möchte), Temperatur, Drehzahl, GPS, Airspeed (über Differenzdrucksensor), Groundspeed (über GPS) . Was fehlt einem da noch? Ich selber brauche bis auf Vario und Spannungsmessung nichts weiter, habe aber auch nicht alle aufgelisteten selber durchprobiert, weil sie mich einfach nicht interessieren.
Voodoo-68
User
Stabi steht noch aus.
ELRS "spricht" Graupner Hott. Damit kannst Du auch den Unisens anbinden
geht mit 3.4. Unisens auf HoTT. Anstecken, Protokoll auswählen und los geht's. Geht z.B. mit RM ER6x, ER8x und dem SuperP
Georg Funk
Vereinsmitglied
Hott geht soweit ich es verstehe nur ab 3.4 und die ist im "Pre-Release, don't flash on anything important" Status. Die "nichttestwilligen"(wie ich) müssen uns also noch eine (absehbare) Zeit gedulden. Aber es geht vorwärts. Rom ist auch nicht an einem Tag erbaut worden.
... ich weiss nicht, ob das Fehlen eines Flächengyro-RX dem ELRS "angelastet" werden sollte.
In der bisherigen Technik entstehen die eigentlichen Gyrofunktionen erst >in< einem Empfänger oder als Anstecklösung nach dem Empfänger.
Insofern sehe ich die RX-Hersteller gefordert. Wenn das vom TX dann allerdings mit Einstellungen und Änderungen im fernen RX angesteuert werden soll, landet man bei neuen integrierten Telemetriefunktionen, die in der Steuerungssoftware plus GUI des Senders, jedoch nicht in der HF-ELRS-Ebene, zu suchen sind. So mein Verständnis.
Unabhängig davon wäre die dem ELRS, einem Open-Source-Funksystem, bisher bescheinigte hohe Aktualisierungsrate als Vorteil anzusehen.
In der bisherigen Technik entstehen die eigentlichen Gyrofunktionen erst >in< einem Empfänger oder als Anstecklösung nach dem Empfänger.
Insofern sehe ich die RX-Hersteller gefordert. Wenn das vom TX dann allerdings mit Einstellungen und Änderungen im fernen RX angesteuert werden soll, landet man bei neuen integrierten Telemetriefunktionen, die in der Steuerungssoftware plus GUI des Senders, jedoch nicht in der HF-ELRS-Ebene, zu suchen sind. So mein Verständnis.
Unabhängig davon wäre die dem ELRS, einem Open-Source-Funksystem, bisher bescheinigte hohe Aktualisierungsrate als Vorteil anzusehen.
Zuletzt bearbeitet:
wimalopaan
User
It is compatible with :
- The Multiplex receivers
- The Frsky receivers : D series (HUB protocol) and X series (Smart Port protocol).
- The Graupner receivers (Hott protocol)
- The Jeti receivers (EX protocol only)
Und wo steht da CRSF / ELRS?
Voodoo-68
User
wo hast Du denn die Liste her?
GitHub - mstrens/oXs_on_RP2040: version of openXsensor to be used on raspberry pi pico RP2040 (more protocols, more functionalities)
version of openXsensor to be used on raspberry pi pico RP2040 (more protocols, more functionalities) - GitHub - mstrens/oXs_on_RP2040: version of openXsensor to be used on raspberry pi pico RP2040...
github.com
da steht ne Menge mehr...
wimalopaan
User
wo hast Du denn die Liste her?
GitHub - mstrens/oXs_on_RP2040: version of openXsensor to be used on raspberry pi pico RP2040 (more protocols, more functionalities)
version of openXsensor to be used on raspberry pi pico RP2040 (more protocols, more functionalities) - GitHub - mstrens/oXs_on_RP2040: version of openXsensor to be used on raspberry pi pico RP2040...
da steht ne Menge mehr...
Ok, das war dann wohl ne alte Version ;-)
Aber selbst bei der neuen sehe ich nicht, wie z.B. Drehzahl über ELRS transportiert wird ...
Hier der Code-Abschnitt dazu:
bool dataAvailable(uint8_t idx) {
switch (idx) {
case CRSF_FRAMEIDX_BATTERY_SENSOR :
return fields[MVOLT].available || fields[CURRENT].available || fields[CAPACITY].available ;
case CRSF_FRAMEIDX_VARIO :
return fields[VSPEED].available ;
case CRSF_FRAMEIDX_ATTITUDE :
return fields[PITCH].available || fields[ROLL].available ;
case CRSF_FRAMEIDX_GPS :
return gps.gpsInstalled ;
//return gps.gpsInstalled || baro1.baroInstalled ; //gps.GPS_lonAvailable ; // gps.gpsInstalled || baro1.baroInstalled
case CRSF_FRAMEIDX_BARO_ALTITUDE :
return fields[RELATIVEALT].available ;
}
return false;
// to be continue with other frames/data if ELRS support them.
}
Copy von der openXsensor-Seite
openXsensor (oXs) on RP2040 board
For rc protocols : expressLRS / FRSKY (sport + Fbus) / HOTT / JETI Ex / JETI EXBUS/ MPX / FLYSKY / Futaba (SBUS2) / Spektrum (SRXL2)
oder habe ich da was übersehen oder missverstanden (könnte ja durchaus sein)??
wimalopaan
User
Ich denke: ja.
Du kannst an einen ELRS-Empfänger direkt Hott-Sensoren anschließen (ab 3.4), ODER Du kannst den oXs anschließen.
In beiden Fällen, kann der ELRS-Empfänger aber nur die Sensordaten transportieren, die ich oben gezeigt habe.
oXs kann direkt an einem Hott- oder S.Port-Empfänger weit mehr Sensordaten transportieren.
Du hast Recht, ELRS mit CRSF kann leider (noch) nicht alle gelisteten Telemetrie-Optionen. In der Doku hat mstrens die für das jeweilige Protokoll zutreffenden Telemetrie-Optionen aufgeführt. Für ELRS/CRSF findet sich da:
** ELRS/CRSF protocol **
******************************************************************************************************************
field measured in mesured and transmitted when transmitted as transmitted in
----- ----------- ---------------------------- -------------- ---------------
VOLT1 0.001V V1 pin is defined Volt 0.1V
VOLT2 0.001V=0.001A V2 pin is defined Current 0.1A
Capacity mAh V2 pin is defined (reset after power down) capacity mAh
VOLT3 0.001V V3 pin is defined not transmitted
VOLT4 0.001V V4 pin is defined not transmitted
Baro Alt cm a baro is installed (and SCL/SDA defined) Altitude dm
Vspeed cm/sec a baro is installed (and SCL/SDA defined) Vspeed cm/sec
if a MP6050 is installed, Vpeed use it too
GPS longitude GPS is installed (and GPS_TX, GPS_RX defined) longitude special format
GPS lat Same as above latitude special format
GPS speed cm/sec Same as above GPS ground speed 0.1 km/h
GPS course 0.01 degree Same as above heading 0.01 degree
GPS Alt cm Same as above; = alt above see level GPAS Alt m
Note : some handsets calculate a relative alt
GPS number of satelites Same as above (+100 when 3D fix) Num of satelites unit (+100)
GPS date YYMMDD0xFF Same as above not transmitted
GPS time HHMMSS0x00 Same as above not transmitted
GPS PDOP 0.01 ???? Same as above not transmitted
GPS bearing from home Same as above not transmitted
GPS distance from home Same as above not transmitted
GPS cumulative distance m Same as above not transmitted
RPM ????? RPM pin is defined not transmitted
Ads1115 0.001V (4X2) 1 or 2 Ads1115 installed +SCL/SDA defined Not transmitted currently
Remain Not measured ELRS field exist but is not used currently (one byte only = %)
Pitch degree MP6050 is installed (and SCL/SDA defined) pitch Rad (1/10000)
Roll degree Same as above roll Rad (1/10000)
Acc X 0.001g MP6050 is installed (and SCL/SDA defined) not transmitted
Acc Y 0.001g MP6050 is installed (and SCL/SDA defined) not transmitted
Acc Z 0.001g MP6050 is installed (and SCL/SDA defined) not transmitted
** ELRS/CRSF protocol **
******************************************************************************************************************
field measured in mesured and transmitted when transmitted as transmitted in
----- ----------- ---------------------------- -------------- ---------------
VOLT1 0.001V V1 pin is defined Volt 0.1V
VOLT2 0.001V=0.001A V2 pin is defined Current 0.1A
Capacity mAh V2 pin is defined (reset after power down) capacity mAh
VOLT3 0.001V V3 pin is defined not transmitted
VOLT4 0.001V V4 pin is defined not transmitted
Baro Alt cm a baro is installed (and SCL/SDA defined) Altitude dm
Vspeed cm/sec a baro is installed (and SCL/SDA defined) Vspeed cm/sec
if a MP6050 is installed, Vpeed use it too
GPS longitude GPS is installed (and GPS_TX, GPS_RX defined) longitude special format
GPS lat Same as above latitude special format
GPS speed cm/sec Same as above GPS ground speed 0.1 km/h
GPS course 0.01 degree Same as above heading 0.01 degree
GPS Alt cm Same as above; = alt above see level GPAS Alt m
Note : some handsets calculate a relative alt
GPS number of satelites Same as above (+100 when 3D fix) Num of satelites unit (+100)
GPS date YYMMDD0xFF Same as above not transmitted
GPS time HHMMSS0x00 Same as above not transmitted
GPS PDOP 0.01 ???? Same as above not transmitted
GPS bearing from home Same as above not transmitted
GPS distance from home Same as above not transmitted
GPS cumulative distance m Same as above not transmitted
RPM ????? RPM pin is defined not transmitted
Ads1115 0.001V (4X2) 1 or 2 Ads1115 installed +SCL/SDA defined Not transmitted currently
Remain Not measured ELRS field exist but is not used currently (one byte only = %)
Pitch degree MP6050 is installed (and SCL/SDA defined) pitch Rad (1/10000)
Roll degree Same as above roll Rad (1/10000)
Acc X 0.001g MP6050 is installed (and SCL/SDA defined) not transmitted
Acc Y 0.001g MP6050 is installed (and SCL/SDA defined) not transmitted
Acc Z 0.001g MP6050 is installed (and SCL/SDA defined) not transmitted
Zuletzt bearbeitet:
wimalopaan
User
Wie schon sagte: um weitere Sensordaten wie etwa RPM oder Temperatur zu transportieren, muss man ein eigenes EdgeTx erstellen, was diese neuen Sensortypen, die es eigentlich im CRSF nicht gibt, auswertet und anzeigen kann. ELRS transportiert Frame-Typen oberhalb von 0x40 schon, allerdings ist das dann eben non-standard.
Die andere Variante ist es, die Daten in einem Paket des Typs 0x7f zu verpacken und durch ein LUA-Skript (etwa: Yaapu) auszuwerten. So macht das ArduPilot. Deswegen dachte ich, das oXs das ggf. auch macht. Machts aber nicht.
wenn man die HoTT Telemetrie mit ELRS erweitern will, muss man EdgeTX und die ELRS Firmware erweitern. Der HoTT Busmaster sitzt in der ELRS Firmware. Gehört aber wieder nicht hier her. Kann man machen wenn, ist aber sicher kein Tipp für alle und würde deshalb gerade hier nicht empfehlen. Wie gesagt, wenn es ein/mehrere neue CRSF Pakete gibt werde ich die HoTT Implementierung in ELRS natürlich erweitern, so ganz offiziell mit release und so, mache das aber nicht als Bastellösung an der Spec vorbei.
Meier111
User
Bei meinem Benziner-Projekt halte ich mich nicht an die Regeln.
Im Flugzeug misst ein STM32 die Drehzahl, sendet den Wert per ELRS an den Sender als "capacity".
Im Sender wird der Wert "capacity" umdeklariert und angezeigt als "RPM".
Mein Trick ist also nur was für unartige.
Wird aber bestimmt nicht "ewig" nötig sein.
CRSF ist ja auch "open". Da wird man sich bestimmt noch was einfallen lassen.
(Ein paar freie 16bit Adressen wären schön: free1, free2, free3, u.s.w. Für die Bastler.)
ELRS ist noch jung.
In meinen Augen erst drei viertel Jahr alt.
Mache mir keine Sorgen um die Zukunft von ELRS.
So, wie sich Linux-Nutzer keine Sorgen um Linux machen.
Im Flugzeug misst ein STM32 die Drehzahl, sendet den Wert per ELRS an den Sender als "capacity".
Im Sender wird der Wert "capacity" umdeklariert und angezeigt als "RPM".
Mein Trick ist also nur was für unartige.
Wird aber bestimmt nicht "ewig" nötig sein.
CRSF ist ja auch "open". Da wird man sich bestimmt noch was einfallen lassen.
(Ein paar freie 16bit Adressen wären schön: free1, free2, free3, u.s.w. Für die Bastler.)
ELRS ist noch jung.
In meinen Augen erst drei viertel Jahr alt.
Mache mir keine Sorgen um die Zukunft von ELRS.
So, wie sich Linux-Nutzer keine Sorgen um Linux machen.
Ähnliche Themen
