OXSENS OpenXsensor Projekt für CRSF Protocol (RP2040)
- Themenstarter Carbonator
- Beginndatum
Man braucht einen Drucksensor für die Höhe, und einen Sensor für den Airspeed. Entweder den MS4525 oder einen SDP Sensor. Der 4525 hat den Vorteil, dass er mit den handelsüblichen Pitot-Rohren funktioniert, die SDP sind prinzipbedingt im unteren Geschwindigkeitsbereich genauer. Aber dafür muss man bei der Sonde etwas basteln.
Die eigentliche Energiekompensation wird gerechnet. Man hat also echte Höhe, echten Airspeed und eine vom Sender aus einstell- und abschaltbare Energiekompensation - mehr geht nicht
Wenn ich eine einigermaßen nachbausichere Kombination mit den SDP habe, werde ich ein paar Bilder einstellen.
Den 4525 hängt man parallel zum MS5611 an i2c, dazu ein Hacker-Duplex Pitotrohr. Dann muss man noch ein Summensignal auf den RP bringen, also SBus, FBus oder TX vom Empfänger, je nach System. Im Sender wird ein Kanal konfiguriert, der die Umschaltung bzw. Einstellung macht.
Die eigentliche Energiekompensation wird gerechnet. Man hat also echte Höhe, echten Airspeed und eine vom Sender aus einstell- und abschaltbare Energiekompensation - mehr geht nicht
Wenn ich eine einigermaßen nachbausichere Kombination mit den SDP habe, werde ich ein paar Bilder einstellen.
Den 4525 hängt man parallel zum MS5611 an i2c, dazu ein Hacker-Duplex Pitotrohr. Dann muss man noch ein Summensignal auf den RP bringen, also SBus, FBus oder TX vom Empfänger, je nach System. Im Sender wird ein Kanal konfiguriert, der die Umschaltung bzw. Einstellung macht.
Hallo Bernd, hallo @Bussard,
das mit der Abendthermik habt ihr richtig beschrieben. Da muß man nicht weiter darüber diskutieren. Das würde auch nicht zu diesem Thema passen.
Ich habe konkret eine Differenz von 8cm/s in der Sinkgeschwindigkeit gemessen. In dem Sinne, daß abends die vs um diesen Betrag kleiner war, als bei der morgendlichen Messung. Der Unterschied ist ca. 25%!! Das ist KEIN brauchbares Messergebnis.
Aber das Thema Flugmessungen gehört überhaupt nicht hier her. Ich denke sowieso, daß außer uns beiden, in diesem Forum noch niemand Flugmessungen gemacht hat.
Ein Prandtl-Rohr selbst zu bauen, aus Messing- oder Alurohren dürfte nicht allzu schwierig sein. Voraussetzung dabei ist wohl die genaue Kenntnis der Abmessungen und die Lage der Bohrungen für den statischen Druck. Und da liegt dann wohl auch der "Hund" begraben! Ich habe in meinem ganzen Modellfliegerleben erst ein einziges Prandtl-Rohr in den Fingern gehabt und eingesetzt. Und das ist von Dir. Das habe ich ich aber immer noch nicht abschließend kalibriert.
Lange Rede, kurzer Sinn, wenn Du mir die Abmessungen eines Rohres bringst, baue ich Dir eines.
Ernst
das mit der Abendthermik habt ihr richtig beschrieben. Da muß man nicht weiter darüber diskutieren. Das würde auch nicht zu diesem Thema passen.
Ich habe konkret eine Differenz von 8cm/s in der Sinkgeschwindigkeit gemessen. In dem Sinne, daß abends die vs um diesen Betrag kleiner war, als bei der morgendlichen Messung. Der Unterschied ist ca. 25%!! Das ist KEIN brauchbares Messergebnis.
Aber das Thema Flugmessungen gehört überhaupt nicht hier her. Ich denke sowieso, daß außer uns beiden, in diesem Forum noch niemand Flugmessungen gemacht hat.
Ein Prandtl-Rohr selbst zu bauen, aus Messing- oder Alurohren dürfte nicht allzu schwierig sein. Voraussetzung dabei ist wohl die genaue Kenntnis der Abmessungen und die Lage der Bohrungen für den statischen Druck. Und da liegt dann wohl auch der "Hund" begraben! Ich habe in meinem ganzen Modellfliegerleben erst ein einziges Prandtl-Rohr in den Fingern gehabt und eingesetzt. Und das ist von Dir. Das habe ich ich aber immer noch nicht abschließend kalibriert.
Lange Rede, kurzer Sinn, wenn Du mir die Abmessungen eines Rohres bringst, baue ich Dir eines.
Ernst
Muss man eigentlich irgendwas beachten, ausser Sensor-IDs nicht doppelt zu haben, wenn man den oXs mit "normalen" Sport Sensoren mischen will? Und dann noch die Frage: Kann man da einfach ein Y-Kabel nehmen?
Ich frage weil in dem Modell isses bissl schwierig kabel erst zum einen, dann zum anderen Sensor zu ziehen. Da hatte ich einfach an nen Y-Kabel gedacht
Ich frage weil in dem Modell isses bissl schwierig kabel erst zum einen, dann zum anderen Sensor zu ziehen. Da hatte ich einfach an nen Y-Kabel gedacht
Genau so habe ich es jetzt auch am Laufen. Mein Denkfehler war, dass der "alte" Arduino-oXs immer die passende Sensor-ID gezogen hat. Ein Lagesensor hat mit ID 8 gesendet, ein Stromsensor mit ID 3 u.s.w..
Der RP-oXs belegt standardmäßig die ID 3, deswegen der Konflikt mit meinem FAS40 und mit dem Neuron-Regler beim Kollegen. Jetzt habe ich den RP in der config.h auf ID 9 konfiguriert, weil beim Kollegen die übliche 8 auch schon belegt war und neu kompiliert.
Der RP-oXs belegt standardmäßig die ID 3, deswegen der Konflikt mit meinem FAS40 und mit dem Neuron-Regler beim Kollegen. Jetzt habe ich den RP in der config.h auf ID 9 konfiguriert, weil beim Kollegen die übliche 8 auch schon belegt war und neu kompiliert.
Code:
#define SPORT_DEVICEID DATA_ID_ACC // this line defines the physical ID used by sport.
// default SPORT_SENSOR_ID use by some original frsky sensors
#define DATA_ID_VARIO 0x00 // = sensor 0 used for Vspeed, GPS long and lat as P1
#define DATA_ID_FLVSS 0xA1 // 1 used as P2
#define DATA_ID_FAS 0x22 // 2
#define DATA_ID_GPS 0x83 // 3 used as P3
#define DATA_ID_RPM 0xE4 // 4
#define DATA_ID_ACC 0x48 // 8 Achtung geändert, war 0x67 !! 8 + 1 = 9
//list of all possible 28 device ID codes (in sequence)
// 0x00,0xA1,0x22,0x83,0xE4,0x45,0xC6,0x67,0x48,0xE9,0x6A,0xCB,0xAC,0x0D,0x8E,0x2F,
// 0xD0,0x71,0xF2,0x53,0x34,0x95,0x16,0xB7,0x98,0x39,0xBA,0x1B
@Piperman hat mir gerade die ersten realen Flugmessungen mit dem Pitchsensor und verschiedenen Höhenrudertrimmungen geschickt. Das sieht sehr gediegen aus, der Sensor hat auch auf dem Schreibtisch schon einen guten Eindruck gemacht. Ich habe in der csv über 300 Frames mal den Mittelwert für stabile Flugphasen gebildet und in die Grafik eingetragen.
Wenn man jetzt noch den Offset ermittelt und in der csv abrechnet, bekommt man den exakten Anstellwinkel. Das dürfte wesentlich einfacher sein, als den Sensor im Modell auf 1/100 ° genau einzubauen.
Wenn man jetzt noch den Offset ermittelt und in der csv abrechnet, bekommt man den exakten Anstellwinkel. Das dürfte wesentlich einfacher sein, als den Sensor im Modell auf 1/100 ° genau einzubauen.
Es war eine Zeitlang relativ still um das Projekt. Jetzt bringt mstrens eine große Erweiterung an den Start - den oXs-Logger. Damit kann man onboard Sensordaten des oXs aufzeichnen. Mit ELRS kann das recht interessant werden, denn das CRSF-Protokoll setzt bekanntermaßen Grenzen und man will eventuell auch nicht zu viel Bandbreite für den Downlink opfern.
Der Logger wird mit einem separaten RP aufgebaut und kommuniziert über einen Pin mit dem openXsensor.
GitHub - mstrens/oXs_logger_arduino
Der Logger wird mit einem separaten RP aufgebaut und kommuniziert über einen Pin mit dem openXsensor.
GitHub - mstrens/oXs_logger_arduino
auf jeden Fall interessante Option! Muss ich mir mal genauer anschauen. Weißt du wie das mit einem PWM Empfänger ist, der das RP2040 Board nur als "Übersetzter" nutzt um ein GPS oder andere Sensoren anschließen zu können? Dass er die am Board angeschlossenen Sachen loggen kann ist klar, aber was mich interessieren würde ist ob der Empfänger da auch Infos weitergibt. Konkret zum Bsp die Radiomaster ELRS PWM Empfänger.
Ich glaube nicht, dass man ohne Eingriffe in die Empfängerfirmware irgendwelche internen Informationen an der seriellen Schnittstelle ausgeben kann. CRSF-TX liefert die Kanalinformationen und CRSF-RX nimmt die externe Telemetrie entgegen.
Du willst vermutlich die ELRS-Linkinfos mitzuloggen, falls tatsächlich mal die Strecke ausfällt? Man kann sich etwas behelfen, indem man die Lost Frames und die Failsafes aus dem SBus aufzeichnet. Die bildet der oXs aus den empfangenen Frames und kann sie an den Logger weitergeben.
Du willst vermutlich die ELRS-Linkinfos mitzuloggen, falls tatsächlich mal die Strecke ausfällt? Man kann sich etwas behelfen, indem man die Lost Frames und die Failsafes aus dem SBus aufzeichnet. Die bildet der oXs aus den empfangenen Frames und kann sie an den Logger weitergeben.
Grundsätzlich wären ein paar Daten aus dem Empfänger hilfreich, ja. Aktuell logge ich das über die Telemetrie am Sender mit.
Wir haben bei uns am Flugplatz leider immer wieder Störungen, was in Einzelfällen auch immer wieder zu Abstürzen führt. Leider betrifft das bis jetzt jedes System (Spektrum, FrySky, Jeti, Futaba,....). Bei ELRS konnte ich im Log kurze Störungen nachweisen, aber noch viel zu wenig Erfahrung um zu sehen ob ELRS da irgendwie besser ist als die anderen Systeme.
Von daher logge ich ganz gerne jeden Flug mit um die Sachen nachzuvollziehen. Jedoch hört das Log auf, sobald die Verbindung weg ist. Ein Onboard Logger sollte weiter aufzeichnen. Selbst wenn es zu einem Crash kommt, wären die Infos vielleicht hilfreich.
Konkret LQ von beiden Antennen und SNR würde ich gern loggen.
Wir haben bei uns am Flugplatz leider immer wieder Störungen, was in Einzelfällen auch immer wieder zu Abstürzen führt. Leider betrifft das bis jetzt jedes System (Spektrum, FrySky, Jeti, Futaba,....). Bei ELRS konnte ich im Log kurze Störungen nachweisen, aber noch viel zu wenig Erfahrung um zu sehen ob ELRS da irgendwie besser ist als die anderen Systeme.
Von daher logge ich ganz gerne jeden Flug mit um die Sachen nachzuvollziehen. Jedoch hört das Log auf, sobald die Verbindung weg ist. Ein Onboard Logger sollte weiter aufzeichnen. Selbst wenn es zu einem Crash kommt, wären die Infos vielleicht hilfreich.
Konkret LQ von beiden Antennen und SNR würde ich gern loggen.
Zuletzt bearbeitet:
