ExpressLRS
- Ersteller simon_123
- Erstellt am
silberkorn
User
Hallo, ist jemand von euch schonmal in das Problem der 8285 basierenden RX mit 3.3.2 gelaufen dass die ab und zu während dem Betrieb Booten?
github.com
[PWM receiver Firmware] frequently lost control. · Issue #2548 · ExpressLRS/ExpressLRS
Current Behavior PWM receiver lost control irregularly. Once the receiver lost control, it will hold the last state for about 10 seconds and then regain control. Since it does not enter failsafe, i...
github.com
Hallo, ist jemand von euch schonmal in das Problem der 8285 basierenden RX mit 3.3.2 gelaufen dass die ab und zu während dem Betrieb Booten?
[PWM receiver Firmware] frequently lost control. · Issue #2548 · ExpressLRS/ExpressLRS
Current Behavior PWM receiver lost control irregularly. Once the receiver lost control, it will hold the last state for about 10 seconds and then regain control. Since it does not enter failsafe, i...
So wie ich das verstanden habe kann das mit den 8285 basierten PWM Empfängern (das sind üblicherweise die mit weniger als 6 Kanälen) passieren, wenn die PWM Frequenz weg von der Voreinstellung 50Hz auf höhere Frequenzen, z.B. 333Hz oder 400Hz gestellt wurde. Fehler ist verstanden und im maintenance branch behoben. Vielleicht gibt es ja noch eine 3.3.3 vor dem ersten 3.4 release candidate der aber auch schon kurz bevorsteht.
silberkorn
User
Das heisst das wird aus dem Maint. Branch auf jeden Fall dann in 3.4 wandern?
Seh ich irgendwo welcher RX welchen Chip hat?
Seh ich irgendwo welcher RX welchen Chip hat?
Ja, das ist dann auch schon im ersten release candidate der 3.4.
Wie findest Du raus ob ein Empfänger einen ESP8285 (ist eine ESP8266 Variante) und nicht einen ESP32 hat?
Näherungsweise: diese hier sind ESP32 Empfänger, also keine ESP8285. Bedeutet aber nicht, Empfänger die hier nicht gelistet sind automatisch ESP8285 sind.
1) Anyleaf 2.4GHz dual radio RX
2) BAYCKRC 2.4GHz Dual Core RX
3) BETAFPV SuperD 2.4GHz RX
4) BETAFPV SuperP 14Ch 2.4GHz RX
5) Generic ESP32 PWM Vario 2.4Ghz RX
6) Generic ESP32 2.4Ghz Franken RX
7) Generic ESP32 2.4Ghz Rx and VTx
8) Generic ESP32 True Diversity PA 2.4Ghz RX
9) Generic ESP32 True Diversity PA 2.4Ghz RX and VTx
10) Generic ESP32 True Diversity 2.4Ghz RX and VTx
11) Generic ESP32 True Diversity 16xPWM 2.4Ghz RX
12) Generic ESP32 True Diversity PA 14xPWM 2.4Ghz RX
13) GEPRC Dual Diversity 2.4GHz RX
14) HappyModel EP Dual 2.4GHz RX
15) HappyModel AIO 2.4GHz RX+VTX
16) iFlight 2.4GHz 250mW Diversity RX
17) RadioMaster ER6 2.4GHz Diversity+6xPWM RX
18) RadioMaster ER6-G 2.4GHz Diversity+6xPWM RX
19) RadioMaster ER6-GV 2.4GHz Diversity+6xPWM+Vario RX
20) RadioMaster ER8 2.4GHz Diversity+8xPWM RX
21) RadioMaster ER8-G 2.4GHz Diversity+8xPWM RX
22) RadioMaster ER8-GV 2.4GHz Diversity+8xPWM+Vario RX
23) RadioMaster RP4-TD True Diversity 2.4GHz RX
Wenn Du es genau wissen willst https://github.com/ExpressLRS/targets/blob/master/targets.json anschauen, nach dem Empfänger suchen und das tag "platform" anschauen.
silberkorn
User
Danke Dir.
kalle123
User
Ich will hier noch mal mit einem Problem aufschlagen, wo ich mich wohl in den letzten Tagen verrannt habe. Shit happens.
Dreht sich um die Telemetrieübertragung zwischen FC und Sender bei ELRS. Speziell die Barometerwerte Alt und VSpd fehlen bei mir im Sender. Naja bei INAV 'Alt', bei AP beide Werte.
Schon bei Ardupilot hab ich mit da eine ziemliche Watsche abgeholt und bin (ungern) dann zu INAV gewechselt. Und wie ich dort das gleiche Fehlen der Barowerte entdeckt habe, hab ich mir erlaubt, einen ELRS issue in github aufzumachen.
github.com
Erste Antwort, FC Herstellerproblem. Schön, aber ich sehe das Problem auch bei einem Kakute FC. Dann dort als Antwort der Wechsel von Herstellerproblem > INAV Problem.
Ich hab mich jetzt erstmal aus github verabschiedet. Bisschen viel die letzten Tage.
Nur was ich nicht verstehe bei der ganzen Sache ist, das bei der wirklich tollen Sache ELRS (es werden ja sowohl bei INAV als auch bei AP, und bei AP OHNE! yaapu installieren zu müssen, massig Telemetriedaten übertragen) anscheinend keine Absprachen zwischen den Beteiligten AP, INAV und ELRS stattfinden.
Jetzt werde ich als Widflieger, der kein FPV und yaapu braucht, aber die Baro Werte akustisch, mich mit INAV und FrSky durch wursteln, aber im vermisse AP schon jetzt.
Gruß - KH
Dreht sich um die Telemetrieübertragung zwischen FC und Sender bei ELRS. Speziell die Barometerwerte Alt und VSpd fehlen bei mir im Sender. Naja bei INAV 'Alt', bei AP beide Werte.
Schon bei Ardupilot hab ich mit da eine ziemliche Watsche abgeholt und bin (ungern) dann zu INAV gewechselt. Und wie ich dort das gleiche Fehlen der Barowerte entdeckt habe, hab ich mir erlaubt, einen ELRS issue in github aufzumachen.
Missing barometer 'Alt' value in telemetry data on the radio ... · Issue #2644 · ExpressLRS/ExpressLRS
According to https://github.com/ExpressLRS/ExpressLRS/tree/master/src/lib/CrsfProtocol I assumed, I should see barometer 'Alt' on the radio telemetry screen. TX hardware: FrSky X10 S Express with H...
github.com
Erste Antwort, FC Herstellerproblem. Schön, aber ich sehe das Problem auch bei einem Kakute FC. Dann dort als Antwort der Wechsel von Herstellerproblem > INAV Problem.
Ich hab mich jetzt erstmal aus github verabschiedet. Bisschen viel die letzten Tage.
Nur was ich nicht verstehe bei der ganzen Sache ist, das bei der wirklich tollen Sache ELRS (es werden ja sowohl bei INAV als auch bei AP, und bei AP OHNE! yaapu installieren zu müssen, massig Telemetriedaten übertragen) anscheinend keine Absprachen zwischen den Beteiligten AP, INAV und ELRS stattfinden.
Jetzt werde ich als Widflieger, der kein FPV und yaapu braucht, aber die Baro Werte akustisch, mich mit INAV und FrSky durch wursteln, aber im vermisse AP schon jetzt.
Gruß - KH
TornadoRot
User
ELRS ist da ja auch der falsche Ansprechpartner, weil ELRS einfach nur weiterleitet was vom FC kommt.
Was spricht denn gegen yaapu? Bei AP z.B. bekommt man VSpd und Alt über CRSF mit yaapu und CRSF Passtrough, dann hast du die Baro Werte genauso akustisch wie mit FrSky.
Was spricht denn gegen yaapu? Bei AP z.B. bekommt man VSpd und Alt über CRSF mit yaapu und CRSF Passtrough, dann hast du die Baro Werte genauso akustisch wie mit FrSky.
@kalle123
ELRS kann da am wenigsten dafür und das Problem schon gar nicht lösen, deshalb wurde Dein ELRS Issue auch geschlossen. CRSF ist eine Spezifikation (Owner TBS), die von allen Beteiligten (FC Software, Empfängersoftware, Sendersoftware) nach dem gleichen (aktuellen) Spezifikationsstand umgesetzt werden muss, wenn alles im Gesamtsystem FC->Empfänger->Sender glatt gehen soll.
Oxs, ELRS und EdgeTX haben das getan (BF wahrscheinlich auch), siehe vorhergehenden Post. Dann gehts auch mit Alt. Wenn iNav die CRSF Spec auch korrekt umsetzen würde (ID9 verwenden), würdest Du Alt auch mit iNAV an einem ELRS Empfänger und mit EdgeTX sehen. iNav hatte das sogar schon umgesetzt, aber eine Woche vor Release der 1.7.0 wieder rausgenommen, siehe iNav PR 9858: Revert baro alt vario over CRSF
ELRS kann da am wenigsten dafür und das Problem schon gar nicht lösen, deshalb wurde Dein ELRS Issue auch geschlossen. CRSF ist eine Spezifikation (Owner TBS), die von allen Beteiligten (FC Software, Empfängersoftware, Sendersoftware) nach dem gleichen (aktuellen) Spezifikationsstand umgesetzt werden muss, wenn alles im Gesamtsystem FC->Empfänger->Sender glatt gehen soll.
Oxs, ELRS und EdgeTX haben das getan (BF wahrscheinlich auch), siehe vorhergehenden Post. Dann gehts auch mit Alt. Wenn iNav die CRSF Spec auch korrekt umsetzen würde (ID9 verwenden), würdest Du Alt auch mit iNAV an einem ELRS Empfänger und mit EdgeTX sehen. iNav hatte das sogar schon umgesetzt, aber eine Woche vor Release der 1.7.0 wieder rausgenommen, siehe iNav PR 9858: Revert baro alt vario over CRSF
ELRS (CRSF) kennt für barometrischen Sensor die beiden Werte ALT und VSPD, dazu auch noch ein GPS-basiertes ALT. Die jeweiligen Sensorwerte müssen sauber vom Sensor gemäss CRSF-Vorgabe an ELRS übergeben werden, ELRS gibt diese Werte dann per Telemetrieübertragung unverändert an das OS vom Sender weiter. Dort werden dann diese auch als Telemetriedaten sauber empfangen und dargestellt. Alles entscheidend ist, dass die Sensordaten sauber durch die Sensor-/FC-Firmware an ELRS übergeben wird. Ist das nicht der Fall, dann hat man ein Problem. Das kann aber nicht ELRS angelastet werden.
@kalle123
Bei wem Du Dich wirklich beschweren kannst, offenbart die Begründung für den iNAV PR, der Dir Alt weggenommen hat, bevor Du es überhaupt hattest: "The new telemetry field uses an optional field that is not processed correctly by all radios. (older radio firmware is less likely to work correctly)." Ja, bei all den Leuten, die zu faul waren ihre Sender auf neusten Stand zu bringen und/oder den Sendersoftwareentwicklern, die ihre Software auch nicht auf Spec-Stand gebracht haben.
Bei wem Du Dich wirklich beschweren kannst, offenbart die Begründung für den iNAV PR, der Dir Alt weggenommen hat, bevor Du es überhaupt hattest: "The new telemetry field uses an optional field that is not processed correctly by all radios. (older radio firmware is less likely to work correctly)." Ja, bei all den Leuten, die zu faul waren ihre Sender auf neusten Stand zu bringen und/oder den Sendersoftwareentwicklern, die ihre Software auch nicht auf Spec-Stand gebracht haben.
kalle123
User
Leute langsam, ich hab ja auch davor ein issue bei AP aufgemacht. Bin wohl mit dem Frust über die fehlenden Baro Werte auch nicht ganz alleine.
github.com
Aber ich will mal ein paar Punkte anreißen:
yaapu ist ja einen tolle Sache, ich hab mir das schon vor Jahren auf der X9D angeschaut, aber zum Fliegen möchte ich das einfach nicht. Bitte da um Verständnis. Und nebenbei, ELRS bringt auch ohne yaapu (fast) alle Telenetriewerte in AP ein.
FPV sicher toll, aber auch nicht mein Ding. Einfach nur 'LOS' (wie ich jetzt gelernt habe
) fliegen.
oXs und oXs on RP2040 kenn ich wohl auch etwas. ABER die FCs bieten alles, was ich so brauche. GPS, Baro, Strom, Spannung. Das alles jetzt noch mal doppelt? Irgendwie sträubt sich da was in mir. Ist auch eine Platzfrage.
Du sitzt mit so einem Problem zwischen relativ vielen Stühlen. In dem Fall sind das AP/INAV, dann ELRS/FrSky und weiter zu EdgeTX und dann noch die Hardwarehersteller. Ich hab mit AP angefangen und peng! Da stehst du vor einer Wand.
Das issue zu ELRS war vielleicht mein Fehler da ich hier seit Monaten nen Aufbau unter oXs on RP240 + ELRS mit redundanten RX, GPS, Baro, Strom und Spannung ohne Probleme in Funktion hab.
INAV in Kombination mit FrSky sehe in nur ungern als Notlösung an. Mir wäre AP (ohne yaapu) mit ELRS sehr viel lieber. Und was mich da auch ärgert, es kann nicht viel im AP source code sein, was da geändert werden muss.
Hab ja auch schon mal etwas Glück bei AP gehabt. Hier z.B. https://discuss.ardupilot.org/t/2-linux-versions-needed-to-build-different-ap-versions/115237
Da kam ich mit einem Entwickler ins Gepräch. Beim Wechsel der Entwicklungsumgebung auf ein virtuelles python 'venv' gibt es Probleme mit älteren AP Versionen. Eine schnelle Lösung bei der Sache hier seitens AP wäre mir aber 100. mal lieber.
Hat den keiner der ELRS Entwickler einen Zugang zu den AP Leuten?
Gruß KH
Missing barometer telemetry values in AP Plane, yaapu and ExpressLRS. · Issue #26699 · ArduPilot/ardupilot
In my opinion, flying a plane the barometer values Alt and VSpd are essential. Especially with a powered glider trying to do some thermal flying. Just learned, that the combination AP Plane, yaapu ...
github.com
Aber ich will mal ein paar Punkte anreißen:
yaapu ist ja einen tolle Sache, ich hab mir das schon vor Jahren auf der X9D angeschaut, aber zum Fliegen möchte ich das einfach nicht. Bitte da um Verständnis. Und nebenbei, ELRS bringt auch ohne yaapu (fast) alle Telenetriewerte in AP ein.
FPV sicher toll, aber auch nicht mein Ding. Einfach nur 'LOS' (wie ich jetzt gelernt habe
) fliegen.oXs und oXs on RP2040 kenn ich wohl auch etwas. ABER die FCs bieten alles, was ich so brauche. GPS, Baro, Strom, Spannung. Das alles jetzt noch mal doppelt? Irgendwie sträubt sich da was in mir. Ist auch eine Platzfrage.
Du sitzt mit so einem Problem zwischen relativ vielen Stühlen. In dem Fall sind das AP/INAV, dann ELRS/FrSky und weiter zu EdgeTX und dann noch die Hardwarehersteller. Ich hab mit AP angefangen und peng! Da stehst du vor einer Wand.
Das issue zu ELRS war vielleicht mein Fehler da ich hier seit Monaten nen Aufbau unter oXs on RP240 + ELRS mit redundanten RX, GPS, Baro, Strom und Spannung ohne Probleme in Funktion hab.
INAV in Kombination mit FrSky sehe in nur ungern als Notlösung an. Mir wäre AP (ohne yaapu) mit ELRS sehr viel lieber. Und was mich da auch ärgert, es kann nicht viel im AP source code sein, was da geändert werden muss.
Hab ja auch schon mal etwas Glück bei AP gehabt. Hier z.B. https://discuss.ardupilot.org/t/2-linux-versions-needed-to-build-different-ap-versions/115237
Da kam ich mit einem Entwickler ins Gepräch. Beim Wechsel der Entwicklungsumgebung auf ein virtuelles python 'venv' gibt es Probleme mit älteren AP Versionen. Eine schnelle Lösung bei der Sache hier seitens AP wäre mir aber 100. mal lieber.
Hat den keiner der ELRS Entwickler einen Zugang zu den AP Leuten?
Gruß KH
wimalopaan
User
Vielleicht auch interessant: https://github.com/wimalopaan/Electronics?tab=readme-ov-file#elrs_jr
oder: https://github.com/wimalopaan/Electronics?tab=readme-ov-file#elrs_x12s
oder: https://github.com/wimalopaan/Electronics?tab=readme-ov-file#elrs_x12s
doloebig
User
weisst du zufällig ob das Twin ISRM Modul z.B. in der X14 die gleiche Belegung hat?
Grüsse und danke
Doro