J-Log.eu - Forum

Eigentlich wollte ich ja nicht drüber reden, es "vertuschen", aber nun muss ich doch.. (Es gab gerade eine neue S32 Firmware, 1.38, sie enthält weitere Workarounds für den Mist, den wir uns diesmal reinziehen als TelMe.)

JLog ist ein TelMe für den ESC. Das Protokoll, was wir dadurch als JLog2.x verwendeten, ist bekanntlich hochgradig buggy, insbesondere der "Drehzahlbug" ist schlimm.
DZ-Bug (JLog3 bekommt ihn NICHT zu spüren):
Es kommt innerhalb der DZ Range eines normalen Motors mehrfach zum Überlauf des "Daten Containers", DZ springt auf Null zurück dadurch, weil der in den Container gepackte Wert (vor Senden) viel zu groß ist, gleich aufgrund von 3 Bugs an einer Sache.

Als Workaround verringern wir den DZ-Wert, bevor er übertragen wird durch den ESC, indem wir den durch die halbe Polzahl teilen lassen. Damit uns dadurch nicht gleichzeitig immens Auflösung verloren geht, bemühen wir nicht zusätzlich das Anwenden des Ratios im ESC. Somit haben wir auch weiterhin beides, Motor- und Rotor-DZ, in Jlog.
Das mit dem Anwenden der Polzahl auf den DZ Wert im ESC funktioniert nur unter bestimmten Voraussetzungen:
- Die Polzahl ist entsprechend hoch, sodass der Teilungsfaktor (halbe Polzahl) hinreichend Wirkung zeigt. Es hängt auch von der KV und der Spannung ab, aber 8 Pole sollten es schon wenigstens sein, knirsch evtl. auch 6 Pole. Darunter funktioniert es nicht.
- Die Motorbremse muss OFF sein. Ist sie an, dann kann JLog nicht seinen Teil zum Workaround beisteuern, der PWM als Führungswert verwendet. Natürlich verwendet die Bremse auch PWM, aber warum gibt man die auch aus als Datum?!

Workaround Teil 2 liegt in JLog's (2.x) Firmware. EINEN Datenüberlauf kann er erkennen und kompensieren. Das tut er, indem er auf die PWM achtet. Das funktioniert nur, wenn PWM ausschließlich "Stoffgeben" folgt, nicht auch "Bremsen", - s.o.
Ein Nebeneffekt ist im Log und u.U. auch in den Maxwerten im Sender zu sehen: Der ESC updatet die Daten nicht prozess-synchron. Wenn ich schlagartig Gas (und damit PWM) auf Null nehme, was beim/nach dem Landen immer passiert, dann ist PWM oft bereits Null, während der DZ-Wert noch nicht. Folge ist ein DZ-Spike minimaler Breite, weil der Workaround kurz ausgehebelt wurde.

---------------------------------------

Da nicht nur die User die Schnauze voll hatten davon, ging es auf ein anderes TelMe Protokoll mit S32, ein ganz neues und "tolles", weshalb der ESC Firmware Version 4.10/1.10 im Minimum haben muss.
Es war die Wahl zwischen Pest und zu befürchtender Cholera. Schon bald stellte sich während des Implementierens in S32 heraus: Jawohl, es ist keine Gesundheitsfarm, es IST Cholera.
Die Implementierung des Protokolls hat katastrophal viele Fehler. Es ist überdeutlich sichtbar: Der Ausführende hat Null Überlegung walten lassen, - aber on top scherte er sich einen Dreck um die Regeln des Protokolls.
Ich baute wieder Workarounds, - bis auf regelmäßige Lücken im Data Update erscheint nichts nach außen zur Anwendung.
Dann traten auch mystische, stochastische Übertragungslücken auf den Plan, als S32 mit diesem TelMe zum ersten mal nicht nur in meinem Lab werkelte. (ok, bisher meldete sich nur "blademaster" dazu) Als Reaktion musste das General Timeout auf sage und schreibe 4 Sekunden gehoben werden! Außerdem musste wieder ein Hazard Filter auf die Daten. Der geht eh nur 1-stufig, - im Falle, er muss kitten, halbiert das die Update Rate noch mal.
Wg. der ingesamt deutlich schlechteren Data Update Rate als mit dem (versauten) TelMe, was JLog2.x ist, hatte ich schon länger auf dem Radar, noch mal zu versuchen, das zu tweaken.
Letzte Nacht war es so weit... und ich fiel endgültig vom Glauben ab. Ich fand den Grund für diese stochastisch möglichen Datenprotokoll-Unterbrechungen. Das ist so unglaublich, macht mich innerlich so sauer, dass ich hier nun doch drüber rede.
("sauer", was sag ich, regelrecht "wütend": Was nutzt es, sich zu bemühen, mit dem Einsatz von IQ zu arbeiten, wenn man dabei mit dem Outcome von IQ umgehen muss?)

1) Das Protokoll enthält Pakete mit 16 Typen Inhalt. Nur 2 davon enthalten den eigentlichen Payload mit Nutzdaten! Ein drittes Paket "enthält "Nutzdaten" ohne Nutzen, komplett sinnlos. Die Crux ist, dass es genauso häufig wie die Nutzdaten zu senden ist, weil sonst der Datenempfänger in Timeout fällt, - nutzloserweise sollte er das nicht, wenn er auch nur Redundanz zu sehen bekommt.

2) Die anderen 13 Pakete, deren Inhalt, müssen zwar gesendet werden, aber nur alle Jubeljahre, weeeesentlich seltener als die Nutzdaten.

3) Man sendet nun einfach alle 16 Pakete immer hintereinander, vor allem, nicht mal die beiden verträumten Nutzdatenpakete verteilt in den viel zu häufig gesendeten anderen, sondern beides jeweils am Stück. Die Nutzdaten bekommen daher die Übertragungskapazität im Verhältnis von nur 2/16! Im Ergebnis ist die Daten Update Frequenz unnötig niedrig. Im Log sieht man das im Vergleich zu allen anderen ESCs, wenn das Log nur ein paar Sekunden dauert. Kommt on top, dass die Auflösung der Daten, wie sie dieser ESC sendet, gering ist, z.B. beträgt die Auflösung von Imot nur 1A. -- Richtig gemacht (Kopf benutzt), hätte man fast 1/1 erreichen können.

4) Man pfeift auf das Protokoll von A bis Z. So kommt es, dass "TelMe JETI" (ohne Not EXbus, dadurch Latenzen einkaufend im Vergleich zu EX und verwendbare Empfänger einschränkend) nicht koexistieren kann auf dem "Bus" mit anderen Sensoren. Es stört das Protokoll massiv, quatscht, wann es will.

5) Nun kommt der Hammer, letzte Nacht entdeckt. Das ist einfach unglaublich:
Auf so einem 1-Wire Bus muss ein Slave (Sensor) immer demselben Spiel in Bezug auf das Agieren des Masters folgen: Er muss dem Master gut zuhören, seine Daten lesen und auswerten, damit er protokollgerecht weiß, wann er senden darf. Ich dachte bis eben, dass der Implementator einfach nur des Lesens nicht mächtig ist, das Protokoll nicht verstand, oder er kurzerhand drauf pfiff. Nee, denkste, er liest es erst gar nicht. Das ist so, als ob die akustischen Aussendungen der Ehefrau einfach nur unregelmäßige Schwankungen des Luftdrucks sind.

Man liest den Master nicht, man sendet einfach, wenn der (scheinbar) aufhört, zu blubbern!
Das Schärfste ist: Dieses Timeout sind 100 Mikrosekunden. 100us, nachdem der Master scheinbar nicht mehr sendet, ballert man einfach los. (in diesem Protokoll darf man nur nach Aufforderung senden, weil man sonst das Modell vom Himmel holen könnte)
Es ist aber noch "besser": Es scheint sich gar nicht um ein bewusstes Beobachten des Blubberns (man hört ja nicht, um zu verstehen) des Masters zu handeln: Das Aussenden eines Zeichens (Bytes) benötigt aufgrund der verwendeten Baudrate 80us. Nach nur 100us erkennt man auf "Master hält nun die Klappe". Häh?! Gerademal 25% über eine Zeichenlänge?! Wenn die 20us mal nicht einfach nur eine Zeit sind, die man selbst braucht.

Beim besten Willen... mehr darf ich public nicht sagen.. (H.K. und sein späterer Mitstreiter S. machten gute ESCs. Sicher, Fehler passieren manchmal. Aber, was da abgeht nach den beiden.. Hoffen wir, dass die eigentliche ESC-Firmware verschont bleibt..)

-----
Somit wissen wir, woher diese stochastischen Lücken kommen werden. Der ESC sendet asynchron parallel zum Master (S32), wenn der mal aufgrund der Priority in seiner Interrupt Chain eine "Denkpause" einlegt, schließlich hat er noch 100 andere Sachen parallel zu tun, schließlich musste er annehmen, dass so eine Denkpause hier unschädlich ist.
Ab S32 Firmware 1.38 musste ich diesem Crap höchste Interrupt Prio einräumen, hoffentlich nicht zum Nachteil anderer Anwendungen.
Dafür revanchiere ich mich, trete auf's Gas, wodurch sich die Data Update Rate nun verdoppelte, - sprich, die unnötigen Gaps zwischen echten Nutzdaten halbieren sich.

Schaun wir mal, was noch so kommt..

_________________
Tom

https://www.rc-heli.de/board/showthread.php?goto=newpost&t=259645

Du kannst es natürlich nicht besser wissen.
Wenn Du wüsstest, wie Du an meinem Entscheidungsrad drehst, eine Kundenklientel zu verlassen, die nicht in der Lage ist, ihre Wertschätzungen an realen Maßstäben zu messen..

"winzig": TelMe sind zwei vorsintflutliche Optokoppler. Es ist das Mittel, sich Weiterentwicklungen der Firmware bezahlen zu lassen.

TelMe JETI (EXbus), die Firmware, ist ein einziger Pfusch.
Sei vorsichtig! Benutze es nur für Telemetrie, hänge nichts mit auf den EXbus. Es würde i.allg. eh nicht funktionieren, weil das TelMe das Protokoll so verletzt.
Aber, falls es doch gehen sollte (nicht vorstellbar), dann KEIN FBL! Die Kanaldaten sind in Gefahr!

TelMe JETI verletzt das EXbus Protokoll massivst, ist daher heiß!
Solange nur JLog den Mist abkriegt (S32), ist das egal, am Empfänger aber..
Also: Ein EXbus Port am Empfänger, nichts auf einem anderen EXbus Port! Parallel einen Port des REX als EX ("Jetibox") zu betreiben, stellt kein Problem dar.

Übrigens, wie sehen denn die EX Displays aus? Die Profibox, zumindest, lässt es Sch.. aussehen. Grund: Die Displaynamen sind zu lang, rutschen daher in die Unit hinein (wie "V", "A" usw.), überschreiben diese.

_________________
Tom

EXbus ist im elektrischen Sinne genauso wenig ein Bus wie EX und zuvor v1 (reiner Text), es ist eine Punkt-zu-Punkt-Verbindung.
Allerdings kommt der Bus im logischen Sinne (Protokoll) doch zustande über das Verwenden mehrerer EXbus Ports am Empfänger (REX).
Es geht nicht. Jemand, der, wie ich gerade erfuhr, hier mitliest, hat es bereits erlebt.

Viel kritischer ist aber das, was der Anlass für meine Offenheit war, was ich erst vor Kurzem bemerkte:
Der Slave TelMe kann gar kein disziplinierter Busteilnehmer sein, weil ihn der Inhalt der Aussendungen des Masters (REX) nicht interessiert.
Sobald auch nur die kleinste Verzögerung zwischen zwei Bytes eines Kanaldatenpakets eintritt (100us), ballert der Slave los (sendet), interferiert dadurch mit den Kanaldaten.
Ein Nebeneffekt ist, dass dadurch natürlich der Ping-Pong Master--Slave (Masters Daten fordern zum Senden des Slave auf oder nicht!) asynchron wird. Man hört nun mal nix, wenn man irrtümlich gerade sendet, - und die Gegenseite (Master) auch nicht auf "Listen" ist, das Dazwischenquatschen nicht mitbekommt. Das ist nun mal Half Duplex auf dem 1-Wire.

-----
Ich hab allerdings nicht getestet, ob der virtuelle Bus in der REX Firmware tatsächlich die Chance gibt, dass TelMe auf einem EXbus Port die Kanaldaten auf einem anderen überschreiben kann. Theoretisch schon.. Ist mir die Zeit zu schade für... Kann man nur hoffen, dass ein REX in der Praxis niemals so eine kleine "Sendepause" macht, was TelMe zum falschen Zeitpunkt zum Senden veranlasst.
Dass es sich auch so nicht daran hält, wann es senden darf, wenn es nicht dem Master in's Wort fällt, - stört vermutlich eher andere EXbus Sensoren als das Übertragen der Kanaldaten.
Auf jeden Fall ist es natürlich heiß, wenn in so einer Operation am offenen Herzen der eine Operateur unsere Sprache nicht versteht, nur unterscheidet zwischen, wir sprechen, wir halten die Klappe. Besonders blöd dabei ist, dass er bereits dann entscheidet "sie haben aufgehört, zu sprechen", wenn wir in einem Satz mal Luft holen. Der Implementator sollte sich sein Lehrgeld zurückzahlen lassen.

Was hinsichtlich Entkopplung der Sensordaten gehen sollte: TelMe als einziger EXbus Sensor auf einem EXbus Port, andere EX (nicht EXbus!) Sensoren auf einem EX Port.
Auch nicht praktisch probiert.
(Es wäre wirklich besser und im Sinne der Anwendung (reine Telemetrie) gewesen, nicht EXbus sondern EX zu nehmen für TelMe..)

------
Anderes Teilthema, - zu lange Displaynamen, sodass der String in den String für "Unit" rutscht.
Die max. Länge spezifiziert JETI nicht. Es kann sein, dass ein Sender-Display längere Namen kann als die Profibox hier. Weiß ich nicht, kann ich nicht überprüfen.
Wenn der Implementator dann nur einen JETI Sender hatte, aber keine Profibox, ... tja, dann geht das auf JETI's Konto.

_________________
Tom

Bisher Glück gehabt.
Wie gesagt, was Schlimmes kann nur passieren, wenn mal aus irgendeinem Grund eine "Kunstpause" zwischen zwei Zeichen vom Master (in den Kanaldaten) gemacht wird, wenn diese Pause ca. 100us erreicht. Dann sendet die Firmware hinter dem Doppel-Optokoppler "TelMe" plötzlich los, weil sie "denkt", der Master wäre fertig. Diese Aussendungen sieht auch Dein Axxon, würde sie als Kanaldaten ansehen.

Wie gesagt: Kein Päuschen, kein Problemchen. Geschmackssache.., mir wäre es zu heiß mit dem FBL (wenn ich noch mal in diesem Leben Zeit für's Hobby hätte, dann noch fliegen könnte )

_________________
Tom

Ich will versuchen ( ), mich noch mal klarer auszudrücken:

Wenn jemand auf einem reinen Telemetrie-Bus den jeweiligen Mechanismus der Bus Arbitration missachtet, dann ist das Ergebnis zwar ärgerlich, kann aber keinen Impact für die Steuerbarkeit des Modells darstellen. Schlimmstenfalls werden Daten von Sensoren geschreddert oder der ganze Bus blockiert. So what, keine Telemetrie, mehr nicht.
HoTT hatte es sogar geschafft, sich im eigenen Hause gegenseitig im Wege zu stehen, indem man kein Idle Line Protocol vorsah.

Die Tendenz geht aber zu Universalinterfaces, ausschließlich async-serial 1-Wire, auf denen die Steuersignale als Summensignal (Single Line) zusätzlich übertragen werden. Es gibt somit zwei Arten von Daten, zwei Empfänger von Daten, wobei das ungestörte Empfangen von Single Line Daten höchst primär ist.
Momentan haben wir dafür
- Futaba S.Bus2 (um Bidirektionalität erweiterter S.Bus)
- JETI EXbus (Summensignal + EX Pakete in EXbus Frames gepackt)
- SPEKTRUM SRXL *)

Auf diesen Bussen darf man kein Auge mehr zudrücken, wenn jemand der Arbitration nicht 100%ig folgt, wenn er sie gar zu 100% ignoriert, wie es die TelMe JETI Software tut! Das gilt zumindest dann, wenn ein Empfänger für Single Line Data im Modell betrieben wird, i.allg. ein FBL.
(Ihr erinnert Euch an den Futaba Rx R7003, wo ich mal wieder als "Dissident" auftrat? Zu dem Ding musste man auch die Klappe aufmachen, weil Single Line Daten auf beiden Bussen, S.Bus2 und S.Bus, gestört werden konnten.)

*) Horizon's SRXL ist eigentlich kein SRXL.
SRXL ist als 1-way definiert, ausschließlich für Single Line, so ziemlich das einzige Standard-Konsortium, was sich in RC je bildete.
SRXL (der Standard) definiert sich NICHT als bidirektional, sondern nur Master(Rx)->FBL, nicht auch Device(Sensor)->Master.
Horizon's SRXL ist aber bidirektional, unabgestimmt mit dem SRXL-Standard.
Single Line Daten in deren "SRXL" haben momentan gar nichts mit SRXL zu tun. Es handelt sich dabei um das SPEKTRUM Remote Receiver Format, was Sat's quatschen.
In der Gegenrichtung ist es SRXL, wo es aber lt. Standard nicht hingehört, und dabei hält man sich auch nicht an den SRXL-Standard, was die Checksumme betrifft.
Selbst, wenn die nächste Variante von SPEKTRUM SRXL auch die Single Line Daten als SRXL verpacken wird, ist es dadurch trotzdem kein SRXL.
Sprich, das Verwenden des Begriffes "SRXL" ist irreführend, "Schokoweihnachtsmann" wäre eindeutiger gewesen für eine proprietäre Lösung.

_________________
Tom

FYI: Ich bin gerade dabei, die weißen Flecken zu beseitigen.

Da EXbus kein Bus ist im elektrischen Sinne, ist die Hoffnung, dass der logische Bus in der Firmware des REX negative Wirkung der Protokollignoranz des TelMe JETI verhindert.

Bin noch nicht fertig, aber bisher sieht's ganz gut aus.

_________________
Tom

Removing White Spots ... + Abschluß

Ausgangspunkt: TelMe schert sich einen Dreck um die Aussendungen des Masters, liest sie nicht. Es wartet, bis der Master aufhört zu "blubbern", dann sendet es, und zwar bereits nach einer Zeichenlänge Blubberpause (100us).

Frage: Welchen Impact kann das darstellen
a) für Kanaldaten, die der Master auf einem anderen EXbus Port sendet (->FBL)?
b) für die Koexistenz mit anderen Sensoren auf anderen EXbus Ports?

Thesen (Theorie):
1) EXbus ist KEIN Bus! Ergo gibt es keinen Grund, ein anderes Device auf einem anderen EXbus Port die Aussendungen von TelMe hören zu lassen. Von daher kann TelMe's Undisziplin diese nicht stören.
2) Dass TelMe sendet (auf seinem EXbus Port), wenn es nicht aufgefordert ist, - dass die Möglichkeit besteht, dass TelMe in die Aussendungen des Masters hineinquatscht (s.o.), kann es das Timing des Masters evtl. stören, sodass es doch eine Rückwirkung zeigt auf einem anderen EXbus Port? Theorie: Keine, kann man nur testen, denn man kennt die Firmware des Empfängers nicht.

Abdeckung: Da der Master ein Empfänger zu sein hat, da die Sourcen von dessen Firmware nicht z.V. stehen, konnte so ein Päuschen zwischen zwei Bytes eines Kanaldatenpakets leider nicht simuliert werden. Die durchaus berechtigte Hoffnung ist, dass es keine Rückwirkung haben würde auf andere EXbus Ports. Allerdings würde es zeitweise Asynchronität auf dem Port, an dem TelMe hängt, bewirken, wodurch dessen Daten zeitweilig nicht gelesen werden können (ca. 100ms Millisekunden +/-).

Anhang 1: Zwei S32 an einem REX6. Man sieht, dass der Sensor nur mit jeder zweiten Aussendung des Masters aufgefordert ist, zu senden.

Anhang 2: Man sieht einen minimalen Versatz der Aussendungen des Masters auf den beiden Ports. Das ist der Sequentialität in der Ausführung in der Firmware geschuldet. (Die eine fehlende Byte-Beschriftung ist keine Lücke, ich hatte den Viewer nur nicht genügend zoomen lassen.)

Anhang 3: Auf einem Port ein S32 (habe sonst keinen anderen EXbus Sensor), auf dem anderen TelMe JETI. Man sieht, TelMe sendet auch, wenn nicht aufgefordert.

Anhang 4: Hat das eine Wirkung auf das Timing des Master? Sprich, sind Aussendungen eines Sensors evtl. am Timing des Masters beteiligt, könnte unaufgefordertes Senden einen Impact darstellen? Sichtbar: Nein. Die beiden Kanaldatenpakete auf beiden Ports, oben S32, unten TelMe, sind identisch. Uff!

Anhang 5: Hat mit TelMe gar nichts zu tun (getestet, daher hängt hier nur noch ein S32 dran): Interessant, dass die Aussendungen des Masters (REX6) nicht in zeitlich konstanten Abständen erfolgen. Ein FBL, wie z.B. das Beast, was aus Knüppelwegänderungen pro Zeit die sog. "Knüppelbeschleunigung" berechnet und in seine Regelkreise einfließen lässt, - wird das weniger gut finden.
Der Sender sendet seine Kanaldaten, der Rx empfängt es, er ballert es dann auf seinen EXbus Ports raus. Könnte natürlich sein, dass mein Sender, eine Profibox, die ich mit PPM Daten aus einem Microcontroller füttere, das verursacht. Allerdings eher unwahrscheinlich.

(Dass ein Anwender vermeldete, dass TelMe auf einem Port einen EXbus Sensor auf einem anderen Port störte: Konnte ich nicht nachvollziehen, - allerdings war es hier ein REX6, der Anwender hat eine Central Box.)

Also zum Thema "Problem"? ==> UFF! Nö, im Fall des Falles nur für die Telemetriedaten von TelMe selbst.
(Es ist schon ein dickes Ei, nicht auf den Master zu hören, aber genau dieser Master (die eher weniger gute Tatsache, dass EXbus auch kein Bus ist), verhindert Schlimmeres.)

Wir lernen etwas dabei in Bezug auf den "EXbus". Er ist auch virtuell im Empfänger kein "Bus". Er ist ein separiertes Protokoll (immer dasselbe, natürlich) auf jedem Port des Empfängers, der als EXbus deklariert ist. Den Begriff "Bus" kann man lediglich dahingehend gelten lassen, das so eine 2-Punkt-Verbindung nun bidirektional sein kann, Kanaldaten in die eine Richtung, Sensordaten in die Gegenrichtung. Es ist sogar so, dass das Senden der Kanaldaten die Voraussetzung für die Gegenrichtung (Sensor->Rx) ist, der Synchronisationspunkt (den TelMe so schofel behandelt). Dieses Verfahren ist eine von zwei Alternativen auf 1-Wire, auf jeden Fall synchronisieren die Aussendungen des Masters. -- Es ist auch so, dass die beiden Baudrates, 125/250kBd, für die das am Rx EXbus Port angeschlossene Gerät adaptiv reagieren muss, pro Port gewählt werden. Ein Bus mit zwei unterschiedlichen Geschwindigkeiten gleichzeitig, das wäre dann eh kein Bus. (TelMe unterstützt die adaptiv zu wählende Baudrate von 250kBd nicht, nur fixe 125kBd. Das könnte evtl. später Probleme bereiten, wenn ein EXbus Master 250kBd vorschreibt, indem er sie spricht. Bis dato scheinen alle JETI Master selbst nur 125kBd zu verwenden.)
-------------------

Zu Letzterem: Bzgl. eigener Daten, deren Update Rate und auch Darstellung, tut TelMe genügend andere weniger nützliche Sachen:

1) Die Definitionen für die EX Displays (Name, Unit (beides Strings), Binärtyp des Displays) müssen alle "Jubeljahre" einmal alle gesendet worden sein (eine Definition pro Paket versendet), dazu auch der Equipment Name (wie "JIVEpro..."). Das wird eigentlich jeweils nur einmal benötigt, nämlich, wenn das Terminal (Sender, Profibox) den Sensor zum ersten Mal lernt. Danach ist das eigentlich egal, aber das kann ein Sensor (TelMe) natürlich nicht riechen.
In der Praxis hat sich "alles einmal gesendet innerhalb 10 Sekunden" als hinreichend erwiesen, - selbst mehr Zeit dafür wäre noch ok. 10 Sekunden sind viel, was man in 10 Sekunden an Nutzdaten senden kann!
TelMe hat diese Regel nicht. Man sendet die Definitionen gleichberechtigt mit Nutzdaten. Da es wesentlich mehr Definitionen gibt als Nutzdatenpakete (binär), nämlich genau zwei, stiehlt dieses unüberlegte Verfahren massiv Update Rate der Nutzdaten.

2) Kommt noch etwas hinzu, fast schon Peanuts, weil "nur" ein weiteres Paket, was keine Nutzdaten enthält: Man bedient auch die Textbox, obwohl man keine produktive Anwendung dafür hat (Status, Setup), da steht nur statisch irgendwas mit "Kontronik" drin.

Die Wirkung sieht man in Anhang 6ff: Unnützerweise verwendet JETI ein Timeout, was, gemessen am Timing der Protokolle, a) Text in EX, b) EX in EXbus, c), wenn ein Expander E4 EX verwendet wird, nicht erst seit EXbus eigentlich zu knapp bemessen ist: ca. 100ms, in den alten JETIboxen (Mini und "Presskohle") hat man sogar ein "Vor-Timeout" von nur 80ms.
Man sieht, zumindest meine Profibox (habe leider keinen JETI Sender als Terminal) fällt stochastisch immer wieder in Timeout ("-------").

3) Was man noch sieht, zumindest in den Displays der Profibox zeitigt es Wirkung: Die Strings der Display-Namen sind zu lang. Sie rutschen dadurch über ihr Limit und in den nächsten String für den Namen der "Unit". Sieht unschön aus. (Wie ist das auf Euren Sendern?)

-------------
Da sich TelMe (die Firmware im ESC) eh wenig an das Protokoll hält, da es ein Gespräch unter 4 Augen ist, weil die Data Update Rate durch o.g. so in Mitleidenschaft gezogen ist, - verstößt S32 nun (seit 1.38) absichtlich selbst gegen das Protokoll, indem er "TelMe" mit der doppelten Frequenz zum Senden veranlasst. Das passt noch in's Timing der Line, es funktioniert, und ein Impact auf die übrige Firmware des ESC ist auszuschließen. Wäre er es, dann hätte man richtig was falsch gemacht, was ich nicht glaube.
Heißt, im Gespräch mit S32 hat TelMe die doppelte Rate im Update der Nutzdaten. Das ist auch nötig.

_________________
Tom