OpenTX - Multiplex MLINK Konverter

[elral]

Hallo zusammen,
gestern abend habe ich dann noch mal oXs neu konfiguriert, Strom - 3 zelligen LiPo - eine Spannung.
An meiner Profi TX kommt dann auch alles schön an, einmal Strom und danach 4 mal Spannung.
Der Konverter funktioniert also wunderbar, und auch das kompilieren von oXs unter Atmel Studio habe ich dann wohl im Griff.
Bei ersky9x wird ebenfalls der Strom dargestellt und unter FSAV eine Spannung. Cell1/Cell2/Cell3 werden nicht dargestellt, kann ja wohl auch nicht da M-Link diese Namen so nicht kennt, oXs das als Spannung ausgibt und der Konverter das in weitere Spannungsanzeigen weiterreicht.
Und unter ersky9x kann ich nur die fest vergebenen Namen anzeigen.
-> Also habe ich da eine andere "Baustelle"

Vielen Dank für die Unterstützung und Grüße

Ralf

P.S.: Gibt es hier auch einen Thread, in dem oXs diskutiert wird?

 

[Reinhardt Werbik]

Moin Kalle,

also von oXs habe ich noch gar keine Ahnung.

Eine Auflösung von 1/100 V ist ganz schön sportlich, und ich würde den Sinn mal ein wenig anzweifeln.
Bei einem angenommenen Messbereich von 40 V entspricht das 0,025 %.
Da braucht es normalerweise schon ein relativ hochpreisiges Digitalmultimeter.
Durch das Teilen einer 16 Bit Integerzahl durch 100 in OpenTx wird das nicht gerade besser.
Und schließlich liegts Du mit 2,6 statt 2,55 (oder 2,56) auch schon ca. 2% daneben.

Aber sei's drum, am Konverter wird es nicht scheitern.
Dieser macht nämlich für die Spannung nichts anderes als ihn von den 15 Bit auf dem MSB in einen 16 Bit Wert umzumodeln.
Der Zahlenwert wird dabei nicht verändert.
(außer dass negative Werte in positive gewandelt werden, da das D-Protokoll keine negativen Spannungen vorsieht.)

Der MSB sieht nur 0,1 V Auflösung vor für Spannungen.
Das muss Dich aber nicht jucken, da das nur für die Anzeige in einem MPX Sender relevant ist, damit er weiss, wo er den Dezimalpunkt setzten muss.
Wenn der vom oXs Sensor gelieferte Wert eine Auflösung von 1/100 V hat, ändert sich das durch den Konverter nicht.
Ich würde dann allerdings als Einheit 'Raw' (keine Einheit) und als Umrechnung 2550 (= * 10)einstellen.
Dann repräsentiert der Wert die Spannung in Millivolt und es gibt keine Umrechnungsverluste durch OpenTx.

 

[Reinhardt Werbik]

An meiner Profi TX kommt dann auch alles schön an, einmal Strom und danach 4 mal Spannung.
Der Konverter funktioniert also wunderbar, und auch das kompilieren von oXs unter Atmel Studio habe ich dann wohl im Griff.

Das verstehe ich jetzt nicht ganz, wo ist der Zusammenhang zwischen der Anzeige der Profi Tx und dem Konverter?
Dafür brauchst du ihn doch gar nicht.

 

[Woodstock218]

Teensy Converter neue Datei zum Testen Für KH

Teensy Converter neue Datei zum Testen Für KH

Hallo Karl-Heinz,

anbei habe ich dir die geänderte Datei.

Hatte leider keine Zeit zum ausprobieren. Kannst ja mal testen ob das Verhalten damit weg ist.

Wenn nicht, muß ich dann etwas mehr Hirnen, um auf eine Lösung zu kommen.

Gruß
Dieter

Anhang anzeigen _MLinkFrSkyConverter_Teensy.ino.txt

 

[kalle123]

Also Reinhardt, mstrens (der Entwickler von oXs) beschreibt den Abgleich der Spannungen so

*      I expect voltage to be normally between 4 volt and 6 volt, so I apply 2 voltages close to those values to End point
*        - for first voltage, voltmeter gives 3510 millivolt and telemetry gives 3622
*        - for second voltage, voltmeter gives 5900 millivolt and telemetry gives 6013
*      Then SCALE_VOLTAGE = (5900-3510) / (6013-3622) = 0.99958
*      and OFFSET_VOLTAGE = -3510 + (3622 * 0.99958 ) = 110

Also Millivolt.

Und die "Messkette" geht ja so

Lipospannung -> oXs Spannungsteiler -> oXs offset+scaling -> ratio Taranis -> Ausgabe.

Ob da jetzt bei ratio 2.6 oder 2.5 steht, ist eigentlich egal, der Abgleich findet bei oXs offset+scaling statt.

Muss halt dazu mehrfach eine Iterationsschleife fahren und ... meine Flukes sind ausreichend genau

Reinhardt, ich geh aber noch mal einen Punkt zurück. Lt. deiner Anleitung sollte die ratio 25.5 sein. Wenn ich nichts an der Justierung innerhalb oXs mache, muss ich bei deinem Konverter aber 2.6 nehmen. Mach mstrens da einen Fehler?

Ich werde mal nachfragen ....

Gruß KH

 

[kalle123]

Hallo Karl-Heinz,

anbei habe ich dir die geänderte Datei.

Hatte leider keine Zeit zum ausprobieren. Kannst ja mal testen ob das Verhalten damit weg ist.

Wenn nicht, muß ich dann etwas mehr Hirnen, um auf eine Lösung zu kommen.

Gruß
Dieter

Anhang anzeigen 1757361

Super Dieter!! Werde testen und melde mich.

LG KH

 

[kalle123]

So Dieter. Mal schnell getestet.



Bei 10:55:16.720 "kommt" der Empfänger mit der RX Spannung und die LQI Werte fahren hoch.

Bei 10:55:17.320 Lipo Volt, Curr und VSpd extrem

Bei 10:55:18.120 ist dann wieder Ruhe

Dieter, kannst du nicht im Programm die ersten 2 Sekunden nachdem die Telemetrie anläuft, die Telemetriewerte ignorieren und (im Beispiel) erst nach 10:55:18.720 Telemetriewerte in Richtung Taranis ausgeben?

Also den "void loop" die ersten 2 Sekunden LEER laufen lassen und DANACH erst die Telemetriewerte generieren ....

Normaler Vorgang mit dem Modell ist ja:

Sender EIN -> LOG EIN -> Empfänger EIN. Und dann erst Modell werfen. Da würden die 2 Sekunden nichts ausmachen

Wenn du nämlich bei der Taranis Funktionen wie Curr+ oder Lipo+ verwendest, werden z.Z. diese Extremwerte jetzt dort dargestellt.

Grüße KH

 

[elral]

Das verstehe ich jetzt nicht ganz, wo ist der Zusammenhang zwischen der Anzeige der Profi Tx und dem Konverter?
Dafür brauchst du ihn doch gar nicht.

Ich auch nicht Man sollte gewisse Dinge einfach nicht so zwischendurch machen, wie zum Beispiel posten
Ich wollte nur sagen, dass der oXs funktioniert. Die "fehlenden" Messwerte also nicht daran liegen.
Grüße
Ralf

 

[Reinhardt Werbik]

Also Reinhardt, mstrens (der Entwickler von oXs) beschreibt den Abgleich der Spannungen so

*      I expect voltage to be normally between 4 volt and 6 volt, so I apply 2 voltages close to those values to End point
*        - for first voltage, voltmeter gives 3510 millivolt and telemetry gives 3622
*        - for second voltage, voltmeter gives 5900 millivolt and telemetry gives 6013
*      Then SCALE_VOLTAGE = (5900-3510) / (6013-3622) = 0.99958
*      and OFFSET_VOLTAGE = -3510 + (3622 * 0.99958 ) = 110

Also Millivolt.

Und die "Messkette" geht ja so

Lipospannung -> oXs Spannungsteiler -> oXs offset+scaling -> ratio Taranis -> Ausgabe.

Ob da jetzt bei ratio 2.6 oder 2.5 steht, ist eigentlich egal, der Abgleich findet bei oXs offset+scaling statt.

Muss halt dazu mehrfach eine Iterationsschleife fahren und ... meine Flukes sind ausreichend genau

Reinhardt, ich geh aber noch mal einen Punkt zurück. Lt. deiner Anleitung sollte die ratio 25.5 sein. Wenn ich nichts an der Justierung innerhalb oXs mache, muss ich bei deinem Konverter aber 2.6 nehmen. Mach mstrens da einen Fehler?

Ich werde mal nachfragen ....

Gruß KH

Hi Kalle,

also ich kenne die Implementierung von oXs nicht, aber nur mal als Anhaltspunkt:
Die Linearität der auf einem µC integrierten ADCs liegt typischerweise bei 0,5 %, und das kriegst Du auch mit einem 2-Punkt Abgleich nicht kompensiert.
Aber egal.

Die Einstellung der Ratio in OpenTx hängt ausschließlich davon ab, welchen Wert (Auflösung) das LSB des vom Sensor gelieferten Wertes hat.
(Die Anzahl der Nachkommastellen wird dann dazu passend eingestellt.)
Die MSB Spezifikation legt fest, dass eine Spannung auf dem MSB eine Auflösung von 0,1 V hat.
Dementsprechend muss dann die Ratio auf 25,5 eingestellt werden (Division durch 10), sinnvollerweise mit einer Nachkommastelle.

Wenn ein Sensor eine Auflösung von 0,01 V liefert, ist er nicht konform mit der MSB Spezifikation.
Es gäbe keine Möglichkeit, auf einem MPX Sender den Wert korrekt darzustellen.

mstrens hält sich also schlichtweg nicht an die MSB Spezifikation, wenn die Auflösung 0,01 V beträgt.
Man kann das aber mit einer Ratio von 2,6 umgehen, oder (genauer) mit 2550 und Darstellung als mV.

 

[Reinhardt Werbik]

Ich auch nicht Man sollte gewisse Dinge einfach nicht so zwischendurch machen, wie zum Beispiel posten
Ich wollte nur sagen, dass der oXs funktioniert. Die "fehlenden" Messwerte also nicht daran liegen.
Grüße
Ralf

Aha, dann ist das klar.

Tja, dann liegt es vermutlich daran, dass die von Dir verwendete SW die nicht vordefinierten IDs für User Data Frames nicht mag.
Der ultimative Test dafür wäre natürlich, das mal mit OpenTx zu testen, was Du aber nicht betreibst, oder?

 

[kalle123]

mstrens hält sich also schlichtweg nicht an die MSB Spezifikation, wenn die Auflösung 0,01 V beträgt.

Das wäre ja dann eine Möglichkeit.

Du hast mitgekriegt, daß sich Dieter hier wieder gemeldet hat. Ich leg deinen Konverter mal für nen Moment zu Seite und befasse mich mal kurz mit Dieters Ansatz. Bißchen hänge ich auch noch daran, hab damals viel Zeit bei Testen investiert.

Bin also kurzfristig entschuldigt.

Grüße KH

 

[kalle123]

Dies betrifft jetzt den Konverter #1 ;-)

Dies betrifft jetzt den Konverter #1 ;-)

Hallo Dieter.

Hab gerade mal deine letzte Version 17.3.2016 mit der Version von heute verglichen.



Das sind die Änderungen zwischen den Versionen. OK. Mein Konverter hat noch den Transistor Inverter drauf.

Was wir eigentlich brauchen, ist so was wie ein Zähler in "void loop", der dafür sorgt, daß erst nach Ablauf einer Zeitspanne die Telemetriewerte generiert werden.

Meine Programmierkenntnisse reicht leider für eine solche Modifikation nicht aus

Grüße KH

 

[kalle123]

@josch

Hab gerade beim Stöbern auf meinen Festplatten das hier gefunden.



Vielleicht solltest du dir das hier mal anschauen ->

http://openrcforums.com/forum/viewtopic.php?f=45&t=9158&p=120780#p120780

und ggfs mit Tobi in Kontakt treten.

Gruß KH

 

[Reinhardt Werbik]

Vielleicht solltest du dir das hier mal anschauen ->

http://openrcforums.com/forum/viewtopic.php?f=45&t=9158&p=120780#p120780

und ggfs mit Tobi in Kontakt treten.

Verrätst Du uns (mir) auch warum?

 

[kalle123]

Wenn ich mich recht erinnere, hat Tobi die Horus und versucht, die MPX Telemetry da drauf zu kriegen ...

Gruß KH

 

[Donaufisch66]

morgen Kalle,

hat Tobi einen Act MLINK-Konverter für SPort Protokoll gemacht? Dachte das Protokoll ist nicht bekannt!
lg
Roland

 

[kalle123]

Hallo Roland,

ich hab nur mit einem Auge mit gekriegt, daß Tobi in openrcforums "sporadisch" wieder aktiv war.

Er war ja auch "die Basis", auf die Dieter aufgebaut hat bei dem Konverter#1.

Tobi hat in openrcforums zip Dateien (die letzte MLink-FrSkyS.PortV0.3.zip) hinterlegt, nur kam wohl keine Reaktion.

Und er ist auch wohl kein eifriger Forenteilnehmer.

Aber ich denke, es könnte sich lohnen, mal genauer in den Code da reinzuschauen und ggfs. auch mal mit ihm Kontakt aufzunehmen. Hab ich damals gemacht, wie es mit Konverter #1 losging. Hier mal, was in der zip Datei drin ist.

Gruß und schönes Wochenende - KH

FrSkySportTelemetry/  FrSkySport_Test_UNO/  Info.txt  MLink-FrSkyS.Port1/  Schematic.png  SensorIDs.txt

./FrSkySportTelemetry:
328p_sport_connection_diagram.jpg  FrSkySportSensorFuel.cpp     FrSkySportSensorT12.h
changelog.txt                      FrSkySportSensorFuel.h       FrSkySportSensorVario.cpp
FrSkySportDecoder.cpp              FrSkySportSensorGps.cpp      FrSkySportSensorVario.h
FrSkySportDecoderExample/          FrSkySportSensorGps.h        FrSkySportSensorXjt.cpp
FrSkySportDecoder.h                FrSkySportSensor.h           FrSkySportSensorXjt.h
FrSkySportPolling.cpp              FrSkySportSensorHdg.cpp      FrSkySportSingleWireSerial.cpp
FrSkySportPolling.h                FrSkySportSensorHdg.h        FrSkySportSingleWireSerial.h
FrSkySportSensorAcc.cpp            FrSkySportSensorRaw.cpp      FrSkySportTelemetry.cpp
FrSkySportSensorAcc.h              FrSkySportSensorRaw.h        FrSkySportTelemetryExample/
FrSkySportSensorAss.cpp            FrSkySportSensorRpm.cpp      FrSkySportTelemetry.h
FrSkySportSensorAss.h              FrSkySportSensorRpm.h        FrSkySportXjtDecoderExample/
FrSkySportSensor.cpp               FrSkySportSensorRpmT12.cpp   keywords.txt
FrSkySportSensorFcs.cpp            FrSkySportSensorRpmT12.h     teensy_36_sport_connection_diagram.jpg
FrSkySportSensorFcs.h              FrSkySportSensorSp2uart.cpp  teensy_sport_connection_diagram.jpg
FrSkySportSensorFlvss.cpp          FrSkySportSensorSp2uart.h
FrSkySportSensorFlvss.h            FrSkySportSensorT12.cpp

./FrSkySportTelemetry/FrSkySportDecoderExample:
FrSkySportDecoderExample.ino

./FrSkySportTelemetry/FrSkySportTelemetryExample:
FrSkySportTelemetryExample.ino

./FrSkySportTelemetry/FrSkySportXjtDecoderExample:
FrSkySportXjtDecoderExample.ino

./FrSkySport_Test_UNO:
FrSkySport_Test_UNO.ino

./MLink-FrSkyS.Port1:
MLink-FrSkyS.Port1.ino

 

[kalle123]

Hab gerade noch mal geschaut.

Tobi schrieb da

"Hello Kalle,

there was only a little time left in last year. But now I have got a Horus so it was necessary to go active again.
Thanks for the link. Looks like this grows to an large project - super "

und

"So, I use a initialisation from D. Kammerer for MPX HF modules.
Because I have no MPX hardware, I can not test it - so I have to wait for feetback."

Ich hab keine Horus und viel feedback is da wohl nicht gekommen

 

[elral]

Hallo Reinhardt,

Tja, dann liegt es vermutlich daran, dass die von Dir verwendete SW die nicht vordefinierten IDs für User Data Frames nicht mag.
Der ultimative Test dafür wäre natürlich, das mal mit OpenTx zu testen, was Du aber nicht betreibst, oder?

ja, ersky9x mag keine undefinierten IDs. Mike hat es zwar auf seine ToDo Liste gesetzt, aber ich denke das wird so schnell nichts. Als interim Lösung schlug er vor diese auf SC1/2.. zu mappen, aber dann passt es nicht mehr für andere.
OpenTx werde ich die Tage mal aufspielen, das Wochenende war zu schön dafür
Allerdings muss ich mir dann wohl noch einen Inverter bauen, in meiner SW kann ich den COM1 negieren. Da unterscheidet sich wohl die Hardware im Pegel des COM Ports. Sollte das funktionieren, wäre es möglich in Deiner SW einen weiteren Ausgang mit negiertem Signal zu implementieren?
Danke und Grüße
Ralf

 

[Reinhardt Werbik]

Allerdings muss ich mir dann wohl noch einen Inverter bauen, in meiner SW kann ich den COM1 negieren. Da unterscheidet sich wohl die Hardware im Pegel des COM Ports. Sollte das funktionieren, wäre es möglich in Deiner SW einen weiteren Ausgang mit negiertem Signal zu implementieren?

Hallo Ralf,

das serielle Signal zur Taranis wird im SW UART des Konverters bereits mit negativer Logik erzeugt.
Der serielle Eingang der Taranis erwartet das so.
Oder brauchst Du ein normales UART Signal?