Der Inhalt eines Datenpakets ist bzgl. sog. "hidden messages", - ein Alarm, Textterminalnavigation, Display-Definitionen für EX Binärdaten, - flexibel. Auch die eigentlichen EX Daten erscheinen nicht immer in derselben Zusammensetzung, sie müssen sich auf mehrere Data Frames aufteilen.
Was in jedem Data Frame erscheint, ist der Text (32+2 Zeichen) für ein Terminal im Text Mode, - das gute alte JETI Protokoll.
Ein Terminal im Text Mode kann (muss nicht) empfangene Daten bestätigen. Eigentlich bestätigt es nicht wirklich, es sendet nur den Status seiner 4 Tasten innerhalb von max. 20ms nach Empfang des Textblocks. Das Ende des Textes ist ein Synchronisationsmarker im Protokoll. Damit kann das Terminal interaktiv werden: Der Sensor empfängt das Acknowledge in Form des aktuellen Tastencodes, kann anhand dessen den Inhalt des Textblocks ändern.
Das ACK ist ein Zeichen (Byte), die 4 Bits seiner oberen Hälfte sind Statusbits der 4 Tasten. Die 4 Bits des Lower Half Byte haben Low zu sein lt. Protocol Specs. Daran hat sich schon mal die Firmware der REX Empfänger von Anfang an nicht gehalten, - neben einer Baudrate aus dem Wald. Standard ist 9600Bd, JETI spezifizierte vorsorglich schon mal 9600..9800 (proprietärer Blödsinn, allenfalls 9500-9700 wären ok gewesen), die REX quasseln mit fast 9800Bd. JETI arbeitet mit 9 Datenbits plus Parity Bit. Ziemlich schräg, und das fiel JETI nun mit den REX selbst auf's Bein, weil sie jetzt ARM Prozessoren verwenden. Deren UARTs (serielle Interfaces) können max. 9 Bits inkl. Parity, das sind hier aber 10. Ergo mussten sie den UART in Software implementieren, weil das die ARM Hardware nicht kann. (musste ich auch, im S32 aka JLog3) *) Dabei haben sie Mist gemacht, - mit der Baudrate, mit dem ACK Byte.
Kommt on top, dass JETI seit Anbeginn einen anderen Bug um besagtes ACK pflegt: Erfolgt die Verbindung physisch via Empfänger ("Expander" in diesem) durch Connect zu "Mx", dann sendet der Empfänger auf seinem seriellen Telemtrieinterface solange Müll als ACK (wo er gar nichts senden sollte), bis sich ein Terminal via "Mx" mit dem Telemetrieinterface, also zum Sensor, verbunden hat. Es brauchte daher schon immer einen ziemlich trickreichen Workaround, damit der Sensor (JLog) nicht wie ein Zombie durch seine Displays navigiert, weil er Zombie Tastencodes empfing.
Bis dato war am Workaround der User beteiligt: "Press and hold DOWN to connect to JLog"
Durch die REX Empfänger, deren zusätzliche Bugs im Bereich des ACK, - auch dadurch, dass die REX nicht regelmäßig mit ACK auf einen Textblock reagieren, - war dieser Workaround (benutzt seit 2011) nicht mehr verwendbar. Ich tüftelte ziemlich lange und fand eine andere Methode, die den User nicht mehr einbezieht.
Erst kürzlich musste ich daran noch mal nacharbeiten und massig Firmwares für JLog austauschen.
Nun kommt die REX Firmware April 2016.., Version 1.02, und wir haben neuen Ärger mit dem Inhalt des ACK Bytes:
Der neue Bug besteht darin, dass der Empfänger das Ende des Textblocks nicht richtig detektiert, bzw. nicht darauf wartet, dass der Sensor die Leitung frei gibt. Das führt dann dazu, dass stochastisch mal ein ACK Byte durch den Empfänger (als Vermittler des Terminals) ausgesendet wird, was zeitlich in das Ende der Aussendung des Sensors (JLog) hineinrutscht.
Die Wirkung ist, dass durch diese Interferenz der Sensor Müll als Tastencode liest. Eigentlich sollte er hex F0 lesen (inaktive Tastenbits sind high), stattdessen liest er ein verstümmeltes ACK mit Tastencodes, wo keine auszusenden waren.
Ich benutze jetzt auch wieder das untere Halbbyte (seit REX maskiert, weil es entgegen Specs nicht immer auf 0 stand), um möglichst viele Anhaltspunkte dafür zu haben, erkennen zu können, ob ein empfangenes ACK nicht nur versaut war.
Das klappt ganz gut, aber natürlich nicht immer. Ein dummer Hazard Filter on top verbietet sich leider: >>Ich muss erst soundso oft eine aktive Taste gesehen haben, bevor ich sie akzeptiere.<<
Das kann man nicht machen, weil die Latenz zu hoch wird. Max. alle 100ms kann eine Taste kommen, aber der REX lässt auch gerne mal ein ACK aus. Der User wird durch einen Hazard Filter, dadurch Latenzen von 200..400ms bei der Tastenabfrage, in den Wahnsinn getrieben: Entweder passiert nix bei Tastendruck, oder es passiert zu viel, er rutscht über das Ziel hinaus.
Sprich: Die Maßnahme, um möglichst durch den neuerlichen Bug versaute Tastenkodes erkennen zu können, lindert das Leiden schon ziemlich. Es gibt aber keine Chance zur vollständigen Genesung allein aus JLog heraus.
(Es gäbe noch eine Möglichkeit: Cursor Links wird am meisten "emuliert". Der Sensor (JLog) könnte das generell ignorieren. Dann müsste man immer rechtsherum durch die Displays navigieren.., - oder ich verwende Cursor Up/Down statt Right/Left.., wobei die Zombimania von Up/Down erst noch zu testen wäre.)
-----
*) Überhaupt zeugen viele elektronischen Modellbauprodukte von mangelndem Know How ihrer Designer, Nichtwissen um State-of-the-Art und um Grundlagen... JETI: Was sollen 9 Databits + Paritybit zu einem Zeitpunkt, an dem längst klar war, dass 10 Bits Payload demnächst ein NoGo sein werden? Wieso nur ~9k6, wieso proprietäre Baudrate von 9k7? - Futaba S.Bus/S.Bus2 und JR: proprietäre Baudrates von 100k und 250k. Als hätte man noch nie was von Ableitung interner Taktfrequenzen gehört. - Futaba S.Bus/S.Bus2, FrSky S.Port: Was soll das Invertieren, high-aktive Pegel? Die Erfinder von RS-232 und V.24 vor Jahrzehnten haben Low-Active nicht durch Flaschendrehen bestimmt. -- Tja.., und dann kommen die Chinesen (DJI) und nehmen was zeitgemäßes, CANbus. Offenbar hörten die schon mal was von der Crux um single-ended Signalübertragung in Systemen mit viel Strom, sowie von Grounds Loops. Der Rest der ach so fortschrittlichen westlichen Welt kommt aus'm Muspott.
Ein selbsternannter Marktführer gar fördert das Bauen von Ground Loops durch einen horrenden Blödsinn am BEC-Ausgang namens "Master/Slave". (Dabei ging es nur darum, zu sparen, - ein manuell anzulötendes Kabel hätte einen höheren Wert in der BOM gehabt als zwei Servo-Männchen, die die Pick&Place Machine setzt. Ergebnis ist, dass dieser Master/Slave denselben Übergangswiderstand der Steckverbindung hat (nämlich 0,5+0,5=1), lediglich der Leitungswiderstand halbierte sich, vernachlässigbar gegenüber immensem Kontaktwiderstand. - Man baute einen weiteren Kontaktwiderstand ein, den der User per "Slave" zu kompensieren hat. Man weist ihn nicht auf das dabei entstehende Risiko von Erdschleifen hin, weil man es offenbar selbst nicht auf dem Radar hatte. Lange Zeit musste der User gar erst das Slave Kabel dazu kaufen. Bingo, da war man kreativ: BOM reduziert, Preis erhöht.)
Tja.., die Modellbauwelt ist doch oft noch eine heile Steinzeitwelt..
Das Schöne ist, die meisten Anwender bemerken es gar nicht. Sie bemerken nicht die Welten zwischen dem technischen Niveau ihrer Modellbauelektronik und dem eines anderen Lieblingsspielzeugs: Smartphone/TabletStatistik: Verfasst von dl7uae — 8. Apr 2016, 22:27
]]>