OpenTX - Multiplex MLINK Konverter

[Reinhardt Werbik]

So, die Suche nach freien IDs war erfolgreich, hier ist das Ergebnis:

#define MSB_00_ID 0x20 // IDs für zusätzliche User Daten (pro MSB Adresse)
#define MSB_01_ID 0x31
#define MSB_02_ID 0x32
#define MSB_03_ID 0x33
#define MSB_04_ID 0x34
#define MSB_05_ID 0x35
#define MSB_06_ID 0x36
#define MSB_07_ID 0x37
#define MSB_08_ID 0x38
#define MSB_09_ID 0x29
#define MSB_10_ID 0x2A
#define MSB_11_ID 0x2B
#define MSB_12_ID 0x2C
#define MSB_13_ID 0x2D
#define MSB_14_ID 0x2E
#define MSB_15_ID 0x2F

#define ID_ALARMS 0x00 // ID für MSB Alarm-Flags

Wie man sieht, repräsentiert das zweite Nibble jeweils die MSB Adresse, 0x00 ist für die Alarm Flags.

Achtung: Die Kapazität wird jetzt als zusätzlicher Parameter behandelt und hat nicht mehr die feste ID 0x29.
(Diese wurde für obige Liste gebraucht, da es sonst keine freie ID mit zweiter Stelle = 9 gibt.)
Kapazität auf Adresse 4 (wie bei mir meistens) wird somit mit ID 0x34 übertragen.

Für Drehzahl bleibt die ID 0x07 fest zugeordnet, da hier ein einfaches Durchreichen des Wertes nicht ausreicht,
wegen der Fallunterscheidung zwischen 10 und 100 1/min Auflösung.

Damit ist das ursprüngliche Konzept nur geringfügig "unschöner" geworden, weil die IDs der zusätzlichen Parameter
nicht mehr direkt aufeinanderfolgend sind, was aber in der Praxis wurscht ist.

Jetzt muss ich das ganze noch schnell in den Code einbauen und hoffen, dass OpenTx nicht mit einer der obigen IDs doch irgendwas spezielles anstellt.

 

[Reinhardt Werbik]

Die Änderungen sind eingebaut und scheinen zu funktionieren.
Nach Beseitigung eines Fehlers kommen jetzt auch die Alarm-Flags durch.
(zumindest das für die Empfängerspannung, welches ich als einziges getestet habe)

Als ID für die Alarm-Flags musste ich allerdings etwas anderes als 0x00 nehmen, da OpenTx die 0x00 schlichtweg ignoriert.
Ich habe jetzt mal 0x0F für die Alarm-Flags genommen.

Ich teste noch ein bisschen und stelle (wahrscheinlich morgen) den neuen Code hier ein.
Nächste Woche bin ich nämlich unterwegs, und ich will Euch doch nicht länger warten lassen.

Viele FrSky IDs sind jetzt nicht mehr ungenutzt.

 

[Donaufisch66]

Vielen Dank!

wirst du den OpenTX Entwicklern davon berichten? vielleicht würden sie die IDs bei künftigen Änderungen berücksichtigen.
lg
Roland

 

[Reinhardt Werbik]

Vielen Dank!

wirst du den OpenTX Entwicklern davon berichten? vielleicht würden sie die IDs bei künftigen Änderungen berücksichtigen.
lg
Roland

Hallo Roland,

das habe ich eigentlich nicht vor, aber mal sehen, wenn der Konverter soweit fertig ist...

Einerseits glaube ich nicht, dass die Jungs für das alte D-Protokoll noch viel machen wollen.
Andererseits sollen sie ja auch die nicht benutzten IDs möglichst nicht antasten, damit sie der Konverter verwenden kann.

Das einzige, was man vielleicht fragen könnte, wäre ob es möglich ist, für IDs oberhalb von 0x3F einfach die Werte durchzuschieben.
Aber wie gesagt, ich glaube, die Jungs haben sehr viel mit anderen Dingen (Horus) zu tun.

 

[Reinhardt Werbik]

Hallo zusammen,

nachdem ich noch schnell erfolgreich ausprobiert habe, ob alle IDs in obiger Tabelle von OpenTx auch
anstandslos durchgeschoben werden, stelle ich mal für Interessierte den neuen Code hier ein.

Hier nochmal zusammengefasst, was die rohen IDs, die neben den in OpenTx bekannten Parametern auftauchen, bedeuten:

0x07: -> Drehzahl (falls vorhanden)
0x0F: -> Alarm-Flags aller 16 MSB Adressen

ID Werte aus obiger Tabelle kennzeichnen die zusätzlichen Daten, wobei die 2. Stelle die MSB Adresse reflektiert.
(erste Stelle ist 2 oder 3, siehe oben)

Nur nochmal zur Erinnerung:
Die Kapazität hat jetzt keine feste ID mehr, sondern gemäß der MSB Adresse eine ID aus der Tabelle oben.

Na dann viel Spaß.

 

[Reinhardt Werbik]

Hallo zusammen,

nach meinem Wanderurlaub, einem langen Wochenende und einer halben Arbeitswoche
will ich mal dem Konverter wieder etwas Aufmerksamkeit schenken, nicht dass das hier einschläft.

Es gibt ja jetzt auch einen g-Raten Sensor von Multiplex, und zufällig gibt es für die g-Raten auch vordefinierte FrSky IDs.
Ich habe also die x- und die z-Richtung mit den IDs 0x24 und 0x26 implementiert.
Die g-Rate in y-Richtung liefert der Multiplex Sensor ja nicht, warum auch immer.
Es wird die niedrigste MSB Adresse mit Werteklasse 14 für die x-Richtung und die zweitniedrigste für die z-Richtung verwendet.
(Ich nehme mal schwer an, dass diese Werteklasse benutzt wird, gibt ja nicht mehr viele freie.)

Wenn ich ein wenig getestet habe, stelle ich die neue Version hier ein.
Echte Praxistests kann ich aber nicht machen, da ich (noch) keinen derartigen Sensor habe.

Watch this space.

 

[Donaufisch66]

Super, danke!
Ich konnte den letzten Konverter noch nicht testen. Werde das nachholen, sobald ich Zeit finde.
Erfahrungen werde ich dir mitteilen.
Lg Roland

 

[Reinhardt Werbik]

Ich konnte den letzten Konverter noch nicht testen. Werde das nachholen, sobald ich Zeit finde.

Lass Dich nicht stressen, Roland, kannst ruhig auf die neue Version warten.

Gemäß D-Protokoll Spezifikation müsste die Auflösung der Beschleunigungen eigentlich 0,016 g sein.
Das ist aber offensichtlich nicht der LSB Wert, den OpenTX erwartet.
OpenTx interpretiert das LSB offensichtlich als 0,001 g, was die Sache sehr einfach macht.
Da die Auflösung des Multiplex g-Sensors auf dem MSB 0,1 g ist, muss man den Wert nur mit 100 multiplizieren.
Dann stimmt die Anzeige im Sender-Display.
Ich habe wie gesagt keinen g-Sensor, aber mit einer Testversion des Konverters, bei der die Werteklassen
für Spannung und Beschleunigung vertauscht sind, konnte ich den neuen Parameter mit den vom UnisenseE gemessenen Spannungen testen.

Ich stelle die neue Version dann demnächst ein, will noch ein paar andere Sachen ausprobieren.

Ach ja: Für den RSSI (sprich LQI) habe ich jetzt wieder die feste MSB Adresse 1 zugeordnet.
Dadurch wird das Programm ein Stück übersichtlicher, da jetzt alle Parameter im RVLQ Frame vordefinierte Adressen haben.
Das ist keine Einschränkung, denn wenn man LQI nicht braucht, kann man Adresse 1 auch für einen beliebigen anderen Parameter verwenden.
Und wenn man den LQI auf einer anderen Adresse überträgt, wird er einfach als zusätzliche Parameter
mit einer der Adresse zugeordneten ID mit übertragen, er erscheint dann halt nicht als RSSI (was er ja eh nicht ist).

 

[Donaufisch66]

Hallo Reinhardt,
ich habe nun endlich Zeit gefunden deinen Konverter zu testen.
Mlink RX7DR mit MPX GPS liefert folgende Anzeige:
Anzeige im Sender / Angezeigter Wert / Klasse nach deiner Liste aus Post 341 / Mlink Klassenbezeichnung

0029 /0/9/Füllstand
002B /129/11/Stromverbrauch
002C/ 1350/12/ Flüssigkeiten
002D/ 711/13/Distanz
0F/ 0 / Alarme
A1 /3,2V bzw mit "Umrechnung" 25,6 = 6,2V/
A2 /0V/
RSSI/100/
GAlt/98m/
OF sind die Alarme. Bei mir NULL. demnach ist kein Alarm definiert. Kann ich anhand des Wertes einen Alarm identifizieren? 1=1 2=10 3=100, 4=1000, usw falls nur ein Alarm definiert wäre? Umgerechnet in eine Dezimalzahl, müsste erkennbar sein, auf welchen IDs ein Alarm liegt, oder? Kann der Sender mit so große Dec Zahlen umgehen? zb Alarme auf 2,4,6,7 = 1101010 = 17829904 dec. Funktioniert das?

Weiters ist mir 0029 und 002B und 2C nicht klar. Am Empfänger ist nur ein GPS Empfänger angeschlossen. Habe ich die falsche Zuordnungsliste?
Müssen die Werte wie A1 auf 25,6 oder einen anderen Wert skaliert werden?

Die Werte werden im laufenden Betrieb gefunden. Das GPS hat rund 10 Minuten gebraucht bis die ersten Werte durchgekommen sind. Letztendlich hat der Konverter alle ordentlich erkannt ohne neu starten zu müssen. Nach einem Neustart werden die Werte der Reihe nach aufgelistet.

Lg
Roland

 

[Donaufisch66]

Hallo Reinhardt,
mein letztes Posting kannst du vergessen!
ich hatte vergessen, dass die IDs die Adressen wiedergeben, nicht die Werteklassen! Habe mich nun eingelesen und wieder verstanden wie die Werte übersetzt werden.

Demnach werden die Sensoren richtig übertragen! Bei den angezeigten Werten bin ich mir nicht sicher. Muß ich eine Skalierung der Werte vornehmen? GPS Werte sind bei ruhendem GPS nichts sagend, daher kann ich eine Mögliche Skalierung nicht erkennen.


LG
Roland

 

[Reinhardt Werbik]

Hallo Roland,

erst mal herzlichen Dank für Deine Tests.

Äähm, das zweite Nibble einer ID für einen zusätzlichen Parameter repräsentiert die MSB Adresse, nicht die Werteklasse.

0029 -> Adresse 9
002B -> Adresse 11
002C -> Adresse 12
002D -> Adresse 13

Die Werteklasse spielt hier keine Rolle, der Parameter wird einfach durchgeschoben.
Je nachdem, was Du auf der Adresse überträgst, musst Du dann im Sender Einheit und Skalierung auswählen.
Also z.B. "mAh" und keine Skalierung für die Übertragung der Kapazität, da diese schon als ganzzahliger Wert in mAh auf dem MSB anliegt.
Oder "A" und Skalierung 25,5 für einen weiteren Stromwert, da dieser in 1/10 A auf dem MSB übertragen wird.
(Ist im Handbuch von Helle ganz gut beschrieben, wie die Umrechnung erfolgt.)

Bei den Alarm-Flags ist es so, dass jedes Bit das Alarm-Flag der entsprechenden MSB Adresse wiederspiegelt.
Wenn nur ein Alarm gesetzt ist, bedeutet also ein Wert von 1, dass das Alarm-Flag der Adresse 0 gesetzt ist.
Ein Wert von 8 würde ein Alarm-Flag auf Adresse 3 anzeigen, u.s.w.
Was man im Sender mit diesen Werten machen kann, habe ich noch nicht probiert, ich habe die Alarm-Flags mehr als Gag aufgenommen.
Bei nur einem einzigen Alarm könnte man einfach über einen logischen Schalter auf den entsprechenden Wert abfragen und dann eine Ansage triggern.
Hier gibt es sicherlich etliche Möglichkeiten, aber einfacher ist es eigentlich, den Alarm direkt in OpenTx zu erzeugen.

Übrigens: Das Auflisten der Reihe nach nach einem Neustart kann nur durch OpenTx erfolgen, der Konverter hat da keinen Einfluß.
Ist aber interessant zu wissen, werde ich demnächst mal explizit testen.

Edit: Ups, Du hast es selbst gemerkt.

 

[Reinhardt Werbik]

Kleiner Nachtrag:

Ich habe mittlerweile eine neue Version am Laufen, hatte ja die neue Werteklasse für Beschleunigung implementiert.
Danach habe ich einen ausführlichen "Code Walkthrough" gemacht und dabei eine deutliche Vereinfachungsmöglichkeit entdeckt.

Ich hatte ja ursprünglich das Ermitteln der MSB Adressen einmalig beim Programmstart ausgeführt.
Wegen der Hochlaufzeiten speziell des GPS-Sensors habe ich das dann in die Hauptschleife verschoben.
Sprich, der Konverter erkennt jederzeit im laufenden Betrieb, wenn sich was tut am MSB.
Ich hatte dazu einfach die entsprechende C-Funktion verschoben.

Dadurch wurden dann Adressermittlung und Werteberechnung immer unmittelbar hintereinander ausgeführt.
Die damit verbundene Vereinfachungsmöglichkeit, sprich das Kombinieren der beiden Funktionen in eine, habe ich jetzt umgesetzt.
Es ist ja schließlich nicht mehr nötig, die gefundenen Adressen abzuspeichern, um dann später wieder darauf zuzugreifen.
Es wird jetzt einfach für jede gefundene Adresse sofort der dazugehörige FrSky Wert berechnet.
Ein Ablegen der Adressen ist nicht mehr nötig, nach jedem empfangenen M-Link Datenpaket wird alles erneut berechnet.

Diese Änderung hat immerhin die Größe des Programms von ca. 4 auf ca. 3,2 kB reduziert.
Außerdem ist die Übersichtlichkeit deutlich gestiegen.
Die neue Version wird natürlich hier veröffentlicht, wenn ich mir sicher bin, keine Fehler eingebaut zu haben.

 

[Donaufisch66]

Ja, wie die Adressen übertragen werden hatte ich zwischenzeitlich vergessen. :-) Ein paar Wochen Pause und alles ist vergessen....

Mir ist aufgefallen, dass die Sensoradressen zwischengespeichert werden. Wird ein Sensor im laufenden Betrieb entfernt und neu gescannt, erkennt der Sender diesen immer noch. Nach einem Neustart werden nur die tatsächlich vorhandenen gefunden.
Dieses Verhalten dürftest du aber in der neuen Version entfernt haben. Es stört jedenfalls nicht.
Kalle hat mal geschrieben, dass seine X9D eine Warnung ausgibt, wenn ein Sensor abgesteckt wird. Diese Einstellungsmöglichkeit habe ich nicht gefunden. mein Sender bleibt stumm, wenn Sensoren abgesteckt werden. Hat jedoch nichts mit dem Konverter zu tun.
Wie ich skalieren muss, habe ich noch nicht verstanden. Werde mir das bei Helle ansehen. Wenn ein System dahinter steckt, ist das natürlich am sinnvollsten.

etwas offtopic passt aber trotzdem gut dazu!

Die Antenne des HFMG1 Moduls ist mit einem U.Fl Stecker auf die Modulplatine gesteckt. Die Bluetooth Antenne nutzt EXAKT denselben Steckertyp! Die "rechte" Bluetooth Antenne am Sender kann also als Modulantenne genutzt werden!! Die Antenne kann beim Bluetooth Modul einfach abgesteckt und am HFMG1 angesteckt werden!
Habe heute umgesteckt. Erste Reichweitetests waren erfolgreich. Ordentliche Tests kann ich erst am Feld machen. Das freie Antennenloch im Sender kann man für die Binding LED nutzen! An dieser Stelle auch ein herzliches Dankeschön an MPX für ihren vorausschauenden und systemübergreifenden Einsatz von U.Fl Buchsen! ;-)
Lg
Roland

 

[Reinhardt Werbik]

Mir ist aufgefallen, dass die Sensoradressen zwischengespeichert werden. Wird ein Sensor im laufenden Betrieb entfernt und neu gescannt, erkennt der Sender diesen immer noch. Nach einem Neustart werden nur die tatsächlich vorhandenen gefunden.
Dieses Verhalten dürftest du aber in der neuen Version entfernt haben. Es stört jedenfalls nicht.
Kalle hat mal geschrieben, dass seine X9D eine Warnung ausgibt, wenn ein Sensor abgesteckt wird. Diese Einstellungsmöglichkeit habe ich nicht gefunden. mein Sender bleibt stumm, wenn Sensoren abgesteckt werden. Hat jedoch nichts mit dem Konverter zu tun.

Hallo Roland,

mir ist nicht so ganz klar, was Du damit meinst.
Der Konverter speichert gar keine Adressen mehr, er reagiert jederzeit auf Änderungen am MSB.
Wenn ein Sensor entfernt wird, schaltet der Konverter nach einer Weile den entsprechenden Daten-Frame zum Sender ab.
(Ausgenommen ist der RVQL Frame, in dem A1, A2 und RSSI übertragen werden, dieser wird immer gesendet.)
Die Zeit hängt vom Sendemodul ab, das eine Weile braucht, bis es den Parameter nicht mehr meldet.

Wenn ein einzelner Daten-Frame verschwindet, setzt OpenTx den entsprechenden Wert in eckige Klammern.
OpenTx merkt sich aber den Parameter (an Hand der ID) und zeigt ihn auch nach einem Neustart des Senders noch in eckigen Klammern an.
Steckt man den Sensor wieder an, verschwinden nach einiger Zeit die eckigen Klammern wieder.
Nur wenn man den Sensor explizit löscht, kommt er nicht wieder und man muss ihn neu einscannen.

Eine Warnung "Telemetrie verloren" kommt dann, wenn der Konverter alle Daten zum Sender abschaltet.
Das macht er z.B., wenn der Empfänger ausgeschaltet wird und daher vom Sendemodul keine Telemetriedaten mehr kommen.
So von sich aus gibt der Sender keine Warnung aus, wenn ein einzelner Parameter verschwindet.
Nur die eckigen Klammern kommen auf dem Display, um anzuzeigen, dass der Parameter nicht mehr aktualisiert wird.

 

[Donaufisch66]

hallo Reinhardt,
ich habe nach Sensoren gesucht und nach deren Erscheinen die Suche beendet. Dann das GPS vom Empfänger abgesteckt und nach ein paar Sekunden waren die Werte eingeklammert. passt!
Jetzt habe ich alle Sensoren gelöscht und eine neue Suche gestartet.
Es werden exakt dieselben Sensoren IDs wie zuvor MIT GPS gefunden! Auch die IDs des GPS das eigentlich nicht mehr vorhanden ist.
Lösche ich alle Sensoren, starte den Sender neu und suche erst nach dem Neustart, werden nur die vorhandenen Werte ohne den GPS IDs gefunden. In diesem Fall nur A1,A2,RSSI.

Dieses Verhalten stört mich nicht. Man wird kaum im laufenden Betrieb die Sensorenkonfiguration ändern.

Kannst du nochmals erklären warum A1 mit 25,6 skaliert wird?
lg
roland

 

[Reinhardt Werbik]

Hallo Roland,

ich habe mal ein bisschen rumprobiert.
Da ist irgendwas noch faul in der Software, ich weiß aber nicht, ob das in Deiner Version auch schon so ist.

Wenn ich einen Unisense als Sensor dran habe und die Sensorsuche starte, findet der Konverter alles wie gehabt.
Stecke ich den Unisense ab, klammert er die entsprechenden Werte ein, auch noch ok.
Wenn ich jetzt aber erneut suche, findet er die Unisense Parameter als zusätzliche Parameter mit einer ID, die die Adresse reflektiert.
Obwohl der Unisense noch abgesteckt ist, wohlgemerkt.

Wenn ich den Konverter nach dem Abstecken des Unisense neu starte (passiert bei meinem Test ohne Sender-Neustart,
da der Konverter außerhalb des Senders am USB Bus hängt),
und dann die Sensoren suche, findet er nur A1, A2, RSSI und die Alarm-Flags, das passt dann wieder.

Auch wenn ich den Empfänger nach dem Abstecken des Unisense aus- und wieder einschalte (ohne den Konverter zurückzusetzen),
findet er nur A1, A2, RSSI und die Alarm-Flags, so wie erwartet.

Es hat natürlich was damit zu tun, was das M-Link Modul tatsächlich liefert.
Da muss ich noch weiterforschen, denn so ist das nicht akzeptabel, auch wenn der Fall in der Praxis nicht relevant ist.

 

[Donaufisch66]

Hi,
für den alltäglichen Gebrauch wäre es irrelevant. Die Tatsache, dass nun alle 15 Adressen übertragen werden ist super und der Konverter dürfte im Gebrauch tadellos funktionieren.
Werden jetzt ALLE 15 Kanälen auf den von dir definierten IDs übertragen? Werden dadurch bekannte IDs doppelt übertragen? Ich habe überlegt ob es möglich wäre, deine 16 IDs im Companion Seite "Telemetrie" vorzudefinieren. So würden immer alle Sensoren erkannt werden. Da mir die IDs bisher nicht bekannt waren, hatte ich bisher alle Sensoren gescannt und dann in Companion übertragen.
Alle Sensoren in einer Vorlage nur einmal anlegen zu müssen, wäre natürlich einfacher und komfortabler.
Falls die dem Konverter "bekannten" Sensoren andere IDs verwenden, hast du eine Liste dieser IDs?

Lg
roland

 

[Reinhardt Werbik]

Kannst du nochmals erklären warum A1 mit 25,6 skaliert wird?

Das hatte ich vorher glatt vergessen zu beantworten.
Es liegt am Messbereich, der mit der Auflösung auf dem MSB und den 8 Bit von A1 eben 25,5 V beträgt.
Ich glaube, dass man genaugenommen mit 25,5 skalieren muss.

Zu den IDs ist zu sagen, dass man natürlich nicht immer die gleichen IDs hat, das hängt von der MSB Konfiguration ab.
Wenn Du z.B. in einem Extrembeispiel 16 mal eine nicht bekannte Werteklasse hast (Füllstand z.B.),
dann tauchen die 16 IDs gemäß Tabelle in Post 341 auf.
Wenn aber einige MSB Adressen mit bekannten Parametern belegt sind, tauchen diese mit den vordefinierten IDs auf.
(z.B. 0x28 für Strom)
Die Parameter mit vordefinierten IDs sollen natürlich nicht doppelt auftauchen.
Sprich, wenn z.B. Strom auf Adresse 3 übertragen wird, darf die ID 0x33 nicht mehr auftauchen.
(Der Strom würde mit der vordefinierten ID 0x28 auftauchen.)

Ist alles ein bisschen verwirrend, wenn man es nicht selbst programmiert hat, denke ich.

 

[Reinhardt Werbik]

Hier noch die Liste der vordefinierten IDs.

0x39: Spannung
0x28: Strom
0x07: Drehzahl
0x02: Temperatur 1
0x05: Temperatur 2
0x10: Baro-Höhe (ganzzahliger Anteil)
0x21: Baro-Höhe (Nachkommastellen)
0x01: GPS-Höhe (ganzzahliger Anteil)
0x09: GPS-Höhe (Nachkommastellen)
0x30: Steigrate
0x24: g-Rate x-Richtung
0x25: g-Rate y-Richtung (vom MPX Sensor nicht gemessen)
0x26: g-Rate z-Richtung

Bei Baro- und GPS-Höhe werden zwei Daten Frames übertragen.
Ich meine, dass in OpenTx die ID für die Nachkommastellen erscheint.
A1, A2 und RSSi haben ganz spezielle IDs, die OpenTx selbst erzeugt, nicht der Konverter.
(Diese Parameter sind im RVLQ Frame, in dem es keine IDs gibt.)

 

[Reinhardt Werbik]

So, jetzt habe ich nochmal mit einem simplen MPX Stromsensor getestet,
der Strom, Kapazität und Maximalstrom auf den Adressen 3, 4 und 12 überträgt.
Die Sensorsuche liefert wie erwartet Curr (= Strom mit vordefinierter ID 0x28), 0034 (Kapazität) und 002C (Maximalstrom).
Kapazität und der zweite Stromwert werden mit IDs gemäß ihrer Adresse übertragen.
(A1, A2, RSSI und Alarm-Flags erscheinen auch, sind aber hier nicht von Interesse.)

Der Kapazitätswert ist 1600 mAh, davon wird dann runtergezählt, wenn tatsächlich Strom fließt.

Und jetzt kommt's:
Wenn ich den Stromsensor abstecke, wird der Curr Wert eingeklammert, passt.
Die Werte für Kapazität und Maximalstrom werden nicht eingeklammert, sprich weiter vom Konverter geliefert.
Und der Wert für die Kapazität springt auf 0!!!
Das kann ich mir nur so erklären, dass beim Abstecken eines Sensors das M-Link Modul Nullen als Werte liefert.
Das führt im Programm bei einer vordefinierten ID dazu, dass der entsprechende Daten Frame abgeschaltet wird.
(da ja die Werteklasse nicht mehr passt)
Bei den zusätzlichen Daten wird aber die Werteklasse gar nicht ausgewertet, das ist ja gerade das gewünschte Verhalten.
Deshalb wird der Parameter fröhlich weiter übertragen, aber eben mit Wert 0.

Ich muss diese Theorie wohl überprüfen, indem ich direkt den Ausgang des M-Link Moduls mit dem Hameg anzapfe.
Aber das wird nicht mehr heute passieren.

Es bleibt spannend.