OpenTX - Multiplex MLINK Konverter

Hallo KH
ich meine das separate MPX Telemetrie Display 45182 , das man an die HFMG's anschliessen kann. Wenn ich das dann dazuschalte kommen die beschriebenen Probleme. ATTtiny muss ich mal sehen. Weiß nicht ob da mein MyAVR Progger geht. Oder hättest Du da eventuell noch einen programmierten gegen Entgeld und Erstattung der Versandkosten ?? Ich würde aber erst mal auf ne Rückmeldung von Andreas warten, Wenn er das MPX Telemetrie Display dazuschaltet, merkt er sofort ob es geht oder nicht. Fliegen ist ja momentan eh nix... Grüße
Wolfram
 
Hallo, ich versuche es so schnell wie möglich zu testen. Als ich das Display dran hatte um die Telemetrie-Werte zu testen, hatte ich keine Probleme. hab aber darauf auch nicht richtig geachtet.

Ich betreibe einen Arduino pro mini mit 5V. Hab ihn intern eingebaut und beziehe den Strom nicht vom Com-Port. Wie sieht dein Aufbau aus?

Kann es sein, dass es nicht parallel geht, wenn man Strom vom Com-Port für den Konverter bezieht und noch zusätzlich das Multiplex Telemetriedisplay anschließt? Habe daher zur Sicherheit die 5V Variante intern gewählt...
 
Der Aufbau ist genauso wie bei Dir, am HFMG3 Com Port hängt nur der Telemetrie Signalabgriff für den Arduino, die Versorgung + für den Arduino (RAW Eingang) sowie Masse kommt vom Abgriff der JR Pin Leiste, da wird dann ja auch das konvertierte Telemetrie Signal an den Sender eingespeist.
Aber Onki hat sowas von Recht, warum ich das mit dem 2. Display ja auch nicht weiter verfolgt hatte. Nur als Du das geschrieben hattest wollte ich wissen, ob es bei Dir geht. Schönen Sonntag noch - Wolfram
 
Hallo Reinhardt
es ist ein "Mini ATMEGA328 3.3V 8Mhz Replace ATmega128 For Arduino Pro Mini Compatible" aus der Bucht.
Wie gesagt es funktioniert mit Deiner 8Mhz "Testversion" perfekt, + Versorgung aber am RAW Eingang von der JR Buchsenleiste .
Mit M-Link Eingang: meinst Du am HFMG3 Com-Port innen auf der Platine ???
 
Ah Danke Dir, muss ich mal nachsehen, hatte ja 3 bestellt, kann aber leider erst morgen mal nachsehen..

Insider: -> schöne, angenehme 21 Resttage ;-) Wird richtig gut, glaub mir (kenn ich seit 01.02. :-) ) Viele Grüße Wolfram
 

Patman

User
Hallo zusammen,

Respekt vor diesem Projekt. Ich hatte mir auch mal einen Konverter gebaut. Allerdings ging die Umstellung auf FrSky dann schneller als gedacht und so brauche ich das nicht mehr.
Aktuell ist es schwierig M-Link Module zu bekommen. Daher von mir eine Info über die ich zufällig gestoßen bin.
Ich hab für meine FrSky so ein Multiprotokoll-Modul um z.B. Blade Helis usw zu steuern.
Nun hab ich gesehen, dass die neueste SW-Version auch M-Link kann. Ist vielleicht mal einen Blick wert.


Grüße,
Patman
 
Hallo zusammen,

es sollte sich aber jeder im klaren sein, womit er sich mit einem solchen Modul einlässt.
Ich will jetzt hier aber nicht die Diskussion aus dem FrSky Forum wiederholen bzgl. Konformität, etc.
Für mich ist es ein NOGO, ein solches Modul mit M-Link zum Steuern eines Flugmodells einzusetzen.
Für weitere Diskussionen zum Thema MPM bitte einen neuen Thread aufmachen.
In diesem Thread sollte es weiterhin ausschließlich um den Telemetriekonverter für Original Multiplex M-Link Module gehen.
 

kalle123

User
Macht nix Patman. ;)

Reinhardt hat sich im dortigem Forum so richtig einhängt und wurde teilweise massiv angegangen.
Nur Gruni (in #1292) hatte schon darauf hingewiesen, dass sich da (MPM und MPX) was tut.
MPM ist hier nicht das Thema. Ich hab mich damals 'für nen Appelund ein Ei' mit zwei HFMG3 eingedeckt.
Das sollte reichen. Und wenn ich dann beim MPM was von Reichweite lese ...

Ich brauch die Dinger nicht und möchte damit auch nicht meine Modelle in die Thermik schicken.

Alleine von der technischen Seite interessiert so ein MPM Modul mich schon, aber NUR aus dem Gesichtspunkt!

Hab nur momentan wieder zu viele andere Projekte laufen ...

Gruß KH
 

gruni

User
Nabend ihr Drei,

die MPM-Problematik ist mir sehr bewusst, das gleiche gilt auch für die TX?? von Jumper und RM. Scheint aber niemandem in dem Umfeld zu stören.
Wäre halt wesentlich einfacher, das Telemetriesignal ALLER Module (MPX, Jeti, Fasst?...) direkt via OTX in die Sender einzuschleusen, was ja die Progger der MPMs schaffen. Das ist der eigentliche Punkt.
Von daher verstehe ich MPX eben nicht, daß die nicht auf den Zug aufspringen mit ihren "alten" Modulen in neuem Gehäuse, quasi.
Die Empfänger machen das Geld, Multiplex, hört ihr......??? Traummodus aus.

Grüsse aus der Quarantäne, Gruni
 

onki

User
Hallo,

Also Jeti wird es mit dem derzeitigen MPM definitiv nicht geben. Dort wird ein komplett anderer Chip (AT86RF231) verwendet der DSSS macht.

Gruß
Onki
 

Patman

User
Also die Idee von Gruni finde ich super, obwohl ich wegen OpenTx nun alle (viele!) MPX Empfänger rausgeworfen habe.
Das wäre ein kleines Hardware- und Software-Update und man könnte die Telemetrie direkt über die serielle Schnittstelle an den Sender geben. Die OpenTx-ler würden die Auswertung sicher auch einbauen.

Das wäre doch eine super Idee für die "Billig-Sender-Linie". Für die Angeber und die die das brauchen gibts dann noch Powerbox.

Gruni, da könnte man mitträumen!

Grüße,
Patman
 

3one5

User
Hallo,

bin neu im Thread und wollte den Konverter für einen Freund zum Laufen bringen, was nach intensivem Studium des Threads nach einigen Tagen dann auch endlich gelungen ist. Vielleicht helfen meine Erfahrungen dabei dem einen oder anderen noch ein wenig weiter. Probleme gab es unterwegs genug.

Meine Hardware: HFMG-2 und Arduino Pro Mini 3.3V, 8 MHz. PC läuft unter Win10. Arduino-Version: 1.8.13
Taranis x9d+ SE (alte Version). Anschluss des Konverters ausschließlich über die Pins im Modulschacht (also TX des Konverters auf S.Port-Pin ganz unten im Eck des Modulschachts.
Telemetry-Protokoll ist auf "FrSky D" eingestellt (nicht auf ...Cable, da ja der Pin im Modulschacht benutzt wird, nicht der im Batteriefach).

Nachdem sich Reinhards Firmware (die Version Konverter_8mhz_mit_IDs.hex bzw. _ohne_) zunächst per Serial-Adapter über den Arduino-Bootloader auf dem Pro Mini mittels

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude" -C"C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega328p -carduino -PCOM8 -b57600 -D -Uflash:w:"C:\Users\3one5\Modeling\Mpx\MLinkFuerOpentx\Konverter_2018-04-10\Hex Files\Konverter_8mhz_mit_IDs.hex":i

flashen ließ, sahe es erst einmal gut aus. Die Led blinkte langsam, das M-Link-Modul lieferte brav Daten.
Aber: Der gleiche Fehler wie bei Andreas. Es kamen keine Telemetriedaten im Sender an. Messung mit dem Oszi ergab, dass der Konverter einen dauerhaften 3.3V-Pegel statt des FrSky-D-Protokolls ausgibt.

Lösung wie bei Andreas: Pro Mini als ISP-Programmer
Wobei bei mir ein Arduino Nano als ISP-Programmer verwendet wurde, was aber im Prinzip nur ein Arduino Pro Mini mit einem auf dem Board bereits vorhandenen USB-nach-Seriell-Umsetzer ist.

Ergänzend waren noch die Infos auf diesen beiden Seiten hilfreich:
Arduino Nano als ISP-Programmiergerät (dort findet sich auch die Verdrahtung zwischen Arduino Nano (Programmer) und Arduino Pro Mini (Zielsystem) und Flashen eines Arduino Nano (dort sind die Einstellungen der Arduino IDE recht gut erläutert).

Damit habe ich den optiboot-Bootloader auf das Pro Mini flashen können. Hierzu muss man in der Arduino-IDE folgendes einstellen:
Screenshot 2021-05-11 110415.png


also nicht "Pro Mini", sondern "Nano", sonst bekommt man wieder den falschen Bootloader. Dann Burn Bootloader ausführen.

Anschließend wurde wieder mit der oben angegebenen Befehlszeile mit dem an das Pro Mini am M-Link-Modul angeschlossenen USB-nach-Seriell-Umsetzer die Firmware von Reinhardt aufgespielt. Und nun funktioniert der Konverter!

Herzlichen Dank an alle im Forum, die ihre Erfahrungen weitergegeben haben! Vor allem an Reinhardt, Kalle und Andreas. Ohne diese Hilfe wäre das nix geworden.

Vielleicht noch ein Gedanke zur Thematik ProMini 5V/16MHz gegenüber 3.3V/8MHz. Wenn man die 5V-Version verwendet, wird mit einem 5V-Pegel auf den S.Port-Pin (oder den seriellen Eingang im Batteriefach) geschrieben. Der Prozessor, bei dem dies ankommt dürfte aber mit 3.3V-Pegeln arbeiten. Das wird dem Pin auf die Dauer nicht gut tun (außer er ist tatsächlich bei 3.3V Betriebsspannung für 5V-Signale zulässig). Daher habe ich auch die 3.3V-Version verwendet.
Wenn man die 5V-Version benutzt, sollte man, denke ich, einen Widerstand zwischen den TX-Ausgang des Pro Mini und den Eingang (S.Port, serieller Anschluss im Batteriefach) einfügen. Ich würde zumindest 1kOhm vorschlagen, aber höher wäre noch sicherer, sofern die Sache damit noch funktioniert. Dann spricht zwar die ESD-Schutzdiode am Eingang des Prozessors noch immer an (dürfte wohl direkt der STM32 im Sender sein), aber der Strom wird zumindest begrenzt.

Markus
 

kalle123

User
Hallo Markus.

Danke für deine Zusammenfassung und deinen Erfahrungsbericht.

Zu deinen Bedenken bezüglich Pegel sag ich jetzt mal nix. Vielleicht äußert sich Reinhardt ja noch.

Zum Bootloader. Kannst du auch in der Datei boards.txt ändern.

Liegt bei mir (Linux) hier

/home/kalle/Anwendungen/arduino-1.8.13/hardware/arduino/avr/


Hier mal der Ausschnitt Pro mini

## Arduino Pro or Pro Mini (5V, 16 MHz) w/ ATmega328P
## --------------------------------------------------
pro.menu.cpu.16MHzatmega328=ATmega328P (5V, 16 MHz)

pro.menu.cpu.16MHzatmega328.upload.maximum_size=30720
pro.menu.cpu.16MHzatmega328.upload.maximum_data_size=2048
pro.menu.cpu.16MHzatmega328.upload.speed=57600

pro.menu.cpu.16MHzatmega328.bootloader.low_fuses=0xFF
pro.menu.cpu.16MHzatmega328.bootloader.high_fuses=0xDA
pro.menu.cpu.16MHzatmega328.bootloader.extended_fuses=0xFD
pro.menu.cpu.16MHzatmega328.bootloader.file=atmega/ATmegaBOOT_168_atmega328.hex <<<

pro.menu.cpu.16MHzatmega328.build.mcu=atmega328p
pro.menu.cpu.16MHzatmega328.build.f_cpu=16000000L

## Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328P
## ---------------------------------------------------
pro.menu.cpu.8MHzatmega328=ATmega328P (3.3V, 8 MHz)

pro.menu.cpu.8MHzatmega328.upload.maximum_size=30720
pro.menu.cpu.8MHzatmega328.upload.maximum_data_size=2048
pro.menu.cpu.8MHzatmega328.upload.speed=57600

pro.menu.cpu.8MHzatmega328.bootloader.low_fuses=0xFF
pro.menu.cpu.8MHzatmega328.bootloader.high_fuses=0xDA
pro.menu.cpu.8MHzatmega328.bootloader.extended_fuses=0xFD
pro.menu.cpu.8MHzatmega328.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex <<<

pro.menu.cpu.8MHzatmega328.build.mcu=atmega328p
pro.menu.cpu.8MHzatmega328.build.f_cpu=8000000L


Gruß KH
 
Ansicht hell / dunkel umschalten
Oben Unten