Donaufisch66
User
danke!
lg
Roland
lg
Roland
OpenTX - Multiplex MLINK Konverter
- Ersteller Donaufisch66
- Erstellt am
kalle123
User
Reinhardt, gerade mal geladen.
Beim meinem SIMPLY sind alle Daten (Spannung, Strom, LQI, Vario und auch die Höhe) sofort da. oXs Sensor.
Mein 2. Versuch, oXs mit GPS Sensor schweigt außer LQI und RX Spannung.
Mal schauen, was Roland findet ...
Gruß KH
PS. Seh gerade, am GPS ist ein Kabel raus. Schaun mer mal
Beim meinem SIMPLY sind alle Daten (Spannung, Strom, LQI, Vario und auch die Höhe) sofort da. oXs Sensor.
Mein 2. Versuch, oXs mit GPS Sensor schweigt außer LQI und RX Spannung.
Mal schauen, was Roland findet ...
Gruß KH
PS. Seh gerade, am GPS ist ein Kabel raus. Schaun mer mal
kalle123
User
GPS Daten kommen an!!
Chapeau! Reinhardt ....
Frage ist jetzt, was ist was bei den Richtungen und wie müssen die Werte skaliert werden ...
#define ID_SPEED1 0x31 // Geschwindigkeit 1 (in OpenTx nicht definiert)
#define ID_DIRECTION1 0x1D // Richtung 1 (in OpenTx nicht definiert)
#define ID_DIRECTION2 0x1E // Richtung 2 (in OpenTx nicht definiert)
Grüße KH
Chapeau! Reinhardt ....
Frage ist jetzt, was ist was bei den Richtungen und wie müssen die Werte skaliert werden ...
#define ID_SPEED1 0x31 // Geschwindigkeit 1 (in OpenTx nicht definiert)
#define ID_DIRECTION1 0x1D // Richtung 1 (in OpenTx nicht definiert)
#define ID_DIRECTION2 0x1E // Richtung 2 (in OpenTx nicht definiert)
Grüße KH
Reinhardt Werbik
User
Hi Kalle,
schön, dass schon mal was rauskommt.
Geschwindigkeit: Einheit km/h
Richtungen: Einheit °
Umrechnungsfaktor ist in beiden Fällen 25,5, Präzision ist 1 Nachkommastelle.
Was die beiden Richtungen bedeuten, weisst nur Du selbst.
0x1D ist die niedrigere, 0x1E die höhere Adresse auf dem MSB.
kalle123
User
Hi Kalle,
schön, dass schon mal was rauskommt.
Geschwindigkeit: Einheit km/h
Richtungen: Einheit °
Umrechnungsfaktor ist in beiden Fällen 25,5, Präzision ist 1 Nachkommastelle.
Was die beiden Richtungen bedeuten, weisst nur Du selbst.
0x1D ist die niedrigere, 0x1E die höhere Adresse auf dem MSB.
Ja, wirklich toll, Reinhardt. War ja auch nur ein "schneller" Versuch. Werde mal das oXs zusammenpacken und mit der "Flieger" (oXs, GPS, Empfänger und Batterie) durch die Umgebung laufen und die Daten loggen. War ja nur ein "Fensterbankversuch"
Was ich noch machen könnte, wäre neben dem Unisens-E auch noch ein "super" oXs mit MS5611, ACS712, Lipospannungen, Drehzahl und GPS. Mal schauen.
Roland und Florian, WO SEID IHR? TESTEN!!
LG KH
Donaufisch66
User
bin arbeiten. sobald ich den Konverter aufgespielt habe, werde ich mein Feedback geben!
@Reinhardt:
Vielen Dank für den Konverter!
ein paar generelle Fragen hätte ich noch dazu:
jetzt sind ja scheinbar alle Parameter implementiert. Gibt es überhaupt noch einen Sensor der nicht funktionieren würde?
Wenn in Zukunft mal ein neuer Sensor rauskommen sollte, der zB eine Entfernung in km ausgibt, kann man dem Konverter diesen Sensor "unterjubeln"? Der Konverter orientiert sich nach MPX Adressen und Wertklassen, oder? Steckt man einen neuen Sensor mit definierter Wertklasse an, nimmt der Konverter jetzt zb. jede Entfernung (MPX Klasse 13) und ordnet sie je nach Verfügbarkeit von 0x33 bis 36 einer FrSky ID zu und die Einheit wird über Sendereinstellungen definiert?
Kann man jetzt jeden neuen Sensor der irgendeine bekannte und definierte Werteklasse überträgt mit dem Konverter übersetzen? (zb neue MPX Sensoren oder Eigenbausensoren).
Hast du die letzten beiden freien Mlink Klassen (14 und 15) auch vordefiniert? Mehr als 16 könnten es per Definition gar nicht werden.
Was passiert wenn man zuviel Sensoren einer Klasse ansteckt? Zb 2x Current oder 3x Temperatur. Also mehr als definiert. Wird ein Wert einfach ignoriert oder bekommt der Konverter Probleme ?
Jetzt wird MPX seine externen Module bald ganz verbieten! ;-)
lg
Roland
@Reinhardt:
Vielen Dank für den Konverter!
ein paar generelle Fragen hätte ich noch dazu:
jetzt sind ja scheinbar alle Parameter implementiert. Gibt es überhaupt noch einen Sensor der nicht funktionieren würde?
Wenn in Zukunft mal ein neuer Sensor rauskommen sollte, der zB eine Entfernung in km ausgibt, kann man dem Konverter diesen Sensor "unterjubeln"? Der Konverter orientiert sich nach MPX Adressen und Wertklassen, oder? Steckt man einen neuen Sensor mit definierter Wertklasse an, nimmt der Konverter jetzt zb. jede Entfernung (MPX Klasse 13) und ordnet sie je nach Verfügbarkeit von 0x33 bis 36 einer FrSky ID zu und die Einheit wird über Sendereinstellungen definiert?
Kann man jetzt jeden neuen Sensor der irgendeine bekannte und definierte Werteklasse überträgt mit dem Konverter übersetzen? (zb neue MPX Sensoren oder Eigenbausensoren).
Hast du die letzten beiden freien Mlink Klassen (14 und 15) auch vordefiniert? Mehr als 16 könnten es per Definition gar nicht werden.
Was passiert wenn man zuviel Sensoren einer Klasse ansteckt? Zb 2x Current oder 3x Temperatur. Also mehr als definiert. Wird ein Wert einfach ignoriert oder bekommt der Konverter Probleme ?
Jetzt wird MPX seine externen Module bald ganz verbieten! ;-)
lg
Roland
Reinhardt Werbik
User
Hallo Roland,
es gibt fünf Werteklassen, die der Konverter (bisher) nicht kennt:
- Füllstand (9)
- Volumen (12)
- Lange Distanz (13)
- die neuen Klassen 14 und 15
Parameter mit diesen Werteklassen werden einfach ignoriert, Probleme hat der Konverter damit nicht.
Das gleiche gilt, wenn mehr Parameter einer Werteklasse vorhanden sind als der Konverter maximal überträgt.
Ich habe mir zwischendurch die Frage gestellt, ob man nicht komplett auf die vordefinierten FrSky IDs verzichtet,
und jeden vorhandenen Parameter auf dem MSB einfach durchreicht, unabhängig von dessen Werteklasse.
Die MSB Adressen würden dann nach einem vordefinierten Schema auf die benutzten IDs verteilt.
Dann würde man allerdings komplett auf die OpenTx Features verzichten und müsste jeden Parameter im Sender selbst konfigurieren.
Grundsätzlich ist das eine Vorgehensweise, die durchaus vorstellbar ist, vorausgesetzt man findet genügend freie IDs.
Du hast mich da auf einen Gedanken gebracht.
Man muss ja nicht auf alle vordefinierten IDs verzichten, für Spannung, Strom, etc. könnte man ja weiterhin die vordefinierten
FrSky IDs benutzten und die in OpenTx implementierten Voreinstellungen verwenden.
Aber vielleicht könnte man ja alle verbleibenden Parameter auf dem MSB einheitlich behandeln.
Man müsste ja eigentlich nicht 4 Entfernungen, 2 Geschwindigkeiten, 3 Richtungen, etc. vorschreiben.
Vielmehr könnte man einfach alles, was über die vordefinierten FrSky IDs hinausgeht, durchschieben ohne die Werteklasse zu beachten.
Die Frage ist, ob das dann nicht doch etwas unübersichtlich wird, und ob man diese Flexibilität wirklich braucht.
Aber man kann ja mal ein wenig in diese Richtung nachdenken.
es gibt fünf Werteklassen, die der Konverter (bisher) nicht kennt:
- Füllstand (9)
- Volumen (12)
- Lange Distanz (13)
- die neuen Klassen 14 und 15
Parameter mit diesen Werteklassen werden einfach ignoriert, Probleme hat der Konverter damit nicht.
Das gleiche gilt, wenn mehr Parameter einer Werteklasse vorhanden sind als der Konverter maximal überträgt.
Ich habe mir zwischendurch die Frage gestellt, ob man nicht komplett auf die vordefinierten FrSky IDs verzichtet,
und jeden vorhandenen Parameter auf dem MSB einfach durchreicht, unabhängig von dessen Werteklasse.
Die MSB Adressen würden dann nach einem vordefinierten Schema auf die benutzten IDs verteilt.
Dann würde man allerdings komplett auf die OpenTx Features verzichten und müsste jeden Parameter im Sender selbst konfigurieren.
Grundsätzlich ist das eine Vorgehensweise, die durchaus vorstellbar ist, vorausgesetzt man findet genügend freie IDs.
Du hast mich da auf einen Gedanken gebracht.
Man muss ja nicht auf alle vordefinierten IDs verzichten, für Spannung, Strom, etc. könnte man ja weiterhin die vordefinierten
FrSky IDs benutzten und die in OpenTx implementierten Voreinstellungen verwenden.
Aber vielleicht könnte man ja alle verbleibenden Parameter auf dem MSB einheitlich behandeln.
Man müsste ja eigentlich nicht 4 Entfernungen, 2 Geschwindigkeiten, 3 Richtungen, etc. vorschreiben.
Vielmehr könnte man einfach alles, was über die vordefinierten FrSky IDs hinausgeht, durchschieben ohne die Werteklasse zu beachten.
Die Frage ist, ob das dann nicht doch etwas unübersichtlich wird, und ob man diese Flexibilität wirklich braucht.
Aber man kann ja mal ein wenig in diese Richtung nachdenken.
Reinhardt Werbik
User
Das habe ich schon mal ein wenig getan und dabei einen Bug entdeckt.
Und zwar bekommt die dritte Richtung die gleiche ID wie die zweite (Copy & Paste).
Ist im Code schon behoben und in der nächsten Version somit gefixt.
Reinhardt Werbik
User
Ich habe mal die oben angedachte Idee des "universellen" Konverters etwas weitergesponnen.
Das ganze könnte folgendermaßen aussehen.
A1/A2 Spannungen und RSSI Wert werden wie jetzt auch aus den Adressen 0, 1 und 2 erzeugt.
Die Sensorwerte, die über User Data Frames übertragen werden, sind in zwei Kategorien eingeteilt.
Zur ersten Gruppe gehören die Parameter, für die es eine geeignete vordefinierte FrSky ID gibt,
sowie Parameter, die häufig vorkommen und denen eine ID auf Grund ihrer Werteklasse zugeordnet wird.
Ich würde dafür folgende Sensorwerte vorschlagen, die somit genau wie in der derzeitigen Version des Konverters,
mit den gleichen IDs, funktionieren:
- Spannung
- Strom
- Ladung
- Drehzahl
- Temperatur 1
- Temperatur 2
- Baro-Höhe
- GPS-Höhe
- Steigrate
Die zweite Gruppe umfasst alle anderen Parameter auf dem MSB.
Diesen wird eine ID auf Grund ihrer MSB Adresse zugeordnet, ohne Berücksichtigung der Werteklasse.
Der Telemetriewert muss dann im Sender entsprechend der Werteklasse konfiguriert werden (Einheit, Umrechnung und Präzision).
(Auch in der jetzigen Implementierung müssen die Telemetriewerte für Richtungen, Geschwindigkeiten und Entfernungen
im Sender manuell konfiguriert werden, da es keine passenden vordefinierten IDs dafür gibt.)
Der Unterschied besteht im wesentlichen darin, dass in der jetzigen Implementierung die vergebene ID immer von der Werteklasse abhängt.
In der "universellen" Implementierung würde das nur noch für die oben aufgelisteten Parameter gelten.
Alle anderen würden eine ID auf Grund ihrer MSB Adresse erhalten, z.B. nach der Formel 0x40 + Adresse, unabhängig von der Werteklasse.
Dann müsste der Konverter in Zukunft nur noch angepasst werden, wenn neue MSB Klassen hinzukommen, für die es FrSky IDs gibt, die man benutzen will.
Das wäre evtl. der Fall, wenn die neue Werteklasse g kommt, denn die könnte man auf die FrSky IDs 0x24 - 0x26 (x/y/z Beschleunigung) umsetzen.
Es wäre natürlich noch zu klären, was OpenTx mit IDs oberhalb des von FrSky belegten Bereichs macht.
Ich vermute, das gleiche wie mit den nicht vordefinierten IDs im FrSky Bereich, aber das werde ich demnächst mal ausprobieren.
Ich glaube, ich muss da mal drüber schlafen.
Das ganze könnte folgendermaßen aussehen.
A1/A2 Spannungen und RSSI Wert werden wie jetzt auch aus den Adressen 0, 1 und 2 erzeugt.
Die Sensorwerte, die über User Data Frames übertragen werden, sind in zwei Kategorien eingeteilt.
Zur ersten Gruppe gehören die Parameter, für die es eine geeignete vordefinierte FrSky ID gibt,
sowie Parameter, die häufig vorkommen und denen eine ID auf Grund ihrer Werteklasse zugeordnet wird.
Ich würde dafür folgende Sensorwerte vorschlagen, die somit genau wie in der derzeitigen Version des Konverters,
mit den gleichen IDs, funktionieren:
- Spannung
- Strom
- Ladung
- Drehzahl
- Temperatur 1
- Temperatur 2
- Baro-Höhe
- GPS-Höhe
- Steigrate
Die zweite Gruppe umfasst alle anderen Parameter auf dem MSB.
Diesen wird eine ID auf Grund ihrer MSB Adresse zugeordnet, ohne Berücksichtigung der Werteklasse.
Der Telemetriewert muss dann im Sender entsprechend der Werteklasse konfiguriert werden (Einheit, Umrechnung und Präzision).
(Auch in der jetzigen Implementierung müssen die Telemetriewerte für Richtungen, Geschwindigkeiten und Entfernungen
im Sender manuell konfiguriert werden, da es keine passenden vordefinierten IDs dafür gibt.)
Der Unterschied besteht im wesentlichen darin, dass in der jetzigen Implementierung die vergebene ID immer von der Werteklasse abhängt.
In der "universellen" Implementierung würde das nur noch für die oben aufgelisteten Parameter gelten.
Alle anderen würden eine ID auf Grund ihrer MSB Adresse erhalten, z.B. nach der Formel 0x40 + Adresse, unabhängig von der Werteklasse.
Dann müsste der Konverter in Zukunft nur noch angepasst werden, wenn neue MSB Klassen hinzukommen, für die es FrSky IDs gibt, die man benutzen will.
Das wäre evtl. der Fall, wenn die neue Werteklasse g kommt, denn die könnte man auf die FrSky IDs 0x24 - 0x26 (x/y/z Beschleunigung) umsetzen.
Es wäre natürlich noch zu klären, was OpenTx mit IDs oberhalb des von FrSky belegten Bereichs macht.
Ich vermute, das gleiche wie mit den nicht vordefinierten IDs im FrSky Bereich, aber das werde ich demnächst mal ausprobieren.
Ich glaube, ich muss da mal drüber schlafen.
Donaufisch66
User
Gute Idee!
Damit wäre der Konverter zukunftssicher und man könnte alle Sensoren einsetzen.
Besteht die Möglichkeit, zwischen fix und undefinierter Klasse selbst zu wählen? Oder wird die eine erkannte Klasse x mal vergeben und wird dann eine undefinierte?
Um mehr gleiche Sensoren einsetzen zu können!
Dann könnte man wie bei Mpx 15 sensoren einer klasse anstecken!
LG Roland
Damit wäre der Konverter zukunftssicher und man könnte alle Sensoren einsetzen.
Besteht die Möglichkeit, zwischen fix und undefinierter Klasse selbst zu wählen? Oder wird die eine erkannte Klasse x mal vergeben und wird dann eine undefinierte?
Um mehr gleiche Sensoren einsetzen zu können!
Dann könnte man wie bei Mpx 15 sensoren einer klasse anstecken!
LG Roland
Reinhardt Werbik
User
Morgen,
eine Klasse, die in die obige Liste fällt, würde zunächst einmal (bei Temperatur zweimal) eine vordefinierte ID bekommen.
Alle weiteren Werte derselben Klasse würden dann einfach mit ID = 0x40 + Adresse durchgereicht.
Man könnte dafür sogar die Adressen 0, 1 und 2 berücksichtigen, wenn sie keine den Parametern A1, A2 und RSSI entsprechende Werteklasse haben.
Dann könnte man in der Tat auch alle MSB Adressen mit gleicher Werteklasse belegen, und alle Parameter wären in der Taranis vorhanden.
Hm..., das Konzept hat was, ich werde das mal weiterverfolgen.
Hätte man gar keine vordefinierten FrSky IDs, würde man es wahrscheinlich genauso machen,
sprich einfach alle Werte durchschieben mit einer ID, die die Adresse repräsentiert.
Letztlich dient die Werteklasse bei MPX Sendern nur dazu, die richtige Einheit anzuzeigen und den Dezimalpunkt richtig zu setzen.
Da man das in OpenTx frei konfigurieren kann, ist die Werteklasse eigentlich nicht mehr wichtig.
Für die "zentralen" Parameter in obiger Liste würde ich dennoch das bisherige Konzept beibehalten.
Für viele Anwendungen würden diese Werte ohnehin völlig ausreichen.
Mal sehen, ob ich in dieser Woche viel am Konverter machen kann, der Job wird in den nächsten Tagen seinen Tribut fordern.
Donaufisch66
User
Hi.
Ja, die zentralen Parameter automatisch zu konfigurieren ist sinnvoll. 90% der Anwendungen werden nur diese nutzen.
Für spezielle Sensor Konfigurationen hätte man dann trotzdem alle Parameter. Selbst wenn mpx mal etwas umstellen würde, würde der Konverter funktionieren.
Das wäre natürlich eine super Sache!
LG Roland
Ja, die zentralen Parameter automatisch zu konfigurieren ist sinnvoll. 90% der Anwendungen werden nur diese nutzen.
Für spezielle Sensor Konfigurationen hätte man dann trotzdem alle Parameter. Selbst wenn mpx mal etwas umstellen würde, würde der Konverter funktionieren.
Das wäre natürlich eine super Sache!
LG Roland
Reinhardt Werbik
User
Kurzes Update, bevor es hier bei der Arbeit richtig losgeht.
Ich bin jetzt überzeugt, dass das hier diskutierte Konzept der größeren Flexibilität eine Super-Sache ist.
Daher habe ich gestern Abend angefangen, das Konzept zu implementieren.
Dank der Code-Optimierungen, die ich im Rahmen des letzten Updates eingebaut habe, geht das recht easy.
Die Kapazität, für die es ja auch keine FrSky ID gibt, werde ich auf der ID0x29 lassen,
da dieser Parameter zu den am häufigsten verwendeten gehören dürfte und er so direkt nach dem Strom (0x28) liegt.
Auch die Drehzahl lasse ich auf 0x07, denn hierfür ist auf Grund der MSB Spezifikation eine Fallunterscheidung nötig, die OpenTx nicht machen kann.
Geschwindigkeiten, Entfernungen, Distanzen und alle bisher nicht berücksichtigten Werteklassen,
sowie zusätzliche Parameter mit Werteklassen aus der "zentralen" Gruppe", werden dann einfach durchgereicht,
wobei die ID 0x40 + MSB Adresse ist (muss ich noch verifizieren, ob das dann auch durchkommt).
Wenn also eine ID ab 0x40 auf dem Display auftaucht, weiss man, dass die zweite Stelle die MSB Adresse ist.
Dann kann man den Parameter im Sender entsprechend der Werteklasse, die er hat, konfigurieren.
Damit ist der Konverter dann wirklich absolut universell einsetzbar.
Ich bin jetzt überzeugt, dass das hier diskutierte Konzept der größeren Flexibilität eine Super-Sache ist.
Daher habe ich gestern Abend angefangen, das Konzept zu implementieren.
Dank der Code-Optimierungen, die ich im Rahmen des letzten Updates eingebaut habe, geht das recht easy.
Die Kapazität, für die es ja auch keine FrSky ID gibt, werde ich auf der ID0x29 lassen,
da dieser Parameter zu den am häufigsten verwendeten gehören dürfte und er so direkt nach dem Strom (0x28) liegt.
Auch die Drehzahl lasse ich auf 0x07, denn hierfür ist auf Grund der MSB Spezifikation eine Fallunterscheidung nötig, die OpenTx nicht machen kann.
Geschwindigkeiten, Entfernungen, Distanzen und alle bisher nicht berücksichtigten Werteklassen,
sowie zusätzliche Parameter mit Werteklassen aus der "zentralen" Gruppe", werden dann einfach durchgereicht,
wobei die ID 0x40 + MSB Adresse ist (muss ich noch verifizieren, ob das dann auch durchkommt).
Wenn also eine ID ab 0x40 auf dem Display auftaucht, weiss man, dass die zweite Stelle die MSB Adresse ist.
Dann kann man den Parameter im Sender entsprechend der Werteklasse, die er hat, konfigurieren.
Damit ist der Konverter dann wirklich absolut universell einsetzbar.
Reinhardt Werbik
User
Abend,
so, der Code für die universelle Variante des Konverters ist jetzt fertig, muss aber natürlich noch getestet werden.
Ich konnte es mir nicht verkneifen, noch ein kleines Extra einzubauen, was die Alarm-Flags angeht, die ja bisher einfach ignoriert wurden.
(Grundsätzlich ist es ja auch sinnvoll, die Alarme im Sender zu konfigurieren.)
Damit der Konverter das Attribut "universell" wirklich verdient, müssen m.E. auch die Alarm-Flags irgendwie berücksichtigt werden.
Ich habe daher kurzerhand beschlossen, alle Alarm Flags in einem 16-Bit Wort auf der ID 0x50 mit zu übertragen.
Die Bit-Position entspricht dabei natürlich der zugehörigen MSB Adresse.
Ob und wie man das dann in der Taranis nutzen kann, wird sich zeigen, aber jetzt ist der Konverter wirklich komplett.
Watch this space.
so, der Code für die universelle Variante des Konverters ist jetzt fertig, muss aber natürlich noch getestet werden.
Ich konnte es mir nicht verkneifen, noch ein kleines Extra einzubauen, was die Alarm-Flags angeht, die ja bisher einfach ignoriert wurden.
(Grundsätzlich ist es ja auch sinnvoll, die Alarme im Sender zu konfigurieren.)
Damit der Konverter das Attribut "universell" wirklich verdient, müssen m.E. auch die Alarm-Flags irgendwie berücksichtigt werden.
Ich habe daher kurzerhand beschlossen, alle Alarm Flags in einem 16-Bit Wort auf der ID 0x50 mit zu übertragen.
Die Bit-Position entspricht dabei natürlich der zugehörigen MSB Adresse.
Ob und wie man das dann in der Taranis nutzen kann, wird sich zeigen, aber jetzt ist der Konverter wirklich komplett.
Watch this space.
Reinhardt Werbik
User
Hallo zusammen,
heute Abend bin ich endlich dazu gekommen, die neue Version mal zu testen.
Die gute Nachricht ist, dass das Programm, nach Beseitigung von ein paar Flüchtigkeitsfehlern, so zu laufen scheint, wie es soll.
Und jetzt die schlechte Nachricht: Offensichtlich akzeptiert OpenTx die Data IDs ab 0x40 nicht.
Am seriellen Eingang konnte ich diese IDs mit dem Bus Analyser zwar sehen, aber am Display der Taranis kam davon nichts an.
Wenn ich die zusätzlichen Daten bei ID 0x30 starten lasse, passt alles.
Aber das geht natürlich so nicht, da ja dieser Bereich teilweise noch mit IDs normaler User Daten besetzt ist.
Da muss ich mir jetzt was einfallen lassen, wie man die zusätzlichen, nicht vordefinierten Daten mit User IDs versieht.
Und zwar so, dass daraus irgendwie die MSB Adresse des zugehörigen MSB Wertes ersichtlich ist.
Bzw. stellt sich die Frage, ob es dann überhaupt genügend unbenutzte IDs gibt.
Mal sehen, was passiert, wenn man mit den IDs noch höher geht.
Aber ich fürchte hier ist irgendwie das Ende der Fahnenstange beim Hub-Protokoll erreicht.
Naja, die IDs 0x31 - 0x38, 0x3C - 0x3E und ein paar andere sind auf jeden Fall frei.
Vielleicht muss man dann eben kleine Abstriche bei der absoluten Flexibilität machen.
Ich werde mal darüber nachdenken, wie man das Konzept etwas weniger flexibel umsetzen kann.
Obige IDs erlauben immerhin 11 zusätzliche Parameter, neben den ganzen vordefinierten.
Es wäre halt schön gewesen, wenn aus der ID sofort die MSB Adresse ersichtlich gewesen wäre.
heute Abend bin ich endlich dazu gekommen, die neue Version mal zu testen.
Die gute Nachricht ist, dass das Programm, nach Beseitigung von ein paar Flüchtigkeitsfehlern, so zu laufen scheint, wie es soll.
Und jetzt die schlechte Nachricht: Offensichtlich akzeptiert OpenTx die Data IDs ab 0x40 nicht.
Am seriellen Eingang konnte ich diese IDs mit dem Bus Analyser zwar sehen, aber am Display der Taranis kam davon nichts an.
Wenn ich die zusätzlichen Daten bei ID 0x30 starten lasse, passt alles.
Aber das geht natürlich so nicht, da ja dieser Bereich teilweise noch mit IDs normaler User Daten besetzt ist.
Da muss ich mir jetzt was einfallen lassen, wie man die zusätzlichen, nicht vordefinierten Daten mit User IDs versieht.
Und zwar so, dass daraus irgendwie die MSB Adresse des zugehörigen MSB Wertes ersichtlich ist.
Bzw. stellt sich die Frage, ob es dann überhaupt genügend unbenutzte IDs gibt.
Mal sehen, was passiert, wenn man mit den IDs noch höher geht.
Aber ich fürchte hier ist irgendwie das Ende der Fahnenstange beim Hub-Protokoll erreicht.
Naja, die IDs 0x31 - 0x38, 0x3C - 0x3E und ein paar andere sind auf jeden Fall frei.
Vielleicht muss man dann eben kleine Abstriche bei der absoluten Flexibilität machen.
Ich werde mal darüber nachdenken, wie man das Konzept etwas weniger flexibel umsetzen kann.
Obige IDs erlauben immerhin 11 zusätzliche Parameter, neben den ganzen vordefinierten.
Es wäre halt schön gewesen, wenn aus der ID sofort die MSB Adresse ersichtlich gewesen wäre.
Reinhardt Werbik
User
So, ich habe gerade nochmal im OpenTx Source Code nachgeschaut wegen der alten (1 Byte) FrSky IDs.
Es sind auf jeden Fall genügend IDs frei, um alle möglichen MSB Adressen aufzunehmen.
Ich muss mir halt jetzt eine Zuordnung überlegen, die einigermaßen logisch ist, das Konzept sollte daran aber nicht scheitern.
ID = 0x40 + MSB Adresse wäre halt eine schöne einfache Sache gewesen, Seufz.
Naja, im schlimmsten Fall muss man sich halt mit einer kleinen Zuordnungstabelle behelfen.
Es sind auf jeden Fall genügend IDs frei, um alle möglichen MSB Adressen aufzunehmen.
Ich muss mir halt jetzt eine Zuordnung überlegen, die einigermaßen logisch ist, das Konzept sollte daran aber nicht scheitern.
ID = 0x40 + MSB Adresse wäre halt eine schöne einfache Sache gewesen, Seufz.
Naja, im schlimmsten Fall muss man sich halt mit einer kleinen Zuordnungstabelle behelfen.
Donaufisch66
User
Hi,
Der MSb kann 16 Adressen übertragen. Also bräuchte man 16 FrSky IDs, die in ansteigender Reihenfolge diese 16 MSB Kanäle repräsentieren.
Gibt es keine 16 freien IDs hintereinander oder "stören" die definierten IDs?
Könntest du eine Art Abfrage einzubauen ob überhaupt unbekannte oder doppelte Klassen vorhanden sind? In 90% der Fälle werden nur Vario, Höhe und andere Standard Sensoren eingesetzt. Für solche Fälle könnte der Konverter auf dein vorhandener "alter" Code "umschalten", sind hingegen unbekannte oder doppelte Klassen vorhanden, reicht der Konverter ALLE Sensoren ohne Definition in ansteigender Reihenfolge durch und der User muss alle Werte im Sender selbst definieren.
Wäre das sinnvoll und machbar?
Lg
Roland
Der MSb kann 16 Adressen übertragen. Also bräuchte man 16 FrSky IDs, die in ansteigender Reihenfolge diese 16 MSB Kanäle repräsentieren.
Gibt es keine 16 freien IDs hintereinander oder "stören" die definierten IDs?
Könntest du eine Art Abfrage einzubauen ob überhaupt unbekannte oder doppelte Klassen vorhanden sind? In 90% der Fälle werden nur Vario, Höhe und andere Standard Sensoren eingesetzt. Für solche Fälle könnte der Konverter auf dein vorhandener "alter" Code "umschalten", sind hingegen unbekannte oder doppelte Klassen vorhanden, reicht der Konverter ALLE Sensoren ohne Definition in ansteigender Reihenfolge durch und der User muss alle Werte im Sender selbst definieren.
Wäre das sinnvoll und machbar?
Lg
Roland
Reinhardt Werbik
User
Guten Morgen Roland,
machbar wäre das, sinnvoll m.E. nicht.
Denn der Fall, dass man ausschließlich unbekannte Werteklassen einsetzt, dürfte in der Praxis nie vorkommen.
Außerderm würde OpenTx bei Verwendung einer vordefinierten ID die hinterlegten Voreinstellungen anwenden.
Dann kommt eine GPS Wegstrecke plötzlich als Stromwert daher, kann man zwar umdefinieren, ist aber nicht intuitiv.
Man sollte nicht alle Werte einfach durchreichen, nur weil eine exotische Klasse dabei ist.
Mir schwebt jetzt folgendes vor:
Alle (und nur die) vordefinierten IDs werden wie bisher für die entsprechenden Parameter verwendet.
Alle Parameter mit nicht vordefinierten IDs (also z.B. auch die Kapazität) werden einfach durchgereicht.
Ausnahme ist evtl. die Drehzahl, bei der eine Fallunterscheidung hinsichtlich der Auflösung und eine entsprechende Umrechnung nötig ist.
Evtl. werde ich hier die ID 0x07 wie bisher fest zuordnen, ist aber nicht zwingend nötig, mal schauen.
Ich muss mal schauen, ob es möglich ist, für jede MSB Adresse eine freie ID zu finden, bei der das zweite Nibble der Adresse entspricht.
Dann wäre das Konzept eigentlich recht einfach:
Bei allen Werten, die OpenTx nicht direkt erkennt, und die deshalb nur mit der ID als Name erscheinen,
entspricht das zweite Nibble der ID der MSB Adresse (Ausnahme evtl. Drehzahl), und der Wert wird einfach durchgeschoben.
Dass die IDs nicht hintereinander liegen ist ja völlig egal, man definiert sich ohnehin einen Namen im Sender für diese Werte.
Donaufisch66
User
Morgen Reinhardt,
Ich habe das noch nicht ganz verstanden.
Woran erkennt man einen durchgereichten Sensorwert?
Wie entspricht die ID dann der mpx Adresse? Anhand der Mpx Adresse identifiziert man IDs und konfiguriert entsprechend dem jeweiligen Wert händisch im Sender?
Bekannte Senorwerte werden wie gehabt erkannt.
Sobald die maximale Anzahl eines bekannten Werts überschritten ist, wird anhand der Adresse der Wert durchgereicht.
Du wolltest die ID Nummern direkt auf die Adresse beziehen, das ist jedoch in OpenTx nicht möglich.
Wirst du eine fixe Reihenfolge definieren, sodass jede Mpx Adresse immer dieselbe definierte ID erhält ?
Wie sonst, könnte man anhand der IDs den entsprechenden Sensorwert identifizieren?
Bekannte Werte würden dann wahrscheinlich stören.
Viel Erfolg. Bin schon gespannt!
Ps: deine letzte Version hatte ich nicht getestet. Ich möchte nicht zu oft den Sender aufschrauben. Warte auf drine nächste version wenns recht ist.Irgendwann passiert sonst ein Missgeschick. ....
Wenn du für dein laufendes Projekt Tests von der X9e benötigst, schraube ich sie gerne auf!
LG Roland
Ich habe das noch nicht ganz verstanden.
Woran erkennt man einen durchgereichten Sensorwert?
Wie entspricht die ID dann der mpx Adresse? Anhand der Mpx Adresse identifiziert man IDs und konfiguriert entsprechend dem jeweiligen Wert händisch im Sender?
Bekannte Senorwerte werden wie gehabt erkannt.
Sobald die maximale Anzahl eines bekannten Werts überschritten ist, wird anhand der Adresse der Wert durchgereicht.
Du wolltest die ID Nummern direkt auf die Adresse beziehen, das ist jedoch in OpenTx nicht möglich.
Wirst du eine fixe Reihenfolge definieren, sodass jede Mpx Adresse immer dieselbe definierte ID erhält ?
Wie sonst, könnte man anhand der IDs den entsprechenden Sensorwert identifizieren?
Bekannte Werte würden dann wahrscheinlich stören.
Viel Erfolg. Bin schon gespannt!
Ps: deine letzte Version hatte ich nicht getestet. Ich möchte nicht zu oft den Sender aufschrauben. Warte auf drine nächste version wenns recht ist.Irgendwann passiert sonst ein Missgeschick. ....
Wenn du für dein laufendes Projekt Tests von der X9e benötigst, schraube ich sie gerne auf!
LG Roland
Reinhardt Werbik
User
Ne, ne, lass Deine X9E ruhig zu, bis die nächste Version verfügbar ist.
Das kann aber evtl. noch ein bißchen dauern, habe gerade ziemlich viel um die Ohren.
Vielleicht mal ein Beispiel zum besseren Verständnis:
Der Strom hat eine vordefinierte ID in OpenTx (0x28).
Somit wird der Stromwert mit der niedrigsten MSB Adresse als ID 0x28 ausgegeben.
OpenTx erkennt das und nennt den Wert "Curr", Auflösung passt auch schon.
Diese ID 0x28 ist unabhängig von der tatsächlichen (niedrigsten) MSB Adresse des Stromwertes.
Ein weiterer Stromwert auf dem MSB (oder irgendein nicht in OpenTx bekannter Parameter) erhält eine ID,
die sich eindeutig aus der MSB Adresse ergibt, die aber zu den für OpenTx unbekannten IDs gehören muss.
Dann taucht als Name auf dem Display einfach die ID auf.
Über die feste Zuordnung zwischen der MSB Adresse und der ID kann man dann identifizieren,
was es ist und einen passenden Namen vergeben (und evtl. die Auflösung anpassen).
Wenn es für jede MSB Adresse eine freie ID gibt, dessen zweites Nibble direkt dieser Adresse entspricht,
wäre die Zuordnung sehr einfach und ohne Zuhilfenahme irgendwelcher Tabellen möglich.
Also z.B. zwei Stromwerte auf den Adressen 3 und 8.
Erster Stromwert kommt mit ID 0x28 und wird von OpenTx als "Curr" erkannt und bezeichnet.
Zweiter Stromwert kommt (z.B.) mit ID 0x38 (8 = MSB Adresse).
Genau die gleichen IDs würden auftauchen, wenn die Adressen 4 und 8 wären.
Wären die Adressen 4 und 6, würden die IDs 0x28 und 0x36 (6 = Adresse des zweiten Stromwertes) auftauchen.
u.s.w.
Die IDs 0x31 bis 0x38 sind schon mal frei, damit könnte man die Adressen 1 bis 8 abdecken.
Klingt alles etwas kompliziert, ist aber in der Praxis recht einfach und intuitiv, glaube icht.
Das kann aber evtl. noch ein bißchen dauern, habe gerade ziemlich viel um die Ohren.
Vielleicht mal ein Beispiel zum besseren Verständnis:
Der Strom hat eine vordefinierte ID in OpenTx (0x28).
Somit wird der Stromwert mit der niedrigsten MSB Adresse als ID 0x28 ausgegeben.
OpenTx erkennt das und nennt den Wert "Curr", Auflösung passt auch schon.
Diese ID 0x28 ist unabhängig von der tatsächlichen (niedrigsten) MSB Adresse des Stromwertes.
Ein weiterer Stromwert auf dem MSB (oder irgendein nicht in OpenTx bekannter Parameter) erhält eine ID,
die sich eindeutig aus der MSB Adresse ergibt, die aber zu den für OpenTx unbekannten IDs gehören muss.
Dann taucht als Name auf dem Display einfach die ID auf.
Über die feste Zuordnung zwischen der MSB Adresse und der ID kann man dann identifizieren,
was es ist und einen passenden Namen vergeben (und evtl. die Auflösung anpassen).
Wenn es für jede MSB Adresse eine freie ID gibt, dessen zweites Nibble direkt dieser Adresse entspricht,
wäre die Zuordnung sehr einfach und ohne Zuhilfenahme irgendwelcher Tabellen möglich.
Also z.B. zwei Stromwerte auf den Adressen 3 und 8.
Erster Stromwert kommt mit ID 0x28 und wird von OpenTx als "Curr" erkannt und bezeichnet.
Zweiter Stromwert kommt (z.B.) mit ID 0x38 (8 = MSB Adresse).
Genau die gleichen IDs würden auftauchen, wenn die Adressen 4 und 8 wären.
Wären die Adressen 4 und 6, würden die IDs 0x28 und 0x36 (6 = Adresse des zweiten Stromwertes) auftauchen.
u.s.w.
Die IDs 0x31 bis 0x38 sind schon mal frei, damit könnte man die Adressen 1 bis 8 abdecken.
Klingt alles etwas kompliziert, ist aber in der Praxis recht einfach und intuitiv, glaube icht.
Ähnliche Themen
