MSB / S-Port Telemetrie-Konverter

[Reinhardt Werbik]

Hi Kalle,

wie der Anleitung zu entnehmen ist ( ), ist der Sensor 8 die Kapazität auf MSB Adresse 4. Da es im S-Port Protokoll (außer für die kombinierten ESC Datenpakete, die ich rausgeschmissen habe) keine Application ID dafür gibt, wird sie als DIY Sensorwert übertragen.

 

[kalle123]

Ach Reinhardt, bitte nicht schlagen.

Pendle zwischen ERLS, Intel NUC und den Diskussionen im Debian Forum, hab mal schnell deine BETA zwischen geschoben. Bin halb am Einschlafen und hoffe, dass mich der Kaffee hier auf dem Tisch wieder einigermaßen wach rüttelt .....

cu KH

 

[kalle123]

Ich hab nachgeschaut Reinhardt ...



Bitte entschuldige die blöde Frage von mir, hätte mal eben nachschauen können. Du machst dir die Arbeit mit der Anleitung und ich werfe da noch nicht mal einen Blick drauf.

Grüße KH

 

[Reinhardt Werbik]

Mach Dir mal keinen Kopf, Kalle. Ehrlich gesagt mache ich die Anleitung nicht zuletzt für mich selbst, oder glaubst Du, ich kann mir das immer alles merken.

 

[Reinhardt Werbik]

Hallo zusammen,

nachdem es aktuell keine Fehler zu korrigieren gibt, habe ich mich an die Implementierung der letzten verbliebenen MSB Werteklasse gemacht (Werteklasse 14 = g-Rate mit Auflösung 0,1 g). Da der Multiplex g-Raten Sensor (warum auch immer) nur die x- und z-Richtung berücksichtigt, der Konverter aber auch dann funktionieren soll, wenn alle drei g-Raten vorhanden sind, wollte ich zuerst den einfachsten Weg gehen und die g-Raten mit DIY Application IDs übertragen. Da es aber geeignete S-Port IDs gibt, werde ich jetzt doch diese verwenden, was aber bedeutet, dass es eine Konvention bzgl. der verwendeten MSB Adressen geben muss, und zwar gelten folgende Regeln:
- Die g-Rate mit der niedrigsten MSB Adresse gehört zur x-Richtung
- Bei nur zwei vorhandenen g-Raten gehört die zweite zur z-Richtung
- Bei drei vorhandenen g-Raten gehört die zweitniedrigste MSB Adresse zur y-Richtung, die dritte Adresse zur z-Richtung
- Mehr als drei g-Raten werden nicht übertragen.

Ich werde das jetzt mal so implementieren, um zu sehen, wie aufwändig das wird. Zur Not kann ich ja immer noch auf die DIY IDs zurückgreifen.

Ich nehme an, es gibt keine Einwände gegen diese Implementierung.

 

[Reinhardt Werbik]

So, nachdem ich die g-Raten nun wie oben beschrieben eingebaut habe, haben sich zwei Probleme gezeigt.

Offensichtlich können sich, abhängig von der zeitlichen Abfolge des Auftauchens der g-Raten für die einzelnen Achsen auf dem MSB, die Daten IDs ändern. Wenn z.B. die zweitniedrigste MSB Adresse zuerst eine gültige g-Rate liefert, wird diese erstmal der x-Achse zugeordnet. Kommt dann die niedrigste MSB Adresse mit der g-Rate daher, kriegt die zweitniedrigste Adresse ja eine andere Achse, und damit Daten ID verpasst. Da die Daten ID sowohl die Achse, als auch die MSB Adresse codiert, bleibt eine Daten ID als "Sensorleiche" übrig, was ETHOS gnadenlos mit periodischem "Sensor verloren" quittiert. Man könnte das vielleicht mit intelligentem Timing/Hysterese irgendwie lösen, aber das ist sicher tricky und fehleranfällig.

Zumal es noch das zweite Problem gibt, nämlich den maximalen Wertebereich in ETHOS von -8g ... +8g. Das erlaubt es nicht, alle möglichen MSB Werte zu übertragen, und ich denke schon, dass im Flug zumindest für die z-Achse höhere g-Raten auftreten können, zum Beispiel beim Schuss während des Hochstarts eines F3B Modells.

Ich werde noch ein wenig weiter experimentieren, aber wahrscheinlich greift am Ende Plan B, sprich DIY IDs für die g-Raten. Das würde beide Probleme auf einmal lösen.

 

[kalle123]

Hallo Reinhardt, oXs kann zwar eine MPU6050 verarbeiten, aber nicht in dem MPX Sinn.
Soll ich mir mal so einen Sensor besorgen wegen zusätzlicher Testmöglichkeit? So langsam scheinen wir uns ja aus der beta Version raus zu bewegen.

Gruß KH

 

[Reinhardt Werbik]

Hallo Kalle,

die Umsetzung der MSB g-Raten auf die entsprechenden S-Port Parameter ist eigentlich trivial. Die Besonderheit besteht mit der obigen Implementierung darin, dass die Daten ID einer bestimmten MSB Adresse davon abhängt, was sich auf den anderen MSB Adressen tut. Das ist per se natürlich etwas komplexer. Mich würde aber schon interessieren, wie es zu dem von mir beschriebenen Phänomen kommt, da ich ja mit einer Testkonfiguration arbeite, die aller MSB Sensorparameter auf bestimmte konstante Werte festnagelt.

Wie gesagt, die DIY IDs würden das Problem aus der Welt schaffen, und wahrscheinlich werde ich wegen des eingeschränkten g Wertebereichs in ETHOS ohnehin auf diese umschwenken. Aktuell ist jedenfalls kein Bedarf für besondere Tests, kommt aber vielleicht noch.

 

[kalle123]

Hi Reinhardt, hab mir die MPX Seite des G-Sensors mal angeschaut. X-Achse relevant z.B. beim Bungee Start oder wenn der Flieger einschlägt, Z-Achse bei den entsprechenden Flugmanövern, aber Y-Achse??
Mir fällt da nur die Gilde der Fesselflieger ein, die so was brauchen könnten ....

Gruß KH

 

[Reinhardt Werbik]

Hi Kalle,

ja Du hast schon recht, der Wert für die y-Achse ist da weniger interessant. Ich habe aber im Netzt irgendwo mal einen Sensor (Eigenbau?) gesehen, der alle drei Achsen macht, der Konverter muss das in jedem Fall können.

Ich bin mittlerweile zu dem Schluss gekommen, dass man die speziellen IDs für die Beschleunigungen doch beibehalten kann. Die Sache mit den verwurschtelten MSB Adressen und "Geistersensoren" passiert nämlich nur sporadisch und typischerweise, wenn man die Sensorsuche für einen längeren Zeitraum laufen lässt. Da das aber in der Praxis nicht vorkommt, ist das Problem nicht wirklich relevant. Und sollte doch zufällig ein "Geistersensor" schon gleich am Anfang auftauchen, dann löscht man diesen einfach, bzw. wiederholt die ganze Sensorsuche. Aber ich werde noch etwas weiterforschen, denn mich würde schon interessieren, warum das in meinem klinischen Labor-Setup passiert.

Auch der eingeschränkte Wertebereich der S-Port IDs für die g-Raten lässt sich leicht umgehen. Wenn man mehr als +-8g messen will, legt man sich einfach für die interessierenden Achsen zusätzliche DIY Sensoren manuell an und gibt ihnen die Physical und Application IDs, die der Konverter verwendet, und schon hat man keine relevante Beschränkung der Werte mehr. Ich hatte irgendwie nicht auf dem Schirm, dass man einem manuell angelegten DIY Sensor ja jede beliebige ID zuordnen kann, nicht nur die DIY IDs.

Auf dieser Basis mache ich jetzt mal weiter, ich halte Euch auf dem Laufenden.

 

[Reinhardt Werbik]

Moin,

jetzt habe ich doch glatt durch eine simple Codeänderung etwa 250 kB Speicher eingespart.

Das habe ich zum Anlass genommen, mir eine schlaue Hysterese-Logik auszudenken und einzubauen, um das Auftreten von "Geistersensoren" bei den g-Raten zu unterdrücken. Ich habe nämlich herausgefunden, dass der MSB Master die Ursache war. Dieser setzt einzelne Sensoren auf ungültig, wenn sie eine bestimmte Anzahl von Abfragen nicht beantwortet haben. Und da ich ja keinen g-Raten Sensor angeschlossen habe, sondern mit festen Testdaten arbeite, überschreibt der MSB Master immer wieder die Gültigkeit der g-Raten. Die Gültigkeit wird dann zwar wiederhergestellt, aber solche kurzzeitigen Ungültigkeiten können dazu führen, dass die MSB Adressen durcheinandergebracht werden. In der Praxis, wenn echte Sensoren vorhanden sind, dürfte das Problem deutlich seltener auftreten, wenn überhaupt. Außerdem läuft die Sensorsuche ja nur einmal, und falls es tatsächlich "Geistersensoren" geben sollte, kann man die ja einfach wieder löschen. Vielleicht ist OpenTx da ja auch ein wenig robuster, das habe ich nicht getestet.

Ich denke, ich werde mir doch mal einen g-Raten Sensor zulegen, um den Konverter damit zu testen. Eine neue Beta-version stelle ich momentan noch nicht ein, die Zahl der Benutzter, die den Konverter in Verbindung mit einem Beschleunigungssensor einsetzte, dürfte jetzt nicht sooo hoch sein. Außerdem will ich noch ein bisschen mit der Hysterese-Logik spielen, bevor sie die endgültige Absolution bekommt.

 

[AndreasN]

Mein Angebot mit dem G-Sensor steht noch

 

[Reinhardt Werbik]

Mein Angebot mit dem G-Sensor steht noch

Habe Dir per PN meine Adresse geschickt.

 

[Reinhardt Werbik]

Andreas hat mich großzügigerweise mit einem neuen g-Raten Sensor gesponsort, der demnächst bei mir eintreffen wird.
Damit werde ich dann den Konverter testen und anschließend eine neue Version hier einstellen.

 

[Reinhardt Werbik]

Der g-Raten Sensor ist bereits da, ganz herzlichen Dank nochmal an Andreas.
Ich werde den jetzt zeitnah mit dem Konverter testen und dann eine neue Version hier einstellen.

Watch this space...

 

[AndreasN]

Super, freut mich. Gern geschehen.

Grüße Andreas

 

[Reinhardt Werbik]

Hallo zusammen,

hier mal ein kleiner Zwischenstand.

Ich habe den g-Raten Sensor aus der Schachtel heraus gleich an meinen Testaufbau gehängt. Wie erwartet, wurden eine x- und eine z-Beschleunigung angezeigt, aber beide mit dem Wert -1g. Hm, bei der z-Achse kann das ja noch sein, je nachdem ob man die Erdgravitation berücksichtig oder nicht, aber zweimal -1g? Ich habe dann in die Anleitung geschaut und gesehen, dass der Sensor defaultmäßig die z-Beschleunigung und deren Min./Max.-Wert auf den Adressen 5 und 6 ausgibt. Damit war klar, warum zweimal -1g angezeigt wurde.

Ich wollte dann den Sensor mit der Multimate umkonfigurieren, was aber nicht funktionierte. Die Sensorwerte auf den Adressen 5 und 6 werden nicht angezeigt, und man kommt nicht in das Einstellungsmenü. Ich dachte schon, das Teil hat eine Macke, aber dann ist mir eingefallen, dass die Werteklasse 14 nachträglich eingeführt wurde, bzw. in der offiziellen Schnittstellenbeschreibung auf der MPX Homepage immer noch fehlt. Somit ist vermutlich die Multimate mit dem g-Raten Sensor nicht kompatibel. Der letzte FW Update für die Multimate liegt ja auch schon 9 Jahre zurück, und in der Anleitung des Sensors wird die Multimate auch gar nicht erwähnt. Eigentlich ist das ein Witz, aber ist eben so.

Ich habe dann den Sensor mit dem MPX Launcher so umkonfiguriert, dass er nur die x- und z-Beschleunigungen, aber keine Min./Max.-Werte ausgibt. Und siehe da, x-Wert ist jetzt 0 und z-Wert -1g, das passt. Wenn man den Sensor hin-und herbewegt, zeigt er auch entsprechende Beschleunigungswerte an. Der Testaufbau läuft jetzt seit geraumer Zeit mit eingeschalteter Sensorsuche, ohne dass irgendwelche "Geistersensoren" aufgetaucht sind.

Die Hysterese-Logik scheint also soweit zu funktionieren, ich werde noch ein wenig rumtesten, aber ich denke, im Lauf der Woche kann ich eine neue Version zur Verfügung stellen.

 

[AndreasN]

Hallo Reinhard. Hattest du den G-Sensor nicht verkehrt rum. Richtige Anzeige sollte 1g sein oder liege ich da falsch.

Schau dir mal den Sensor mit dem MultiLauncher an. Da kannst du dem Sensor die neue Firmware verpassen und vieles einstellen. Auch Live lassen sich die Sensordaten sehen bzw überprüfen.

Grüße Andreas

 

[Reinhardt Werbik]

Hallo Andreas,
ist alles auch eine Definitionssache, wenn der Sensor mit der Beschriftung nach oben liegt, wird -1g angezeigt, dreht man ihn um, dann sind es +1g.
Ich habe zum Konfigurieren den MPX Launcher verwendet, ist der MultiLauncher etwas anderes?

 

[AndreasN]

Ah, das 8st das Gleiche. PC Programm von Multiplex.