OpenTX - Multiplex MLINK Konverter

gruni

User
Hallo Gruni,

hatte leider noch keine Zeit mich dem Problem zu widmen.
Werde aber morgen, am Karfreitag, mich mal dran setzen.
Zuerst werde ich schauen, ob die Schnittstelle überhaupt funktioniert mit einem FrSky XJT Modul. Danach werde ich weiter schauen.
Melde mich aber mit meinem Ergebnis wieder hier.

Anbei 3 Fotos vom aufgeschraubten HFMG3-Modul:

Modul aufgeschraubt ohne Teensy:
Anhang anzeigen 1576220

Modul mit Teensy. Gut Isoliert könnte man ihn dort liegen lassen:
Anhang anzeigen 1576224

Eine praktische Stelle währe auf dem Piepser. Allerdings weis ich nicht, wie laut der dann noch piepst:
Anhang anzeigen 1576225

Auf dem Piepser könnte man ihn mit Doppelseitogem Klebeband befestigen. Er muß allerdings Kopfüber befestigt werden, da sonst der Taster, vom Moduldeckel, aus Versehen gedrückt werden könnte und so der Teensy nicht funktioniert. Wert will könnte sich, mit dieser Methode, auch eine Isolierung sparen.

Gruß
Dieter

Hallo Dieter,

ich bin platt, was sich MPX für einen Aufwand mit dem Gehäuse gemacht hat, RESPEKT. Ich glaube, ich muss mal mein JetiTG aufschrauben, ist e ausserhalb der Garantiezeit. Das ist aber bestimmt nicht so aufwändig gebaut. Danke für die Fotos.
Wenn ich Zeit habe ... dann werde ich die LC-Platine doch irgendwie da reinbauen. Wird zwar schnibbelig, sollte aber passen.

Beste Grüsse, Gruni
 
Hallo zusammen,

nachdem mich Roland im FPV Forum dezent auf diesen Thread hingewiesen hat (den ich natürlich von Anfang an verfolgt habe ;)),
melde ich mich also hier zu Wort.

Ich hatte ja in einem Nachbarthread schon angedeutet, dass ich evtl. einen auf meine Bedürfnisse zugeschnittenen
M-Link/FrSky Konverter auf Basis eines Atmel µC realisieren möchte, Programmierung wäre dann in C.
Ich bin das jetzt über die Ostertage mal etwas konkreter angegangen und habe mir die notwendigen Informationen zusammengesucht.
Und weil es so interessant ist, habe ich das C-Projekt auch schon aufgesetzt und die einzelnen Module angelegt.

Als µC muss erst mal der ATmega 328 herhalten (Arduino Pro Mini oder Klon).
Wenn ich mit 8k hinkommen sollte (was ich momentan bezweifle), wäre natürlich dieses kleine Board interessant.
Die Portierung sollte sich für den Fall der Fälle aber leicht durchführen lassen, also erst mal der 328er.

Die grundlegenden Funktionen, etwa Lesen und Schreiben der seriellen Daten, konnte ich weitgehend aus meinen früheren Projekten übernehmen.
Als ersten Zwischenschritt habe ich mir vorgenommen, den LQI und die Empfängerspannung zu übertragen.
Das lässt sich im FrSky D-Protokoll mit dem Frame für RSSI und die A1/A2 Ports machen, ohne dass man User Frames braucht.

Das Projekt ist eine gute Gelegenheit, meine C Kenntnisse mal wieder etwas aufzufrischen.
Außerdem macht es mir großen Spaß, und ich kann alles genau so machen, wie ich es will/brauche.
Mal sehen, wie lange es dauert, bis ich was konkretes vorweisen kann, Ihr wisst ja, der Job...

Ich werde hier über den Fortschritt berichten, bzw. wahrscheinlich auch die eine oder andere Frage stellen.


Gruß
Reinhardt
 
Hallo,
der "arme" Thred im FPV Forum war ganz alleine und verlassen! Wir hatten vergessen unseren Umzug bekannt zu machen. Dies hatte ich damit nachgeholt! :-)
 
Hallo zusammen,

damit nicht auch dieser Thread in der Versenkung verschwindet, hier mal ein kleines Update.

Die C-Module für das Einlesen der M-Link Daten (SW UART) und das Senden der FrSky Telemetrie Frames (HW UART) sind soweit fertig.
Ich habe das Byte Stuffing so implementiert, dass es quasi "En Passant" beim Senden bzw. Empfangen passiert.
Der Rest des Programms kriegt gar nichts davon mit.

Es gibt einen kritischen Punkt, und zwar die Frage, ob ein SW UART in C schnell genug für die 115,2 kBd des M-Link Signals ist.
Bei 16 MHz Taktfrequenz könnte das knapp werden, und da der ATmega 328 nur einen HW UART hat, wäre das ein NoGo für meinen bisherigen Plan.
Ich hoffe, dass ich am WE dazu komme, das zu testen.

Aber natürlich habe ich schon einen Plan B.

Mir geht es letzlich um die Konvertierung folgender Daten:

- Empfängerspannung, LQI, zwei weitere Spannungen, Strom, Kapazitä, Höhe und Steigrate

Für diese Parameter sind eigentlich nur relativ einfache Byte Manipulationen erforderlich, wenn ich das richtig sehe.
Daher lautet mein Plan B (falls der SW UART in C zu langsam ist), den Konverter in Assembler zu machen. :eek:
Auch dafür habe ich den Code für die serielle Datenein- und ausgabe von früheren Projekten in der Schublade.
Und Assemblerprogrammierung hält den Geist wach. :D

Mal schauen, was im am WE erreiche.


Gruß
Reinhardt
 

onki

User
Hallo Reinhardt,

wenn du Performancebedenken hast, wäre dann nicht der Teensy bzw. der Teensy LC die bessere Wahl?
Gut der kostet mehr aber dafür hat er auch mehr Bumms auf dem Dye;).

Gruß
Onki
 
Hallo Onki,

was das Teil kostet spielt jetzt nicht die große Rolle. ;)

Im Grunde reicht der ATmega 328 mit 16 MHz dicke aus, der Teensy ist eigentlich ein absoluter Overkill für den Konverter.
Das kritische ist die Zeit zwischen Start-Bit und erstem Datenbit, was halt bei 115,2 kBd nur µs sind.
Und der Compiler müllt leider gerade die Interrupt-Routinen ziemlich mit Registersicherungen zu, das könnte eng werden.

Aber ich kann auch für ein Assemblerprogramm den Programmrahmen und den Code zum Senden und Empfangen aus früheren Projekten übernehmen.
Und das ist die eigentliche Arbeit, denn das Umformatieren der paar Bytes vom M-Linki in den FrSky Datenstrom ist kein großes Ding für die oben genannten Parameter.

Der Weg ist für mich das Ziel, und ich bin ein Freund davon, nur das einzusetzen, was man wirklich braucht.
Und ich denke, eine schlanke ATmega Lösung für ein Mini-Pro wäre vielleicht auch für andere interessant.

Am WE weiß ich dann hoffentlich mehr.


Gruß
Reinhardt
 
Hallo Reinhardt,
ich hatte mit dem Teensy Konverter und der X9E Probleme mit RSSI. Bei der X9D dürfte RSSI problemlos funktionieren. Warum die beiden Anlagen unterschiedlich reagieren ist mir unklar.

Jedenfalls "hängt" bei mir RSSI auf 100% und will nicht abfallen, egal was ich mache. Die anderen Telemetriewerte funktionieren problemlos.
Welche FrSky Anlage verwendest du?

Ich habe erst wieder in einer Woche Zeit mich damit zu beschäftigen.

LG
Roland
 
Hallo Roland,

ich verwende eine X9D+.

Ich weiss, dass der LQI Wert bei M-Link meistens bei 100% steht.
Ich nehme mal an, dass die von Euch verwendete SW diesen einfach 1 zu 1 in das RSSI Byte kopiert.
(Habe ich auch so vor.)
Wenn man allerding durch gezielte Abschattung den Empfang beeinträchtigt, sollte der Wert schon runtergehen.
Sobald ich LQI und Empfängerspannung am laufen habe, werde ich das natürlich testen.


Gruß
Reinhardt
 
Ich habe Empfänger sogar in die Mikrowelle gepackt. Keine Änderung. Entweder null oder 100.
Bei Mpx Sender kann ich RSSI alleine mit der Hand ändern.
Ich habe mehrere Module und Empfänger getestet.
Daher wird es wohl eher an der X9e liegen.
Werde nächste Woche wieder testen.
Lg Roland
 

kalle123

User
Daher wird es wohl eher an der X9e liegen.

Hallo Roland. So wird es sein, warum auch immer ...

Hab ja schon mal einen Parallelversuch mit der X9D und einer Poyal Pro gemacht und konnte in beiden
Fällen die LQI Werte durch Abdecken mit der Hand reduzieren. Von 100% -> 80% bzw. 60%

Hab damals extra für dich ;) das auf ein Video aufgenommen ...

Gruß KH
 
Hallo KH,
Es muss an der X9e liegen, wie auch immer. ..
Meines Selenfriedens wegen, habe ich mir eine X9D+ bestellt! :-)
Dann kann ich endlich beruhigt unter Tags mpx mlink - opentx fliegen und abends die x9e weiter testen.
 

gruni

User
Hallo Roland,

jaja, diese blöden Luxusprobleme...

Grüsse Gruni:)

PS: @Reinhardt, weisst Du, ob man die Schnittstelle zur Taranis mit dem Nano oder whatever ohne Inverter betreiben kann wie beim Teensy?
 
PS: @Reinhardt, weisst Du, ob man die Schnittstelle zur Taranis mit dem Nano oder whatever ohne Inverter betreiben kann wie beim Teensy?
Hallo Gruni,

wenn ich es im Datenblatt des ATmega 328 nicht übersehen habe, geht das leider mit dessen HW UART nicht.
Und den benutze ich für die Datenausgabe, da er bei 16 MHz Taktfrequenz für die 115,2 kBd des M-Link Signals leider nicht geeignet ist. :cry:

Das ist sehr schade, da die Baudrate zur Taranis ja nur 9600 Bd ist, was für einen SW UART ein Klacks wäre.
Wenn man auf die Nutzung der HW Schnittstelle komplett verzichtet und auch die Ausgabe zur Taranis per SW UART macht,
könnte man die Invertierung natürlich leicht berücksichtigen, das wäre dann ein Finetuning, wenn alles andere mal läuft.


Gruß
Reinhardt
 
Abend zusammen,

heute habe ich mal die beiden Schnittstellen-Module soweit fertiggemacht und mit einem derzeit noch leeren Hauptprogramm kompiliert.
Ich hatte vorher einige kleinere Optimierungen gemacht, verglichen mit dem Projekt, aus dem ich den SW UART entnommen habe.
Da ich den SW UART ursprünglich für einen Tiny mit nur zwei Timern geschrieben hatte, konnte ich durch die Verwendung
des dritten Timers des ATmega 328 auch Bit-Takt und Idle Time Überwachung entkoppeln und damit den Code vereinfachen.

Ich habe mir dann mal die ISRs im erzeugten Assembler Listing angeschaut und bin jetzt eigentlich recht optimistisch, dass es klappt mit dem Atmega.
Wenn ich mich nicht verzählt habe, braucht die ISR nach dem Start-Bit etwa 35 Taktzyklen (2,2 µs) und die Bit-Takt ISR etwa 45 Taktzyklen (2,8 µs) für ein Daten-Bit.
Das schaut recht vielversprechend aus, am Wochenende komme ich hoffentlich dazu, das Teil auf den Controller zu laden und zu testen.
Vielleicht schaffe ich es ja sogar, LQI und Empfängerspannung einzubauen, dann könnte man evtl. schon was auf dem Taranis-Display sehen.
Allerdings ist für das Wochenende Flugwetter vorhergesagt, also schaun mer mal... ;)


Gruß
Reinhardt
 
Hallo zusammen,

nachdem es gestern wegen Saharastaub bei uns ziemlich trüb war, habe ich das Fliegen sein lassen und am Konverter gebastelt.
Und es gibt Positives zu vermelden. :)
Nach den üblichen doofen Flüchtigkeitsfehlern habe ich das Einlesen des 115,2 kBd M-Link Signals per SW UART auf dem ATmega 328 am Laufen.
Das Schreiben der FrSky Daten über den HW UART ist mit den 9600 Bd ohnehin kein Akt und läuft ebenso.

Ich halte es für möglich, den SW UART auch mit 8 MHz Taktfrequenz hinzukriegen.
Dann könnte man den ATmega mit 3,3 V versorgen, 16 MHz macht er erst ab 4,5 V mit.
Das probiere ich aber erst ganz zum Schluss, wenn der Konverter erst mal mit 16 MHz läuft.
Es ist eigentlich ein Witz, ein 115,2 kBd Signal zu verwenden, aber nur alle ca. 100 ms ein Datenpaket zu senden.
2% der Zeit ist der µC am Rödeln, und danach hat er nichts mehr zu tun bis zum nächsten Datenpaket.
Aber so ist nun mal das von MPX verwendete Protokoll, sie werden sich schon was dabei gedacht haben.

Naja, die verbleibenden 98% der Zeit kann ich jetzt zum Ummodeln der M-Link Daten in das FrSky Format verwenden.
Da kann man dann ganz entspannt ohne Rücksicht auf die letzte Mikrosekunde drauflosprogrammieren. :D
Mal sehen, wann ich die ersten Daten auf dem Display meiner Taranis vermelden kann.
Machbar ist es jedenfalls mit dem kleinen Atmel Käfer, das steht jetzt fest.
Und das war das Ziel des Wochenendes, mal sehen, wann ich den nächsten Erfolg vermelden kann.


Gruß
Reinhardt
 
Morgen zusammen,

kurzer Update von gestern Abend.

Der Konverter läuft jetzt schon mal für Empfängerspannung und LQI/RSSI. :)
Ich kann die Daten im FrSky Datenpaket mit dem Oszi / Bus Analyser sehen.
An die Taranis kann ich das Teil leider noch nicht anschließen, da mir der nötige Stecker fehlt.
Das Programm läuft momentan auf einem Arduino Uno Board, welches ich über ISP mit dem Atmel Studio sehr komfortabel programmieren kann.

Die Empfängerspannung kommt ja über M-Link mit einem LSB von 0,1 V an.
Die unteren 8 Bits des 15-Bit Datenwortes werden einfach in das A1 Byte kopiert.
Damit ergibt sich ein Meßbereich bis 25,5 V, das sollte reichen.
In der Taranis muss man dann später einen Faktor von ca. 7,8 einstellen, damit das Ergebnis richtig angezeigt wird.
Der LQI Wert wird einfach eins zu eins in das RSSI Byte kopiert.
Da muss ich dann später mal testen, welche Schwellwerte für die Warnungen sinnvoll sind.

Jetzt werde ich den Code mal in aller Ruhe durchsehen, ob es noch sinnvolle Möglichkeiten zur Vereinfachung der Programmstruktur gibt.
Und dann muss ich mir überlegen, wie ich den Programmteil zur eigentlichen Konvertierung so strukturiere,
dass ich die fehlenden Sensor-Parameter möglichst elegant einfügen kann.
Außerdem sollten zukünftige Erweiterungen möglich sein, ohne gleich Alles umschmeißen zu müssen.

Das soll es erst mal gewesen sein, watch this space. :cool:


Gruß
Reinhardt
 

gruni

User
Hallo Reinhardt,

hört sich gut an. Schöne Arbeit.

Der Stecker ist der hier:

JST Jumper 4 Wire Cable + Connector bei Flikto. (zB) Es werden nur die zwei äusseren Adern benötigt.

Wie klein könnte die Platine sein? Ein nano oder mini, oder soll ein anderes nichtarduinoboard verwendet werden?
Ich bin gespannt. BBlöd nur, daß ich nix davon verstehe, selbst Arduinoprogrammierung zieht mir den Schuh aus...

Der TeensyLC-Konverter läuft seit ein paar Wochen im Praxistest mit parallelem MPX-Display...auf der Taranis plus.

Grüsse Gruni
 
Ansicht hell / dunkel umschalten
Oben Unten