ExpressLRS
- Ersteller simon_123
- Erstellt am
ExpressLRS - Open Collective
ExpressLRS aims to provide the best completely open, high refresh radio control link while maintaining a maximum achievable range at that rate with low latency.
opencollective.com
FrSky arbeitet an einem (ab)geschlossenen System (ab ACCESS u folgende Protokolle)- eine Implementierung derer (BUS)Protokolle auf (OpenSource) RX Seite wird nach meiner Info nicht toleriert. (OpenSource SENSOREN schon)
Unabhängig davon, dass eine nachhaltige Lösung mit dem ELRS Steer abgestimmt sein müsste.
P.S: Ich war zu Anfang auch der Meinung FrSky Telemetry auf ELRS würde Sinn machen - aber nur weil ich Sensoren (bzw. ein FrSky System hatte). Die Lösung dazu ist jedoch eine andere, nämlich den Komplettumstieg auf OpenSource zu wagen (Funke mit EDGE, RM oder BETAFPV Empfänger sowie zur Hott Telemetry, oXS od. auf die Verfügbarkeit von CSRF/ELRS kompatiblen Sensoren zu warten)
Klar, alles was HoTT Telemetrie spricht geht, z.B. auch YGE Regler. Hier findest Du eine Liste der Sensoren, die getestet wurden: https://github.com/ExpressLRS/ExpressLRS/pull/2408#issue-1899739754. Wird alles auch geflogen.
glipski
User
Die sm-Sensoren funktionieren einwandfrei mit ELRS / HoTT.
Das einzige „Manko“ ist, dass das CRSF - Telemetrieprotokoll etwas eingeschrängt ist in Bezug auf die übertragenen Werte, z.B. „GPS-Entfernung“ nicht kennt und deshalb beim GPSLogger 3 nicht überträgt. Das ist aber eine Einschränkung von CRSF / ELRS und geht auch nicht bei einem oXs-RP2040 GPS-Sensor.
Eas stimmt, ich stelle mal ein Liste der Telemetrieparameter zusammen, die CRSF übertragen kann. M.M. nach sind aber die wichtigsten dabei, Einigen werden vielleicht Temperaturen und Drehzahlen fehlen.
Dein Beispiel GPS Entfernung läßt sich aber leicht mit EdgeTX Bordmitteln lösen. EdgeTX kann die 3D Entfernung aus GPS Position und Höhe errechnen und als "calculated" Sensor, der sich wie jeder andere Sensor nutzen läßt, darstellen.
- model settings, telemetry, add new
- Sensornamen vergeben, z.B. GPdi, type calculated, formula distance
- GPS sensor "GPS"
- Alt sensor "ALT"
Es wird dann die Entfernung zwischen home point (erste gültige GPS Position) und der aktuellen GPS Position des Modells zyklisch errechnet.
Wenn Du GPdi auch in den Logs haben möchtest, dann Logs anhaken nicht vergessen.
Beispiel mit calculated sensor GPdi: (RQly Minimalwert über den ganzen Flug übrigens 96%).
Zuletzt bearbeitet:
Liefern kann CRSF neben den Daten der HF Strecke folgende Telemetriewerte, die auch von HoTT Sensoren befüllt werden. Die Liste ist nicht besonders lang, aber das wichtigste ist dabei. Dass die Liste nicht alles umfaßt, was die HoTT Telemetrie liefern könnte, liegt daran, dass CRSF nicht mehr Telemetrie definiert. Dies gilt wie @glipski richtig angemerkt hat auch für oXs usw. Der Grund dafür ist nachvollziehbar. Jedes Telemetriepaket mehr auf dem dwonlink wirkt sich auf die packet rate und Latenz des uplinks aus.
Antriebsdaten
Antriebsdaten
- RxBt: wenn ein HoTT Sensor, z.B. GAM, EAM oder ESC Spannung liefern können, wird diese übertragen, ansonsten, wenn der Empfänger das kann die interne oder am Empfänger direkt gemessene externe Spannung
Curr: Strom - Capa: Kapazität
- Bat%: Batteriefüllstand, wird von einigen HoTT Sensoren, z.B. GAM aus der gemessenen Spannung errechnet
- GPS: GPS Latitude/Longitude
- GSpd: GPS Geschwindigkeit
- Hdg: GPS Heading
- ALT: GPS Höhe (MSL)
- Sats: GPS Anzahl Satelliten
- (GPdi: GPS distance läßt sich mit EdgeTX calculated Sensor "distance" darstellen)
- Vspd: Vario
- ALT: Baro Höhe (AGL)
- Pitch, Roll, Yaw: Lagewinkel, werden von HoTT nicht benutzt, sichtbar nur mit FC die das liefert
@mha1
besten Dank für die FW-Dateien und die Schaltpläne. Meine 3 Empfänger sind jetzt geflasht und auf Hott Telemetry gestellt.
Die Diode ist wahrscheinlich dafür da, die RX-Signale abzusperren, da ja beide Signale über einen Draht laufen. Stimmt*s?
Schade, dass ich die Firmware nicht selbst habe erzeugen können, aber der ELRS-Configurator zeigt immer noch Fehler an, auch nach Neuinstallation.
Gruß
Bernd
besten Dank für die FW-Dateien und die Schaltpläne. Meine 3 Empfänger sind jetzt geflasht und auf Hott Telemetry gestellt.
Die Diode ist wahrscheinlich dafür da, die RX-Signale abzusperren, da ja beide Signale über einen Draht laufen. Stimmt*s?
Schade, dass ich die Firmware nicht selbst habe erzeugen können, aber der ELRS-Configurator zeigt immer noch Fehler an, auch nach Neuinstallation.
Gruß
Bernd
Wolfgang Fleischer
Vereinsmitglied
Ich hatte meine TX16S zerschossen, siehe hier.
Jetzt läuft sie wieder aber mit einigen Problemen.
LUA ELRS läuft nicht.
Wahrscheinlich ist die HF FW des Modul beschädigt, denn ich kann CRSF nicht auswählen, nur MULTI.
Da das LU ELRS nicht läuft, kann ich keine WiFi Verbindung herstellen.
Ich habe deshalb mit dem ELRS Konfigurator ein Update direkt auf die Anlage gemacht, das war auch erfolgreich.
Der Fehler ist aber nach wie vor vorhanden.
Hat jemand einen Ratschlag ?
Jetzt läuft sie wieder aber mit einigen Problemen.
LUA ELRS läuft nicht.
Wahrscheinlich ist die HF FW des Modul beschädigt, denn ich kann CRSF nicht auswählen, nur MULTI.
Da das LU ELRS nicht läuft, kann ich keine WiFi Verbindung herstellen.
Ich habe deshalb mit dem ELRS Konfigurator ein Update direkt auf die Anlage gemacht, das war auch erfolgreich.
Der Fehler ist aber nach wie vor vorhanden.
Hat jemand einen Ratschlag ?
Wolfgang Fleischer
Vereinsmitglied
Das war's vielen Dank !
Es wird eine Baudrate von 400K vorgegeben, ist das korrekt ?
Das ist in den meisten Fällen ok. Mit 400kBaud kann EdgeTX ELRS Module mit Daten für bis zu 333Hz packet rate versorgen. 921kBaud reichen für alle packet rates die ELRS kann, also bis 1kHz packet rate. 921kBaud ist deshalb die universellste Baudrate und sollte eigentlich Voreinstellung sein. Natürlich tun es 400kBaud auch, wenn Du mit max. 333Hz packet rate fliegst. Und für uns Flächenflieger mit PWM Empfängern kommen ja ohnehin nur 100Hz oder 333Hz packet rate wirklich in Frage.
