OpenTX - Multiplex MLINK Konverter

Hallo zusammen,

die CKDIV8 Fuse darf auf keinen Fall gesetzt sein. :eek:
Damit wird die Taktfrequenz durch 8 geteilt und nichts stimmt mehr.
 

Patman

User
So, über ISP geht's jetzt.
Nur hex-File geflasht, keine Fuses gebrannt!!!

Wer kann mir das erklären???

Ernst, wenn Du beim Mini-Pro bleiben willst, dann nehm so was hier. Das habe ich auch verwendet, weil auch ich beim Mini-Pro bleiben will. Ich möchte es ins HFMG3-Modul einbauen.

Atmel Atmega Sockel Firmware Flashing-Tool

27195-3.jpg


Grüße,
Patrick
 
So, über ISP geht's jetzt.
Nur hex-File geflasht, keine Fuses gebrannt!!!

Wer kann mir das erklären???
Hallo Patrick,

schwer zu erklären, wie sind Deine Fuses denn jetzt gesetzt?
Wenn Du mit ISP gebrannt hast, ist jetzt kein Bootloader mehr drauf.
Vielleicht hat ja der ein Problem verursacht.
Ich hatte auch schon mal Probleme, wo der BL nicht korrekt an die Applikation übergeben hat.
Das Programm selbst hatte er aber korrekt geladen.
Sprich nach dem Zurücksetzen der Boot Reset Fuse lief das Programm (ohne erneut zu flashen).
 
Hallo Sigimann,
der "neue" MLINK Konverter von Tobi dürfte das SPort Protokoll verwenden. Hat vielleicht Vorteile, wenn ja, kenne ich diese nicht.
Hier, ist seit längerem Reinhardt der Mann, der einen Konverter für MULTIPLEX MLINK erstellt hatte und diesen bis zur Perfektion optimiert hat. Der Konverter deckt alle gängigen und möglichen zukünftigen Optionen des MLINK Protokolls ab.
Ich kann mich erinnern, dass es Anfangs Probleme mit Tobis Konverter gab, da es vielleicht kleine Unterschiede zwischen ACT und MPX gibt. Ob das stimmt, kann ich nicht sagen. Es wurde relativ schnell ein neuer MPX Konverter hier veröffentlicht. Daraus entsand dann ein weiterer wodurch letztendlich Reinhardt begann seinen eigenen zu erstellen.
Sollte ACT doch das selbe MLINK nutzen wie MPX, dann dreht doch den Spieß einfach um! Versucht ob Reinhardts Konverter auch für ACT MLINK funktioniert!

lg
roland

Na klar verwendet Tobi dabei den SPortim Modulschacht. Die Frage war, ob hier jemeand weiss (oder es verwendet), ob das auch bereits unter Opentx 2.1 geht oder erst ab 2.2.
Wenn ich deine Antwort interpretiere wird von dir immer der Serielle Bus verwendet. Was mich wundert, da du ja mal selbst in diese Richtung geschaut hast und vor allem auch eine X9E hast, die keine Seriellen Buchse mehr aufgelötet hat.

Auch Reinhard hat sich nicht weiter geäusert, dann wird er es auch nicht wissen.
Tobi selbst ist leider auch seit Monaten nicht mehr bei RCGroups gewesen.

Da bleibt Kalle meine Hoffnung, ansonsten muss ich halt probieren.


Hallo Sigimann,


Sollte ACT doch das selbe MLINK nutzen wie MPX, dann dreht doch den Spieß einfach um! Versucht ob Reinhardts Konverter auch für ACT MLINK funktioniert!

lg
roland

Das ist völlig unrealistisch. Identisch sind nur die Übertragungsprotokolle, wobei ACT wie zum Beginn von MLink nur die Daten der Sensoren 1:1 durchreicht, wird von MPX der Dateninhalt angepasst oder dem Sensorhersteller vorgegeben. Das grausigste was ich hier gelesen habe, das bei MPX in einem Datenwort ein Bitt als Flag für Alarme missbraucht wird. Das hat Kalle und Gruni schon viel Arbeit gemacht.

Den Weg muss man jetzt nicht noch einmal Rückwärts gehen.

Sigi
 

Patman

User
Hier meine ISP-Evolution von gestern. Ich will ja möglichst wenig Platz mit dem Arduino verbrauchen.
Verwendet habe ich wie immer den mySmartUSB light und das Progrämmchen myAVR ProgTool .

Zuerst mal mit einem Nano und ISP Header.
IMG_5868.JPG

Dann mit einem Nadel-Adapter ohne ISP Header.
IMG_5869.JPG

Dann noch mit dem uC-Adapter.
IMG_5870.JPG
IMG_5871.JPG
 

Patman

User
Wollte übrigens noch sagen: Hurra!!! Es funktioniert.
Danke an Reinhardt!!!

Als Segelflieger interessiert mich natpürlich vor allem die Vario-Ausgabe. Werde das demnächst mal testen.
Zuerst muss ich mich noch mit der OpenTX Telemetrie-Ausgabe/-Anzeige beschäftigen. Hatte bis jetzt ja immer keine Daten und kann das nun zum ersten Mal verwenden.

Grüße,
Patrick
 
@Patman: Dann hat sich mein Screenshot der Flasheinstellungen erübrigt. Bin nämlich noch nicht dazu gekommen. Aber dann hast Du ja jetzt auch Weihnachten :). Danke für den Hinweis mit dem Flashing-Tool.

Ich habe nicht den Mut das HFMG-3 anzufassen, hätte ich schon, will aber keine möglichen Störungen provozieren. HF ist eine eigene Welt. Habe mir deshalb neben dem COM-Anschluss vom Modul ein kleines Loch in das Sendergehäuse gebohrt und werde so das Kabel gleich vom Modul in den Sender führen. Unten neben dem Batterieschacht hat es noch Platz für den Microcontroller. Von dort kann man gleich mit dem Stecker auf den Serialport vom Sender.

Gruss Ernst
 
Hallo zusammen,

vielleicht noch abschließend zu den Fuses:

Diese sollten bei Betrieb ohne Bootloader (Flashen über ISP) für die Arduino Boards wie folgt gesetzt sein:

Lock Bits: 0xFF
Low Fuse: 0xFF
High Fuse: 0xD9
Extended Fuse: 0xFF

Damit ist dann auch der Quarzoszillator mit externem Quarz aktiviert.
 
Hallo zusammen,

die CKDIV8 Fuse darf auf keinen Fall gesetzt sein. :eek:
Damit wird die Taktfrequenz durch 8 geteilt und nichts stimmt mehr.
Da bin ich mir nicht mehr so sicher.
Evtl. besagt diese Fuse auch, dass die Teilung durch 8 deaktiviert ist, das ist bei den Fuses manchmal etwas komisch. ;)
Sei's drum, mit den Fuses gemäß vorherigem Post funktioniert es.
 

Patman

User
Hallo Reinhardt,

ich denke die CKDIV8 wirkt nur für die interne Clock.
Die Arduinos haben einen externen Oszillator und die Fuses sind auch entsprechend gesetzt.
Wie gesagt, ich habe alle Fuses belassen.

Grüße,
Patrick
 
Hallo Ernst,

Na das schaut doch gut aus. :)

Bei den Fuses gibt es schon ein wenig Spielraum, z.B. was die größe des Speichers für den Bootloader angeht.
(habe ich früher mal hier im Thread erklärt)
Die wichtigen Fuses passen so wie sie bei Dir gesetzt sind.
 
Zwei Fragen kann man sich aber noch stellen.

Da es jetzt nur noch wenige Parameter sind, die mit vordefinierter FrSky ID übertragen werden, könnte man darüber nachdenken,
auf diese völlig zu verzichten und alle Sensorwerte mit einer ID gemäß ihrer MSB Adresse einfach durchzureichen.
(Das hatten wieder früher im Thread schon mal als mögliche Option andiskutiert.)
Den RVLQ Frame müsste man aber in jedem Fall auch senden, da sonst OpenTX die Telemetriedaten nicht erkennt.
Entweder wäre dieser dann leer, oder man belässt den RSSI/LQI und die Empfängerspannung auf Adresse 0 darin.

Zum zweiten könnte man die Alarm-Flags rausschmeißen.
Es war seinerzeit eigentlich mehr eine Spielerei, in der Praxis wird man Alarme immer in OpenTX konfigurieren.
Zumal das Auswerten individueller Bits im Alarm-Datenwort ohne LUA wohl auch nur in sehr einfachen Fällen möglich ist.

Naja, schaun mer mal.
Hallo zusammen,

um nochmal auf diese beiden Punkte zurückzukommen...

Ich habe beschlossen, eine Version des Konverters zu machen, die völlig auf die vordefinierten FrSky IDs verzichtet.
Da ich ohnehin zumindest den vorgegebenen Namen immer ändere, bringen mir die Voreinstellungen von OpenTX nichts.
Und bei den Temperaturen muss man auch eine Ratio definieren, da die Daten nicht mit der FrSky Auflösung,
sondern mit der besseren MSB Auflösung übertragen werden.
Dann kann man den ganze FrSky ID Kram eigentlich auch gleich ganz rausschmeißen, und genau das werde ich tun.
Alle Parameter bekommen eine ID gemäß ihrer MSB Adresse und werden dann im Sender entsprechend konfiguriert.

Was bleiben wird, ist die Zuordnung bestimmter MSB Adressen zu den Parametern im RVLQ Frame:

- A1 Spannung: Adresse 0 (normalerweise die Empfängerspannung)
- A2 Spannung: Adresse 2 (eine weitere Spannung bis 25,5 V)
- RSSI Wert: Adresse 1 (repräsentiert den M-Link LQI)

Wenn einer dieser Parameter nicht benötigt wird, kann wie gehabt die entsprechende Adresse
für einen beliebigen Parameter mit einer anderen Werteklasse benutzt werden.
Wer den Thread genau verfolgt hat, weiß, dass ich die feste Adresse für den RSSI/LQI Wert kürzlich eliminiert habe.
Das hat zu einer kleinen Besonderheit im Code geführt, über die ich schon zweimal gestolpert bin,
da der im RVLQ Frame übertragene LQI in der Schleife für die User Daten auftaucht.
Daher habe ich das wieder rückgängig gemacht, da es in der Praxis bedeutungslos ist.

Was ich mit den Alarm Flags mache, weiß ich noch nicht.
Einerseits sind sie eigentlich überflüssig, andererseits ist der Konverter ohne sie irgendwie nicht komplett.

Ich werde diese Version parallel zur bisherigen erstellen.
(Bis auf ein File können alle C Sourcen per Link vom bisherigen Konverter benutzt werden.)

Watch this space.
 

Patman

User
Hallo Reinhardt,
Nachdem es nun bei mir funktioniert, hab ich etwas an der Telemetrie rum gespielt.
Da ist mir genau das aufgefallen. Ich würde mich über die Änderung freuen, da das für
Mich viel logischer und symmetrischer wäre.
Freue mich auf die Software!
Grüße,
Patrick
 
Ansicht hell / dunkel umschalten
Oben Unten