OpenTX - Multiplex MLINK Konverter

So, 60 km später ... (auf dem Fahrrad)

... und nach einigen Versuchen hat sich meine obige Theorie bzgl. des Abschaltens abgesteckter Sensoren als falsch herausgestellt (Gottseidank).
Offensichtlich überträgt das M-Link Modul, wenn auf einer bestimmten Adresse nichts mehr kommt, den entsprechenden Datensatz
für diese Adresse noch weiter (mindestens einmal), mit auf 0 gesetzter Werteklasse.
(ob auch der Sensorwert auf den Code für ungültigen Messwert gesetzt wird, habe ich nicht überprüft, da muss dann mal der Hameg ran.)
Wenn der Wert auf der Adresse wieder kommt, wird auch wieder die richtige Werteklasse übertragen.
Somit werden abgesteckte und wieder angesteckte Sensoren vom Konverter korrekt behandelt.
Ich finde, das ist ein feiner Zug vom M-Link Modul.

Die permanente Adressen-Überwachung habe ich auch eingebaut, scheint soweit auch zu funktionieren.
Ich will da aber noch ein wenig rumspielen, wer weiß ...
Eine neue Version gibt es dann in den nächsten Tagen, wenn ich mir sicher bin, dass das immer korrekt funktioniert.

Danach kann man dann ja die GPS Daten in Angriff nehmen, wie ich sehe, seid Ihr ja schon fleißig dabei.

Donaufisch66 schrieb:

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

Zum Vergrößern anklicken....

Ist Dieter's Konverter der Teensy Konverter?

Ja, das ist der Teensy Konverter.
Dieter hatte teilweise Code von Tobis ursprünglichen Konverter übernommen.
Tobi hatte ursprüngliche alle Paramater eingebaut, Dieter hat einige übernommen ich glaube aber nicht alle.

Reinhardt, mit euren 60 km kann ich nicht mithalten, waren bei mir nur 25 km heute.

@Roland. Werde das oXs GPS morgen mal mit Dieters Konverter probieren. Welchen Datenlogger meinst du? Den ich nach Maximilians Anleitung mal nachgebaut hab? M.E. müsse da ein ganz neuer Logger programmiert werden. Hast du inzwischen ein oXs GPS?

So wird heute noch ein langer Abend. Tochter #1 sitzt z.Z. noch in Budapest und wünscht "shuttle service" vom Düsseldorfer Flughafen. Schau mir gerade DEPARTURE BUD an. Delayed

LG KH

Openxsensor GPS habe ich schon länger. Rennt tadellos mit MPX.
Zum Logger: Ja, du hast mir mal Infos per Mail zu diesem "DIY GPS Logger" geschickt. Kann man die RX/TX Daten nicht für beide Arduinos verwenden? (1x OpenX, 1x DIY GPS Logger). Dann hast zwar 2 Arduinos im Modell, bei der Größe aber nicht relavant. Der MPX Logger ist größer....

Donaufisch66 schrieb:

Zum Logger: Ja, du hast mir mal Infos per Mail zu diesem "DIY GPS Logger" geschickt. Kann man die RX/TX Daten nicht für beide Arduinos verwenden? (1x OpenX, 1x DIY GPS Logger).

Zum Vergrößern anklicken....

Der "DIY" Logger konfiguriert das GPS Modul und das tut oXs auch. Du müßtest also die Konfigurationssequenzen bei einem rausschmeißen.

Dann das Datenformat der Loggers. Ist m.E. nicht so "prickelnd". Wenn du willst, schick ich dir mal die *.ino Dateien zum anschauen. Wenn ich es nicht schon gemacht hab. Ist vielleicht was für den kommenden Winter. Brauchst einen Arduino, ein GPS, einen SD Kartenadapter und eine SD Karte.

So die Maschine mit Tochter #1 steht gerade in Budapest auf der Startbahn. Es wird Mitternacht in D'dorf werden

Hallo Kalle,
hoffe deine Tochter ist wohlbehalten zurück gekommen. In Budapest war ja wieder eine "Bomben Stimmung".

Das man das GPS Signal nicht einfach parallel hängen kann, war mir klar. Ein Arduino müsste das GPS steuern und der andere nur mithören. Am optimalsten wäre ein Logger im OpenXsensor. Da FrSky am Sender loggt, wurde diese Option wohl nie angedacht.


@ Reinhardt:
du schreibst: ".....Da diese aber z.T. mit bereits verwendeten Werteklassen ankommen, müssen wir uns dann auf die Regeln einigen,"
Dürfen Werteklassen nur 1x vorkommen? Bei MPX kann man zb mehrere Varios anhängen, solange jedes einem anderen Kanal zugeordnet ist. Ich dachte das Prinzip wird vom Konverter übernommen. Jede Adresse am MLink BUS wird entsprechend der Klasse auf eine eigene FrSky ID gelegt. Somit ist jeder Wert eindeutig zugeordnet, dachte ich...
Kann man am FrSky Bus auch doppelte Sensoren auf unterschiedlichen Kanälen/IDs nutzen oder ist dort jeweils nur eine vorgegebene Anzahl an einzelnen Sensorwerten erlaubt?

Wenn Regeln notwendig sind, erstelle sie so, wie es für dich am einfachsten ist.
Lg
Roland

Donaufisch66 schrieb:

@ Reinhardt:
du schreibst: ".....Da diese aber z.T. mit bereits verwendeten Werteklassen ankommen, müssen wir uns dann auf die Regeln einigen,"
Dürfen Werteklassen nur 1x vorkommen? Bei MPX kann man zb mehrere Varios anhängen, solange jedes einem anderen Kanal zugeordnet ist. Ich dachte das Prinzip wird vom Konverter übernommen. Jede Adresse am MLink BUS wird entsprechend der Klasse auf eine eigene FrSky ID gelegt. Somit ist jeder Wert eindeutig zugeordnet, dachte ich...
Kann man am FrSky Bus auch doppelte Sensoren auf unterschiedlichen Kanälen/IDs nutzen oder ist dort jeweils nur eine vorgegebene Anzahl an einzelnen Sensorwerten erlaubt?

Wenn Regeln notwendig sind, erstelle sie so, wie es für dich am einfachsten ist.
Lg
Roland

Zum Vergrößern anklicken....

Hallo Roland,

natürlich ist es kein Problem, mehrere Werte mit gleicher Werteklasse zu verarbeiten.
Das passiert ja mit der Spannung auch jetzt schon (mit der Empfängerspannung bis zu drei Spannungen).

Es gibt aber für den Konverter keine Möglichkeit, Parameter mit gleicher Werteklasse zu unterscheiden.
Es gibt halt im MSB Protokoll nur Adresse, Werteklasse und Sensorwert.
Wenn jetzt also z.B. Höhe sowohl vom Vario als auch vom GPS kommen, weiss der Konverter nicht, welche Höhe von welchem Sensor kommt.
Er muss sich aber entscheiden, welche Höhe er als Baro-Höhe und welche als GPS Höhe ausgibt (sind verschiednene FrSky IDs).
Das lässt sich dann nur über entsprechende Regeln bei der Adressvergabe bewerkstelligen.
Zum Beispiel:
Ist nur eine Höhe vorhanden, nimmt der Konverter Baro-Höhe an, wenn die Adresse 6 ist, GPS Höhe, wenn die Adresse nicht 6 ist.
Sind zwei Höhenwerte vorhanden, ist der mit der niedrigsten Adresse die Baro-Höhe, der andere die GPS Höhe.
u.s.w.
(Leider ist das mit der Höhe in Wirklichkeit noch komplizierter, da vermutlich auch die GPS Entfernung mit der gleichen Werteklasse kommt.)

Bei den MPX Sendern ist das insofern kein Problem, als jeder Parameter einfach in einer speziellen Displayzeile steht.
Aber OpenTx macht je nach Daten ID unterschiedliche Dinge, z.B. beim Vorbesetzen der Telemetriekonfiguration (Einheiten, etc.)

Vielleicht denkt man auch darüber nach, ohne Rücksicht auf OpenTx jeder MSB Adresse eine feste FrSky ID zuzuordnen.
Dann müsste man in der Regel diese Telemetriezeilen manuell konfigurieren.
Man könnte es ja so machen, dass häufig benutzte Zuordnungen berücksichtig werden (z.B. eben Adresse 6 nach Baro-Höhe)
Da werden wir sicher demnächst öfter drüber dikutieren.

Hallo Roland.

Kannst du bitte nochmal ein Bild machen, was dein oXs GPS am Sender aus gibt. Welche Werte siehst du da bei dir?

Bin mit den 0.7 km noch nicht klar. In oXs_config_description.h steht "* GPS_DISTANCE 0.1 m Distance from home". Vielleicht fehlt da das kbei Metern?


Zum Logger. Wozu den Logger? OpenTX loggt doch schon.
Und - oXs steuert das GPS Modul. Start mit 9600 baud und 1Hz, dann auf 57600 baud und 5Hz. Dann werden die NMEA/UBX Datensätze vom GPS zum Arduino gesendet.

Der Logger müsste also warten, bis die Datensätze übertragen werden, die Datensätze auf einer SD Karte speichern. Oder die Datensätze auswerten und relevante Daten (Datum, Zeit, Höhe, Speed, Koordinaten etc.) speichern.

Aber wie schon gesagt, wozu? OpenTx loggt doch und hier geht es doch darum, die MPX Daten nach openTX zu transferieren.

Grüße KH

Hallo Kalle,
anbei die Bilder. Qualität ist nicht besonders. Ich müsste mal die Handykamera putzen..

Werte beginnen mit Kanal 10: 10 , GPS_SPEED , 11 , GPS_ALTITUDE , 12 , GPS_DISTANCE , 13 , GPS_BEARING ,



Diese Werte gibt mir openXsensor aus. Der Sensor lag auf der Fensterbank. Auch der originale MPX Sensor liefert keine stabilen Werte bzw. keine realen Werte von der Fensterbank.
Draußen habe ich den Sensor noch nicht getestet.

OpenXsensor und der GPS Logger sind natürlich OFFTopic. Wir sollten uns vielleicht woanders über dieses Thema unterhalten, um diesen Thred sauber zu halten.

Eins noch zur Notwendigkeit eines Loggers: Da openXSensoren auch MPX MLINK ausgeben können, kann man die Sensoren natürlich auch mit MPX Sendern nutzen! Von den MPX Sendern hat keiner einen Logger eingebaut, so wie FrSky. MPX bietet einen Datenlogger fürs Modell um ~100€ an. Ohne GPS!, nur der Logger! Für MPX Anwender wäre eine Logger Option am openxsensor sicher eine tolle Sache!
lg
Roland

Dank dir Roland.

Ich vermisse GPS_COURSE bei dir. Und, obwohl auf der Fensterbank, GPS_DISTANCE 6.7 km.

Wegen GPS_DISTANCE (km <> m ??) hat Michel aka mstrens geantwortet. Du kannst ja mal hier mit rein schauen.
http://openrcforums.com/forum/viewtopic.php?f=86&t=7562&start=360

Zu offtopic Roland, ich dachte, dir liegt daran, GPS mit in Reinhardts Konverter einzubinden!? Das wäre dann wohl on-topic, oder?
Anderenfalls koppele ich mich beim Thema GPS aus. Versteh mich recht, bevor ich da in Richtung GPS unter M-Link über Konverter auf Taranis gehe, muss ich wissen, dass oXs da einwandfrei arbeitet. Aber das kläre ich in openrcforums ab.

Logger ist sowieso was anderes .... aber Logger mit MPX Sender leuchtet mir natürlich ein

Ich habe auch noch mal oXs GPS mit Dieters und Reinhardts Konverter probiert.



Bei Dieter: Alt und Hdg, wobei der Hdg Wert massiv springt. GPS war ja auch nicht angedacht!
Bei Reinhardt: Alt und GSpd, sieht gut aus, nur sollte km/h statt kts da stehen.

So, genug off-topic

Grüße KH

kalle123 schrieb:

Bei Reinhardt: Alt und GSpd, sieht gut aus, nur sollte km/h statt kts da stehen.

Zum Vergrößern anklicken....

Hallo zusammen,

das FrSky Protokoll sieht Knoten für GSpd vor, daher zeigt OpenTx das defaultmäßig als Einheit an.
Der Konverter gibt den Wert in km/h mit 0,1 km/h Auflösung aus, aber die Einheit muss man dann natürlich im Sender anpassen.

@Roland:
Könntest Du mal auflisten, welche Parameter das MPX GPS maximal gleichzeitig ausgibt, und mit welchen Werteklassen.
Aus der Anleitung konnte ich das nicht wirklich ersehen.
Dann haben wir eine Ausgangsposition für die Diskussion der bereits erwähnten Regeln zur Adressvergabe.
Ich könnte dann mal einen diesbezüglichen Vorschlag machen.

Moin,

wollte nur kurz ein Lebenszeichen geben und melden, dass ich dem Thread noch gespannt folge.

Das Flashen meines Arduino hatte mit Nicos Hilfe funktioniert, ich habe ihn dann nur idiotischer Weise in Rauch aufgehen lassen als ich plus und minus am seriellen Port der Taranis vertauscht habe. Der neue Arduino müsste morgen da sein und dann geht es weiter.

Gruß

Florian

Reinhardt Werbik schrieb:

das FrSky Protokoll sieht Knoten für GSpd vor, daher zeigt OpenTx das defaultmäßig als Einheit an.
Der Konverter gibt den Wert in km/h mit 0,1 km/h Auflösung aus, aber die Einheit muss man dann natürlich im Sender anpassen.

Zum Vergrößern anklicken....

Reinhardt, hast recht, also abgehakt.

Gruß KH

flosch1980 schrieb:

Das Flashen meines Arduino hatte mit Nicos Hilfe funktioniert

Zum Vergrößern anklicken....

Und wie/womit hab ihr das gemacht? Nur so aus Interesse, Florian.

flosch1980 schrieb:

...in Rauch aufgehen lassen als ich plus und minus am seriellen Port der Taranis vertauscht habe.

Zum Vergrößern anklicken....

"Shit happens", passiert nicht nochmal

Gruß KH

War etwas kompliziert durch meine Rechnerkonfiguration, ich kann dir nur den Ablauf schildern, 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. Danach dann halt die Kabel anlöten und dummerweise plus und minus vertauscht.

Die test.cmd lief zuerst nicht und ich hatte eine Fehlermeldung "libusb0.dll fehlt".

Dann habe ich den USBasp-Stick, den hatte Nico mir mal zum programmieren von Beleuchtungsmodulen gemacht, an den Rechner angesteckt und dann das Programm zadig.akeo.ie/downloads/zadig_2.2.exe ausgeführt und dann nach Nicos Anleitung den libusb-win32 (v1.2.6.0) Treiber installiert. Danach funktionierte das Flashen des Arduino problemos.


Gruß
Flo

Hallo Reinhardt,
ich habe den MPX GPS Sensor angesteckt und allen Sensorwerten eine Adresse zugeordnet.
Es funktionieren alle gleichzeitig!
Folgende Konfiguration habe ich am GPS gewählt:
(min/max Werte habe ich nicht definiert)



Name:MLINK Adresse ...Werteklasse:Klasse Beschreibung Auflösung Wertebereich
3D Geschwindigkeit: 3 [km/h] ...Werteklasse:4 Geschwindigkeit 0,1 km/h 0 bis +6000
Höhe: 4 [m]...Werteklasse:8 Höhe 1m -500 bis +2000
3d Entfernung: 5 [m]...Werteklasse:8 Höhe 1m -500 bis +2000
2d Geschwindigkeit: 6 [km/h] ...Werteklasse:4 Geschwindigkeit 0,1 km/h 0 bis +6000
2d Entfernung:7 [m]...Werteklasse:8 Höhe 1m -500 bis +2000
Wegstrecke 3d : 8 [m]...Werteklasse:8 Höhe 1m -500 bis +2000
Azimuth: 9 [° grad]...Werteklasse:7 Richtung 0,1 Grad 0 bis 3600
Wegstrecke2d:10 [m]...Werteklasse:8 Höhe 1m -500 bis +2000
Heading:11 [° grad]...Werteklasse:7 Richtung 0,1 Grad 0 bis 3600
Elongation:12 [° grad]...Werteklasse:7 Richtung 0,1 Grad 0 bis 3600

Werteklasse ergibt sich aus den definierten Einheiten. Eine Liste der tatsächlichen Werteklassen habe ich nicht gefunden!
Distanz (13 Distanz 0,1 km 0 bis +16000) wird scheinbar nicht eingesetzt, da die Distanz in 0,1km angegeben ist.

Zusätzlich war auf 13 Höhe und 14 ein Vario von einem 2ten Sensor. Damit war das Display voll! Die Sinnhaftigkeit und Überschaubarkeit sei mal dahingestellt. Wie man sich bei so viele Werten noch auskennen soll, ist eine andere Frage!


Heading und Elongation konnten im Stand nicht sinnvoll berechnet werden. Habe das GPS nur aus dem Fenster gehalten. Einmal hatte ich kurz eine Heading Anzeige.
Also generell kann man ALLE Werte gleichzeitig übertragen.


Sinnvoll wäre Geschwindigkeit3d, Entfernung3d, Höhe3d, Azimuth und vielleicht die 2dWegstrecke für Streckenflieger.
Heading bzw. Elongation könnte für FPV Piloten wichtig sein.
Für 2D Werte kenne ich zur Zeit keine sinnvolle Anwendung. Vielleicht könnte man es so definieren, dass man entweder 3d oder 2d Werte verwendet.
Min/Max Werte sind für FrSky generell unnötig.

Modelltyp ist eine interne GPS Einstellung und für die Übertragung belanglos.

Lg
Roland

Florian, hiermit, mit dem FTDI USB Adapter?



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.
Bin aber auch nicht vom Fach

cu KH

Ja genau mit dem Adapter.

Nein den Test kann ich erst am Mittwoch machen, vorher habe ich keinen Zugriff auf einen Multiplex Empfänger.

Gruß

Florian

Donaufisch66 schrieb:

Sinnvoll wäre Geschwindigkeit3d, Entfernung3d, Höhe3d, Azimuth und vielleicht die 2dWegstrecke für Streckenflieger.
Heading bzw. Elongation könnte für FPV Piloten wichtig sein.
Für 2D Werte kenne ich zur Zeit keine sinnvolle Anwendung. Vielleicht könnte man es so definieren, dass man entweder 3d oder 2d Werte verwendet.
Min/Max Werte sind für FrSky generell unnötig.

Zum Vergrößern anklicken....

Hallo Roland,

angesichts dieses Wusts an verschiedenen Parametern (allein 5 mit Werteklasse 8) müssen wir eine sinnvolle Auswahl treffen.
Das FrSky Protokoll unterstützt nicht alle diese Werte, und außerdem gingen alle diese Parameter wohl nur mit fester Adressenzuordnung.
Ich würde vorschlagen, folgende GPS Parameter zu berücksichtigen:

- Geschwindigkeit: 2d oder 3d, je nachdem was konfiguriert ist, aber nur 1 Wert -> ist bereits implementiert
- Entfernung: 2d oder 3d, je nachdem was konfiguriert ist, aber nur 1 Wert
- Höhe 3d (zusätzlich zur Baro-Höhe vom Vario)
- Azimuth

Wegstrecken, Heading und Elongation würde ich unter den Tisch fallen lassen.
Es gibt einfach nicht genug FrSky IDs, und die Adressregeln wären ziemlich unübersichtlich.

Ohnehin muss man sich für Höhe und Entfernung etwas einfallen lassen, was die Vergabe der Adressen angeht.
Es gibt mit der Baro-Höhe vom Vario dann nämlich immerhin bis zu 3 Parameter mit Werteklasse 8.
Ich überleg mir da mal eine einleuchtende Logik.