MSB / S-Port Telemetrie-Konverter

Klar, nach Sulden am Ortler. Ist bereits unser zweiter Skiurlaub dieses Jahr, nach den Weihnachtsferien waren wir im Grödnertal. Das ist der Luxus des Vorruhestands, dass ich nicht mehr abwechselnd in diese beiden Skigebiete fahre, sondern jedes Jahr in beide. :D
 
Hallo Leute,

seit Samstag sind wir wieder zu Hause, nachdem wir einen megageilen Skiurlaub bei super Wetter verbracht haben. 🌞🎿

Ich habe jetzt nach längerer Zeit wieder in das Konverter-Projekt reingeschaut, und wie erwartet muss ich die letzten Änderungen erst mal wieder verinnerlichen (sprich kapieren, was ich da gemacht habe ;)).

Als nächsten Schritt mache ich dann einen neuen Release des alten D-Konverters. Das ist deswegen sinnvoll, weil einige Source Code Files identisch sind und mittlerweile (im Zuge der Entwicklung des neuen Konverters) geändert und optimiert wurden. Dann habe ich auch für den alten Konverter eine konfigurierte Version mit dem neuesten Stand aller Source Code Files. Das muss Euch aber nicht kümmern, da die Funktion des alten Konverters in keiner Weise betroffen ist. Die Änderungen waren ausschließlich Optimierungen, bzw. teilweise Ergänzungen für den neuen Konverter. Ich werde diese Version des D-Port Konverters daher auch nicht im RCN hochladen. Alle, die mir dem D-Protokoll Konverter arbeiten, können weiterhin die Version 1.20 vom 27. September 2022 verwenden. Die Version 1.30 wird nur auf meinem Notebook existieren.

Zum Schluss kommt dann die versprochene erste "offizielle" Version des neuen S-Port Konverters, die ich natürlich hier in diesem Thread hochladen werde. Ich werde wie gehabt beide Varianten für alle drei HW Standards (6 hex Files) zur Verfügung stellen. Momentan bin ich dabei, mein Excel File zur Dokumentation der Versionen zu überarbeiten, damit ich damit auch den S-Port Konverter abdecken kann. Danach geht's dann ins Eingemachte, sprich es steht ein ausführliches "Code Reading" an, um z.B. nicht mehr benötigte Anmerkungen, auskommentierte Code-Anteile, etc. zu entfernen, bevor die verschiedenen Varianten kompiliert, und die Code Files archiviert werden.

Watch this space...
 
Reinhardt, DAS (mit Edge!) hätte ich aber nicht von dir gedacht! :D

Schönen Urlaub wünsche ich dir - KH
Hallo Kalle,

ich habe mittlerweile einige in OpenTX erstellte Modelle auf meine X10S mit Edge übertragen, alles problemlos. Außerdem habe ich mir noch ein schönes Theme gebastelt mit dunklem Hintergrund, in Anlehnung an das Darkblue Theme von OpenTx. Ich habe nämlich schon zu OpenTX Zeiten festgestellt, dass die Lesbarkeit in Freien damit besser ist. Das gefällt mir alles recht gut, die für Touch überarbeitete Oberfläche macht auch auf der X10S einen guten Eindruck. Wenn mein Konverter soweit ist, werde ich die Version für das M-Link Modul in/an der X10S installieren.
 

kalle123

User
Hallo Reinhardt.

Schön von dir zu hören. Es geht also weiter!
Meine beiden Taranis lasse ich auf OTX 2.2.4. Da bringt OTX 2.3.15 und EdgeTX nix. Und die X10 lasse ich auf EdgeTX 2.7.1. Ohne touch bringt mir die 2.8.1 da nichts und die Menüstruktur erscheint mir so etwas kompakter.

Hab mir gerade eine einfache hot air Station zugelegt und übe fleißig! Aber bin überrascht, wie einfach das ist. Vielleicht mach ich auch nochmal neue PCBs für den MSB / S-Port Telemetrie-Konverter, aber dann mit Anschluss zu flashen. Hab Spass an solchen Frickeleien .... ;)

Grüße KH
 
Hallo Leute,

der konfigurierte Release des alten Konverters ist jetzt soweit fertig, alle Code Files sind eingefroren
Jetzt ist der neue S-Port Konverter dran, aber in diesbezüglich gibt es interessant Neuigkeiten.

Ich habe ja mittlerweile auf meiner X10S Express EdgeTX 2.8.1 laufen, da ich die überarbeitete Oberfläche recht gut finde.
Vor einigen Wochen habe ich mich mit unserem Vorsitzenden über EdgeTX unterhalten, und der war offenbar nicht untätig.
Er mir eine Testversion für die X10S zur Verfügung gestellt, in die er die Konvertierung der Telemetriedaten vom M-Link Modul eingebaut hat. :D
Man braucht also kein µC Board mehr, sondern muss nur den Signalausgang des Moduls mit dem S-Port Modul-Pin verbinden.
Ich habe diese Firmware heute getestet und sie funktioniert im Prinzip.

Es gibt noch einige Baustellen, z.B. kommen keine Daten vom g-Raten Sensor, aber das lässt sich sicher alles lösen.
Wenn dieses Feature tatsächlich in EdgeTX eingebaut wird (ich kann da nichts versprechen, da ich da nicht direkt involviert bin),
dann ist die Version meines Konverters zum Einbau in den Sender für EdgeTX User hinfällig.

Ich habe jetzt das Code Reading für den S-Port Konverter erst mal unterbrochen, um mich mit der EdgeTX Testversion zu befassen.
Aber keine Angst, so oder so werde ich den Konverter weiterpflegen, es gibt ja schließlich auch noch OpenTX.
Und die Variante für das Modell, zum Anschließen von MSB Sensoren an einen FrSky Empfänger, gibt es ja schließlich auch noch.

Ich halte Euch auf dem laufenden.
 

kalle123

User
Hallo Reinhardt.

Interessant, dann würde es also reichen, den Signalausgang des MPX Moduls im HFMG3 einfach durch zu schleifen.

Mal schaun, was da noch kommt. ;)

Grüße - KH
 
Hallo zusammen,

Bei der Durchsicht des Codes haben sich jetzt doch einige Änderungen aufgedrängt.

Die möglichen Rundungsfehler bei den Geschwindigkeiten lassen sich leider nicht vermeiden, da das S-Port Protokoll genau vorgibt, welche Gewichtung das LSB des Sensorwerts haben muss (0,1 kn für die Airspeed und 0,001 kn für die GPS Speed). Auf diese Skalierung muss der MSB Sensorwert (LSB = 0,1 km/h) umgerechnet werden, und da das eine Division durch 1,852 impliziert, muss auch gerundet werden. Wenn diese Werte dann im Sender wieder in km/h mit einer Auflösung von 0,1 km/h umskaliert werden, kann es halt sein, dass die Nachkommastelle vom MSB Wert um 1 abweicht. Das ist also kein Bug, sondern ein Feature. :D

Ich habe diese Besonderheiten jetzt in die Anleitung aufgenommen, die ich zusammen mit der nächsten Version im Verlauf der Woche hier einstellen werde.

Bis dahin...
Ich bin wieder auf diese Umrechnerei gestoßen, die ja im Sender wieder rückgängig gemacht werden muss, da wohl kaum jemand hier mit kn arbeitet. Ich habe daher beschlossen, die Application IDs für GPS Geschwindigkeiten rauszuschmeißen und die Daten mit DIY IDs auszugeben. Im Sender muss der Parameter so oder so editiert werden, und dann entfällt die doppelte Umrechnung. Das gleiche gilt für die True Air Speed, auch diese werde ich dann mit einer DIY App. ID ausgeben. Das hat den zusätzlichen Vorteil, dass man keine vordefinierte Adresse für die TAS mehr braucht, da sie der Konverter nicht mehr anders behandelt wie die anderen Geschwindigkeiten.

Bei den Daten mit Werteklasse 7 (Richtung) werde ich ebenfalls DIY App. IDs (statt der IDs für GPS Course) verwenden. Es gibt alle möglichen Richtungen vom Multiplex GPS, so dass der Default Name ohnehin meistens nicht passt, und die Nachkommastellen muss man auch in jedem Fall anpassen. Dann kann ich auch gleich eine DIY ID nehmen.

Auch bei der Werteklasse 8 (Höhe oder kurze Distanz) werde ich die Sache vereinfachen. Ein Parameter mit dieser Werteklasse auf Adresse 6 wird weiter als Baro-Höhe ausgegeben. Das macht Sinn, da diese eine andere Physical ID hat wegen der Update Rate. Aber die vordefinierte Adresse für eine GPS Höhe werde ich rausschmeißen und diese (wie alle sonstigen Parameter mit dieser Werteklasse) als DIY Parameter übertragen.

Mit diesen Änderungen entfällt auch die Sinnhaftigkeit einer gesonderten Physical ID für GPS Daten. Diese wird somit entfallen, und alles, außer Baro-Höhe und Steigrate, kommt mit derselben Physical ID daher. Baro-Höhe und Steigrate behalten ihre eigene Physical ID, damit deren Übertragungsrate schön hoch bleibt.

Einwände gegen diese geplante Änderungen können wir gerne hier diskutieren, aber ich fange schon mal an... ;)
Der Speicherbedarf dürfte sich dadurch auch reduzieren, was uns wieder etwas Luft im Hinblick auf den 841er gibt.
Außerdem reduziert sich durch diese Änderungen insgesamt das Risiko eines Konflikts mit anderen Sensoren am S-Port.

Über die Behandlung der g-Raten werde ich auch nochmal nachdenken. Da gibt es auch gute Gründe, diese mit einer DIY App. ID zu übertragen.

Wenn mir noch mehr einfällt, melde ich mich.
 
So, die oben beschriebenen Änderungen habe ich eingebaut, jetzt muss ich natürlich noch die Anleitung anpassen.

Was die g-Raten betrifft, so werde ich auch hier den Konverter vereinfachen. Ich werde aber keine DIY App. IDs verwenden, sondern alle g-Raten werden zukünftig mit einer App. ID aus dem S-Port ID Bereich für die x-Achse übertragen (von denen es ja auch 16 gibt). Dann erkennt man sofort, welche Parameter g-Raten sind und muss nur die Namen so anpassen, dass sie die Achsen der auf dem MSB vorhandenen g-Raten reflektieren. Die MSB Adresse ist ja wie bei allen anderen Parametern direkt aus der App. ID ersichtlich. Es entfällt die komplizierte Mimik, um eine veränderliche Anzahl von g-Raten auf dem MSB immer den richtigen Achsen zuzuordnen, so dass man auch keine Regeln mehr bei der Vergabe der MSB Adressen beachten muss. Außerdem entfällt auch die Beschränkung auf maximal drei Parameter mit dieser Werteklasse. Alles in allem ist das m.E. eine deutlich praxisgerechtere Lösung.

Na dann ans Werk...
 
Ich habe jetzt alle Änderungen eingebaut, und das hat glatt 2kB, also etwa ein Drittel an Speicher gespart.
Jetzt ist auch beim 841er wieder etwas Luft nach oben. :cool:

Jetzt muss ich natürlich noch testen...
 
Hallo zusammen,

hier mal ein kurzer Zwischenstand zum Konverter.

Ich habe jetzt im Zuge des Austauschs mit meinem Vereinskollegen, der eine Testversion von Edge mit Einlesen der Telemetriedaten vom M-Link Modul gemacht hat, einige Verbesserungen in den Konverter eingebaut, die teilweise auch den alten Konverter betreffen, z.B. die Prüfung der Checksumme im M-Link Datenpaket. Dabei hat sich witzigerweise herausgestellt, dass im Konverter seit Jahren (schon immer) ein Fehler drin ist, der dazu führt, dass die letzten paar Bytes des Datenpakets gar nicht eingelesen werden. Das hatte aber keinerlei Auswirkungen, da in diesen Bytes keine Daten sind, die der Konverter verwendet. Aber das letzte Byte der Daten vor dem End Byte ist eben die Checksumme, und als ich die jetzt eingebaut habe, kam der Fehler zu Tage. :eek:

Sei's drum, jetzt ist das alles korrekt, mit Prüfung der Checksumme, auch wenn es bisher auch ohne völlig problemlos lief. Es wird aber den Release der 'offiziellen' Version etwas verzögern. ;)

Ich habe in der Diskussion mit meinem Kollegen viel Interessantes erfahren, was mich noch mehr überzeugt hat, dass OpenTX ein Auslaufmodell ist. Was EdgeTX angeht, da sind einige Dinge grundlegend anders gemacht, was auch die Zukunftsfähigkeit sicherstellen soll. Man darf aber halt auch nicht vergessen, dass OpenTX schon eine Dekade alt ist und ursprünglich für die 8-Bit ATmel µCs geschrieben wurde.

Leider gibt es auch bei EdgeTX einen Pferdefuß, was den Konverter angeht. Dieser funktioniert damit ab der Version 2.9 nicht mehr, schlicht und einfach. Die technischen Gründe hier genau zu erläutern, das würde zu weit führen. Aber wenn es uns gelingt, die Konverter-Funktionalität aus dem derzeitigen Fork meines Kollegen in den Mainstream zurückzuführen, dann können wir das leicht verschmerzen.

In diesem Sinne...
 

kalle123

User
Hallo Reinhardt.

Interessante Neuigkeiten, die du da hast.

- die Nichtauswertung der letzten Bytes in derzeitigen Konverter. Never mind ;)

- das bei OTX nix mehr kommen wird, war mir schon ne ganze Zeit klar. Trotzdem wird derjenige, der mit OTX weiterhin fliegt auch keine Probleme haben. Die zwei Taranis Sender hier bleiben auf OTX 2.2.4!

- zu EdgeTX 2.9 ... Mal schauen, wann und was da schlussendlich kommt ....

Grüße - KH
 

Gast_92971

User gesperrt
Servus,
Reinhardt hat mich gerade auf das Projekt aufmerksam gemacht. Da mir im Moment mit Kind ( Vollzeit Daddy) die Zeit fehlt, wäre jemand bereit mir Do ein MBS auf Sbus Konverter zu bespielen oder fertig abzudrücken? Würde gerne von einem IBEX Regler die Telemetrie auf einer Frsky x18 und Xe nutzen können.
Falls sich jemand dazu bereit erklären würde würde ich mich über eine PN freuen,

Gruß Martin
 
Hallo zusammen,

ich bin derzeit ganz intensiv mit dem Konverter Projekt zu Gange, um den Code des Konverters zu überarbeiten. Nach den Verbesserungen, die ich ins M-Link Interface eingebaut habe, habe ich nämlich beschlossen, auch die anderen Code Module (die ich teilweise seit ewiger Zeit nicht mehr angefasst habe) durchzugehen und zu "modernisieren". Das hat meistens mit der Optimierung der Interrupt Service Routinen zu tun, in denen teilweise Dinge reingepackt waren, die besser außerhalb passieren. Außerdem ist es so, dass die ISRs wegen der verschiedenen HW Varianten immer mehrfach existieren. Wenn da dann Code drinsteckt, der gar nicht HW-abhängig ist, dann hat man überflüssige Duplizierungen, die mir schon länger ein Dorn im Auge sind. Das arbeite ich jetzt alles sauber durch und teste zwischendurch immer wieder mal kurz, damit das Teil am Ende auch noch funktioniert. ;)

Ich werde, wenn ich soweit durch bin, dann doch nochmal eine "Betaversion" hier einstellen. Die konfigurierte Version (die übrigens 2.0 heißen wird, um sofort zu sehen, dass es der neue Konverter ist), kommt dann, wenn die zahlreichen Änderungen auf der Code-Ebene ausreichend getestet sind. Da die neue Version ja auch die weiter oben beschriebenen funktionalen Änderungen hat (sprich teilweise andere Physical und Application IDs benutzt), will ich mit ihrer Veröffentlichung nicht mehr zu lange warten. Denn sie hat zur Folge, dass man teilweise die Sensoren neu einlesen muss, wenn man vorher die Version vom November verwendet hat. Das mache ich lieber jetzt, wo noch keine Flugsaison ist. Für die offizielle Version sind keine funktionalen Änderungen mehr geplant, so dass ein Update auf diese die Telemetrie-Setups nicht mehr beeinflussen wird.

Parallel teste ich immer wieder Testversionen des EdgeTX Forks, der die Verarbeitung der Telemetriedaten vom M-Link Modul drin hat, da gibt es noch ein/zwei hartnäckige Probleme. Aber ich habe dabei schon eine Menge gelernt.

So, jetzt aber schnell das Microchip Studio angeschmissen und frisch ans Werk...

@Martin:
Wenn Du noch niemanden gefunden hast, ich kann Dir gerne einen oder mehrere Boards mit der Firmware bespielen (idealerweise gleich mit der überarbeiteten Version). Für die Anwendung als MSB/S.Port Konverter an einem FrSky Empfänger empfehle ich Dir, die 16MHz Variante des Pro Mini zu besorgen. Die Mindestspannung von 4,5V für 16MHz Taktfrequenz ist ja im Modell immer erfüllt (wenn es sich nicht gerade um einen DLG mit einer Lipozelle handelt), und dann hast Du etwas größere Performance Reserven. Wenn Du sie mir mit einem frankierten Rückumschlag zuschickst, flashe ich sie und schicke sie zurück. Die Details können wir gerne per PM klären.
 
Hier ist ein kleiner Teaser, was evtl. für EdgeTX kommen könnte.

image001.png


Dann wäre die Konverter Variante (2) für Edge Tx hinfällig, aber das könnte ich leicht verschmerzen. ;)
 
Das ist ja super!

Wäre es vielleicht möglich, auch das zu händern, dass man bei den Outputs nicht -107 bis +107 einstellen muss, damit man 100% der Ruderausschläge erreicht? Das wäre perfekt. Beim MultiProtocol-Modul ist es bereits so.

Vielen Dank und Grüße

Andreas
 
Hallo Andreas,

ich habe mit der Programmierung von Edge selbst nichts zu tun, das Bild hat mir ein Bekannter geschickt, der derzeit an einer experimentellen Version zum Einlesen der Telemetriedaten direkt vom M-Link Modul arbeitet. (Es ist auch keineswegs sicher, dass das irgendwann einmal in die offizielle Version einfließt.)

Ich glaube aber nicht, das eine solche Änderung sinnvoll wäre. Die 107% kommen daher, dass FrSky Sender schon immer bei 100% Servoweg eine Impulsbreite von 512µs erzeugen (völlig unabhängig vom benutzten HF-Modul), während das bei Multiplex 550µs sind. Ich halte es für keine gute Idee, den Servo-Output eines Senders abhängig davon zu machen, welche HF-Strecke aktiv ist. Stell Dir nur mal vor, Du möchtest ein Modell von Multiplex auf FrSky (oder umgekehrt) umstellen, dann müsstest Du alle Servowege ändern. Wenn man ein Modell von einem Multiplex Sender auf einen FrSky Sender migriert (ich habe das schon sehr oft getan), dann muss man eben die Servowege einmalig an die FrSky Norm anpassen.
 
Da hast du Recht Reinhard!

Wie machst du das genau, wenn du ein Modell von Multiplex auf FrSky migrierst bzw auf FrSky-Norm anpasst?

Stellst du einfach bei Outputs 7 Punkte überall zurück? Reicht das?

Danke und Grüße
 
Man muss bei den Outputs überall mit 550/512 multiplizieren, das ist etwa 1,07. Natürlich muss man auch die ganzen Mischer migrieren, aber wenn man die Outputs anpasst, dann sind die Mischanteile prozentual gleich. Ich prüfe das immer mit dem Kanalmonitor bei den beiden Sendern, wobei man natürlich auch den Faktor 1,07 berücksichtigen muss. Aber so habe ich die meisten Modelle migriert, ohne vom Schreibtisch aufzustehen. :D
 
Ansicht hell / dunkel umschalten
Oben Unten