OpenTX - Multiplex MLINK Konverter

onki

User
Hallo Reinhardt,

Danke für deine Antworten.
Ist schon klar, das modulseitig was gemacht bzw. umgelegt werden müsste.
Wenn ich nicht komplett falsch liege, ist der S-Port in der RadioMaster an den Modul-Schachtpins (mutmaßlich der ehemelige 35MHz-Antennenpin).
Ist das bei den neueren Taranissen und Horussen nicht mehr der Fall? Hätte halt den massiven Vorteil, dass außer dem Modul keine zusätzlichen Steckverbindungen zum Sender nötig sind.
OpenXSensor nutzt doch auch S-Port. Könnte man davon nicht profitieren (abkupfern)?

Ich hab, wie vermutlich bekannt die TX16s und find z.B. die Möglichkeit super, schnell mal ein Modell eines Jugendlichen damit incl. Telemetrie steuern zu können schon super. Wenn dann noch Jeti ginge (mit Modul) wäre das die Universallösung.
Jeti wird mit dem MPM vermutlich nie klappen (die nutzen einfach zu exotische Transceiver) aber am ext. Modul ist die Telemetrie ja auch verfügbar.
MLink hat halt noch den Vorteil, dass es hardwaremäßig mit dem MPM funzen könnte (ist AFAIK ein CC25000 von TI drin).
Vielleicht erleben wir es noch, dass es in das MPM migriert wird (Vorversuche dazu gibt es offenbar schon).
Vielleicht fndet sich ja noch jemand in einer ähnlichen Situation der irgendwie die Arbeit aus OpenXSensor mit der Jeti-Bibliothek von Bernd Wokoeck kombiniert zu einem Jeti-Telemetriekonverter.
Trotzdem ein tolles Projekt, das ihr das habt. Hätte ich MLink wär das schon lange nachgebaut.

Gruß
Onki
 

onki

User
Hallo Andreas,

Ich hab dafür doch Verständnis.
Die wollen halt doch lieber ihre eigenen Sender an den Mann / Frau / Divers bringen anstatt irgendwelcher Fremdkonstrukte.
Es wäre aber sicher eine Art entgegenkommen den Antennenpin zumindest via Steck- oder Lötjumper mit dem Telemetriepin zu verbinden.

Gruß
Onki
 
Weil der OpenTX Multiplex-Senderverschnitt mit M-Link (Powerbox-Core-Sender) ist zwar das Non-Plus-Ultra, aber auch mit € 2500 zu veranschlagen.
 
Hi Onki,

den S-Port Pin im Modulschacht gibt es natürlich noch, sonst wären wir ja mit unserem Konverter schon ausgebootet.
Der Pin kann eben als S-Port oder zum Einspeisen von Telemetriedaten mit dem D-Protokoll verwendet werden.
Letzteres ist notwendig, um alte FrSky Sendemodule einsetzen zu können, und da haben wir uns mit dem Konverter drangehängt. :)
Und der Einbau des Konverters in das M-Link Modul ist problemlos möglich, haben einige auch schon gemacht.

Es gibt noch einen Aspekt, warum ich, selbst wenn ich es könnte, nicht in OpenTx rumpfriemeln würde.
Der Konverter kann den Sender nicht aus dem Tritt bringen, schlimmstenfalls funktioniert die Telemetrie nicht.
Da kann ich es verantworten, wenn andere das Teil verwenden, OpenTx zu ändern, ist da eine ganz andere Nummer.

Was M-Link in einem MPM Modul angeht, ich würde nie und nimmer ein richtiges Modell damit fliegen.
Jenseits aller rechtlichen Fragen ist es für mich absurd, ein anerkannt zuverlässiges System durch einen Klon zu ersetzen.
Wem M-Link (im Original) zu teuer ist, der hat genügend sinnvolle Alternativen, aber einen M-Link Klon einzusetzen ist für mich absurd.
Selbst für Hallenflieger ist das sinnfrei, da andere Marken wesentlich geeignetere Empfänger dafür anbieten.
Das einzige Argument wäre, dass es eben keine M-Link Module mehr zu kaufen gibt.
Aber dann würde ich doch lieber das Übertragungssystem wechseln oder eben auf OpenTx verzichten.
(Wobei die Auswahl an M-Link Sendern ja derzeit etwas dürftig ist.)

Aber jetzt sind wir doch etwas abgedriftet. :o
 

kalle123

User
A0 für MPX und A1 für FrSky habe ich auch so vorgesehen und werde ich auch so lassen.
Der LED Ausgang liegt natürlich auf dem Port, wo auf dem Nanite Board die Status LED angeschlossen ist (Pin B2).

Reinhardt, ich hab ja Ralfs Code hier auf dem ATTiny.

Ralf hat den Status anscheinend sowohl auf B2 und A3 gelegt.

Und hier fällt mir auf ...
  • Der Start bzw. Reset des Konverters wird durch eine spezielle Blinksequenz signalisiert (3-mal lang/kurz/kurz).
  • Die LED ist aus, wenn der Konverter überhaupt keine Telemetrie-Daten vom M-Link Modul empfängt (z.B. weil ein Modellspeicher angewählt ist, für den das M-Link Modul nicht benutzt wird).
  • Dauerleuchten zeigt an, dass der Konverter in der Startschleife ist, während der er empfangene Telemetrie-Daten ignoriert. Dieser Zustand dauert normalerweise nur einige Sekunden.
wenn ich den ATTiny ohne Verbidung zu MPX und FrSky starte, kommt die Start Blinkfrequenz, danach Dauerleuchten. :confused:

cu KH
 

elral

User
Hallo zusammen,

Reinhardt,
da hast Du mich eiskalt erwischt ;) PlatformIO erzeugt kein lss File, daher habe ich dann nochmal mit dem Atmel Studio kompiliert. Und dabei ist mir dann aufgefallen, das ich dort unter einer Solution anscheinend keine unterschiedlichen Prozessoren verwenden kann. Der Solution Manager hat mir schon häufig graue Haare bereitet, einer der Gründe warum ich PlatformIO verwende. Mit ein bisschen suchen habe ich das lss File aber dann auch da erzeugen können. Wie auch immer, ich schicke es Dir per Mail. Ein Vergleich mit einer boolschen Variable habe ich noch nicht gemacht, komme ich wohl erst am Wochenende zu....

Kalle,
das mit der LED muss ich mir mal am anschauen, aber wohl auch erst am Wochenende.

Grüße

Ralf

P.S.: OpenTX auf einer ProfiTX hätte schon etwas....
 
Hi Kalle,

einen zweiten LED Ausgang braucht man nur, wenn man eine externe LED sichtbar im Sender anbringen will.
Eigentlich also nur für die X9E oder bei einer ganz individuellen Anordnung.
Wenn die "Mainstream" Version des Konverters mal läuft, können wir solche Details verhandeln. :D

Das Dauerleuchten der LED, wenn von Anfang an nichts angeschlossen ist, ist normal.
Der Konverter zählt eine bestimmte Anzahl von M-Link Paketen ab, bevor er das Dauerleuchten abschaltet.
Wenn keine Pakete kommen, bleibt das Dauerleuchten eben bestehen.
Die Beschreibung ist da vermutlich ein wenig ungenau.
Vemutlich schaltet er die LED ab, wenn er vorher schon mal normal gelaufen ist.
Das muss ich mal nachprüfen unf ggf. die Anleitung anpassen.
 
Hi Ralf,

also man kann innerhalb einer Solution schon verschiedene Controller verwenden.
Der Controller wird dem Projekt zugeordnet, nicht der ganzen Solution.
Man muss dann eben gemeinsame Source Files per Link in die verschiedenen Projekte einbinden.
Das kann auch das gleiche File in Projekten mit unterschiedlichen Controllern sein, wenn das File unabhängig von der HW ist.
Es ist ein sehr flexibles Konzept, wenn man sich erst mal damit angefreundet hat.
 
wenn ich den ATTiny ohne Verbidung zu MPX und FrSky starte, kommt die Start Blinkfrequenz, danach Dauerleuchten. :confused:
Ich habe das gerade nochmal mit der Pro Mini Variante getestet, und da ist es tatsächlich anders, nämlich so wie in der Anleitung beschrieben.
Der Konverter blinkt dreimal lang/kurz/kurz und dann ist die LED aus.
Bei der ATtiny 841 Version bleibt die LED nach der initialen Blinksequenz an.
Irgendwas muss da im Code des Hauptprogramms anders sein, was mich jetzt doch sehr wundert.
Also wieder mal Code Reading...
 
Das mit der LED ist mir jetzt klar.
Auf dem Arduino Pro ist die Status-LED mit einem Widerstand gegen Masse geschaltet.
Der Code geht von dieser Konfiguration aus und zieht den Pin zum Einschalten der LED auf HIGH, auch in der t841er Version.
Auf dem Nanite Board ist aber die Status LED nach Vcc geschaltet, man muss daher zum Einschalten den Pin auf LOW setzen.
Ich habe mir schon gedacht, dass die Blinksequenz des Nanite etwas komisch ausschaut. :rolleyes:
Die Anleitung ist jedenfalls richtig.

@kalle:
Hast Du ein Nanite Board oder Dein eigenes Design verwendet?
Wenn letzteres, musst Du die LED gegen Vcc geschaltet haben, anders ist das Verhalten nicht zu erklären.

Ich habe jetzt im Code für den t841 die LED Ansteuerung umgepolt.
Die LED des Nanite Boards blinkt jetzt richtig und ist nach der initialen Blinksequenz aus, wenn nichts angeschlossen ist.
Wie die Logik für eine zusätzliche Status LED sein soll, müssen wir dann noch klären, als Pin würde ich dann auch PA3 nehmen, so wie Ralf.

PS: Der Micronucleus Bootloader blinkt nach dem Reset auch erstmal, also nicht verwirren lassen.
Die Sequenz des Konverters ist aber leicht zu erkennen.
 

kalle123

User
Bei der ATtiny 841 Version bleibt die LED nach der initialen Blinksequenz an.
Irgendwas muss da im Code des Hauptprogramms anders sein, was mich jetzt doch sehr wundert.
Also wieder mal Code Reading...

Ach Reinhardt, da hab ich ja wieder mal gemacht. ;)

Fummel ja, wie bekannt, gerne rum und war mit meinem KiCad Produkt noch nicht so zufrieden.
Text auf der backside war viel zu klein und mir fehlte da noch die LED drauf.
(Ist so ein bisschen wie puzzeln :D)


Unbenannt.png

Seh gerade Reinhardt, du hast wegen der LED geantwortet.

Ich hab keinen Nanite, ist wohl auch nicht lieferbar. Also den 'blanken' ATTiny. RST high und die LED(B2) auf GND über den Widerstand rechts oben. Nach dem START Blinken >> LED ist ON. (Ralfs hex)

IMG_20210114_175525.png

cu KH
 
Merkwürdig.
Ralf hat die ganzen HW abhängigen Definitionen und Makros in ein großes Header File ausgelagert.
Ich habe da jetzt nicht genauer nachgeforscht, vielleicht hat er ja die Logik gemäß Nanite Board gemacht, Deine Beschaltung entspricht aber dem Pro Mini.
In meinem Master Projekt passt jetzt der Code zur Beschaltung auf dem Nanite.
 

kalle123

User
Deine Beschaltung entspricht aber dem Pro Mini.

Versteh ich jetzt aber nicht? A0 und A1 sind offen, B3 über 10k auf Vcc und LED an B2 und über 270 auf Gnd.

Aber STOPP, hab die LED mal rumgedreht und auf Vcc gelegt, dann kommen die Startblinks und danach ist aus!

(... und bei Mini liegt die LED auf Gnd)

Was ist denn da für ein Pegel auf B2? ich kram dafür aber jetzt nicht den Oszi raus. War ein 'harter' Tag, meine bessere Hälfte hat nen Rappel gekriegt und fing mit nem verfrühten Frühjahrsputz an und ich wurde eingespannt ... :rolleyes:

Naja, morgen ändere ich die KiCad nochmal und mach die Sache 'nanite' gerecht.

Gruß und schönen Abend noch - KH
 
Es bleibt merkwürdig, denn aus Ralf´s Code kann ich nicht erkennen, dass er die LED Logik umgedreht hat.
Es müsste also bei LED nach Masse richtig und bei LED nach Vcc falsch sein.
Es ist aber offensichtlich genau andersrum.
Naja, vielleicht kann er selbst es ja aufklären.
 
So, Kalle, jetzt kann ich es selbst aufklären (es hat mir doch keine Ruhe gelassen).
Nachdem ich nochmal in Ralf's Code geschmökert habe, habe ich gesehen, dass er die Definitionen für LED An und Aus vertauscht hat.
Er hat die LED Ansteuerung damit an die Beschaltung des Nanite mit LED nach Vcc angepasst.
Der Schlingel hat aber vergessen, auch meine Kommentierung auszutauschen, daher habe ich das auf den ersten Blick nicht gesehen. ;)

Somit ist jetzt alles klar:
Ralf's Code (und jetzt auch mein Master) gehen bei der Ansteuerung der Status-LED davon aus, dass diese gegen Vcc geschaltet ist wie beim Nanite.
Damit muss zum Einschalten der LED der Pin auf Low gezogen werden.
 

elral

User
Hallo zusammen
so schnell komme ich gar nicht nach...

Kalle,
das die LED an Vcc kommt hatte ich in #1137 schon gesagt ;)
Wenn Du magst kannst Du ja mal das anhängende HEX File aufspielen. Der M-Link Eingang ist PA0, der FRRSky Ausgang ist PA1. EIne Status LED kann an PA3 oder PB2 (ist die vorhandene auf dem Nanite) angeschlossen werden. Der Ausgang ist Low aktiv, die LED also an +3.3V.

Reinhardt,
also man kann innerhalb einer Solution schon verschiedene Controller verwenden.
Der Controller wird dem Projekt zugeordnet, nicht der ganzen Solution.
oh ja, ich erinnere mich. Man muss ein zweites Projekt in der Solution anlegen. Dabei ist mir aber dann auch wieder eingefallen, wo der Knackpunkt bei verlinkten Dateien ist. Auf Dateien, deren Verweise in einem Unterordner liegen, kann wohl nicht zugegriffen werden, zu mindestens ich schaffe das nicht (z.Bsp. /include/<link zum h-file>). Das habe ich dann "damals" auch schon durch setzen des include Pfades in der Toolchain umgangen (was manchmal sogar auch mehr sinn macht). Der Configuration Manager bleibt für mich aber weiterhin, ich sage mal gewöhnungsbedürftig ;)

Der Schlingel hat aber vergessen, auch meine Kommentierung auszutauschen, daher habe ich das auf den ersten Blick nicht gesehen
uuupppssss :(

Viele Grüße

Ralf
 
Hi Ralf,

habe Dir per E-Mail ein paar Anmerkungen zu Deiner Implementierung der FrSky IDs geschickt.

Was die Verlinkung von Dateien angeht, da muss man einfach mit relativer Adressierung, ausgehend vom Pfad des main Files arbeiten.
Die Option, ein File als Link einzufügen (wenn es in mehreren Projekten verwendet wird) ist allerdings in der Tat ein wenig versteckt.

Den Configuration Manager verwende ich nicht, ist ja schließlich ein Hobby, meine Config Control passiert in Excel.
Es stimmt schon, dass das Atmel Studio ein wenig überfrachtet ist.

Und ja, das mit der Status LED hatte ich völlig überlesen und daher nicht gemerkt, dass hier das Nanite anders ist als das Pro Mini.
Das Blinken mit meinem Code hat komisch gewirkt, aber ich hatte es doch noch irgendwie als lang/kurz/kurz erkannt.
Vielleicht sollte ich mir da ein Pattern einfallen lassen, bei dem eine Invertierung sofort ins Auge springt. :D
Beim Anschauen Deines Codes ist mir noch eine Idee gekommen, wie man das Ansteuern der Status LED im Code vielleicht vereinfachen könnte.
Das werde ich bei Gelegenheit mal genauer untersuchen.
 
Zuletzt bearbeitet:
Ansicht hell / dunkel umschalten
Oben Unten