MSB / S-Port Telemetrie-Konverter

Hallo zusammen,

hier ist also der neue Thread zum MSB / S-Port Konverter. Da es eine andere Anwendung (im Modell) ist, und der "alte" Thread ohnehin schon recht monströs geworden ist, ist es wohl besser, für die neue Anwendung neu zu starten. Zumal der Interessentenkreis vermutlich recht überschaubar bleiben wird. Ich habe mal meinen letzten Post aus dem alten Thread als Startpunkt hier reinkopiert.

Hallo zusammen,

der MSB/S-Port Konverter läuft jetzt soweit, bis auf ein paar Kleinigkeiten. Damit ein Parallelbetrieb mit originalen FrSky Sensoren möglich ist, verwendet der Konverter andere Sensor (Physical) IDs. Folgende Sensor IDs werden emuliert und zur Übertragung der aufgelisteten Parameter verwendet. Dabei können außer den Reglerparametern alle Parameter mehrfach vorkommen.

ID 10: Höhe, Steigrate
ID 11: Parameter vom Regler (Spannung, Strom, Ladung, Drehzahl, Temperatur)
ID 12: Spannung, Strom, Ladung, Drehzahl, Temperatur, Füllstand
ID 24: RSSI, Empfängerspannung
ID 26: VFR (Valid Frame Rate, durch M-Link LQI ersetzt)

Die Verwendung einer eigenen Sensor ID für die Variodaten optimiert deren Datenrate (das ist z.B. beim UniSense anders, da er alles unter einer einzigen ID ausgibt). Die Sensor IDs für die Parameter vom Empfänger sind fest vorgegeben.

Parameter, die normalerweise vom FrSky Neuron Regler kommen, werden teilweise als Paar in einem einzigen S-Port Datenpaket übertragen, was der Datenrate zugute kommt. Soll der Konverter das tun, müssen die entsprechenden Parameter auf dem MSB mit fest vorgegebenen Adressen vorhanden sein, um sie von anderen Parametern mit gleicher Werteklasse unterscheiden zu können.

Neben den Reglerparametern ist nur noch für die Empfängerspannung eine vordefinierte MSB Adresse nötig (da sie sonst nicht von anderen Spannungen auf dem MSB unterscheidbar wäre), ansonsten gibt es keine Beschränkungen bei der Wahl der MSB Adressen.

Das S-Port Interface kombiniert eigentlich die Vorteile der beiden bisherigen Konverter-Versionen für den Sender (mit/ohne vordefinierte FrSky IDs). Das ist möglich, da es für jede Parameterart einen ganzen Bereich von Daten IDs gibt. Daher hätte die Umstellung auf S-Port auch für den bisherigen Konverter deutliche Vorteile.

Es ist übrigens durchaus nicht so, dass der neue Konverter nur für die Verwendung von Multiplex Sensoren Sinn macht. Es gibt nämlich auch andere Produkte, die zwar den MSB, aber nicht FrSky S-Port unterstützen. Selbst für den UniSense kann es vorteilhaft sein, ihn für MSB zu konfigurieren und dann den Konverter nachzuschalten. Dann kann man z.B. einzelne Parameter, die man nicht braucht abschalten, was in der FrSky Konfiguration nicht geht.

Ich werde weiter berichten...
 
Ich bin dabei.
Mein Plan ist den Konverter bei einem YGE xxLVT zu nutzen, da es das Texy derzeit nicht für die ursprünglichen 39 € mehr gibt.
Wenn Du eine Vorabversion hast, würde ich die ausprobieren.

Gruß
Christoph
 
Hallo Kalle,

natürlich wird es immer noch Pro Mini (8MHz oder 16MHz) sein, alles andere wäre ein Overkill. :cool:

Eine Variante für den ATtiny841 habe ich noch nicht, das kommt aber später noch, da ja doch einige einen solchen µC ins M-Link Modul eingebaut haben. Hier soll es zwar um den Konverter im Modell gehen, aber unser guter alter Konverter mit D-Protokoll wird natürlich auch auf S-Port hochgepäppelt. Und da der Code für die S-Port Seite für beide Konverter völlig identisch sein wird, muss es zu gegebener Zeit auch eine t841 Version geben.

Es wird einen kleinen Pferdefuß beim Hochrüsten des alten Konverters geben, und zwar wird der Pin an dem die Telemetriedaten rauskommen ein anderer sein (müssen). Der jetzt verwendete Pin ist nämlich der Tx Ausgang des HW UARTs, und da beim neuen Konverter derselbige für den MSB verwendet wird, muss der S-Port woanders hin.
 
Kleiner Nachtrag:
Ich werde hier erst mal nur Versionen für 8MHz Boards zur Verfügung stellen, da diese einen 3,3V Spannungsregler haben und daher auch den korrekten Pegel von 3,3V für das S-Port Signal liefern. Dann müssen wir nicht diskutieren, was passiert, wenn man einen FrSky Empfänger am S-Port mit TTL Pegeln beaufschlagt. ;)
(Für Boards mit dem t841 gab es ohnehin schon immer nur 8MHz Versionen für den "alten" Konverter.)
 
Hallo zusammen,

ich habe jetzt eine erste Version des MSB/S-Port Konverters am laufen, und zwar auf einem Pro Mini mit ATmega328, 8MHz Takt und 3,3V On-Board Spannungsregler (Wattuino Pro Mini von Watterott Electronic). Aktuell habe ich einen Multiplex Stromsensor und einen UniSense angeschlossen, die zusammen immerhin 9 MSB Adressen belegen. Alle Parameter werden einwandfrei von meiner Horus X10S Express mit ETHOS 1.1.2 erkannt und angezeigt. Ich werde jetzt noch ein wenig weitertesten, bevor ich eine erste Testversion hier als hex File einstelle. Falls jemand Interesse hat und sich schon mal ein Board vorbereiten will, die Belegung der I/O Pins ist wie folgt.

D0/D1 (USART Tx/Rx) -> MSB
D3 -> S-Port
B5 -> Status LED (auf dem Board schon drauf)

Hier eine kurze Beschreibung der wichtigsten Features der derzeitigen Version.

Damit ein Parallelbetrieb mit originalen FrSky Sensoren möglich ist, verwendet der Konverter andere Sensor (Physical) IDs.
0x0A: Spannung, Strom, Ladung, Drehzahl, Temperatur, Füllstand in %, Volumen (jeweils mehrfach)
0x0B: Höhe, Steigrate (jeweils mehrfach)
0x0C: Parameter vom Regler (jeweils einmal Spannung, Strom, Ladung, Drehzahl, Temperatur)

Jeder MSB Parameter wird mit einer zu seiner Werteklasse passenden Daten ID übertragen, von denen es immer mehrere gibt. Die Daten ID wird in der Regel gebildet wird, indem zur ersten Daten ID des entsprechenden Bereichs die MSB Adresse addiert wird. Dadurch kann man im Sender leicht aus der Daten ID die MSB Adresse des zugehörigen MSB Sensorwerts erkennen.

Parameter, die normalerweise vom FrSky Neuron Regler kommen, haben spezielle Daten ID Bereiche. Soll der Konverter diese benutzen, müssen die entsprechenden Parameter auf dem MSB mit fest vorgegebenen MSB Adressen vorhanden sein, um sie von anderen Parametern mit gleicher MSB Werteklasse unterscheiden zu können. Der Vorteil dabei ist, dass dann Spannung/Strom und Drehzahl/Ladung jeweils als Paar in einem S-Port Paket übertragen werden, was der Datenrate zugute kommt. Hier wird dann immer die erste Daten ID aus dem entsprechenden Bereich verwendet.

Parameter vom Empfänge (RSSI, VFR und Empfängerspannung) spielen für den Konverter im Modell keine Rolle, da sie vom FrSky Empfänger selbst erzeugt werden. Sie sind aber im S-Port Anteil des Codes schon berücksichtigt, damit dieser dann später leicht für einen Upgrade des "alten" Telemetriekonverters auf S-Port verwendet werden kann.

Soviel im Moment zu diesem Thema.
 

kalle123

User
Hallo Reinhardt. Ja ich weiß, der Nanite 841 ist zur Zeit nicht erhältlich und ober der nochmal aufgelegt wird? Aber ich würde irgendwann gerne auch die 841er (Andreas hat 3 und ich habe 2 hier, wie viele sonst noch in Gebrauch sind ??) auf die S-Port Variante umflashen ....

Grüße KH
 
Hallo Kalle,

wenn die Version des MSB/S-Port Konverters für FrSky Empfänger jetzt dann mal soweit fertig ist (mache gerade noch ein wenig Fine Tuning), kommt als nächstes die t841 Variante für diesen Konverter, sprich das S-Port Interface wird für den t841 umgeschrieben. Das ist für diesen Konverter viel einfacher, da ich zum Testen den Konverter nirgends einbauen muss.

Danach kommt dann unser "alter" Konverter dran, in den das S-Port Interface integriert werden muss. Die Pinbelegung ergibt sich dabei praktisch von selbst aus den Interrupts, die ich dann für die beiden SW UARTs brauche, und der Forderung, dass kein Pull-Up an diesen Pins sein darf. Sehr wahrscheinlich wird es folgende Pin-Belegung für die S-Port Variante, die dann irgendwann als V2.0 erscheinen wird.

Pins.png
 

kalle123

User
Hallo Reinhardt.

Hab mich gerade daran gesetzt und einen ATTiny mit dem micronucleus bootloader geflashed und schnell mal die Schaltung aufgebaut.

Flashen des bootloaders (USBasp) und upload BLINK (USB) von der Arduino IDE aus. Absolut problemlos. An der Schaltung selbst ist ja nicht viel dran. Und ein Micro USB Anschluss müsste noch auf einem PCB von Hand lötbar sein (bei USB C hab ich da so meine Zweifel). Aber ob sich da ein PCB Entwurf lohnt? Wohl kaum ....

Werde mich etwas mit dem eigentlichen micronucleus Paket geschäftigen, da finden sich ja div. tools.

Das schöne, wenn du das aus der Arduino IDE machst, du brauchst dich um Einzelheiten nicht zu kümmern. Der bootloader liegt ja hier wohl nicht in einem geschützten Bereich.

Grüße KH
 

Anhänge

  • 20220406_162621.jpg
    20220406_162621.jpg
    195,5 KB · Aufrufe: 148
Hallo Kalle,

ich habe es heute geschafft, den auf den ATtiny841 portierten MSB/S-Port Konverter zum Laufen zu bringen. Ich habe dafür eine Nanite 841 Board benutzt, das aber für einen praktischen Einsatz im Modell nicht geeignet ist, da es keinen Spannungsregler hat. Diese Version war ja auch als Zwischenschritt für eine S-Port Version unseres "alten" Konverters für das M-Link Modul gedacht. Nachdem das S-Port Interface jetzt läuft, werde ich dieses, wie versprochen, in den "alten" Konverter integrieren, damit dieser endlich S-Port fähig wird.

Die Atmega328 Version des MSB/S-Port Konverters für den Einsatz im Modell werde ich demnächst hier zur Verfügung stellen (8MHz Taktfrequenz). Ich habe damit gewartet, bis ich die Portierung auf den ATtiny abgeschlossen hatte, da sich dabei meistens gewisse Verbesserungen ergeben (und so war es auch hier).

Da muss ich dann auch meine Taranis X9D zum Testen aus dem Keller holen, denn meine Horus läuft mittlerweile mit ETHOS, und das soll auch so bleiben. Wie in alten Zeiten ... ;)
 

kalle123

User
Hallo Reinhardt,
warum ein Spannungsregler beim 841, wir holen doch die Versorgung vom HFMG3?

Gruß KH
 

Anhänge

  • Konverter HFMG3_1.jpg
    Konverter HFMG3_1.jpg
    427,6 KB · Aufrufe: 106
Hallo Kalle,

der neue Konverter dient ja erst mal zur Anbindung des MSB an den S-Port eines FrSky Empfängers im Modell. Und da gibt es normalerweise keine 3,3V, sondern irgendwas zwischen 5V und 8,4V.

Wenn ich das S-Port Interface in den "alten" Konverter integriert habe, kann dieser natürlich wie bisher auch direkt vom M-Link Modul versorgt werden, somit ist auch der Einsatz des ATtiny841 kein Problem.
 

kalle123

User
Dank dir für die Klarstellung, Reinhardt.

Ich spiele derweil noch was mit dem micronucleus .... Ist zwar ganz nett, aber meine ganz persönliche Meinung als Laie, mit nem ISP geht es einfacher und auch direkter, einen Code auf einen ATTiny zu kriegen.

Frohes Schaffen noch - KH
 
Also da würde ich Dir glatt widersprechen, Kalle. :cool:
Wenn man weiß, wie es geht, ist das mit dem Micronucleus ganz easy. Allerdings hat er eine Besonderheit, die man unbedingt kennen muss. Und zwar muss man zum Aktivieren des Bootloaders einen Reset machen, sonst wird er nicht aktiv. Als ich letztes Jahr den Micronucleus nach Jahren wieder mal zum Flashen verwenden wollte, bin ich daran fast verzweifelt, da ich es schlichtweg vergessen hatte.
Es gibt ja mittlerweile auch eine Optiboot Version für den ATtiny841, vielleicht probiere ich den gelegentlich mal aus.
 

kalle123

User
Optiboot ist aber wohl seriell, Reinhardt?!

Mit dem reset drücken hatte ich recht schnell raus, nur dann hab ich mit CLI commands 'rumgespielt' und weg war der bootloader.
Hab um 23:30 dann frustriert aufgegeben und heute morgen, ne Stunde, dann lief das Ding wieder.

Trotzdem USBasp auf den Tisch, MOSI, MISO, SCK und RST dran und gut isses ;)

Gruß KH
 
Hallo zusammen,

wenn jemand den Konverter testen möchte, hier ist eine erste Vorabversion für den ATmega328 mit 8MHz Taktfrequenz.
Die Endung .txt ist wie üblich zu entfernen, weitere benötigte Infos stehen im Post #6 weiter oben.

Rückmeldungen nehme ich gerne hier entgegen.

@kalle:
Ich werde jetzt als nächstes unseren "alten" Konverter auf S-Port umstellen und dann dafür eine Testversion veröffentlichen.
Ich denke, wir sollten alles, was mit dem Konverter für den Sender zu tun hat, im alten Thread behandeln, oder was meinst Du?
Ich würde dann dort auch die Files einstellen, dann haben wir eine klare Trennung zwischen Konverter im Sender (M-Link Funkstrecke) und Konverter im Modell (FrSky Funkstrecke).
 

Anhänge

  • MSB_SPort_Konverter_Beta_2022-04-08.hex.txt
    12,7 KB · Aufrufe: 131
Hallo Reinhardt,
absolut tolle Sache, die Du da umsetzt ! Deine 8Mhz SW Konverter Version im Atmega328/8MHz und eingebaut im HFMG3 Modul betreibe ich ja schon seit Jahren mit äußerster Zufriedenheit !
Dass ich jetzt auch die MPX Sensoren am FrSky SPort betreiben kann ist top und würde ich umgehend ausprobieren.
Kannst Du eventuell nochmal die Pinbelegung der Anschlüsse MSB -> Konverter -> SPort kurz aufzeigen ?
Dein #6 also
D0/D1 (USART Tx/Rx) -> MSB
D3 -> S-Port
hab ich nicht ganz verstanden.
D3 vom ATMega geht zum SPort als Signal. Aber wird das MSB Signal bei D0 und D1 am ATMega eingespeist, Der MSB Sensor hat ja nur Signal/+/- ???
Sorry für die zugegeben dämliche Nachfrage, bin da gedanklich noch nicht ganz drin.
Und funktioniert neben Vario und Stromsensor auch GPS ??
Vielen Dank !
Wolfram
 

kalle123

User
Hallo Reinhardt, wo die Senderrelevanten Sachen gepostet werden, up to you ;)

War bisher davon ausgegangen, wir operieren nur am Sender.

Hab mal in meinen Kisten gekramt und den hier gefunden. Ist ein 328 und wohl umschaltbar 5/3.3V. Ober der geht? Werde nachher mal schauen, ob ich deinen hex Code drauf packen kann ....

Gruß KH
 

Anhänge

  • 20220408_125726.jpg
    20220408_125726.jpg
    801,9 KB · Aufrufe: 80
  • 20220408_125735.jpg
    20220408_125735.jpg
    314,9 KB · Aufrufe: 78
Hallo Wolfram,

cool, dass Du Dich gleich als Tester zur Verfügung stellst. :)

Die Pins D0 und D1 werden verbunden, und daran wird dann das Signal des MSB angeschlossen. Der Konverter muss ja sowohl senden als auch empfangen, da er den MSB Master spielt, den sonst der Empfänger macht.

Es gibt ein paar Werteklassen, die aktuell noch nicht unterstützt werden:
0 (Sonderdaten), 4 (Geschwindigkeit), 7 (Richtung), 13 (lange Distanz) und 14 (g-Rate)

Für diese Werteklassen habe ich keine Sensoren zum Testen, daher habe ich sie erst mal weggelassen. Das Multiplex GPS benützt sicher einige davon, so dass es momentan nicht unterstützt wird.

Die fehlenden Werteklassen werde ich noch einbauen, aber das gibt es noch einige Fragen zu klären. Vielleicht kannst Du hier mal posten, welche Parameter das Multiplex GPS mit welcher Werteklasse ausgibt. Sicher müssen wir dann einige Konventionen bezüglich der verwendeten MSB Adressen festlegen, da einige Werteklassen für unterschiedliche Parameter benutzt werden. Wir hatten z.B. für den "alten" Konverter mal festgelegt, dass die Höhe vom GPS auf einer bestimmten Adresse sein muss, um sie als GPS Höhe auszugeben (im Unterschied zur Höhe vom Vario).

Für den Multiplex g-Raten Sensor würde man wohl einfach festlegen, dass die ersten drei MSB Adressen mit Werteklasse 14 die g-Raten der x, y und z Richtungen (in dieser Reihenfolge) darstellen.

Ich bin übrigens der Meinung, dass es mindestens zwei Multiplex Sensoren gibt, die auch für FrSky Nutzer sehr interessant sind. Zum einen der Spannungssensor, der zwei Spannungen potentialfrei messen kann. Und zum anderen der LiPo Zellensensor, weil er mit Strom, Verbrauch, Gesamtspannung und niedrigster Zellenspannung genau das (und nur das) liefert, was man zur Antriebsüberwachung braucht. Außerdem gibt es auch andere Anbieter mit MSB kompatiblen Sensoren, die FrSky nicht direkt unterstützen (YGE, PowerBox z.B.). Und schließlich hat es sogar Vorteile, einen UniSens-E für MSB zu konfigurieren und dann den Konverter nachzuschalten, obwohl der auch FrSky S-Port kann. Dann kann man nämlich einzelne Parameter, die man nicht braucht, abschalten, was in der FrSky Konfiguration nicht geht. Außerdem ist die Übertragungsrate für die Variodaten deutlich höher, wenn man den Konverter verwendet, da er diese (im Gegensatz zum UniSens) unter einer separaten Sensor ID überträgt.

Insgesamt gibt es doch einige interessante Anwendungen für den MSB/S-Port Konverter, die sich nicht auf den Einsatz von Multiplex Sensoren beschränken.
 
Ach ja, noch was.
Ich habe festgestellt, dass es Sensoren gibt, die zwar OpenTx, nicht aber ETHOS mit der normalen Sensorsuche findet. Dazu gehört zum Beispiel die "Fuel Quantity", die der MSB Werteklasse 12 (Volumen in ml) zugeordnet ist. In ETHOS muss man in so einem Fall einen DIY Sensor anlegen und in diesem Menü dann die automatische Erkennung aktivieren, dann findet er den Sensor. Liegt möglicherweise daran, dass die Sensorsuche mit ETHOS auf diejenigen Sensoren beschränkt ist, die es tatsächlich auch von FrSky gibt.
 
Ansicht hell / dunkel umschalten
Oben Unten