ELRS 2.4 Vorteile

[BZFrank]

Tolle Lotte. Nur - irgend jemand muss die Spezialisten bezahlen. Sonst passiert irgendwann mal genau das:

Dependency

xkcd.com

auch ist man erst kürzlich mit der libxz-Beinahekatastrophe am Supergau vorbeigeschrammt. Wenn halt keiner weiss, wer irgendeine OSS Bibliothek eigentlich maintained und die eben irgendwo ganz tief drin fast überall eingesetzt wird, kann es schon mal kritisch werden.

Und ganz ehrlich - lese ich von solchen ELRS Bugs, bin ich doch froh nicht auf den neusten Gaul gesetzt zu haben. Das soll jetzt die Bleeding Edge Leute nicht davon abhalten sich mit Wolllust in den Hand zu schneiden.... jeder wie er mag.

 

[madmao]

Leading Edge, bleeding Edge. Klar gibt's Bugs, in welcher Software oder Protokoll nicht. Genau das ist die Innovationsbremse bei den etablierten Herstellern, die scheissen sich in die Hose deswegen. Never touch a running System ist der Tod jedweder Innovation. Und einen Tod muss man sterben. Da schneide ich mich doch lieber in die Hand als einen toten Gaul zu reiten.

Dakota-Indianer: Wenn Du ein totes Pferd reitest, steig ab

Dakota-Indianer: Wenn Du merkst, dass Du ein totes Pferd reitest, steig ab! Über irrsinniges Verhalten am Arbeitsplatz und einen Jobwechsel.

www.weg-zum-traumjob.de

 

[Extreme]

Na ja, so schlecht fliege ich mit den Toten Pferden aber nicht.

Torsten

 

[FlyingNuri]

Und die Entwickeler investieren viel Zeit und vielleicht Geld damit andere Firmen ihre Software kostenlos nutzen können? Und das macht denen Spaß?

Hier kannst Du einen Teil der finanziellen Transaktionen sehen. Die Hersteller stellen kostenfrei Equipment bereit und zahlen sicherlich auch für das Listing im Configurator und Pre-Tests bei neuen Produkten. Nur aus lauter Lust & Laune wird das bei der Projektgröße sicherlich nicht mehr stattfinden. Finde ich vollkommen ok und unterstütze ExpressLRS als normaler Anwender ebenso.

 

[glipski]

Leading Edge, bleeding Edge. Klar gibt's Bugs, in welcher Software oder Protokoll nicht. Genau das ist die Innovationsbremse bei den etablierten Herstellern, die scheissen sich in die Hose deswegen. Never touch a running System ist der Tod jedweder Innovation. Und einen Tod muss man sterben. Da schneide ich mich doch lieber in die Hand als einen toten Gaul zu reiten.

Dakota-Indianer: Wenn Du ein totes Pferd reitest, steig ab

Dakota-Indianer: Wenn Du merkst, dass Du ein totes Pferd reitest, steig ab! Über irrsinniges Verhalten am Arbeitsplatz und einen Jobwechsel.

www.weg-zum-traumjob.de

Naja, so schwarz-weiß ist die RC-Welt nun auch nicht. Ich fliege parallel zu ELRS auch noch eine Graupner mz-32, und die Software hat sich seit dem Start kräftig weiterentwickelt (inkl. der CRSF-Schnittstelle) und braucht sich nicht zu verstecken. Reaktionszeit bei Bugmeldungen oder auch bei Feature-Anfragen ist auch kurz und sehr positiv.

 

[FlyingNuri]

Ich fliege parallel zu ELRS auch noch eine Graupner mz-32, und die Software hat sich seit dem Start kräftig weiterentwickelt (inkl. der CRSF-Schnittstelle) und braucht sich nicht zu verstecken.

Kannst Du kurz benennen, welche der aktuellen Graupner-Sender das CRSF-Protokoll unterstützen? Ich hab einen Kumpel, der ist Graupner-Fan und denkt gerade über einen neuen Sender nach.

 

[Marcus M]

Hier kannst Du einen Teil der finanziellen Transaktionen sehen.

Direkt auch mal unterstützt.

Naja, so schwarz-weiß ist die RC-Welt nun auch nicht.

Ich fliege aktuell 3 Systeme parallel, bei einem kotzt mich die Geschäftspolitik an, beim anderen die Geschäftspolitik und diverse kleinere Bugs, und halt ELRS ;-)

 

[glipski]

Kannst Du kurz benennen, welche der aktuellen Graupner-Sender das CRSF-Protokoll unterstützen? Ich hab einen Kumpel, der ist Graupner-Fan und denkt gerade über einen neuen Sender nach.

Beitrag #74 weiter oben hier im Thread, die mechanische Befestigung für das externe Modul ist leider DIY oder 3D-Druck, kein Schacht.

 

[Rüdiger]

Leading Edge, bleeding Edge. Klar gibt's Bugs, in welcher Software oder Protokoll nicht. Genau das ist die Innovationsbremse bei den etablierten Herstellern, die scheissen sich in die Hose deswegen. Never touch a running System ist der Tod jedweder Innovation. Und einen Tod muss man sterben. Da schneide ich mich doch lieber in die Hand als einen toten Gaul zu reiten.

Kann ich nicht nachvollziehen. Du gehst also lieber das Risiko ein, wissentlich jemanden wegen nicht ausgereifter Software/Protokoll/Rxen umzufliegen als mit bewährter Technik dein Hobby so weit wie es geht verantwortungsvoll auszuüben. Klar, dieses Szenario ist schon hart an der Grenze zur Fiktion, das gebe ich gerne zu, aber dennoch nicht so unwahrscheinlich wie die Fangemeinde sich hier vormacht. Kommt mir vor wie die berühmte Bananensoftware, die reift erst beim Anwender. Hier geht die Begeisterung für neue Möglichkeiten gegenüber der Produktsicherheit anscheinend durch.

cu,

Rüdiger

 

[Marcus M]

Einfach mal die aktuellen Issues bei ELRS anschauen:

Issues · ExpressLRS/ExpressLRS

STM32/ESP32/ESP8285-based High-Performance Radio Link for RC applications - Issues · ExpressLRS/ExpressLRS

github.com

Mal im Ernst, mehr Transparenz geht nicht, und was kritisches, was mich vom fliegen abhält, kann ich nicht erkennen.
Welcher der etablierten bietet diese Transparenz? Ich behaupte einfach mal, dass die meisten der etablierten haben wesentlich längere liste an Themen die man angehen sollte.

Issue, so ein tolles Wort aus dem Englischen... Vielleicht Fehler, vielleicht nicht, doch nur eine Anfrage/Problem/Thema zur Diskussion, oder Verbesserung.

 

[defender67]

Da ich mangels elektronischem Know-How nichts zum Projekt beitrage und Nutznießer bin hab ich eine Spende getätigt.
Ich finde so eine Sache muß unterstützt werden.

 

[BZFrank]

Mal im Ernst, mehr Transparenz geht nicht, und was kritisches, was mich vom fliegen abhält, kann ich nicht erkennen.

Manches stösst mich eben sauer auf, Beispiel

EU compatibility · Issue #5 · ExpressLRS/ExpressLRS

Hey, interesting project - thanks for sharing. In order to use it over here in the EU we would need this to run on 868MHz, which I assume would not be a big deal. How about LBT - did you consider i...

github.com

letzer Eintrag:

"It's implemented but, as the rest of the protocol, not yet properly tested."

das zieht sich leider durchs ganze Projekt. Es gibt keine Qualitätssicherung, Endkontrolle oder Abnahme. Man baut ein Feature ein, hofft das beste und das es beim Benutzer "reift". Dann kommt u.U. sowas dabei heraus:

EU LBT firmware loosing connection and won't re-connect · Issue #2028 · ExpressLRS/ExpressLRS

Current Behavior LBT EU firmware 3.1.2 at 50Hz packet rate and traditional 2.4Ghz radio close to force LBT activity: After successfully establishing connection the tx module randomly loses connecti...

github.com

Das könnte insbesondere bei der wachsenden Bandbreite von unterschiedlicher Hardware ein grösseres Problem werden.
Das das Projekt trotzdem ausreichend gut funktioniert ist erfreulich, aber das ist nicht das was ich will.... "It's all sh*ts and giggles until somebody gets hurt".

 

[wimalopaan]

Es gibt keine Qualitätssicherung, Endkontrolle oder Abnahme.

Und woher weißt Du, wie kommerziellen Hersteller das machen?

Vom Einsatz des MPM (Heldenprojekt) mal ganz zu schweigen.

Ich denke, gerade bei EdgeTx und ELRS ist die Anzahl der Tester eines RC sehr hoch, so dass da in Summe mehr getestet wird, als bei einem Hersteller.

 

[Georg Funk]

Das mit der Qualitätssicherung sehe ich eigentlich als einen der großen Vorteile von OpenSource. Der beste Test ist halt einfach die Praxis. Und hier haben wir viele freiwillige die top motiviert ihre Zeit, Wissen und wenn es schief läuft auch ihre Modelle riskieren um die Beta- oder Pre Releases zu testen bevor sie dann als offizielles Release herausgegeben werden. Dass sie dabei darauf achten das Drittschäden weitestgehend ausgeschlossen sind liegt ja nur in ihrem eignen Interesse.
Jede neue Fernsteuerung der "Großen" wurde sicher lange getestet, trotzdem waren die Laufzeiten der "1.0" Versionen immer sehr kurz und die Hersteller haben sehr deutlich gemacht dass man doch bitte schnell auf 1.xx updaten soll um die Sicherheit zu gewährleisten.
Diejenigen die wie ich ein fertiges System wollen, das alle ihre Grundanforderungen erfüllt müssen halt dann solange das (alte) System fliegen das ihren Anforderungen näher kommt, bis das neue das dann auch besser kann.
Ein Kritikpunkt ist für mich die Unterscheidung zwischen den "Release" und "pre Release" Versionen da muss man doch ziemlich genau lesen. Mein Vorschlag wären hier 3 Listen auf Github 1. Beta, 2. Pre Release 3. Release. Vor allem die Liste mit den Releases würde ich dann aber auch mit dem klaren Hinweis versehen dass diejenigen (wie ich) die sich nicht an der Entwicklung beteiligt haben doch bitte in guter OpenSource Manier etwas spenden sollten.

 

[FlyingNuri]

Es finden sich immer Argumente für oder gegen eine Technik. Bei Open Source in im hiesigen Bereich wird regelmäßig über Rechtskonformität und Qualitätssicherung debattiert bzw. generell in Frage gestellt. Damit muss man halt leben und sowas schlicht überlesen, weil das genauso gut bei "etablierten" Herstellern ein Problem sein kann.

Die an den Haaren herbeigezogenen Schreckensszenarien helfen auch nicht. Jede Technik kann ausfallen und zum Problem werden, egal welches Markensymbol dort drauf klebt.

IMHO sollte man sich darauf konzentrieren, technische Vor-/Nachteile zu diskutieren. Open Source Projekte sind nicht per se für alle Anwender sinnvoll, im hiesigen Bereich aber eine ernst zu nehmende Alternative.

 

[bendh]

...

das zieht sich leider durchs ganze Projekt. Es gibt keine Qualitätssicherung, Endkontrolle oder Abnahme. Man baut ein Feature ein, hofft das beste und das es beim Benutzer "reift".
...

Na ob das bei Multiplex, da wurde gleich ein ganzer Sender wegen Softwareproblemen eingestellt und auf einen anderen Hersteller verwiesen, oder FrSky, siehe Stabiempfänger, besser ist?

 

[Rüdiger]

Bei Open Source in im hiesigen Bereich wird regelmäßig über Rechtskonformität und Qualitätssicherung debattiert bzw. generell in Frage gestellt. Damit muss man halt leben und sowas schlicht überlesen, weil das genauso gut bei "etablierten" Herstellern ein Problem sein kann.

Den Ansporn, es besser als die etablierten(!) Hersteller zu machen hat man deinen Worten nach zu urteilen also nicht. Mir kommt es vor, als lebten sich Entwickler aus, ohne jeweils Best Practices anzuwenden. Ist ja nur Hobby für ein Hobby. Das man neue Soft/Hard/Firmware Features vielleicht erstmal für sich unter realen Bedingungen ausgiebig testet bevor man Releases verteilt scheint nicht usus zu sein, sonst gäbe es solche gravierenden Fehler wie Verbindungsabbrüche erst garnicht.

Die an den Haaren herbeigezogenen Schreckensszenarien helfen auch nicht. Jede Technik kann ausfallen und zum Problem werden, egal welches Markensymbol dort drauf klebt.

An den Haaren herbeigezogen, soso

Gerne würde ich meine etwas ältliche Hardware gegen etwas aktuelles tauschen, warte aber lieber noch ein paar Jahre ab. Ich hab's nicht eilig, meine bisher zu 100% fehlerfrei funktionierende Soft/Hardware tauschen zu müssen, auch wenn nach hiesiger Ansicht die darin eingebauten 15 Jahre alten Transceiver unbedingt zu verachten sind

 

[FlyingNuri]

Gerne würde ich meine etwas ältliche Hardware gegen etwas aktuelles tauschen, warte aber lieber noch ein paar Jahre ab.

Mach das ... der Sprung auf ein dann aktuelles Setup wird groß sein, hoffentlich ist dann die Lernkurve nicht zu steil.

 

[Rüdiger]

Mach das ... der Sprung auf ein dann aktuelles Setup wird groß sein, hoffentlich ist dann die Lernkurve nicht zu steil.

Ein Schenkelklopfer

 

[wimalopaan]

Das man neue Soft/Hard/Firmware Features vielleicht erstmal für sich unter realen Bedingungen ausgiebig testet bevor man Releases verteilt scheint nicht usus zu sein, sonst gäbe es solche gravierenden Fehler wie Verbindungsabbrüche erst garnicht.

Findet doch statt. Du solltest halt keinen RC installieren ... dann bist Du Tester