OpenTX - Multiplex MLINK Konverter

Donaufisch66 schrieb:

Ok, also müsste ich mit "Erase Chip" zuerst den Speicher komplett löschen und erst dann das Programm hochladen. Ich glaube das hatte ich beim ersten mal nicht gemacht, da ich angenommen hatte, das beim hochladen zuerst der Chip gelöscht wird, weil die Option "Erase device before prorgamming" aktiviert war.
Egal, Wenn die BOOTRST Fuse ohne bottloader nicht gesetzt sein darf, muß ich es wohl doch anders gemacht haben! :-) sonst hätte es wohl nicht funktioniert


Danke für die Infos!

Zum Vergrößern anklicken....

Hallo Roland,

Wenn Erase before Programming aktiviert ist, wird der Speicher vor dem Programmieren gelöscht.
Man kann aber über die Lock Bits den Speicherbereich des Bootladers schützen.
Vielleicht verhindert das dann auch, dass dieser Bereich beim Programmieren gelöscht wird, und der Bootlader bleibt erhalten.
Es würde eigentlich Sinn machen, denn der Bootladert stört ja wie gesagt nicht (außer, dass er ein bisschen Speicher braucht).
Da muss ich mich mal schlau machen, denn mit Bootlader könnte man dann sowohl per USB Kabel, als auch mit ISP Flashen.


Gruß
Reinhardt

Hallo,
ich habe im Sensor neue Adresse vergeben. Anbei ein Bild der neuen Adressen und ein Bild des Ergebnisses auf der X9E.
Parameterwerte mit aktivem MAX Speicher im Sensor springen nicht mehr herum. Ein MAX Wert MUSS jedenfalls eine höhere Adresse als der normale Parameter haben, dann sollte ein Sensor mit Multiplex und Konverter funktionieren! In openTX wird nur die niedrigere Adresse angezeigt. Warum es gehupft ist, kann ich jetzt nicht mehr nachvollziehen. War das vielleicht bei der ersten Version noch ein Problem und ich hatte das Problem noch mit der ersten Version??? Ich werde noch einige Sensoren und Adressen prüfen und dir ein Feedback geben, falls es wieder auftreten sollte.
JETZT, hupft jedenfalls nichts mehr!

Versuche ich Parameter und MAX Parameter auf die gleiche Adresse zu legen, schreit mein Sensorprogramm (Sensorcontrol von RCelec für Mlink Nachbausensoren mit Temp, Vario, Alt, 2xSpannung) bzw. kann ich es so nicht in den Sensor schreiben. Es kann also nicht sein, dass ein Paraeter und ein MAX Speicher auf dem selben Kanal sendeten.

Ich könnte prüfen wie sich der Konverter verhält, wenn ich zwei Sensoren mit gleicher Kanalbelegung in Serie anhänge. Jedoch glaube ich das dieses Fall auch bei MPX nicht vorgesehen wäre!


Sensor Adressen:


X9E Telemetrie:


Am Bild ist der Spannungssensor noch nicht auf 25,6 eingestellt.

Ansonsten schaut es sehr gut aus. Es dürfte alles richtig funktionieren, obwohl MAX Speicher aktiviert sind. Was der Konverter mit Alarmen macht, konnte ich noch nicht prüfen.

Zu RSSI habe ich nochmals bei Tobis "ACT-Konverter" nachgesehen. Er hatte in seinem Konverter RSSI gemittelt. In seiner Beschreibung weist er darauf hin, dass das Multiplex RSSI Signal manchmal kurzzeitig "hupft". Er hat die gemittelte RSSI-neu als LQI ausgegeben und die ursprüngliche RSSI auf einen unbelegten Kanal gelegt.
Sein Konverter dürfte unter MPX MLINK nicht funktioniert haben. Die Grundidee, RSSI zu "bearbeiten" ist aber sicher eine gute Idee.
Interessant wäre, Ausreißer die nur einige Millisekunden dauern, zu ignorieren und alle anderen Werte über eine definierte Anzahl (oder Zeitspanne) von Werten zu mitteln.


Das mein Sender keine Warnung bei verlorener Telemetrie ausgibt, ist sicher kein Konverter Thema. Da muss ich wohl Helles Handbuch nochmal durchsehen......
zu den LEDs: ist die boardLED nicht auf PIN 13?

LG
Roland

Hallo Roland,

na das schaut doch schon mal recht gut aus.

Mit den Alarmen macht der Konverter gar nichts, er ignoriert sie geflissentlich.
Alarme lassen sich sehr komfortabel in OpenTx konfigurieren, und das gehört m.E. auch in die Sendersoftware.

Das mit der Filterung des LQI Wertes kann man sicher mal aufgreifen, vielleicht ergeben sich da ja im diesbezüglichen Thread noch neue Erkenntnisse.

Als nächstes werde ich wie schon angedeutet die ID für die Drehzahl auf 0x07 abändern (Begründung s. oben).

Außerdem hatte ich früher mal gepostet, dass man den Auto-Offset bei der Höhe deaktivieren muss, da das MPX Vario
manchmal beim Einschalten kurzzeitig einen falschen Wert ausgibt, der dann von Opentx als Bezugswert genommen werden könnte.
Ich glaube mittlerweile, dass ich da dem Vario unrecht getan habe, und dass es lediglich den in der MSB Spezifikation definierten
Code für einen (noch) nicht vorhandenen Messwert ausgibt.
Dieser ist 0x8000, und wenn man das als echten Wert interpretiert, ergibt sich -16384 m (die oberen 15 Bit als signed int).
Nimmt OpenTx zufällig diesen Wert als Offset, ergibt sich eine Höhe von 16384 m, wenn das Vario den echten Wert (0 m) anzeigt.
Genau dieses Verhalten hatte ich beobachtet (irgendwas mit über 16000 m, werden dann wohl 16384 m gewesen sein).
Dieses sporadische Problem lässt sich leicht beheben, was ich dann auch machen werde.

Ich werde dann zu gegebener Zeit wieder eine neue Version einstellen, will aber erst mal noch ein wenig abwarten, vielleicht kommt ja noch mehr.


Gruß
Reinhardt

Reinhardt Werbik schrieb:

Übrigens scheint sich das "Problem" mit der vordefinierten ID für die Drehzahl tatsächlich als Feature zu erweisen.
Das Hub Protokoll sieht hier wohl die Übertragung von Umdrehungen pro Sekunde vor, Gott weiss warum.
(Das hat natürlich was mit der Implementierung des FrSky eigenen Drehzahlsensors für das Hub Protokoll zu tun.)
Open Tx multipiziert das dann mit 60 (und macht ggf. noch andere Anpassungen wegen Blattzahl etc.).

Zum Vergrößern anklicken....

Kleiner Nachtrag zur Drehzahl:

Ich habe mal blind ein bisschen im OpenTx Source Code "gesurft" und das da gefunden:

if (id == RPM_ID) {
data = data * 60;
}

Das scheint meine Theorie zu bestätigen.


Gruß
Reinhardt

Hallo zusammen,

hier nochmal was zur Drehzahl.

Die ID hierfür hatte ich ja auf 0x07 geändert, und heute habe ich dann endlich mal geschaut, was denn da so auf dem Display ankommt vom MSB Expert Regler.
Das Ergebnis war eher bescheiden, eine Drehzahl von 2 oder 3 war jetzt nicht so prickelnd bei drehendem Motor.

Nachdem ich verifiziert hatte, dass am seriellen Port der richtige Drehzahlwert als Ganzzahl ankommt,
habe ich mal ein bisschen mit den Telemetrie-Einstellungen herumprobiert.
OpenTx macht da offensichtlich für die Drehzahl irgendwas, was ich nicht wirklich nachvollziehen konnte (abhängig von Blattzahl, etc.).

Die Lösung war schließlich, als Einheit "Roh (-)" ohne irgendwelche Faktoren oder Offset einzustellen.
Dann kommt auch die Drehzahl richtig am Display an, und man sieht schön die Auflösung von 10 1/min des MSB Expert Reglers.

Na also, geht doch.


Gruß
Reinhardt

Hallo,

heute bin ich, trotz böigem Wind, endlich mal mit meinem Testflieger (FunCub mit MSB Expert Regler) auf dem Platz gewesen.
Der Konverter funktioniert soweit einwandfrei, ich konnte nichts Auffälliges feststellen.

Mit einer Ausnahme: Sporadisch kommt es vor, dass kurzzeitig ein blödsinniger Wert auf dem Display aufflackert.
Das hatte ich vorher schon beobachtet, und es liegt mit ziemlicher Sicherheit daran, dass das Einlesen der M-Link Daten
und das Senden der FrSky Daten nicht synchronisiert sind, da letzteres von einem freilaufendem Timer mit Interrupt getriggert wird.
Dadurch kommt es eben hin und wieder zu Kollisionen, was im Ergebnis zu einzelnen unsinnigen Werten führt, die zur Taranis gesendet werden.
Das war mir wie gesagt vorher schon bewusst, und ich habe es in Kauf genommen, dass das auf dem Display vorkommt, da es ja auch nicht wirklich stört.

Heute habe ich nun festgestellt, dass es auch sporadisch zu blödsinnigen Ansagen über die Sprachausgabe kommt, und das stört mich dann schon.
Ich werde also hier nochmal ran müssen, um die beiden SW UARTs zu synchronisieren, damit kein sporadischer Datenmüll mehr produziert wird.

Ich werde berichten.

Hallo liebe Kollegen,

ich muss Euch noch einmal etwas nerven. Nachdem ich mich eigentlich schon entschlossen hatte die Idee von Reinhard zu verfolgen und ich mir den gesamten Thread noch einmal angesehen habe - war ich mir nicht mehr so ganz einig und habe mal erst alles liegen gelassen.

Mittlerweile ist der Gedanke allerdings mehr gereift und ich möchte Eurer Empfehlung folgen und den Teensy aufbauen - hierfür habe ich den Teenys 3.2 (MK20DX256 Chip) beschafft. Ich habe allerdings ebenfalls ein Platinchen Arduino-Pro-Mini mit einem ATmega 328P AU1544 (soweit ich es ohne Lupe lesen konnte) ebenso habe ich noch einen NANO V3.0, ATmega328, CH340G -- alle hatte ich mir für dieses Projekt hier besorgt.
Komme ich zu meiner eigentlichen Frage: mit welcher Software bringe ich diese SW ??MLINKFrSkyConverter_Teensy_ohneInv_TX3.txt ?? oder auch

_MLinkFrSkyConverter_Teensy_SW_In.zip.txt

Zum Vergrößern anklicken....

//Text etwas reduziert//_MLinkFrSkyConverter_Teensy_Trans_Inv.zip.txt
Beide Programme können für den Teensy 3.2 oder den Teensy-LC übersetzt werden.
Beim Teensy 3.2 kann mit einer CPU-Taktfrequenz von 72MHz, 48MHz oder 24MHz, beim Teensy-LC mit 48MHz oder 24MHz übersetzenhttp://www.rc-network.de/forum/attachment.php?attachmentid=1572697&d=1458328954

Zum Vergrößern anklicken....

http://www.rc-network.de/forum/attachment.php?attachmentid=1572697&d=1458328954
- nur womit und wie "übersetze" ich denn? Welche SW benötige ich um die entpackten Dateien auf den Teensy zu schreiben? An einem der Bausteine ist ein micro USB und am Teensy ist mini USB.
Das ich 1x JR Stecker und 1x JST PH4 Stecker benötige - ist okay und habe ich auch.

Ich würde mich freuen, wenn Ihr mir noch einmal über'n Fluss helfen würdet. Danke.

Gruß
Frank

Frank, hallo, nimm deinen Teensy 3.2.

Dann die Arduino IDE 1.6.8 (bei der aktuellen Version 1.6.9 bin ich nicht sicher, ober der teensy loader die Version unterstützt.) https://www.arduino.cc/en/Main/OldSoftwareReleases#previous

Dazu den https://www.pjrc.com/teensy/loader.html installieren, damit die Arduino IDE auch Teensy kann.

Dann das zip Paket entpacken und mit der Arduino IDE die ino Datei öffnen.

Auf den Teensy laden. Kabel dran und feddig.

Würde aber zu Beginn raten, erst mal mit dem der IDE und dem Teensy etwas "spielen". Z.B. BLINK sketch laden ...

Aber die Anleitung von Roland hast du gesehen? -> http://www.rc-network.de/forum/showthread.php/567929-OpenTX-Multiplex-MLINK-Konverter

Da steht eigentlich alles ausführlich beschrieben ...
Getestet und geflogen Gruß KH

Hallo zusammen,

obwohl das Interesse an der simplen Arduino Lösung offensichtlich ziemlich eingeschlafen ist (ist ja auch Flugsaison),
und auch ich in den letzten Wochen nichts am Konverter gemacht habe, möchte ich das Thema trotzdem nicht ganz einschlafen lassen.
(Schließlich ist ja die Horus bereits am Horizont sichtbar, und wer weiss ... )

Für das weiter oben beschriebene Phänomen sporadischer falscher Daten hatte ich noch vor meinem Sommerurlaub einen Quick & Dirty Fix probiert.
Dieser hat aber nicht zufriedenstellend funktioniert, daher habe ich ihn verworfen und das ganze Thema erst mal wegen Urlaub, etc. auf Eis gelegt.
Nachdem sich der Sommer jetzt langsam seinem Ende zuneigt, werde ich sicherlich in absehbarer Zeit das Konverterthema wieder aufgreifen.
Sollte es also wider Erwarten noch irgendein Feedback zu der existierenden Version geben, immer her damit.
Ansonsten werde ich als nächstes das oben erwähnte Phänomen bereinigen, und dann schaun mer mal.


Gruß
Reinhardt

Hallo Reinhardt!
nachdem dein Konverter immer noch der einige ist, der auf der X9E problemlos funktioniert, wäre ich über jedes Update höchst erfreut!
Auch die Horus wird wohl einen Konverter benötigen. Daher bin ich sicher nicht der einzige, der diesen Thred verfolgt.
PS:
Hast du in Erwägung gezogen die neuen Sensorklasse "g" mit aufzunehmen?

lg
Roland

Reinhardt Werbik schrieb:

offensichtlich ziemlich eingeschlafen ist (ist ja auch Flugsaison) ....

Zum Vergrößern anklicken....

Reinhardt, ich fang jetzt an zu weinen

Am Konverter Version #1 hielt/hält sich das Interesse auch im recht überschaubaren Rahmen. Leider!

@Roland. Sensorklasse "g" - Was ist das denn? Hab das wohl was verpasst.

Grüße KH

kalle123 schrieb:

Reinhardt, ich fang jetzt an zu weinen

Am Konverter Version #1 hielt/hält sich das Interesse auch im recht überschaubaren Rahmen. Leider!

@Roland. Sensorklasse "g" - Was ist das denn? Hab das wohl was verpasst.

Grüße KH

Zum Vergrößern anklicken....

Hi Kalle,

klappern gehört zum Handwerk, aber weinen musst Du nicht gleich.
Ich habe jetzt nicht damit gerechnet, dass ich mit Anfragen überhäuft werde, ist mir eigentlich auch ganz recht so wie es ist.
Aber schön, dass sich die bisherigen treuen Seelen gleich wieder melden.

@Roland:
Muss mal schauen, welche FrSky ID sich für die g-Klasse anbietet.
Weiss man denn überhaupt schon, welches Format (LSB) Multiplex dafür vorgesehen hat?
Ein Update der MSB Spezifikation habe ich noch nirgends entdeckt.
Allerdings habe ich beim Suchen festgestellt, dass MPX ihre Web-Page modernisiert hat.
Dass ich das noch erleben darf.
Aber um Dir zu antworten, ja klar, wenn das Format bekannt ist, sollte das kein Problem sein.


Gruß
Reinhardt

über Sensorklasse "g" ist mir nur bekannt, dass die nächste frei Klasse 14 dafür verwendet wird.
Es gibt schon eine Firmware auf der Profi_TX Masteredition für HF und Sender. Für alle anderen soll das Update Ende August kommen. Also es kann sich also nur noch um Stunden handeln..
Neben Updates der ProfiTX soll es Updates aller HF Module geben um die neue "g" Klasse einzubauen. Dann wird auch bekannt sein, wie MPX damit umgeht. Sensor habe ich jedenfalls auch noch keinen gesehen. Vielleicht kann das Wingstabi dazu Sensorwerte ausgeben.

lg
roland

Die Sensoren müßt es eigentlich schon geben:
sm gps2 und
vspeak vario
Gruß Tk7

Dank euch für die Info.

War auch nur eine Frage am Rand.

Gruß KH

Beschläunigung als "g" kann jedoch noch kein Modul ausgeben.

Zumindest steht bei beiden auf de4 Homepage der Meßbereich jeweils in "g"
Gruß Tk7

Ach das hier



aus http://www.vspeak-modell.de/de/variometer/vspeak-vario

Den 3 Achsen Sensor MPU6050 haben wir aber auch schon in oXs mit drin ....

Gruß KH

Hallo zusammen,

nachdem es heute noch keine Sekunde ohne Regen gab, habe ich mich mal wieder meinem Konverter zugewandt.
Nach mehreren Monaten Pause musste ich erst mal ganz schön rödeln, bis ich alles wieder zusammengesucht hatte.
Es ist erschreckend, wie schnell man alles vergisst, wenn man sich mit einer Sache längere Zeit nicht mehr beschäftigt.

Aber es gibt positives zu vermelden.

Ich hatte zuerst keine Erklärung, warum mein Quick & Dirty Fix zum Synchronisieren der M-Link und der FrSky Datenpakete nicht funktionierte.
Durch den sporadischen Clash des Sendens der FrSky Daten mit dem Empfangen der M-Link Daten war es ja zu gelegentlichen blödsinnigen Daten gekommen.
Ich habe das heute wieder eindeutig sehen können (LQI bis zu 200), obwohl die Änderung es eigentlich zuverlässig verhindern hätte müssen.
Also musste das große Besteck (Hameg) her, um der Sache auf den Grund zu gehen, das Ergebnis war dann (für mich) eine Überraschung.
Und zwar sendet das M-Link Modul sporadisch bereits nach ca. 60 ms das nächste Datenpaket, statt nach etwas über 100 ms.
Und genau das hat meinen schnellen Fix zunichte gemacht.
Ich hatte aber schon eine weitergehende Lösung eingebaut (und wieder auskommentiert).
Die habe ich jetzt reaktiviert, und damit scheint das Problem behoben zu sein.

Ich werde jetzt noch einige Tests machen und schauen, ob sich noch das eine oder andere im Programm verschönern lässt.
Dann werde ich (für Roland?) ein Update hier einstellen.
Danach reden wir dann über zusätzliche Parameter, für mich ist jetzt erst mal wichtig, dass die implementierten Parameter
(sind ja doch schon einige) zuverlässig und ohne Falschalarme funktionieren.

hallo Reinhardt,
freue mich über jedes Update!
Lg
Roland