OpenTX - Multiplex MLINK Konverter

hallo Reinhardt,

bei mir funktionieren Höhe und Vario. >GPS Daten wie Speed werden problematisch.

In deiner alten Version hattest du Geschwindigkeit umgesetzt. Auch in der neuen?

Der Empfänger liegt nun auf der Fensterbank mit einem GPS Sensor. Sehe ich das richtig, dass der Konverter beim Senderstart die verfügbaren Sensoren einliest? Wenn dem so ist, wird es bei GPS Sensoren immer Probleme geben, bzw zuerst Empfänger einschalten und dann erst den Sender, wenn der GPS Sensor Satelliten gefunden hat. (Kaltstart :1Minute /Warmstart approx. 10Sekunden)
Bei meinen Seglern geht das, bei Motor-Maschinen wird's vielleicht gefährlich.

Wäre es möglich in einer Version diese Wartezeit auf 15 Sekunden hochzudrehen? MPX gibt beim GPS Sensor 10 Sekunden für einen Warmstart an. Demnach sollten 15 oder 20 auch für GPS ausreichend sein. 20 Sekunden Wartezeit wäre für mich kein Problem. Lieber länger warten, als mit dem Motor rum-pfuschen...

Mit längerer Wartezeit bräuchte man Sender und Empfänger nach einer "Aufwärmphase" nur kurz restten, dann sollten die Daten ankommen.

LG
Roland

Nachtrag:
Gspd: 0 Knoten wurden soeben gefunden. Der >GPS Sensorwert funktioniert. Lediglich die Startzeit ist problematisch!
(GSpd = GroundSpeed)

lg
Roland

Also geht ein Teil des M-Link GPS Protokolls wohl doch!

Aber beim MPX GPS wird doch u.a. so was wie Richtung und Entfernung übertragen, opentx erwartet doch NMEA Koordinaten.

cu KH

MPX überträgt Speed, Distanz und Richtung. jeweils mehrere Varianten. Koordinaten können im Flieger auf den Flightrecorder geloggt , jedoch nicht zum Sender gefunkt werden.

Die GPS Sensordaten die über Mlink geschickt werden, sind "einfache" Daten, wie Höhe, Vario, Strom usw. und können natürlich auch übersetzt werden, wie jeder andere Mlink Sensorwert.

PS: Diese Daten können auch vom OpenXsensor mit GPS übertragen werden!! Verteilt man die GPS Daten auf Arduino und "DIY GPS Logger", könnte man gleichzeitig auch loggen.
lg
roland

Hallo Mitstreiter,

erst mal vielen Dank für Eure tatkräftige Mitarbeit.

Um herauszufinden, was da bei Kalle mit der Höhe schief läuft, sollten wir erst mal das Feedback des Entwicklers abwarten.

Ja, der Konverter setzt die Geschwindigkeit vom M-Link Modul (Werteklasse 4) in die GPS Geschwindigkeit (ohne Vorzeichen) des FrSky Protokolls um.
Allerdings wird die Einheit/Auflösung von 0,1 km/h beibehalten und nicht in Knoten umgerechnet.
Ich werde mal drüber nachdenken, wie man die vom MPX GPS Sensor gelieferte Entfernung umsetzen könnte.
Wenn es keine geeignete vordefinierte ID gibt, muss man sich halt (wie bei Drehzahl und Kapazität ja auch schon)
eine unbenutzte ID suchen und dann die Einheit etc. manuell im Sender konfigurieren.
Gibt der MPX GPS Sensor außer Geschwindigkeit, Höhe und Entfernung sonst noch was Sinnvolles aus?

Das mit der Hochlaufzeit eines GPS Sensors ist mir in den letzten Tagen auch schon durch den Kopf gegangen.
Das mit dem Empfänger zuerst einschalten ist keine Option, da muss ich mir was einfallen lassen.
Mal schauen, ob es möglich ist, sagen wir mal nach 3-4 s die Telemetrie-Ausgabe zu starten und parallel dazu
noch für eine gewisse Zeit (oder vielleicht auch permanent) nach neuen MSB Adressen Ausschau zu halten.

Watch this space.

Hallo Reinhardt,
anbei ein Bild der GPS Einstellungen.
Was sinnvoll ist kann ich noch nicht sagen. Habe das Teil erst ein paar Tage.
Heading/ Elongation sind Richtungen in Grad. Also der Flugkurs entweder auf Pilot oder Modell bezogen. Azimut ist die Richtung des Modells, falls es mal wo "eingeschlagen" sein sollte, und man es suchen will.
2D und 3D dürfte Geschwindigkeit ohne und mit Einfluß der Höhe sein.

Positionsdaten werden auch auf den BUS geschickt aber da diese Daten nicht den Spezifikationen entsprechen, werden sie entweder gar nicht zum Sender geschickt oder können vom Sender nicht ausgewertet werden.
Interessant würde ich Groundspeed, Distanz und Azimut finden. Höhe und dh (Änderung der Höhe könnte der Sender berechnen) könnte man als 2tes Vario verwenden. Wegstrecke und Min/Maxwerte sind nicht notwendig. diese kann auch der Sender ermitteln.

Wäre es nicht am einfachsten, die "Startzeit" auf 1-2 Minuten hinaufzudrehen, bzw mit "delay" eine definierte Zeit pausieren. Ob die Telemetrie gleich oder erst nach einer Minute rennt, wird egal sein. Nach 1-2 Minuten stecke ich auch keine neuen Sensoren mehr an.
lg
roland

Guten morgen in die (kleine) Runde hier

Nach einer Nacht, in der ich schlecht geschlafen habe, (passiert mir immer, wenn ich ein mir nicht erklärliches Phänomen habe ...) noch mal daran gesetzt.

Von Michel hab ich nichts gehört, aber bei oXs ist es auch momentan sehr ruhig. Urlaub?

Mal eine kleine Übersicht, welche Komponenten da sind und was ich gewechselt habe. So was hilft immer beim "trouble shooting".



Gewechselt wurden: oXs, RX, TX Modul. Kann man erst mal ausschliessen. Bleiben also "Reinhardts" Konverter und die Taranis. Hab nur eine Taranis, also noch mal den Konverter mit anderen Komponenten aufgebaut und hex file aufgespielt.

Sieh ein bißchen wild aus, aber einen pro mini wollte ich auf die schnelle nicht zusammen braten.



So EIN und Höhe wieder nix



Dann einfach mal so den RESET auf dem nano gedrückt. Amber flüstert "Telemetry lost .... telemetry recovered" und siehe da



HÖHE IST AUF WUNDERSAME WEISE AUCH BEI MIR DA!

Reinhardt, der "Ball" geht an dich ....

LG KH

Hallo Kalle,
Bleibt Höhe jetzt erhalten oder kommt und geht sie?
Ich habe meinen Sender mit dem neuen Konverter erst 3x eingeschaltet und Sensoren gesucht. Höhe wurde jedes mal gefunden.
Passiert das nur bei Höhe? Hast du einen Kanal priorisiert? Wie verhält sich Höhe auf einem anderen Kanal?
LG Roland

Hallo Roland.

*Momentan mach ich gar nichts damit.

Bin erst mal froh, daß die Höhe erschienen ist und warte jetzt mal auf Reinhardts Meinung dazu.

Wenn der Code eine *.ino Datei wäre, würde ich mich ja auf die Suche machen, aber bei *.hex?


*Hab doch nochmal eingeschaltet. Verhalten wie oben. (Erst nach RESET erscheint die Höhe)
Arbeitet und scheint stabil anzustehen.

Mal schauen, was Reinhardt dazu sagt.

Was ich jetzt nicht möchte ist, den oXs Sensor umzuflashen. War bei 2 verschiedenen oXs Sensoren immer die Höhe, die nicht kam.
Ich halte das für ein reines timing Problem.

Schau'n mer ma!

Grüße nach Wien - KH

PS. JST 4pin 2mm hab ich mir jetzt in China bestellt. Die Versandkosten bei Conrad, nein danke!
Und wenn ich hier noch etwas suche, finde ich bestimmt noch irgendwo ein weiteres soundblaster Kabel.

Wie? Du musst jedesmal resetten?
Einschalten, resetten und erst dann rennt der Konverter?
Das wäre tragisch! Denn genau dasselbe Problem hatte ich mit Dieters Konverter auf der X9e.
Ich musste resetten oder den Konverter kurz vom Strom nehmen bzw erst anstecken wenn der Sender lief. Muss jetzt selber nochmal nachlesen, ob das Problem am Modul oder Sender lag. Ich verwende x9e mit Hfmg1!

Ich werde den Konverter demnächst auch auf der X9d testen. Welchen Sender hat Reinhard? Ich dachte Reinhardt testet und schreibt primär für die X9d ?
LG Roland

Donaufisch66 schrieb:

Wie? Du musst jedesmal resetten?
Einschalten, resetten und erst dann rennt der Konverter?

Zum Vergrößern anklicken....

Nein, Roland. Telemetrie ist da, nur Höhe fehlt.

RESET und DANN ist AUCH die Höhe da

Gruß KH

Hallo zusammen,

ich musste heute den ganzen Tag als Helfer auf dem von unserem Verein jährlich veranstalteten Oktoberfestpokal rumrödeln.
Daher bin ich gerade erst nach Hause gekommen und habe natürlich gleich interessiert hier nachgeschaut, was sich getan hat.

Ich teile Deine Meinung, Kalle, dass es sich um ein Timing Problem handelt.
Es gibt eigentlich keine andere Möglichkeit, das Verhalten bei Dir zu erklären.

Wir machen jetzt Nägel mit Köpfen:

Im Anhang ist eine gepatchte Version des Codes.
Bei dieser habe ich nichts anderes gemacht als die Anzahl der zur Adressenermittlung ausgewerteten M-Link Pakete auf 100 hochgesetzt.
Das sind dann ca. 10 s, das sollte eigentlich für den oXs Sensor ausreichen.
Es dauert dann mit dieser Version ca. 12 - 13 s, bis nach dem Einschalten bzw. Reset des Konverters die Telemetriedaten kommen.

Diese Version ist nur zum Testen, ich mache da noch eine elegantere Lösung, die dann auch mit dem GPS funktioniert.

Dank dir Reinhardt.

Runtergeladen und nachher spiel ich diese auf den Nano (geht einfacher, ISP Anschluss).

Beim pro mini hatte ich das BOOTRST Flag gesetzt, beim nano nicht. Hab aber da keinen Unterschied gesehen.

Für heute hast du genug getan

Ich melde mich morgen. Schönen Abend noch - KH

Das isses!

Höhe ist da. Mehrfach probiert ....

Eine paar Bemerkungen für die, die hier still mit lesen und sich nicht trauen.

- Nimmt man statt des Arduino pro mini den Arduino nano (der ist nur unwesentlich größer als der mini), ergeben sich zwei Vorteile.

Der nano hat eine USB Schnittstelle und (zum Aufspielen des hex files) eine ISP Schnittstelle. Vereinfacht einiges ... Kostet ~ 2€ in der Bucht.

- Ich verwende zum Aufspielen des hex files einen USBasp, dazu noch einen Adapter 10 pin -> 6 pin (für den ISP Anschluss des nanos) ~ 3€ in der Bucht.

- Zum Aufspielen nutze ich als Programm den AVR8_Burn-O-Mat. Gibt es als freeware unter Windows und Linux. Erfordert keinen IQ > 130

- Bißchen löten sollte man könne. Ein Kabel zum HF Modul - normales Servokabel. Das Kabel zur Buchse der Taranis X9D ist etwas problematisch. Hatte noch alte Soundblaster Kabel, die passen. Conrad hat wohl auch so etwas im Programm, muß man aber bestellen.
Hab mir jetzt eine 10er Packung der Kabel aus China bestellt. Könnte, wenn da, welche bei Bedarf von abgeben.

LG KH

Hallo zusammen,

na also, geht doch.

Das Hochsetzen der Zeit zum Scannen der Adressen ist allerdings wie gesagt nur ein vorübergehender Workaround.
Ich denke, ich werde das so machen, dass das Auftauchen neuer Parameter an der M-Link Schnittstelle ständig abgeprüft wird.
Dann ist auch das Thema GPS Hochlaufzeit gleich mit erschlagen.

Wie man dann mit Parametern umgeht, die plötzlich verschwinden, wäre noch zu klären.
Im Moment ist es ja so, dass der Konverter einen abgesteckten Sensor erkennt und die entsprechenden FrSky Daten abschaltet.
Das kann ich mir allerdings momentan nicht ganz erklären, warum das eigentlich funktioniert.
Es gibt nämlich im Code nichts, was die Eingangsdaten individuell daraufhin prüft.
Ich vermute, es hängt mit dem Abschalten / Wiedereinschalten der kompletten Telemetrie nach einer
bestimmten Anzahl von M-Link Paketen ohne / mit gültigen Werte zusammen.
Hier sind relativ kleine Werte als Hysterese eingebaut, und ich vermute, dass die Telemetrie
kurzzeitig (intern) abgeschaltet wird, aber bevor alle FrSky Frames verschwunden sind, wieder aktiviert wird.
Die Taranis kriegt das im Prinzip gar nicht so mit, aber nach einem Abschalten der Telemetrie werden alle Sensordaten
neu initialisiert, wobei der nicht mehr vorhandene Parameter dann für ungültig erklärt wird.
Das muss ich mir nochmal gaaanz genau durch den Kopf gehen lassen.
Es gibt in der SW Entwicklung fast nichts schlimmeres, als wenn etwas funktioniert und man weiß nicht warum.

@Roland:
Wenn das ganze Timing mal erledigt ist, werde ich mich um die noch ausstehenden Parameter vom GPS kümmern.
Da diese aber z.T. mit bereits verwendeten Werteklassen ankommen, müssen wir uns dann auf die Regeln einigen,
nach denen die Umsetzung der MSB Adressen auf die FrSky IDs erfolgt.
Der Konverter kann nämlich z.B. die Höhe vom Vario nicht von der GPS Höhe unterscheiden,
außer man vereinbart z.B., dass die Baro-Höhe vom Vario immer auf Adresse 6 kommt.
Die GPS Entfernung kommt vermutlich mit der gleichen Werteklasse wie die Höhe, was weitere Vereinbarungen nötig macht.
Hier schlägt halt die doch recht eingeschränkte Menge an möglichen Werteklassen auf dem MSB gnadenlos zu.

Als kleine Vorbereitung habe ich übrigens bereits die feste Zuordnung des LQI entfernt.
Dieser kommt ja stets nur einmal, es ist also kein Problem, die Adresse automatisch zu ermitteln.

Weitere Fortschritte sind in den nächsten Stunden nicht zu erwarten.
Bei dem Wetter heute werde ich meine Frau schwerlich vom Vorhaben einer ausgedehnten Fahrradtour abbringen können.

Dann fröhliches Radeln, Reinhardt.

Leg deinen Konverter jetzt erst mal zur Seite.

Beim MPX GPS kann ich euch leider nicht helfen. Bin nicht bereit, die MPX Apothekerpreise dafür zu zahlen.

Da fällt mir ein, ich habe/hatte zu Beginn des Projekts "Konverter" in openrcforums Kontakt mit Jonathan in Singapur.

Er hat wohl das MPX GPS und den MPX Datenlogger im Einsatz. Werde ihn mal anmailen und auf deine Version hinweisen.

Vielleicht kann ich da als "Relais" helfen.

Schönen Tag noch - KH

Hallo Kalle,
Du kannst einen openxsensor auch als mlink gps nutzen.
Der spuckt dieselben Werte wie ein mpx gps aus! Speed, Distanz , Richtung und Höhe sollte er auswerten können. Der SM gps logger könnte sogar Koordinaten übertragen. Der maskiert diese als "Füllstand" .
Lg Roland

Donaufisch66 schrieb:

Hallo Kalle,
Du kannst einen openxsensor auch als mlink gps nutzen.
Der spuckt dieselben Werte wie ein mpx gps aus! Speed, Distanz , Richtung und Höhe sollte er auswerten können. Der SM gps logger könnte sogar Koordinaten übertragen. Der maskiert diese als "Füllstand" .
Lg Roland

Zum Vergrößern anklicken....

Hi Roland.
Ich habe, wie du weisst, oXs mit GPS. Aber bisher unter oXs + Frsky.
Aber du hast recht, sehe gerade, oXs kann unter dem MPX Protokoll das hier senden.

**** 9.3 Multiplex ************************************************************************************
.
.
* GPS_COURSE 0.1 deg Orientation of plane
* GPS_SPEED 0.1 km/h Ground speed (2D or 3D)
* GPS_ALTITUDE m Absolute Altitude
* GPS_DISTANCE 0.1 m Distance from home
* GPS_BEARING 0.1 deg Direction from home

Und das würde ja dann gehen. Bin immer von den NMEA Protokoll ausgegangen.

oXs ist schon phantastisch! Gut, Dieters Ansatz hat die Option nicht. Aber ich werde dann mal hier kramen und ein GPS raussuchen, einen Uno mit einer speziellen oXs MPX Version "beglücken". Irgendwie brauch ich eine 2. Taranis

Roland, welche GPS Daten von den oberen Werten hast du denn schon gesehen?

Grüße KH

So.

oXs Multiplex mit GPS funktioniert erst mal so.





Das sind die Ausgabedaten
// ***** 9.3 - Multiplex data *****
#define SETUP_MULTIPLEX_DATA_TO_SEND \
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

#7 GPS_Distance ist mit 0.7 km ein bißchen "wild". Der Sensor steht hier auf der Fensterbank
Hab das aber schon weitergegeben ....

Wie geht es jetzt weiter?

LG KH

Hallo Kalle,
genau! diese Werte kann der openxsenser übertragen. Ist schon eine nette Sache, der OpenXsensor!
Zusätzlich könntest du die 4 GPS Leitungen parallel an den DIY GPS Logger schicken. Dann kannst auch gleichzeitig (im Modell) Positionsdaten loggen. Hab ich noch nicht probiert, müsste aber funktionieren.

Hast du Dieters Konverter getestet? Erkennt er diese Werte? Soweit ich mich erinnern kann, waren im Code alle Werte definiert.
lg
Roland