Expresslrs / Crossfire für Flächenmodelle
- Ersteller glipski
- Erstellt am
kalle123
User
Irgendwie beschleicht mich das Gefühl, das Projekt
github.com
von mstrens könnte tot sein?!
Hab hier mal einen Versuchsaufbau mit RP2040 Zero, GPS Beitian BN180, Baro MS5611, SPL06 und BMP280 gemacht.
Spuckt ja jede Menge Telemetriewerte aus.
Was mir aufgefallen ist, Servo Kanal 5 ist auch dort kein vollwertiger PWM Kanal.
Bei den PWM Kanälen (hab mit 6 Kanälen aufgebaut) gibt der Sender 988µs - 1497µs - 2012µs aus, am RP2040 erscheinen 1.06ms - 1.59ms - 2.13ms!?
Bei den Varios: Werten mit MS5611, SPL06 scheinen ok, beim BMP280 ist m.E. was faul, Werte dort ziemlich daneben.
Bei github tut sich nichts, ebenso auf RCN. Ich vermute, mstrens hat 'oXs_on_RP2040' nach kurzer Zeit fallen gelassen.
Zu komplex, platformio, daher und vielleicht auch allgemein zu wenig Interesse? Wäre schade drum.
Gruß KH
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
von mstrens könnte tot sein?!
Hab hier mal einen Versuchsaufbau mit RP2040 Zero, GPS Beitian BN180, Baro MS5611, SPL06 und BMP280 gemacht.
Spuckt ja jede Menge Telemetriewerte aus.
Was mir aufgefallen ist, Servo Kanal 5 ist auch dort kein vollwertiger PWM Kanal.
Bei den PWM Kanälen (hab mit 6 Kanälen aufgebaut) gibt der Sender 988µs - 1497µs - 2012µs aus, am RP2040 erscheinen 1.06ms - 1.59ms - 2.13ms!?
Bei den Varios: Werten mit MS5611, SPL06 scheinen ok, beim BMP280 ist m.E. was faul, Werte dort ziemlich daneben.
Bei github tut sich nichts, ebenso auf RCN. Ich vermute, mstrens hat 'oXs_on_RP2040' nach kurzer Zeit fallen gelassen.
Zu komplex, platformio, daher und vielleicht auch allgemein zu wenig Interesse? Wäre schade drum.
Gruß KH
glipski
User
Um das Thema ExpressLRS für Flächenflieger ( Seglersegler 2,5 - 5m ist es leider etwas ruhig geworden. Mit Version 3.0 und den von Matek angebotenen Empfängern und CRSF- > PWM Convertern funktioniert alles sehr gut. Etliche mögliche Interessenten werden vielleicht jedoch davon abgehalten, dass diese Empfänger doch noch etliches an Löten und Einstellen (mit dem ELRS-Tool für den Empfänger und mit dem Matek-Tool für den Converter) benötigen. Die einschlägigen Hersteller scheinen sich mit den Empfängern wohl mehr auf FPV-Fläche auszurichten. Für Telemetrie ist auch nichts am Horizont zu sehen ausser die „Selbstbaulösungen“ bei Matek. Und das oXs-Projekt scheint, wie KH schreibt, eingeschlafen zu sein.
Ich denke, ExpressLRS hat auch für Flächenflieger noch etliches Potential. Wäre schade, wenn die etablierten Hersteller das ignorieren würden ( TWIN von Frsky mit deren ExpressLRS compatible Lösung ist ja wohl eher ein Witz
)
Ich denke, ExpressLRS hat auch für Flächenflieger noch etliches Potential. Wäre schade, wenn die etablierten Hersteller das ignorieren würden ( TWIN von Frsky mit deren ExpressLRS compatible Lösung ist ja wohl eher ein Witz
)Gast_74695
User gesperrt
Man kann ohne weiteres einen Matek-Decoder für die PWM-Ausgabe mit einem oXs für die Telemetrie kombinieren (TX/RX). Eine Datei über USB auf den RP2040 kopieren und danach die Optionen über ein Menue einstellen, das sollte ein Modellflieger hinbekommen 
kalle123
User
Hänge dazu dieses relativ 'frische' YT Video an, welches verdeutlicht, was mit Kanal 5 zu machen ist.
Schade, weil du bei diesem Ansatz mit einem Empfänger und einem RP2040 ausgekommen wärst, ohne einen Umsetzer auf PWM, ohne einen Pro Mini, ohne ....
Und dazu sehr kompakt. Ist halt keiner drauf angesprungen, wie mstrens das Projekt im Frühjahr raus brachte. Ich auch nicht! Hab mir zwar damals einen RP2040 besorgt und mich mit platformio CLI beschäftigt und geflashed, aber dann zur Seite gelegt.
cu KH
Voodoo-68
User
wo ist der Vorteil?
Du brauchst einen Empfänger und einen Konverter. Ob Du den Konverter mit einem RP2040 umsetzt oder dir ein fertiges Produkt besorgst. Preis ist ähnlich, Grösse ist ähnlich (eher kleiner), Aufwand 1/10.
Einen GPS-Empfänger kannst Du auch direkt anschliessen. Es gibt auch Konverter mit Baro. Also noch mehr "ohne".
Ich bin bei Dir, immer schade wenn ein eigentlich tolles Projekt stirbt nur weil das öffentliche Interesse nahezu 0 ist.
Unter den Modellbauer gibt es aber nicht viele Elektroniker die sowas nachbauen. Bei den meisten ist ab Servostecker löten schluss.
Ich sehe es ja bei meinem SBUS-Switch. Auch da ist das Echo verhalten. Obwohl recht einfach gehalten und es gibt auch nichts vergleichbares auf dem Markt.
Auch die Verbreitung der PWM Konverter wird sich in Grenzen halten. Man muss sich schliesslich dann um die Firmware von Empfänger und Konverter kümmern. Die meisten maulen schon rum wenn mal ein Update für den Empfänger kommt obwohl man es einfach über den Sender einspielen kann.
Bzgl. Antenne: habe hier dieses Video gefunden:
Stimmt das und welche Reichweite bleibt da? Wäre ja dann ideal…
Stimmt das und welche Reichweite bleibt da? Wäre ja dann ideal…
glipski
User
Ich habe mich noch nie mit dem openXsensor befasst. ist das hier der richtige Einstieg?Man kann ohne weiteres einen Matek-Decoder für die PWM-Ausgabe mit einem oXs für die Telemetrie kombinieren (TX/RX). Eine Datei über USB auf den RP2040 kopieren und danach die Optionen über ein Menue einstellen, das sollte ein Modellflieger hinbekommen
GitHub - openXsensor/openXsensor: Arduino Telemetry for the RC world
Arduino Telemetry for the RC world. Contribute to openXsensor/openXsensor development by creating an account on GitHub.
github.com
In den einschlägigen Foren kann man zwar auch etliche Threads finden, für den Einstieg ist das aber etwas unübersichtlich.
Graubussard
User
Ja, das ist einfach Physik und gilt für alle 2.45GHz-Antennen.
Aktiv als Antenne ist nur der abgemantelte Teil, die sonst vorhandene Länge dient nur dazu, die eigentliche Antenne weg von störenden Teilen oder Komponenten zu bekommen. Als halber Dipol ist der Rest nicht so empfangsstark wie eine T-Antenne, das wird aber teilweise dadurch ausgeglichen, dass die Dämpfung durch das (jetzt kaum mehr vorhandene) Koaxialkabel wegfällt.
Bei guter Antennenpositionierung (freie Sicht zum Sender/ Ausrichtung) wirst du in der Praxis keinen Unterschied bemerken.
Die physikalisch ähnlichen Antennen der EP2 Receiver haben ja schon mehrere hundert Meter Reichweite selbst in Bodennähe und hinter Bäumen usw.
Gast_74695
User gesperrt
Das ist der "alte" openXsensor. In Verbindung mit ELRS brauchts den "neuen" openXsensor, der aber ebenso mit FrSky und Jeti funktioniert. Der neue ist zum Einstieg besser, denn es wird nur eine uf2-Datei über USB auf den RP2040 kopiert und nach dem Neubooten kann man mit einem Terminalprogramm die Optionen konfigurieren.
Ganz wichtig: auf der Startseite zum "Test-for-16-PWM"-branch wechseln, Mstrens pflegt "main" nicht mehr.
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
In config.h steht am Anfang auch nochmal alles Wissenswerte über Verkabelung und Konfiguration.
kalle123
User
Scheint doch nicht tot zu sein. Zum PWM Punkt habe ich eine Antwort und zum BMP280 Problemchen hoffe ich noch was zu hören ....
Gruß KH
PS. Interessenten an 'oXs on RP2040' sollten sich schon mal mit Platformio beschäftigen
Gast_74695
User gesperrt
Das ist komplett unnötig. Der RP2040 wird über ein simples Terminalfenster konfiguriert, die Baros werden automatisch detektiert.PS. Interessenten an 'oXs on RP2040' sollten sich schon mal mit Platformio beschäftigen
glipski
User
Ich habe mir jetzt einen RP2040 bestellt, GPS und Barosensor habe ich noch hier liegen, und dann werde ich ersteinmal einen atestsufbau vornehmen. Das Aufspielen und Einstellen klingt ja recht einfach.
Für Frsky / S.Port ist das so als Sensor sicher noch noch gut verwenbar. Für ELRS benötigt man dann ja auch noch eine einigermaßen saubere und mechanisch stabile Anschlußmöglichkeit für die Servos. Ohne ein PCB geht da eigentlich nichts, Lochrasterplatte ist als Bastellösung ist da sicher nicht akzeptabel. Die Frage ist halt, ob es je käuflich erwerbbare PCBs geben wird. Aber selbst wenn, für eine große Verbreitung wird das sicher nicht reichen. Da braucht es schon einen größeren Anbieter, der sich dafür interessieren wird.
Hier übrigens noch der dazugehörige Thread in RCG, wurde, glaube ich, noch nicht verlinkt
Für Frsky / S.Port ist das so als Sensor sicher noch noch gut verwenbar. Für ELRS benötigt man dann ja auch noch eine einigermaßen saubere und mechanisch stabile Anschlußmöglichkeit für die Servos. Ohne ein PCB geht da eigentlich nichts, Lochrasterplatte ist als Bastellösung ist da sicher nicht akzeptabel. Die Frage ist halt, ob es je käuflich erwerbbare PCBs geben wird. Aber selbst wenn, für eine große Verbreitung wird das sicher nicht reichen. Da braucht es schon einen größeren Anbieter, der sich dafür interessieren wird.
Hier übrigens noch der dazugehörige Thread in RCG, wurde, glaube ich, noch nicht verlinkt
kalle123
User
Ich häng mal ein Bild meiner momentanen 'Bastelei' an. RP2040, Baro und GPS.
Drunter hab ich mal einen Revo Mini gestellt. Fast gleiche Größe wie der RP2040. Den Revo gibt es leider nicht mehr. Toller FC für Flugmodelle (Arduplane). 8! PWM, MS5611, Compass und IMU on board, GPS Anschluss. PCBs hab ich da noch keine gesehen. Gibt halt solche und solche 'Basteleien'.
Gruß KH
kalle123
User
@glipski
Ich will zu zwei Punkten noch etwas sagen.
Zur Verkabelung: Ich nutze Arduplane bei kleinen Nuris (Schweissgut) und da ist verdammt wenig Platz im Rumpf. So etwas peile ich auch hier an. Einen Matek F405 Wing z.B. krieg ich schon nicht mehr rein, drum hab ich auch Revo Minis 'gebunkert'. Da bin ich dann frei mit der Positionierung z.B. des Übergabepunkts für die 3 PWM Signale (Nuri). Dort kann ich denn verlöten oder aber auch mit einer kleinen Lochrasterplatine arbeiten, wo auf der einen Seite die Käbelchen vom Controller angelötet sind und auf der anderen Seite die header pins. Die Lötseite wird auf jeden Fall versiegelt (Ich bevorzuge da Epoxy, aber Heißkleber müsste auch gehen). Ganz wichtig ist auch, die Käbelchen zu bündeln und zu fixieren. Wenn du mal an ein manntragendes Flugzeug ran kommst, schau dir mal an, wie da die Kabel gebündelt, gesichert und befestigt sind. Ne Cessna reicht da. Da wackelt und flattert nix. Wenn das beachtet wird und sauber ausgeführt wird, hab ich absolute keine Bedenken gegen 'Lochrasterplatinen'
Zu platformio: Hab gerade noch die aktualisierte main geladen und aufgespielt. Da hatte der Entwickler 'debug' beim BMP280 nicht raus genommen und so rasselten mir hier die Baro Werte über den Bildschirm. Hab momentan den BMP280 drauf auf meiner 'Bastelei'. Also kommentiere ich das schnell aus und spiele mit platformio die Software auf und gut isses. (Hab nachgeschaut, die Datei APPLICATION.uf2 in main ist 'sauber' und hat den 'gimmik' nicht
Ich hatte mich Anfang des Jahres mit dem Projekt beschäftigt, da gab es keinen 'Config' und ich kam zu dem Zeitpunkt nicht um platformio rum. Hab mir dann mal die platformio IDE angeschaut, aber die ganze GUI dort und was da alles auf den Rechner drauf muss. Insbesondere VSCode und dass auf meine Linux Maschine hier. Und da bei Linux sowieso python mit kommt, hab ich mir die platformio CLI drauf gepackt. Dazu noch eine library. Schön simpel und übersichtlich. 2 kurze Befehle und die Software ist auf dem RP2040 drauf.
Platformio CLI ist kein Hexenwerk, aber ich muss sagen, die platformio GUI (ziemlich überladen und viel 'Mickey Maus') hat mir absolut nicht zugesagt.
Ich werde mich jetzt mal mit den Spannungseingängen beschäftigen, mal schauen was sich da tut und ob es dort auch solche kleinen 'gimmiks' gibt. Ich denke, das Projekt ist noch in Entwicklung und es sollte von verschiedener Seite getestet und ggfs. mit dem Entwickler diskutiert werden. Anscheinend tut sich da aber recht wenig! Und da ist platfprmio schon hilfreich! Du kannst dann direkt mit dem Entwickler reden und der sagt dir dann, mach da und dort mal einen kleine Änderung und melde dich. Und frag nicht, wie oft wegen der Baro Sache da kleine Änderungen und die Rückmeldungen erforderlich waren. Ansonsten müsste jeweils eine spezielle APPLICATION.uf2 gebaut und verschickt werden.
Ich vertrete nicht die Meinung, das Projekt ist zum jetzigen Zeitpunkt fehlerfrei. Andere mögen das anders sehen .....
Wenn was sein sollte, melde dich beim Entwickler über github, Der Link von dir, der RCN thread scheint selig zu ruhen. Dort wurden ja tolle PCBs entworfen, aber war es das?
Gruß KH
Ich will zu zwei Punkten noch etwas sagen.
Zur Verkabelung: Ich nutze Arduplane bei kleinen Nuris (Schweissgut) und da ist verdammt wenig Platz im Rumpf. So etwas peile ich auch hier an. Einen Matek F405 Wing z.B. krieg ich schon nicht mehr rein, drum hab ich auch Revo Minis 'gebunkert'. Da bin ich dann frei mit der Positionierung z.B. des Übergabepunkts für die 3 PWM Signale (Nuri). Dort kann ich denn verlöten oder aber auch mit einer kleinen Lochrasterplatine arbeiten, wo auf der einen Seite die Käbelchen vom Controller angelötet sind und auf der anderen Seite die header pins. Die Lötseite wird auf jeden Fall versiegelt (Ich bevorzuge da Epoxy, aber Heißkleber müsste auch gehen). Ganz wichtig ist auch, die Käbelchen zu bündeln und zu fixieren. Wenn du mal an ein manntragendes Flugzeug ran kommst, schau dir mal an, wie da die Kabel gebündelt, gesichert und befestigt sind. Ne Cessna reicht da. Da wackelt und flattert nix. Wenn das beachtet wird und sauber ausgeführt wird, hab ich absolute keine Bedenken gegen 'Lochrasterplatinen'
Zu platformio: Hab gerade noch die aktualisierte main geladen und aufgespielt. Da hatte der Entwickler 'debug' beim BMP280 nicht raus genommen und so rasselten mir hier die Baro Werte über den Bildschirm. Hab momentan den BMP280 drauf auf meiner 'Bastelei'. Also kommentiere ich das schnell aus und spiele mit platformio die Software auf und gut isses. (Hab nachgeschaut, die Datei APPLICATION.uf2 in main ist 'sauber' und hat den 'gimmik' nicht
Ich hatte mich Anfang des Jahres mit dem Projekt beschäftigt, da gab es keinen 'Config' und ich kam zu dem Zeitpunkt nicht um platformio rum. Hab mir dann mal die platformio IDE angeschaut, aber die ganze GUI dort und was da alles auf den Rechner drauf muss. Insbesondere VSCode und dass auf meine Linux Maschine hier. Und da bei Linux sowieso python mit kommt, hab ich mir die platformio CLI drauf gepackt. Dazu noch eine library. Schön simpel und übersichtlich. 2 kurze Befehle und die Software ist auf dem RP2040 drauf.
Platformio CLI ist kein Hexenwerk, aber ich muss sagen, die platformio GUI (ziemlich überladen und viel 'Mickey Maus') hat mir absolut nicht zugesagt.
Ich werde mich jetzt mal mit den Spannungseingängen beschäftigen, mal schauen was sich da tut und ob es dort auch solche kleinen 'gimmiks' gibt. Ich denke, das Projekt ist noch in Entwicklung und es sollte von verschiedener Seite getestet und ggfs. mit dem Entwickler diskutiert werden. Anscheinend tut sich da aber recht wenig! Und da ist platfprmio schon hilfreich! Du kannst dann direkt mit dem Entwickler reden und der sagt dir dann, mach da und dort mal einen kleine Änderung und melde dich. Und frag nicht, wie oft wegen der Baro Sache da kleine Änderungen und die Rückmeldungen erforderlich waren. Ansonsten müsste jeweils eine spezielle APPLICATION.uf2 gebaut und verschickt werden.
Ich vertrete nicht die Meinung, das Projekt ist zum jetzigen Zeitpunkt fehlerfrei. Andere mögen das anders sehen .....
Wenn was sein sollte, melde dich beim Entwickler über github, Der Link von dir, der RCN thread scheint selig zu ruhen. Dort wurden ja tolle PCBs entworfen, aber war es das?
Gruß KH
