OpenTX - Multiplex MLINK Konverter

kalle123

User
Ach Reinhardt.

Muss ich ja dann wieder den Schrumpfschlauch runter nehmen und den USBASP und die Fliegenbeinkäbelchen raus kramen.
Glaube, ich mach mir nen 2. Konverter zum "Schnellwechseln" :cool: Mit nem schönen ino sketch und nem Nano wäre das einfacher. Aber du bist der Chef!

Hab hier zwei Schweissgut Flieger mit MPX und oXs drin. Beide mit Spannung, Strom und Vario. Wetter ist ja nicht so und ich werde mich mal daran setzen und einen der oXs mit GPS nachrüsten. Mal schauen, wie sich das macht ...

Grüße KH
 
Ach Reinhardt.

Muss ich ja dann wieder den Schrumpfschlauch runter nehmen und den USBASP und die Fliegenbeinkäbelchen raus kramen.
Glaube, ich mach mir nen 2. Konverter zum "Schnellwechseln" :cool: Mit nem schönen ino sketch und nem Nano wäre das einfacher. Aber du bist der Chef!

Hab hier zwei Schweissgut Flieger mit MPX und oXs drin. Beide mit Spannung, Strom und Vario. Wetter ist ja nicht so und ich werde mich mal daran setzen und einen der oXs mit GPS nachrüsten. Mal schauen, wie sich das macht ...

Grüße KH
Armer Kalle.

Warum machst Du keinen Optiboot Bootloader drauf? ;)
So wie ich auf meinem Test-Board und dem Board in der X9E?
Dann kannst Du entweder mit einem längliche Befehl per Eingabeaufforderung
oder einer Oberfläche wie Burn-o-Mat neue Firmware aufspielen.
 

kalle123

User
Reinhardt, warum nen anderen boot loader. Platzprobleme?

Mit dem länglichen Befehl meinst du so was hier ...

"/home/kalle/Anwendungen/arduino-1.8.0/hardware/tools/avr/bin/avrdude -C/home/kalle/Anwendungen/arduino-1.8.0/hardware/tools/avr/etc/avrdude.conf -v -patmega328p -carduino -P/dev/ttyUSB0 -b57600 -D -Uflash:w:/tmp/arduino_build_989283/Blink.ino.hex:i"

Hab ich auch schon gemacht, ist mir aber zu umständlich. Lieber den USBASP raus, die Strippen ran, BURN-O-MAT angeworfen und hex druff.

Und wenn ich jetzt einen oXs auf GPS hochrüste, muss ich auch da über die ISP Schnittstelle an den pro mini. Die FTDI Schnittstelle hat nicht so gerne, wenn schon was an RX TX hängt ;)

Null problemo hier, war nur geflachst. Schönen Abend noch - KH
 

kalle123

User
Eine gute und eine schlechte Nachricht ;)

Hab gestern Abend Schluß gemacht mit dem Gedanken, wie ich den GPS Anschluß in einen oXs hier noch mit rein kriege.
Die Dinger sind schon sehr kompakt.

21.jpg

Heut morgen kam mir der Gedanke, vielleicht geht es ja, trotz FrSky D (cable) Protokoll, zwei oXs zu koppeln.

Soll ja nur beim S-Port Protokoll gehen. Also schnell mal provisorisch einen zusätzlichen oXs mir GPS aufgebaut und dabei das GPS geschossen.
Hatte meinen Kaffee noch nicht. :rolleyes:

22.jpg

Glücklicherweise hat man ja Reserve! Also nach Frühstückskaffee noch mal und siehe da, es lassen sich die oXs koppeln.

Also jetzt noch einen separaten GPS oXs bauen! Langsam wird der Telemetriescreen voll.

23.jpg

Ja, ich weiß, noch nix konfiguriert, sieht aber gut aus, Reinhardt. Mühsam ernährt sich das Eichhörnchen :D

Grüße KH
 
Hallo zusammen,

ich habe im Code noch ein kleines Goodie eingebaut für den Einsatz in einer X9E.
Und zwar habe ich das Signal zur Ansteuerung der Status-LED zusätzlich auf den Pin B0 gelegt.
Dort kann man eine externe LED (mit Vorwiderstand!) anschließen, falls die LED des Arduino Boards
(wie beim Einbau in eine X9E) nicht sichtbar ist, und diese z.B. mit einer Fassung in ein freies Schalterloch setzen.

Ich habe auch die Ansteuerung noch ein wenig geändert.
Es hat mir nicht gefallen, dass die LED dauerhaft leuchtet, wenn der Konverter nichts tut.
(weil z.B. ein Modell mit FrSky Modul geflogen wird)
Daher habe ich den Code so geändert, dass die LED aus ist, wenn keine M-Link Datenpakete ankommen.
Nach dem Empfang des ersten Datenpakets leuchtet die LED dauerhaft, solange sich der Konverter in der Startschleife befindet.
Dann blinkt die LED langsam oder schnell, je nachdem, ob gültige Telemetriedaten ankommen oder nicht.
(Reset per Watchdog, wenn gar keine M-Link Datenpakete mehr ankommen)

@Ralf:
Das normale UART Signal liegt nach wie vor auf Pin D3.
Wenn Du den neuen Sourcecode willst, bitte per PM.
 

Anhänge

  • Konverter_2017-04-16.hex.txt
    8,6 KB · Aufrufe: 65

kalle123

User
Hallo Reinhardt. Ja, die Status LED ist schon interessant.

Hab den Konverter zwar an der Rückseite, doch seitlich ist die board LED sichtbar. Muss halt die "Kiste" rumdrehen.

Welchen Anschluß meinst du mit B0? PB0 -> Pin 8?

Gruß KH
 

kalle123

User
Will mich mal schnell melden.

Telemetrie mit Reinhardts Konverter und 2 x oXs soweit eingerichtet. Modell SIMPLY von Schweißgut.

oXs GPS unter MPX Protokoll mit dabei.

25.jpg

Markiert die GPS Telemetrie.

Bearing, Course, GPS Speed (3D), GPS Altitude und GPS Distance (2D).

Altitude über MS5611 und GPS Altitude liegen gut beieinander. Nur bei Spannweite von 1.12m sind (für mich) 240 m schon grenzwertig. Und bei der Blauthermik ging es weiter nach oben ;)

26.jpg

Bei Course und Bearing weiß ich nicht so recht, inwieweit das für mich überhaupt nutzbar ist? Funktioniert aber einwandfrei. Hatte beide Werte auf einem Telemetriescreen der Taranis. NUR, ich halte lieber das Modell im Auge.

27.jpg

Bearing ist Position Pilot zum Modell bezogen auf N. Die Stelle hier machte zuerst keinen Sinn, nur bei Betrachtung der GPS Distance kann man feststellen, daß das Modell dabei "über Kopf" war.

Hier noch die Einbausituation des GPS Moduls. Mit Sperrholzlasche unter der Haube.

28.jpg

Gruß KH
 

josch

User
ECU Status Sonderdaten Werteklasse 0 Problem

ECU Status Sonderdaten Werteklasse 0 Problem

Hallo Reinhardt,


habe mich mit OpenTX angefreundet und auch schon einige Modelle damit programmiert.
Programmiert habe ich auf dem Sender direkt (ohne Companion).

Bekomme den ECU Status und Fehlermeldungen (Sonderdaten Werteklasse 0) nicht in der Telemetry angezeigt, dieser sollte doch zumindest als Zahl erscheinen.

Der ECU Status wird auf MSB04 gesendet, das sollte ID0034 sein, diese ID wird bei automatischer Sensorsuche jedoch nicht erkannt.
Habe den Sensor deshalb manuell hinzugefügt.

Bei Änderung des ECU Status, sehe leider sehe ich keine Änderungen an der ID0034 (habe auch alle Eingheiten durchprobiert)

SW Konverter_2017-02-28.hex.txt (ist nicht der letzte Stand)

Ansonsten sind OpenTX / HORUS und ich gute Freunde geworden

Viele Grüße
Josef
 
Hallo Josch,

dass die ECU Daten mit Werteklasse 0 nicht durchkommen ist klar, siehe hierzu auch mein früherer Post hier.
Das Auftauchen der Werteklasse 0 führt dazu, dass die Sensordaten als ungültig deklariert werden, wodurch das An- und Abstecken von Sensoren erkannt wird.

Die Gretchenfrage ist jetzt: Wie kann ich die Werteklasse 0 für einen abgesteckten Sensor von einer Werteklasse 0 für gültige ECU Daten unterscheiden? :eek:
Erst wenn ich das herausgefunden habe, macht es wirklich Sinn, am Code was zu machen.
Mal sehen, ob was aus der MSB Spezifikation herauszulesen ist, ich glaube aber eher nicht.

Andererseits ist der Fall eines abgesteckten Sensors für den laufenden Betrieb nicht wirklich relevant.
Vielleicht muss man also hier einen Kompromiß machen und Werteklasse 0 generell als gültige Werteklasse behandeln.

Wenn ich schon dabei bin, hier noch zwei andere Anmerkungen:

1. Der letzte hier veröffentlichte Code hat die Eigenheit, dass die Bits des M-Link Signals nicht genau in der Mitte,
sondern nach etwa zwei Dritteln der Bitdauer abgetastet werden.
Das hat sich durch verschiedene Änderungen an der entsprechenden Interrupt Service Routine eingeschlichen,
da ich nicht daran gedacht habe, das Vorladen des Timers für den ersten Interrupt (1. Datenbit) des SW UARTs anzupassen.
Es wird trotzdem problemlos funktionieren, ich werde das aber bei nächster Gelegenheit korrigieren.

2. Ich bin gerade dabei, den Code (wieder einmal) ein bisschen umzustellen.
Sprich, die Aufteilung auf die einzelnen Module ändert sich, ohne allerdings die Funktion zu verändern.
Ich mache das, weil ich vorhabe, den Code für ein Nanite Board mit ATtiny841 zu portieren.
Dieses Board läuft nur mit 8 MHz und kommt dadurch mit 3,3 V aus.
Es könnte direkt im M-Link Modul untergebracht und über die Telemetrie-Schnittstelle mit Strom versorgt werden.
Dazu muss aber der Code eben etwas umgestellt werden, um z.B. Funktionsaufrufe aus der ISR des SW UART zu entfernen.
Derzeit ist nämlich die Laufzeit der ISR bei 8 MHz länger als die Bitbreite des M-Link Signals. :cry:
Und das ist hauptsächlich bedingt durch etwa 40 push und pop Befehle, die der Compiler einbaut, um den Status zu sichern.
Aus früheren Versuchen weiss ich, dass das drastisch abnimmt, wenn keine Funktionsaufrufe in der ISR sind.
(z.B. muss dann kein Stack gesichert werden.)

Es handelt sich übrigens um dieses Board.

Mal sehen, ob es gelingt, den Konverter mit 8 MHz laufen zu lassen.
 

josch

User
Hallo,


ja handelt sich um eine Turbine, diese liefert neben Spannung, Temperatur, Drehzahl, Pumpenspannung, Verbrauch auch den Status ( Standby, Run, Ignition usw.) an den MSB Bus.
Wobei lediglich der Status als Sonderdaten Werteklasse 0 übertragen wird.

Probleme könnten noch die Drehzahlen bis ~ 260.000 1/min machen, diese könnte ich aber im ECU Konverter runterteilen.

Sorry Reinhardt, hatte ich wohl mehrmals überlesen.
 
Probleme könnten noch die Drehzahlen bis ~ 260.000 1/min machen, diese könnte ich aber im ECU Konverter runterteilen.
Hallo Josef,

ich denke, es gibt noch Hoffnung für die Drehzahl.
Ich habe mal ein wenig experimentiert, und mit einem Umrechnungsfaktor von 2550 (Multiplikation mit 10)
lassen sich auf dem Display der Taranis X9D tatsächlich numerische Werte mit 6 Stellen hervorzaubern.
Kleine Unschönheit ist lediglich, dass dadurch auf dem Telemetrie-Bildschirm die letzten zwei Zeichen des Sensornamens verdeckt werden.
(Das mag auf dem Display der Horus aber ganz anders ausschauen.)

Es gibt ja für die Drehzahl zwei Formate gemäß MSB Spezifikation, und zwar mit 10 1/min und 100 1/min Auflösung.
Momentan rechnet der Konverter das immer in 1/min um.
(Die 100er Auflösung ließe sich gar nicht auf dem Display darstellen, da der maximale Umrechnungsfaktor 3000 ist.)

Es kommt jetzt darauf an, welche Auflösung der Drehzahlwert aus Deiner ECU auf dem MSB hat.
Nach MSB Spezifikation sind das entweder 10 1/min oder 100 1/min.
Mit 10 1/min lassen sich Werte bis 163830 auf dem MSB darstellen (15 Bit signed Integer).
Für noch größere Drehzahlen müssten es 100 1/min Auflösung sein.

Wenn der Konverter das auf 10 1/min umrechnen würde, statt auf 1/min,
könnte man mit einem Umrechnungsfaktor in OpenTx von 2550 auch die hohen Drehzahlen einer Turbine darstellen.

Für die Standardversion möchte ich das aber nicht machen, da man dann immer den hohen Umrechnungsfaktor einstellen müsste.
Und für alle "normalen" Anwendungen reicht es ja eigentlich auch so wie es ist.
(sprich bis 65535 1/min unter Berücksichtigung der 16 Bit Ausgabe des Konverters zum Sender.)

Du könntest Dir aber natürlich mit dem Source Code eine Spezialversion basteln, die Änderungen wären nicht schwierig.
 
Die Gretchenfrage ist jetzt: Wie kann ich die Werteklasse 0 für einen abgesteckten Sensor von einer Werteklasse 0 für gültige ECU Daten unterscheiden? :eek:
Erst wenn ich das herausgefunden habe, macht es wirklich Sinn, am Code was zu machen.
Mal sehen, ob was aus der MSB Spezifikation herauszulesen ist, ich glaube aber eher nicht.
Hallo Josef,

ich habe mal in die MSB Spezifikation reingeschaut und denke, das Problem lässt sich doch relativ leicht lösen.
Und zwar werden ECU Meldungen durch die Unterklasse 0x01 im Byte 3 der Sensorantwort gekennzeichnet.
Dadurch müsste sich eigentlich der Fall gültiger ECU Daten von einem abgesteckten Sensor unterscheiden lassen.
Ich werde da mal was im Code einbauen...

Nochmal zur Drehzahl:

Nach weiterer Überlegung bin ich zu dem Schluss gekommen, dass es eigentlich doch am logischsten wäre, Drehzahlen auf eine Auflösung von 10 1/min umzurechnen.
Man verliert dadurch nichts, da es gemäß MSB Spezifikation auf dem MSB keine bessere Auflösung geben kann.
Andererseits ergäbe sich dadurch die Möglichkeit, mit dem 16-Bit Wort zum FrSky Sender Drehzahlen bis 655350 zu übertragen.
Das sollte wohl für's erste reichen. :D

Man müsste dann halt für Drehzahlen eine Umrechnung von 2550 in OpenTx einstellen, um den korrekten Wert zu erhalten.

Wenn die Drehzahl einen Wert von 163830 übersteigt, müsste auf dem MSB die 100er Auflösung benutzt werden, sonst reichen die 15 Bit Signed Integer nicht aus.
Beide Fälle müssten, wie in der MSB Spezifikation vorgesehen, durch das Vorzeichen unterschieden werden, damit der Konverter immer den richtigen Wert ausgeben kann.
Eben so, wie er das jetzt auch schon macht, wobei die 100er Auflösung wohl nur bei den ganz alten Sensoren vorkommt.
(UniSense-E und die MSB Expert Regler benutzen schon die 10er Auflösung.)

Was meinen die anderen Mitstreiter (Robert, Kalle, mehr fallen mir gerade nicht ein. ;))
Wollen wir Josef seine Turbinen-Drehzahlen anzeigen lassen und dafür in Kauf nehmen, immer eine Umrechnung von 2550 einstellen zu müssen?
Ich denke, es macht Sinn, den Konverter universell zu halten und keine Spezialversionen zu machen.
 

kalle123

User
Hallo Reinhardt.

Betrifft NUR die Drehzahl?!

Ich mache mit Drehzahl eigentlich nichts, hab nur mal bei BLs versuchsweise Drehzahlwerte mit oXs übertragen ....

Gruß KH
 
Betrifft NUR die Drehzahl?!
Ja, nur Drehzahl ist betroffen.
Diese bekommt ohnehin eine Spezialbehandlung, da die MSB Spezifikation zwei unterschiedliche Auflösungen erlaubt,
die durch das Vorzeichen gekennzeichnet werden.
Das wandelt der Konverter derzeit in einen immer positiven Wert mit Auflösung 1/min um.
Nach der Änderung wäre das ein immer positiver Wert, der Vielfache von 10 1/min repräsentiert.
Sprich der numerische Wert wäre ein Zehntel dessen, was jetzt rauskommt, daher die Umrechnung in OpenTx.
 

kalle123

User
OK, Reinhardt.

Drehzahl gehört dann bei mir in die gleiche Kategorie wie das MPX GPS. Funktioniert, aber ich brauch es eigentlich nicht.

Hab Drehzahl damals mal mit Dieters Konverter und Unisense-E und auch mit oXs und einem gebastelten Adapter
(Basis LM358) auf meinem "Prüfstand" getestet.

Kann den Versuch aber auch gerne mal mit deinem Konverter machen, wenn du die entsprechende Version online stellst.

Grüße KH
 
Hallo Reinhardt,
auch ich brauche die Dehzahl zur Zeit nicht. Ich freue mich natürlich über jede Verbesserung am Konverter.
Lg
Roland
 
Sehr schön, somit ist die Änderungen von allen maßgeblichen Nutzern genehmigt. :D

Nur nochmal zur Klarstellung:
Die Drehzahl bleibt voll nutzbar, ohne jede Abstriche.
Man muss nur eine Umrechnung von 2550 einstellen, statt gar nichts wie jetzt.
 
Ansicht hell / dunkel umschalten
Oben Unten