OpenTX - Multiplex MLINK Konverter

Misch mich nochmal ein.

Das seh ich bei Frsky RX TX.



Koordinaten, Höhe, Speed, Heading.

Und das steht unter oXs MPX zur Verfügung

4 , GPS_COURSE , 1 , 1 , 0 , -16384 , 16383 , \
5 , GPS_SPEED , 1 , 1 , 0 , -16384 , 16383 , \
6 , GPS_ALTITUDE , 1 , 1 , 0 , -16384 , 16383 , \
7 , GPS_DISTANCE , 1 , 1 , 0 , -16384 , 16383 , \
8 , GPS_BEARING , 1 , 1 , 0 , -16384 , 16383

COURSE wird Heading entsprechen. SPEED und ALTITUDE sind klar. DISTANCE könnte die von dir erwähnte Entfernung sein, Reinhardt und BEARING der Azimuth Wert.

Der Unterschied Frsky <> MPX halt statt Koordinaten DISTANCE und BEARING bzw. Entfernung und Azimuth.

cu KH

Hallo zusammen,

ich habe mir das Alles gestern Abend nochmal durch den Kopf gehen lassen, war aber schon zu spät zum Schreiben hier.

Ich denke, man könnte mit relativ wenigen Regeln alle GPS Parameter unterstützen.
Da es für die meisten Werte ohnehin keine vordefinierte FrSky ID gibt, und für Course und Speed
wegen der nicht passenden Einheit ohnehin im Sender manuell konfiguriert werden müsste, schlage ich folgendes vor.

Die (maximal 2) Geschwindigkeiten werden in der Reihenfolge der MSB Adressen als FrSky IDs 0x31 - 0x32 übertragen.
(liegen damit unmittelbar hinter der ID für die Vertikalgeschwindigkeit vom Vario)

Alle Winkel (maximal 3) werden in der Reihenfolge der MSB Adressen als FrSky IDs 0x1D - 0x1F übertragen.
Es gibt ohnehin nur für Course eine vordefinierten ID, aber mit falscher Einheit und einer vom MPX GPS nicht unterstützten Auflösung.

Höhen / Entfernungen / Wegstrecken:

Baro-Höhe, falls vorhanden, wird immer auf MSB Adresse 06 übertragen.
GPS Höhe, falls vorhanden, wird immer auf MSB Adresse 10 übertragen.

Alle anderen (maximal 4) Parameter mit Werteklasse 8 (3d/2d Entfernungen und Wegstrecken)
werden in der Reihenfolge der MSB Adressen als FrSky IDs 0x33 - 0x36 übertragen.
(Es gibt ohnehin keine vordefinierten IDs dafür.)

Durch die Verwendung freier IDs für alle Geschwindigkeiten und Winkel werden auch die alten BP/AP Formate
für Speed und Course vermieden, die zwei statt einem FrSky Frame erfordern.

Jetzt muss ich mir nur noch überlegen, wie ich das dann implementiere.

Was haltet Ihr davon?

Deinen Beitrag hier, Reinhardt, hab ich jetzt gar nicht mitgekriegt.

Ich hab "hinter den Kulissen" mit Roland gemailt und auch den Fehler und die Unklarheiten beim Entwickler von oXs beseitigen können.

Die GPS Daten des oXs GPS sind diese (MPX GPS bietet mehr, ich weiß ;-) )

GPS_COURSE
GPS_SPEED
GPS_ALTITUDE
GPS_DISTANCE
GPS_BEARING

Die Fehler bei GPS_DISTANCE mit 0.7 km ist nun geändert.

Sieh jetzt so aus >> 2m



Jetzt sind die o.a. Begriffe noch etwas unklar im Einzelnen.

Ich beziehe mich mal auf diese Zeichnung aus dem MPX GPS manual.



GPS_COURSE ist Heading. Also Flugrichtung des Modells bezogen auf true north.
GPS_SPEED ist klar. Kann 2D oder 3D sein, aber das sollte die Programmierung nicht betreffen. Und ich weiß km/h <> kts
GPS_ALTITUDE ist Höhe auf NN
GPS_DISTANCE ist Entfernung 2D Pilot - Modell in m (und nicht km!)
GPS_BEARING ist Azimuth. Auch auf true north.

Grüße KH

Hallo zusammen,
ich wollte mich nur mal kurz melden. Florian hat alle Vorgänge und Problemchen korrekt geschildert hat.

flosch1980 schrieb:

... für die Hintergründe und Detailinfos muss Nico sich melden.
Nico hat mir eine Zip Datei zusammen gestellt welche ich mir runter geladen habe, in dieser waren avrdude.conf, avrdude.exe, flash.cmd, MLink20160919.hex und test.cmd. Dann habe ich den Arduino so wie auf Nicos Bild ein paar Seiten vorher zu sehen an die PIN Leiste des Programmieradaters gesteckt, dann den Adapter mit dem USB Kabel an den Rechner angeschlossen, die test.cmd ausgeführt und als das lief dann flash.cmd und fertig war es.

Zum Vergrößern anklicken....

Florian hat das alles völlig richtig beschrieben. Zur Vereinfachung hatte ich ihm ein .zip-Archiv mit allen benötigten Dateien zusammengestellt und zwei Batch-Dateien geschrieben, damit er das sehr einfach zuerst mal auf Funktion testen und später flashen konnte.
Wenn klar ist, ob auch die Konverter-Firmware auf seinem Arduino Pro Mini mit dem Bootloader korrekt kooperiert, werde ich gerne meine Anleitung für Flo und die .zip-Datei bei Interesse zur Verfügung stellen.

kalle123 schrieb:

Aber ob das Programm auch funktioniert, weisst du noch nicht.
Bin immer davon ausgegangen, das der direkte Zugriff mit hex code nicht über TX RX geht.

Zum Vergrößern anklicken....

Diese Frage ist aktuell auch noch offen!
Sobald Florian seinen neuen Arduino Pro Mini wieder geflasht hat und die Kombi mit dem M-Link-Modul testen konnte sehen wir mal weiter.
Notfalls kann er dann ja auch über USBasp flashen, aber die Lösung per Bootloader und FTDI-Adapter hat den Charme dafür nicht löten zu müssen und nur unbenutzte Anschlüsse zu verwenden. So lässt sich später recht elegant neue Firmware aufspielen.
Aber warten wir einfach mal ab...

Grüße,
Nico

Hallo Reinhardt,

ich denke wir sind mit allen deinen Vorschlägen zu den Erweiterungen einverstanden! Egal wie man diese im FrSky Sender definieren muss. Für jeden Sensorwert der konvertiert werden kann, wird dir früher oder später jeder dankbar sein, der einen konvertierbaren Sensorwert einsetzen möchte!

Lg
Roland

Hallo zusammen,

ich habe gestern Abend die Erweiterungen noch zum großen Teil eingebaut.

Ich bin dabei auf ein potentielles Problem gestoßen, was die Richtungen und Geschwindigkeiten angeht.
Und zwar bin ich mir nicht sicher, ob es mit nicht vordefinierten IDs überhaupt möglich ist, die richtige Anzeige im Sender zu erzeugen.
Das liegt daran, dass diese Parameter keine ganzzahligen Einheiten (LSB Werte) haben (0,1 ° bzw. 0,1 km/h).
Ich muss mal testen, ob es möglich ist, über die Konfiguration des Telemetrie-Wertes im Sender hier die richtige Anzeige hervorzuzaubern.
(sprich so, dass der Wert mit einer Stelle hinter dem Komma, die aber nicht einfach 0 ist, dargestellt wird)

Für die Entfernungen sehe ich kein Problem, da hier die Einheit ganzzahlig (m) ist.
Aber für die anderen Parameter wäre möglicherweise ein Feature in OpenTx erforderlich, das es für undefinierte IDs natürlich nicht gibt.
Für die (nachträglich eingeführte) ID 0x39 ist dieses Feature z.B. implementiert, um eine Spannung mit 0,1 V Auflösung richtig darzustellen.
Da das ein reines Anzeigeproblem ist, kann man da wahrscheinlich im Konverter auch nichts dementsprechendes programmieren.

Wenn sich das mit den unbenutzten IDs nicht so konfigurieren lässt, kann ich nur eine Geschwindigkeit und eine Richtung übertragen.
Dafür müssten dann die vordefinierten IDs für GSpd und Course benutzt werden, die einen Anteil hinter dem Komma mit separater ID vorsehen.

Ich werde berichten, was mei meinen Versuchen herausgekommen ist.
Eine neue Version stelle ich dann hier ein, wenn die GPS Parameter implementiert sind, wie auch immer.

Nico_S_aus_B schrieb:

aber die Lösung per Bootloader und FTDI-Adapter hat den Charme dafür nicht löten zu müssen und nur unbenutzte Anschlüsse zu verwenden. So lässt sich später recht elegant neue Firmware aufspielen.

Zum Vergrößern anklicken....

Da würde sich ja dann der nano anbieten. Bin schon mehrfach mit einem so einfach daran gehaltenen FTDI oder CP2102 beim flashen von pro minis rein gefallen.

Gruß KH

@Reinhardt, du denkst bitte bei deiner nächsten Version auch an das Timing Problem.

Ich lasse das GPS dann erst mal so hier auf der Fensterbank so stehen und mache dann nur Versuche in der Richtung.

@Roland. oXs GPS Fehler (km <> m) beseitigt, Ausgabedaten klar?

Frohes Schaffen - KH

kalle123 schrieb:

@Reinhardt, du denkst bitte bei deiner nächsten Version auch an das Timing Problem.

Zum Vergrößern anklicken....

Aber sicher doch, ich mache jetzt nur keine eigene Version dafür.

Im Moment ist es so gelöst, dass die Adressermittlung nach jedem empfangenen gültigen M-Link Datenpaket aufgerufen wird.
Damit ist es dann egal, wann ein Parameter zum ersten Mal auftaucht.
Man kann sogar jederzeit Sensoren an- und abstecken, und das wird richtig erkannt.

Es kann aber möglicherweise im Zusammenhang mit der automatischen Adressenermittlung zu kleinen Besonderheiten führen.
Wenn z.B. nur eine der Entfernungen auftaucht, ist die MSB Adresse ja zuerst die niedrigste und bekommt die entsprechende ID.
Kommt dann ein bißchen später eine weitere Entfernung dazu, die eine niedrigere MSB Adresse hat, bekommt die erste Entfernung eine andere ID.
Es könnte also sein, dass sich an der Sensorkonfiguration über eine gewisse Zeit die zugeordneten IDs ändern, solange noch nicht alle Daten vorhanden sind.
Da muss ich nochmal ein wenig drüber nachdenken.

Dann frohes Schaffen, Reinhardt

Grüße KH

Guten Abend,

ich habe jetzt mal einen Test gemacht, indem ich den Wert für die Ladung auf einen festen Wert von 25318 gesetzt habe.
Dieser Parameter wird ja auch über eine von OpenTx nicht benutzte ID (0x29) übertragen.
Preisfrage war: Wie kriege ich mit diesem Wert eine Anzeige von 2531.8 auf das Display.

Nach Helle's Handbuch soll der Telemetriewert einfach durch 10 geteilt werden , wenn keine Umrechnung (Ratio) eingestellt ist.
Das hätte ja genau gepasst, dem ist aber nicht so, vielmehr wird der Wert unverändert dargestellt.
Bei einer Präzision von einer Nachkommastelle erscheint also 25318.0, das bring uns nicht weiter.

Mit eingestelltem Umrechnungsfaktor ist laut Handbuch die Umrechnung = (Wert / 256) * Umrechnungsfaktor + Offset.
Das ist fast richtig, es ist in Wirklichkeit (Wert / 255) * Umrechnungsfaktor + Offset (wie auch im Beispiel im Handbuch korrekt dargestellt).
Man muss also lediglich einen Umrechnungsfaktor von 25.5 einstellen, und schon erscheint auf dem Display 2531.8, Heureka.

Somit müsste sich das obige Konzept mit den freien IDs doch ohne Probleme umsetzen lassen.
Ich gehe schwer davon aus, dass das, was mit einer freien ID geht, mit allen freien IDs geht.

Na dann mal los (das meiste ist eh schon fertig ).

Reinhardt, was für eine LADUNG?

Meinst du mAh? Hab mir deinen letzten post hier dreimal durchgelesen, aber ich weiß nicht, wie ich da eine "intelligent" erscheinend Antwort drauf geben könnte.

Politiker z.B. können das mit Links, aber ich bin halt Ing. geworden.

LG KH

kalle123 schrieb:

Reinhardt, was für eine LADUNG?

Meinst du mAh? Hab mir deinen letzten post hier dreimal durchgelesen, aber ich weiß nicht, wie ich da eine "intelligent" erscheinend Antwort drauf geben könnte.

Politiker z.B. können das mit Links, aber ich bin halt Ing. geworden.

LG KH

Zum Vergrößern anklicken....

Hallo Kalle,

siehe hier zum Thema Ladung.

Eine intelligente Antwort ist im Moment nicht nötig, ich habe alles was ich brauche.

OK. Bin wieder im Lot, Reinhardt.

Grüße KH

PS. Verwende dieses script hier. http://rcdiy.ca/battery-capacity-remaining/
Danke noch mal an rcdiy!

Zur Erläuterung (ja, ich weiß, ist off-topic ) ...

Stromsensoren bei mir ACSxxx mit oXs.

Verbrauch (Ladung) rechnet die Taranis Telemetry hier als Produkt aus Strom und Lipo Spannung



Blöd ist nur, das da der mAh Wert hochgezählt wird. Interessanter für den Piloten ist aber die Akku Restkapazität.

Und hier kommt o.a. lua script zum tragen.



Das script rechnet die Kapazität runter. Ich habe dazu noch auf einem 3 pos Schalter folgende Funktionen:

(Weil ich nicht dazu auf das display schauen will ...)

- AUS

- alle 10s sagt Amber mir die Lipo Spannung an

- alle 10 s flüstert Amber mir die Restkapazität des Akkus in Prozent an.

So, jetzt bin ich wieder still

Grüße KH

Hallo, das Skript ist super!
OXs hat doch die Ausgabe Option "Consumption "=Verbrauch.
Nutzt du diese Option oder rechnet/zählt die Taranis bei dir die mAh?
Über Consumption könnte man die Restladung einfach über die Einstellungen im Sender ermitteln indem man die Akku Kapazität abzieht.
Bei mir und den 5A Sensoren funktioniert die Consumption nich.

Das, lieber Roland, ist OFF-TOPIC!!

Aber ich will nochmal eine Ausnahme machen ...

Consumption addiert laufend das Produkt aus Lipo Spannung und Strom auf.

Aber Consumption ergibt einen ANSTEIGENDEN Wert. Mich interessiert aber die Restkapazität.

Und das geht mit dem lua script recht einfach.

Hab mal einen Wert aufgeschrieben: Mit dem Chinook II

Cons lt. Telemetrie 664 mAh

danach geladen 690 mAh. Ich bin zufrieden.

LG KH

PS. ... und so sieht das im Sim aus.
https://www.dropbox.com/s/3pi5nsay3o6aihh/test.mp4?dl=0
Mit einer log Datei von einem Flug. SA ist der Schalter für Spannungs- und Stromansage.

Hallo zusammen,

ich war die letzten Tage recht fleißig zugange mit dem Konverter und habe jetzt alle neuen Features eingebaut.
Es können jetzt auch alle Daten vom MPX GPS übertragen werden.
Dafür werden überwiegend freie IDs benutzt, d.h. man muss die Telemetrieanzeige im Sender konfigurieren.
Für Parameter mit einer Auflösung von 0,1 km/h bzw, 0,1 ° muss eine Umrechnung von 25,5 eingestellt werden und eine Nachkommastelle.
Ich habe das, wie weiter oben beschrieben, mit der Ladung (für Kalle: Kapazität ) ausprobiert.
Ich habe kein MPX GPS, daher konnte ich die neuen Parameter nicht selbst testen, aber Roland ...

Die Ermittlung der MSB Adressen läuft jetzt permanent (nach jedem empfangenen M-Link Datenpaket).
Daher sollte es jetzt keine Probleme mehr mit langen Startzeiten geben.
Man kann sogar im laufenden Betrieb neue Sensoren am Bus anstecken, und sie werden erkannt.

Der Preis für die Vielzahl an nun möglichen Parametern, die teilweise die gleiche Werteklasse haben,
besteht in folgenden Regeln für die Vergabe der MSB Adressen:

Für Spannung A1, Spannung A2 und RSSI (derzeit einfach der durchgereichte LQI) sind die konstante Adressen 0, 2 und 1 zugeordnet.
(Diese können nicht anderweitig verwendet werden.)

Für Baro-Höhe und GPS-Höhe sind ebenfalls konstante Adressen zugeordnet (6 bzw. 10).
Diese können jedoch auch für Parameter mit anderen Werteklassen verwendet werden, wenn keine Baro-Höhe, bzw. GPS-Höhe vorhanden ist.

Die Werte dieser vordefinierten Adressen entsprechen den Multiplex Werkseinstellungen.
Ich denke, damit kann man leben, der Konverter kann jetzt mehr Parameter übertrage als es verschiedenen MSB Adressen gibt.

Ich habe im Zuge dieser Änderungen etliche Optimierungen im Code vorgenommen, ohne die Funktionalität zu ändern.
z.B. habe ich die einzelnen Variablen für die FrSky Sensordaten, zusammen mit den zugeordneten MSB Adressen, in ein Daten-Array gepackt.
Dadurch sind Dutzende von einzelnen Variablen überflüssig geworden, und der Code ist jetzt wesentlich übersichtlicher.
Solche Änderungen, die sich durch das ganze Programm ziehen, sind natürlich von Natur aus anfällig für Flüchtigkeitsfehler.
Bisher läuft das Teil zu meiner vollen Zufriedenheit, aber bevor ich das File hier einstelle, will ich noch ein bisschen testen.
Mal schauen, morgen soll das Wetter wieder besser werden, und meine Frau muss arbeiten ...

Als kleinen Vorgeschmack habe ich die letzte Version des Header Files für das FrSky Interface angehängt.
Daraus gehen die verwendeten FrSky Daten IDs hervor.

Hallo Reinhardt. Schön, von deinen Fortschritten zu hören.

Da muß ich ja langsam hier einen Tisch freimachen für weitere Versuche.

Freu mich drauf. Schönen Abend noch - KH

Hallo zusammen,

nachdem das Wetter heute doch nicht ganz so einladend für Feldtests ist, will ich Euch die neue Version nicht länger vorenthalten.
Zusätzlich zu den obigen Regeln für die Adressvergabe ist folgende wichtig:

Gleichartige Parameter werden in der Reihenfolge der MSB Adressen den FrSky IDs zugeordnet.
Ich weiß nicht, ob das in der Praxis vorkommt, aber wenn diese Parameter zeitlich versetzt am MSB auftauchen,
kann das theoretisch dazu führen, dass während der Hochlaufphase die IDs der Parameter noch wechseln.

Viel Spaß beim Testen, gemeldete Fehler werden unverzüglich behoben.