(Aug-3 2013) Schon wieder neue Firmwares von Graupner/SJ…
Es gibt ja schon immer im Protokoll die etwas seltsame Vorschrift, dass ein Sensor seine Datenbytes nicht hintereinander senden darf, wenn er angefragt wird, er muss einen Abstand von 2ms zwischen den Zeichen lassen. Mit den neuesten Firmwares der Sensoren von Graupner/SJ hat sich das geändert, zwar nicht grundsätzlich, aber es sind nun nur noch ~0,5ms. Die Abfragefrequenz hat sich nicht geändert, alle 200ms im Binärmodus. Bisher hat durch die 2ms ein Sensor fast den gesamten Time Slot von 200ms benötigt, um seine Daten auszusenden, jetzt sind es nur noch ca. 50ms. Eigentlich schwer vorstellbar, welchen positiven Effekt diese neuerliche Änderung haben soll.. – Erst seit Kurzem ist endlich der Bug weg, dass die Sensoren (ihre Adressen) nicht gleichverteilt rundherum abgefragt werden. – Nun hat Kamil (“MeiT”) heute noch mal gemessen: Befinden sich Sensoren mit obiger geänderter Firmware zusammen mit Sensoren auf dem Bus, die noch der bisherigen Vorschrift von 2ms Pause zwischen den Byte-Aussendungen gehorchen, hat das den Effekt, dass der alte Bug wiederkommt: Die Sensoren werden nicht mehr gleichverteilt abgefragt im 200ms-Rhythmus, Sensoren mit 2ms-Pausen sind benachteiligt. — Der benachteiligte Sensor wäre also im Augenblick auch JLog, wenn sich Sensoren von Graupner/SJ mit neuester Firmware parallel auf dem Bus befinden.
Etwas widersprüchlich bzw. offensichtlich nicht stimmend sind die Aussagen von Graupner/SJ zu notwendiger Firmware für den Empfänger (bzw. auch Sender) für die neue (evtl. sinnlose) “Highspeed-Variante”.. Kamil stellte fest, dass das offenbar egal ist.
Mir wird also nichts anderes übrig bleiben, als schnellstens sämtliche JLog-Firmwares für HoTT auf 0,5ms-Pausen umzustellen und im Download zu erneuern. Dafür meinen Herzlichen Dank an Graupner/SJ!
——————————————————————————————————————————-
(Jun-1 2013: Seit ein paar Tagen gibt es einen Update der Senderfirmwares, in denen der Sensorscan beim Startup des Senders auf ca. 10 Sekunden verlängert wurde. Das u.g. Problem existiert somit nicht mehr. Beispiel, mx-16: Letzte Firmware ohne automatischen Sensorscan: 1.722/1.724. Erste mit Sensorscan, aber viel zu kurz: 1.726. Korrigierte Version mit verlängerter Scanperiode: 1.731. Graupner/SJ hatte sofort reagiert. Danke!)
——————————————————————————————————————————-
Alternative Firmwares (siehe Download) erlauben nun auch, JLog2 an Stelle des Sensors “GAM” als neuen HoTT Sensor “ESC” grafisch erscheinen zu lassen (Binärmode-Sensor). Der Sensortyp “GAM” wird damit frei auf dem Bus.
Das Text-Mode-Display, nun unter “ESC” adressiert, bleibt identisch zur bisherigen Ausführung.
Zu beachten ist: Der bisherige HoTT-Sensor “ESC” hat nicht nur ein anderes Erscheinungsbild, auch seine Datenstruktur ist völlig anders als beim neuen. JLog2 unterstützt auch den alten “ESC”, siehe Download. Wegen Platzmangel im ROM (Programmspeicher) konnten die drei Sensordispays leider nicht per JLC wählbar gemacht werden. Der neue “ESC” ist Bestandteil der Firmware für Sender/SmartBox, die Graupner kurzzeitig am 10.April 2013 im Download hatte, dann aber wieder entfernte. Das erfolgte aus technischen Gründen, nicht wegen Bugs. Diese neue Firmware wird sicherlich bald wieder in Graupners Download erscheinen.
Um jetzt seitens who-is-who identifizieren zu können: Den alten “ESC” gab es seitens der mx-16 bis Firmware 1.722/1.724, den neuen nun ab 1.726.
Hier das grafische Display (Binär-Mode)
Offenbar hat man irgendwann das von Vielen ungeliebte Hochpoppen der Subdisplays zum Sensor im Alarmfalle disabled, jedenfalls passiert das nicht beim “ESC”, weder beim alten (Pre-Release, lt. Graupner noch “inoffiziell”) noch beim neuen.
Alarmbehaftete Werte werden invertiert dargestellt (die entsprechenden Felder, kommandiert JLog).
Hier, wie das aussieht, und die Subdisplays:Mit der neuen Firmware hat sich noch mehr geändert: Sensoren auf dem Bus werden jetzt automatisch erkannt. Das betreffende Menü im Setup des Senders ist daher nur noch ein Display, man kann nichts mehr manuell machen. Um das Automatische zu gewährleisten, poll-et man offenbar stets alle Sensoradressen, darum hat sich auch die Abfragefrequenz erhöht (angeblich) durch den Busmaster, den Empfänger. (Fürchte, ich muss schnell mal meine Bequemlichkeit überwinden, und den Logic Analyzer gucken lassen.)
Daraus scheint für einige 3rd-Party-Sensoren ein Problem zu erwachsen, wie eben festgestellt, auch für JLog2: Es ist eben nicht so, dass ständig ALLE Sensoradressen ge-poll-et werden für diesen Automatismus zum Finden angeschlossener Sensoren. Es sieht so aus, als würde der Sender bei seinem Startup nur einmalig den Empfänger dazu animieren, danach fragt er nur noch gefundene Sensoren ab via den Empfänger. “Gefundene” heißt, Sensoren, die in dieser kurzen Zeitspanne antworteten. Also, Sender an, dann das Modell anschalten, Empfänger und Sensoren starten. JLog hat hier ganz offenbar ein Problem, denn er braucht einen Augenblick im Bootloader, um die SD zu mounten und nach einem möglichen Update zu schauen. – Arrghhh! Schon wieder so ein Käse, SPEKTRUM/TM1000-XBus hatte schon gereicht (–>JSPEK bzw. Workaround im Bootloader, um den TM1000 aufzuhalten).
Was hier hilft, ist, den Sender zuletzt einzuschalten oder noch mal aus/an. Aus alten HF-Zeiten sagt man: Niemals nicht, tu’ das nicht. Mit den Übertragungs-/Modulationsverfahren auf 2G4 kann man das aber bedenkenlos.
*) Wen die Details interessieren, am Ende des Artikels.
Was geht JLog2 verloren, wenn er anstatt als “GAM” als “ESC” in HoTTv4 betrieben wird?
JLog-eigene Sensoren: Nur noch eine externe Temperatur, kein Display für die externen Temperaturen 2..5 und die externe Drehzahl. (Allerdings waren die Darstellungsmöglichkeiten dafür mit “GAM” eh nicht so rosig.)
Die Fuel Gauge gibt es nicht in “ESC”. (Die Gauge im “GAM” ist eh nur 4-stufig.)
Ich könnte jetzt einen der beiden Balken, “Strom” oder “RPM”, weil für diese der jeweilige Maximalwert durch den Sensor (JLog2) einstellbar ist, wunderbar und viel granularer als im “GAM” als Fuel Gauge mißbrauchen. Natürlich stimmte die Maßeinheit nicht, “A” oder “rpm” statt “mAh”, das wäre aber nicht schlimm. Allerdings gäbe es dann keine Möglichkeit, “Strom” (Imot) bzw. “RPM” (rpmUni==Rotordrehzahl) anderweitig im Display unterzubringen, je nachdem, welchen der beiden Balken man sich für eine Fuel Gauge abzweigt. Meinungen sind gefragt (–> JLog-Forum), der Programmierer (ich ) führt’s aus. Da der Motorstrom in einer Telemetrie, gerade in visueller Form, doch eh nur Mäusekino ist, man aber eine Drehzahl eher mal gebrauchen könnte, würde ich jedenfalls bevorzugen, wenn, dann Imotor und seinen Balken für eine Fuel Gauge zu opfern. - In den Subdisplays bliebe der geopferte Wert auch nicht erhalten.
—————————————————————————————
Autosensing in HoTT Senderfirmware ab … (1.726 für die mx-16):
Der Sender ist an. Dann wird der Empfänger nebst Sensoren bestromt, 345ms nachdem der Empfänger Spannung bekam, fängt er an, die Sensoren auf dem Bus abzufragen: “Wer da?”
Er fragt jede Adresse 3x, bzgl. Adresse 0×89 konnte wohl einer nicht zählen bei SJ, die fragt er nur 2x. Manchmal fragt er auch die erste Adresse nur 2x ab. Der Abstand der Abfragen (HoTT Binärmode (–>grafische Displays) ist geblieben, alle 200ms:
Nach (4 x 3 +2 -1) x 200ms == 2,6s ist der Spuk vorbei, 2,9s nach Powerup des Empfängers, wenn der den Sender sieht. Ein Sensor, der nicht anwortete in seiner Zeitspanne von 600ms, wird nicht mehr gefragt.
Die schlechtesten Karten hat der HoTT-Sensor “ESC”, nach 345ms, spätestens ca. 700ms nach seinem Powerup, muss er antworten können, letzte Chance.
Das wird für 3rd-Party-Sensoren ein Problem darstellen können, für JLog allemal. Er ist nach Powerup zunächst im Bootloader, der muss erst die SD mounten und nach einem evtl. Update schauen, er ist also von der Geschwindigkeit des jeweiligen Exemplars SD Card abhängig. Außerdem braucht JEDE SD Card etwas Zeit nach Powerup, die muss man ihr geben.
Das Problem hatten wir schon mit dem TM1000 von SPEKTRUM, der startet seinen Sensor-Scan auf dem X-Bus (I²C) unmittelbar nach Powerup, obwohl ohne Zeitnot, die blanke Unüberlegtheit. Nur konnte man hier mit relativ einfachen technischen Mitteln heilen, indem man den TM1000 aufhält, den Bus blockiert, man zieht eine Leitung (SCL) auf Low. Hier, auf dem asynchron-seriellen Bus von HoTT, erforderte das wesentlich mehr Aufwand.
Das ist untragbar und vollkommen unnötig! SJ muss das ändern!
————
Den Scan führt natürlich der Empfänger durch, er ist Busmaster. Zu einem Scan wird er animiert, wenn er Connect zum Sender bekommt, der vorher nicht bestand. Das ist der Fall nach Powerup des Empfängers, Sender bereits an, oder wenn der Sender erst hinterher eingeschaltet wird bzw. noch mal AUS/AN. —-> Hier liegt der Workaround: Sender später einschalten oder noch mal AUS/AN.
Ich habe jetzt den applikativen Teil der Firmware von JLog2 so geändert, dass er wenigstens dann schnell genug ist, wenn er ohne SD Card gestartet wurde, die SD kann man hinterher reinstecken. Ich werde aber erst morgen, 16.April, die beiden Firmwares im Download austauschen. Der Workaround, den Sender hinterher einzuschalten, oder eben später noch einmal AUS/AN, gefällt mir aber noch am besten, Erstere am allerbesten. Man muss eben nur die Failsafes im Empfänger richtig gesetzt haben.
Noch mal der Hinweis, das hat nichts mit “ESC” zu tun, sondern rein mit dem mit der neuen HoTT-Senderfirmware eingeführten Autosensing, JLog2 wird also als “GAM” damit dasselbe Problem haben. Heilen, wenn SJ nichts tut, lässt es sich wieder nur durch eine Änderung im Bootloader oder eine extra Hardware, die während des Scans statt JLog antwortet. Na schönen Dank, das SPEKTRUM-/TM1000-Unsinnssyndrom erfährt eine Renaissancedurch HoTT.. Sollte daraus eine Änderung des Bootloaders künftig gefertigter JLogs erwachsen, dann werde ich generell solchem Quatsch vorbauen, indem das Flashen von der SD im Bootloader erst durch einen Jumper freizuschalten ist. Damit startet JLog im normalen Betriebsfall immer unmittelbar die Applikation, so, wie es die vergleichsweise primitiven Sensoren des Herstellers tun, die ja den Unsinn eines überhasteten Scans abkönnen.
————
17. April 2013: Habe eben die Firmwares R62 und R72 ausgetauscht. Alles Firmwares mit HoTT-Telemetrie können nun als Workaround dienen, indem man JLog2 ohne SD startet. Er ist dadurch schnell genug, weil der Bootloader ja keine SD sieht. Die SD kann man hinterher reinstecken. Was ein Novum ist für JLog: Man kann aber auch ganz ohne SD weiterbetreiben, dann gibt’s natürlich kein Logging, aber das Data Processing wird trotzdem durchgeführt, und die Telemetrie wird gefüttert. JLog als HoTT-Sensor “GAM” geht auch mit der HoTT-Senderfirmware vom 10.4.2013, JLog als HoTT-Sensor “ESC” muss als neuer “ESC” betrieben werden, wenn der Sender die o.g. neueste HoTT-Firmware fährt. Die JLog-Firmwares sind natürlich bzgl. älterer HoTT-Senderfirmwares abwärtskompatibel, JLog2 als “ESC” muss dann logischerweise als alter Sensor “ESC” betrieben werden.
Inzwischen ist klar, dass Graupner/SJ demnächst einen Fix in den HoTT Senderfirmwares bringen wird, der das Autosensing, den Scan nach Powerup, auf 10 Sekunden ausdehnen wird. Damit wäre das Thema aus der Welt.
) führt’s aus. Da der Motorstrom in einer Telemetrie, gerade in visueller Form, doch eh nur Mäusekino ist, man aber eine Drehzahl eher mal gebrauchen könnte, würde ich jedenfalls bevorzugen, wenn, dann Imotor und seinen Balken für eine Fuel Gauge zu opfern. - In den Subdisplays bliebe der geopferte Wert auch nicht erhalten.