Hallo zusammen,
jetzt hat sich im GitHub ja auch ein Jetianer zu Wort gemeldet.
Mir war immer klar, dass die Tage des alten FrSky D-Protokolls irgendwann gezählt sein würden. Man kann einfach nicht erwarten, dass dieses alte Protokoll für immer und ewig unterstützt wird, und man kann da schwerlich mit ein paar selbstgebauter Konverter argumentieren, das wird den OpenTx/Edge Entwicklern vermutlich sonst wo vorbei gehen.
Ich selbst benutze den Konverter eigentlich fast gar nicht mehr, da meine Hauptsender mit ETHOS laufen, wo er in seiner jetzigen Form mit Sicherheit nicht unterstützt wird. Und da braucht man gar nicht erst anfragen, die würden einen für verrückt erklären, wenn man nach dem alten D-Protokoll verlangen würde. Ich will aber das Projekt jetzt nicht einfach begraben, da mich das C-Programmieren immer noch reizt, und ich da eigentlich schon irgendwie weitermachen möchte.
Da ich seit einigen Wochen ein neues Notebook habe, und ich auf diesem das neueste Atmel Studio (heißt jetzt Microchip Studio) installiert habe, suche ich natürlich nach einer sinnvollen Beschäftigungsmöglichkeit dafür. Als erstes habe ich daher das bestehende Konverter Projekt aufgeräumt und die Kommentierung vervollständigt. Ich hatte ja, wie schon öfter erwähnt, die bedingte Kompilierung für verschiedene Boards und sonstige Optionen eingeführt, um die Redundanz im Source Code zu eliminieren.
Was also als nächstes angehen? Nun, ich habe bereits alle meine Motorflieger auf FrSky umgestellt, während die Segler noch alle mit M-Link fliegen, was bei den Bestandsmodellen auch so bleiben wird. Ich habe aber jetzt einige MSB-Sensoren von den Motorfliegern rumliegen, die ich eigentlich nicht verscherbeln will. Ich habe mich daher entschlossen, als nächstes C-Projekt einen Konverter zu machen, um MSB Sensoren am S-Port von FrSky Empfängern betreiben zu können. Ich wollte mich schon lange näher mit dem S-Port Protokoll beschäftigen, und das ist jetzt eine gute Gelegenheit dafür. Ich habe die Programmstruktur auch schon soweit fertig, aber der Code ist natürlich noch bei weitem nicht vollständig.
Ein MSB/S-Port Konverter per se dürfte nur für ganz wenige Anwender (z.B. mich
) interessant sein, da die S-Port Sensoren günstiger zu haben sind, und das sehr häufig eingesetzte UniSense-E FrSky direkt unterstützt.
Aaaaber: Wenn dieser Konverter mal läuft, bietet es sich natürlich an, das darin enthaltene S-Port Interface für einen Upgrade unseres bisherigen Konverters zu nutzen und eine S-Port fähige Version daraus zu basteln. Ich muss allerdings gleich vorwegschicken, dass das auf Grund der deutlichen Unterschiede zwischen den beiden Protokollen kein universeller Konverter sein kann, der alle denkbaren MSB Konfigurationen in eine entsprechende S-Port Sensorik umsetzen kann. Das ist aber auch gar nicht nötig, und einiges wird sich auch vereinfachen, da sich z.B. die Frage mit/ohne FrSky IDs gar nicht stellt, da das S-Port Protokoll immer mit definierten Daten IDs arbeitet.
Letztlich ist auch immer noch nicht abschließend geklärt, ob man bei ETHOS Telemetriedaten im S-Port Format einspeisen kann, wenn ein externes Modul mit PPM angesteuert wird. Vielleicht muss ich da einfach mal meinen Oszi an die Horus hängen. Das schöne am S-Port ist ja, dass der Busmaster pollen muss, was man am Oszi sehen würde. Wenn das mit ETHOS ginge, bekäme das neue Projekt einen ganz anderen Fokus.
Soweit jetzt erst mal von mir zu diesem Thema.
