ExpressLRS
- Ersteller simon_123
- Erstellt am
Entfernung kannst Du mit einem calculated sensor darstellen. EdgeTX rechnet genauso gut wie es das GPS intern macht. Bezugspunkt ist die Position des ersten GPS Fix. Funktioniert bei mir ohne Probleme. Beispiel:
Name "GPdi" ist frei erfunden. Wenn Du 2D Entfernung haben willst, dann Alt sensor freilassen, ansonsten für 3D Entfernung (Schrägentfernung) Deinen Baro altitude Sensor einfügen. Wenn Du die Entfernung auch loggen wilst, nicht vergessen etwas runter scrollen und Logs anschalten.
Schaut dann so aus:
Name "GPdi" ist frei erfunden. Wenn Du 2D Entfernung haben willst, dann Alt sensor freilassen, ansonsten für 3D Entfernung (Schrägentfernung) Deinen Baro altitude Sensor einfügen. Wenn Du die Entfernung auch loggen wilst, nicht vergessen etwas runter scrollen und Logs anschalten.
Schaut dann so aus:
Zuletzt bearbeitet:
glipski
User
Danke, wieder was gelernt
kalle123
User
Wenn ich dich recht verstehe, also diese hier
aus https://github.com/ExpressLRS/ExpressLRS/blob/master/src/lib/CrsfProtocol/crsf_protocol.h
Gruß KH
kalle123
User
Dann noch hier zu. Wann wurde (bei welcher ELRS Version) die Änderung gemacht, wenn du das wissen solltest?
Ich hample ja noch immer mit den fehlenden Baro Werte in Ardupilot rum.
Gruß KH
Genau die.
Ich bin nicht gut in Geschichte, aber wir können Source Code und die Historie dazu anschauen. Vor ca. 2 Jahren wurde native baro implementiert.
Blaming ExpressLRS/src/lib/Baro/devBaro.cpp at 57cf9d78bfb1fda6a70678044967892176cf27c4 · ExpressLRS/ExpressLRS
STM32/ESP32/ESP8285-based High-Performance Radio Link for RC applications - Blaming ExpressLRS/src/lib/Baro/devBaro.cpp at 57cf9d78bfb1fda6a70678044967892176cf27c4 · ExpressLRS/ExpressLRS
github.com
Das war die Implementierung mit der ELRS Empfänger selbst zu Telemetriesensoren mutierten. Zu Beginn mit externem Drucksensor, später in z.B. RM ER6 und ER8 Empfängern mit direkt verbauten Drucksensoren. Es wurde von Anfang an die ID9 (Baro altitude und Vspd) versendet. ELRS hat nie die ID7 verwendet. Als die native Baro Implementierung in ELRS gemacht wurde gab es die ID9 schon. Es wäre ungeschickt gewesen die ID7, die ja nur Vspd kannte, zu nutzen. Probiere es aus. mit einem ER8(G)V wirst Du ALT und Vspd bekommen.
Wenn Du allerdings einem ELRS Empfänger über die serielle (CRSF) Schnittstelle ein ID7 Paket schickst, wird er das unangesehen weiterrouten. Ältere FCs haben das wahrscheinlich für die schon länger existierenden TBS Crossfire Sender getan. Die sind älter als der Zeitpunkt an dem TBS das CRSF Protokoll um ID9 erweitert hat. Einige der FC Firmwaren haben aber munter weiter ID7 verwendet, genauso einige Sender Firmware Hersteller. Auch Ethos konnte mit ID9 nichts anfangen. Hat Bertrand mit der 1.5.irgendwas geändert. Centerum censo, dass Probleme an der Quelle gelöst werden müssen und nicht irgendwo in der Verarbeitungskette geradegebogen werden, zumal in diesem Fall es ELRS nur schlecht machen könnte. Vspd aus der Telemetrie fischen und zu integrieren würde zu grausamen Altitudedriften führen.
Du suchst immer noch in der falschen Ecke. Es sind die Leute, die FC Firmware machen, die keine ID9 versenden und die Leute die alte Firmware auf ihren Sendern haben oder Sender mit Firmwaren betreiben, die ID9 nicht verstehen. iNav und offensichtlich auch AP versenden schlicht die ID9 nicht, sondern immer noch die alte ID7. iNav hat sogar geschrieben, dass sie ID9 wieder rausgenommen haben, um mit altem Zeug (sie meinen Sender) rückwärtskompatibel zu sein.
ELRS kann da nichts machen. ID7 wird nur durchgeroutet. Um ID7 zu übersetzen und daraus ID9 zu machen, müsste ELRS einen Wert für ALT selbst aus der Vspd errechen. Ist ziemlich unsinnig und wird auch nicht passieren. Du bist wenn Du mit AP zugange bist an der Quelle Deines Problems. Wenn iNav und AP ID9 schicken und die Sender ID9 dekodieren können (EdgeTX kann das, Ethos mittlerweile auch) ist das Problem weg.
Ab ELRS V2.5.0 sind die baro-Sensoren Alt und VSpd korrekt im CRSF drin
ja, das ist ID9 und vorher hat ELRS gar keine der 4 oben gelisteten Pakte verschickt, also auch nie ID7
kalle123
User
Franz, schön für ... ELRS. Bei INAV hab ich ja, nachdem was ich hier gehört habe, Hoffnung, das beide Baro Werte in näherer Zukunft auftauchen. Nur bei AP wurde mir das hier vor 2 Tagen von einem Entwickler dort gesagt
und hinzu kommt, das hier hatte ich unter AP anfangs des Jahres
und ein paar Tage später waren die beiden Baro Werte weg, dafür dann erschienen ROLL, PITCH und YAW.
NUR, ich weiß nicht, was da zwischen den beiden screenshots von mir geändert wurde. Hab ich meine ELRS Teile mit neuer FW versorgt? Könnte das deine Ursache sein.
DAS SOLL KEINE VERDÄCHTIGUNG GEGEN ELRS SEIN! Hab deswegen ja schon einen auf den Deckel bekommen.
Oh. sehe gerade, auf #1406 steht schon eine Antwort, die schaue ich mir jetzt erstmal in Ruhe an.
Grüße und nen schönen Abend noch - KH
Du hast AP mit einer neuen FW Version versehen, oder?
Roll, Pitch und Yaw sind in einem eigenen Paket, das für uns wenig Relevanz hat. Damit teilen die FCs die Lagewinkel der x-, y- und z-Achse der Plattform mit. Z.B für eine künstlichen Horizont im OSD. Das Versende des Pakets ID30 (glaube ich) hat AP wohl in dem Zeitraum aufgenommen.
Roll, Pitch und Yaw sind in einem eigenen Paket, das für uns wenig Relevanz hat. Damit teilen die FCs die Lagewinkel der x-, y- und z-Achse der Plattform mit. Z.B für eine künstlichen Horizont im OSD. Das Versende des Pakets ID30 (glaube ich) hat AP wohl in dem Zeitraum aufgenommen.
Meier111
User
Ich wollte für mein neues Projekt (kleiner Benziner) unbedingt Drehzahl und Temperatur haben.
Mit oXs_on_RP2040 ging das nicht. (Sonst ist oXs_on_RP2040 sehr gut.)
Also was mit Hilfe von "CapnBry" gebastelt. https://github.com/CapnBry/CRServoF/
Innerhalb des Programms wird bisschen geschummelt.
Der STM32 misst mir die Drehzahl und Temperatur, diese Werte werden in dem CRSF Protokoll an die Stelle von "Curr" und "Capa" verschickt.
RxBt | = | Volt1 |
Curr | = | Tmpr |
Capa | = | RPM |
Bat% | = | Volt2 |
Und im Sender wird das empfangene umdeklariert.
Sieht dann so aus:
Diese Methode ist zwar etwas umständlich, aber für verspielte (wie mich) eine schöne Denkaufgabe.
Wie ich schon mal geschrieben habe, bin weder Programmierer noch Informatiker.
Hab mich im Prinzip nur an dem frei verfügbaren Source-Code (CapnBry) bedient.
Der X8R ist hier nur zum Größenvergleich drauf:
8 * PWM, 1 * Schaltkanal (Zündbox ein/aus), und die vier Telemetrie-Eingänge (2 * Spannung, 1 * RPM, 1 * Temperatur).
RX ist ein RP3 von Radiomaster.
Super Projekt. Verallgemeinern kann man das so aber nicht. Sender und Empfänger der Daten müssen halt beide wissen wie das zu interpretieren ist. Ist leider keine mehrheitstaugliche Lösung. Schwer jedem zu erklären, der eine braucht unbedingt Capa und will dafür Alt opfern, Du verstehst was ich meine. Und mehr Sensoren werden es dadurch auch nicht.
Zuletzt bearbeitet:
.... hab ich gemacht als bisher stiller Mitleser und hier mein Feedback.
Absoluter Respekt und ein grosses Lob für diese Leistungen des ganzen Teams, läuft:
Radiomaster TX Pocket, ER8GV RX mit dem fertigen Kabel aus dem RX-Lieferumfang
und das SM-Modellbau Unisens-E im Hott-ESC-Mode.
Gruss Dietmar
P.S. Am Pocketsender ist ein zweites HF-Modul eingesetzt.
.... hab ich gemacht als bisher stiller Mitleser und hier mein Feedback.
Absoluter Respekt und ein grosses Lob für diese Leistungen des ganzen Teams, läuft:
Radiomaster TX Pocket, ER8GV RX mit dem fertigen Kabel aus dem RX-Lieferumfang
und das SM-Modellbau Unisens-E im Hott-ESC-Mode.
Gruss Dietmar
P.S. Am Pocketsender ist ein zweites HF-Modul eingesetzt.
Vielen Dank für das Feedback. Aber Vorsicht: ich habe das hier schon geschrieben. Für den 3.4-rc2 musste ich nach einem Review den Pin nochmal ändern. Wenn Du also 3.4-rc2 und spätere Versionen flasht, musst Du das Kabel ändern. Verdrahtet wird final mit TX, also das anderen mitgelieferte Kabel nehmen (das 4-polige) und GND/VCC/TX mit einer Servobuchse GND/VCC/Signal verbinden.
Sorry, aber TX zu nutzen war Projektwunsch
kalle123
User
@mha1
Ich will mich noch mal kurz melden. Habe mir das, was du zu meiner 'Sache' hier gesagt hast, durch den Kopf gehen lassen. Und ich weiß, ich nerve damit wohl etwas. Sorry! Aber ich hab hier auf meiner Seite ne ganze Masse probiert, um dahinter zu kommen, warum der Sender hier die beiden Baro Werte angezeigt hat, obwohl DAS ja eigentlich nicht passieren sollte/konnte.
Div. alte FW Versionen AP geflashed. Jetzt gerade bin ich beim ELRS TX Modul und beim RX Empfänger auf die 3.0.0 zurück. Hilft alles nix. Es ist zum Mäusemelken!
Dazu kommen noch die Punkte, dass ich mich recht wohl bei AP fühle, ich aber meine Schweissgut Nuris NICHT ohne Baro Werte akustisch auf dem Sender fliegen werde und die FCs alle! relevanten Telemetriedaten produzieren incl. Baro.
Aber mal eine Frage an dich, auf die ich bisher keine Antwort gefunden habe. Könnte man z.B. einen Matek PWM Empfänger mit Vario an einen FC über RX/TX anschliessen oder ist das eine reine serielle Schnittstelle zum upload von Firmware?
Dank dir und Gruß - KH
Ich will mich noch mal kurz melden. Habe mir das, was du zu meiner 'Sache' hier gesagt hast, durch den Kopf gehen lassen. Und ich weiß, ich nerve damit wohl etwas. Sorry! Aber ich hab hier auf meiner Seite ne ganze Masse probiert, um dahinter zu kommen, warum der Sender hier die beiden Baro Werte angezeigt hat, obwohl DAS ja eigentlich nicht passieren sollte/konnte.
Div. alte FW Versionen AP geflashed. Jetzt gerade bin ich beim ELRS TX Modul und beim RX Empfänger auf die 3.0.0 zurück. Hilft alles nix. Es ist zum Mäusemelken!
Dazu kommen noch die Punkte, dass ich mich recht wohl bei AP fühle, ich aber meine Schweissgut Nuris NICHT ohne Baro Werte akustisch auf dem Sender fliegen werde und die FCs alle! relevanten Telemetriedaten produzieren incl. Baro.
Aber mal eine Frage an dich, auf die ich bisher keine Antwort gefunden habe. Könnte man z.B. einen Matek PWM Empfänger mit Vario an einen FC über RX/TX anschliessen oder ist das eine reine serielle Schnittstelle zum upload von Firmware?
Dank dir und Gruß - KH
Welchen Matek PWM Empfänger meinst Du? Den Matek ELRS 2.4G PWM Vario RX? Den kannst Du ziemlich sicher nicht an eine FC anschließen. Der Matek PWM mit Vario ist aus dem Matek PWM Converter mit Vario und einem separaten ELRS Empfänger zusammengebastelt. Der ELRS Empfänger sitzt Huckepack auf dem Converterboard und ist mit dem Converterboard über die CRSF Schnittstelle verbunden. Die CRSF Schnittstelle ist deshalb nicht weiter verfügbar. Aus Sicht des ELRS Empfängers ist da schon eine FC (das Converterboard) angeschlossen. Wenn auf dem Converterboard noch eine serielle Schnittstelle ist, dann sicher nur zum Flashen des Converterboards.
Die Radiomaster ER6 und ER8 Varioempfänger haben das alles auf einer Platine, die CRSF Schnittstelle mit der man den Empfänger an eine FC anbinden kann ist herausgeführt. So einen müsstest Du an eine FC anschließen können. Damit bekommst Du Vspd und ALT, aber nur wenn die FC selbst kein Baropakete (ID7 in diesem Fall) schickt. Der ELRS Empfänger priorisiert externe Barodaten vor den internen. Sobald Du ihne extern mit ID7 oder ID9 fütterst, werden die internen Barodaten nicht verwendet. Um das zu umgehen gibt es zwei Möglichkeiten. Entweder Du schaffst es die FC dazu zu bewegen selbst keine Barodaten zu schicken (vielleicht per Konfiguration - ob das möglich ist musst Du selbst rausfinden) oder Du änderst den ELRS Barocode so, dass die Priorisierung der externen Daten entfällt.
Kannst Du Dich auf das verlassen was ich sage? Eher nicht, da ich werde die Matek Empfänger, noch AP oder iNav im Detail kenne.
TornadoRot
User
Hattest du da vielleicht yaapu laufen? Dann bekommst du die Baro Werte in der Telemetrie.
Mit ELRS 3.4 lassen sich Sbus und HoTT (noch) nicht gleichzeitig nutzen, oder? (Die Idee wäre dann, AP über das HoTT-Telemetrie Protokoll anzubinden)
kalle123
User
Klare Aussage! Dank dir.
Und das ist also ein sehr ungewisses Terrain ...
OK, no chance!
Aber was mich am meisten bei der Sache piesackt, ich hab 1x 'Alt' und 'VSpd' als ausgedruckten screenshot von der Sendertelemetrie. Wenn ich das ja nur mal flüchtig so aus dem Augenwinkel gesehen hätte
Gruß KH
kalle123
User
yaapu ist da so eine Sache. Von Alex hab ich auf meine Anfrage dazu folgende Antwort erhalten
Du hast die Baro Werte dann nicht wie reale Werte auf dem Sender, sodass du 'Alt' bzw. 'VSpd' z.B. auf einen Schalter legen kannst und einen Audioausgabe generieren kannst. So interpretiere ich zumindest seine Aussage ....
Meine mich zu erinnern, dass war zu den Anfängen von yaapu mal etwas anders.
cu KH
Zuletzt bearbeitet:
FlyingNuri
User
Ardupilot mit ExpressLRS sendet überhaupt kein VSpd. Weder mit ID7 noch mit ID9. Die einzige Möglichkeit ist derzeit die Verwendung des Yaapu-Script und einschalten der Passthrough Telemetrie. Dann ist VSpd verfügbar, das Yaapu-Script muss dafür halt laufen, damit die Passthrough Telemetrie "entpackt" wird.
Bei Ardupilot mit FrSky Empfänger bzw. S.Port sieht es etwas anders aus. VSpd kommt dort mit SERIALx_PROTOCOL = 4, weil ich die Umsetzung damals angestoßen hatte, weil halt nicht jeder das Yaapu-Script nutzen wollte. Man kann aber auch mit SERIALx_PROTOCOL = 10 die Passthrough Telemetrie mit dem Yaapu-Script nutzen, VSpd ist dann auch verfügbar.
Bei Ardupilot mit FrSky Empfänger bzw. S.Port sieht es etwas anders aus. VSpd kommt dort mit SERIALx_PROTOCOL = 4, weil ich die Umsetzung damals angestoßen hatte, weil halt nicht jeder das Yaapu-Script nutzen wollte. Man kann aber auch mit SERIALx_PROTOCOL = 10 die Passthrough Telemetrie mit dem Yaapu-Script nutzen, VSpd ist dann auch verfügbar.