Es ist wohl leider an der Zeit, mal ein klares Wort dazu zu sagen. Zumal Castle Creations sich nun hinstellt und einfach behauptet, ihre Produkte seien 100%ig OK, es läge allein am 3rd Party Device, an JLog.
Nun, wer im Glashaus sitzt.. Andererseits kann uns das auch egal sein, schließlich ist es nicht unüblich, erst mal sein Produkt zu verteidigen nach außen. Andererseits steht für mich, steht für R²Prototyping die Frage, ob man die Castle Creations ESCs (momentan die ICE und EDGE Serie) überhaupt noch unterstützt durch JLog.
Seit geraumer Zeit kann so ein Castle ESC als Multisensor an JLog betrieben werden, Datenlink via Castle Link Live. Es gab ein paar praktische Erfahrungen durch User, aber erst seit diesem Sommer geht das mehr in die Breite durch einen wachsenden US-Markt. Die ersten Erfahrungen waren nicht alle positiv, immer wieder musste in JLog “Heilung” nachimplementiert werden, weil ein Exemplar eines ESC Modells, was eigentlich als erfolgreich getestet galt, seltsame Effekte unzuverlässigen Funktionierens mit Castle Link Live zeitigte. Weitere “Heilung” wurde in JLog eingebaut, Datenkorrekturen, um fehlerhafte Ausgaben des ESC oder Datenübertragungsfehler zu kompensieren.
Seit nun viel mehr Anwender JLog mit Castle verwenden, US-Markt eben, stellt sich so allmählich heraus: Es hat kein Ende, es findet sich keine Systematik, jedes Exemplar Castle ICE oder EDGE kann ein neues Problem mitbringen. Somit sind wir mittlerweile an der Stelle angelangt, die Flinte in’s Korn werfen zu müssen. Jedem Anwender, der vorab fragt, weil er sich mit dem Gedanken trägt, einen Castle ICE/EDGE an Jlog zu betreiben, um hierin einen Telemetrie-Gateway zu haben, können wir nur lakonisch antworten: Es könnte problemlos funktionieren, es könnte funktionieren, aber mit Problemen, es könnte u.U. gar nicht funktionieren. Wir hoffen, Du wirst Glück haben mit Deinem Castle..
Castle Link Live würde ich eigentlich als Notlösung bezeichnen, um ohne wesentliche Hardwareänderung ESCs mit einem Datenlink auszustatten. Doch leider zeigt sich anhand neuer Modelle von Castle, dass die “Notlösung” eine etablierte Lösung ist. Ich hätte eigentlich gedacht, dass man alsbald auf ein Standardprotokoll geht, mit mehr Störsicherheit, Asynchron-Seriell oder I²C oder irgendein 1-Wire-Protokoll, dessen atomare Information auf digitalem Pegel beruht. Leider gefehlt..
Was ist Castle Link Live?
Das Prinzip beruht darauf, dass der Gaseingang des ESC nach jedem Gasimpuls zum Impulsausgang wird, der ESC sendet einen Datenimpuls für einen der Datenwerte, die er liefern kann, Ubat (Batteriespannung), z.B. Der Informationsgehalt steckt in der Zeit, die zwischen dem Ende des Gasimpulses und dem Erscheinen des Datenimpulses vergeht. Aus nicht ganz nachvollziehbaren Gründen, vermutlich, um in einem ESC mit BEC einfach nur einen Pullup (“Hochzieh-Widerstand”) verwenden zu können, muss der Gasimpuls für Castle Link Live invertiert geliefert werden. “Invertiert” hat nichts mit dem sonst bekannten “Reverse” (Sender) zu tun, es heißt einfach: Aus LOW wird HIGH, aus HIGH wird LOW. Das kann kein Empfänger, FBL-System oder irgendein anderer Standardlieferant von Gasimpulsen, dass muss das Gerät, das mit einem Castle ICE oder EDGE Castle Link Live sprechen will, selbst machen, – also hier JLog. (Hat man in seinem ESC per Castle Link (USB Interface) Castle Link Live aktiviert, versteht der Steller nur noch invertierte Gasimpulse, also nichts mehr vom Empfänger oder FBL.)
Was Castle nicht sagt, was man aber beachten muss: Die Frequenz des Gasimpulses ist nicht beliebig, es sollte die Standardfrequenz sein (50Hz, alle 20ms ein Gasimpuls), maximal aber 100Hz. Der Grund ist, dass ja der zeitliche Abstand des Datenimpulses vom Ende des Gasimpulses durch den ESC die Größe eines Datenwertes definiert. Das Maximum laut Protokoll ist 5ms, davor liegen aber noch 0,5ms Grundabstand, die zum Abgleich der Zeitbasen, – ESC, Datenempfänger (JLog), – verwendet werden. Also brauchen wir mindestens 5,5ms Platz zwischen zwei Gasimpulsen, mit etwas Reserve für Mode-Umschaltungen und Murphy ergo wenigstens 6ms. Ich würde sagen, besser 10ms, also maximal 100Hz Gasimpulsfrequenz. Castle scheint das Maximum tatsächlich im ESC auf 5ms zu begrenzen, obwohl es teilweise direkt nötig wäre, über 5ms zu gehen: Nach der vom Protokoll Castle Link Live definierten Formel für die Berechnung des Wertes “RPM” (Drehzahl) reichen die 5ms eigenlich nicht: Der “Scale” für RPM ist 20.416,7 (pro Millisekunde), damit ist der maximal mögliche Wert 102.083,5. Der Drehzahl-Output ist 2-pol-normalisiert, für einen 14-poligen Motor wären das, geteilt durch 7, 14583 UPM im Maximum, was etwas wenig ist… Aber offenbar besteht diese Einschränkung, mit hochpoligen Motoren hat man u.U. Pech.
Dass so ein Protokoll ziemlich störanfällig ist, liegt auf der Hand, es handelt sich gewissermaßen um ein “analoges Protokoll”. Jedenfalls gibt es keinerlei Chance für einen Integritätscheck, wie er potentiell mit jedem Protokoll möglich ist, das ein digitales Pegelschema verwendet, LOW, HIGH. Jede Verschiebung des Referenzpegels, also auf der Masse (die berühmten Erdschleifen, die sich Viele unbemerkt bauen..), jede Leitungseinstrahlung auf die “heisse Seite” kann dazu führen, dass ein Zombie-Impuls gelesen wird, oder der Datenimpuls wird nicht zeitrichtig oder gar nicht gelesen.
Nun fragt sich nur, warum manche Exemplare eines ICE/EDGE teilweise massive Fehlwerte zeitigen. Offenbar werden diese schon so ausgesendet, sprich, die Zeit spielt ja eine Rolle, zum falschen Zeitpunkt ein Datenimpuls durch den ESC gesendet. On top kommt, dass Daten direkt falsch im ESC gebildet werden, bevor sie zur Aussendung kommen. OK, das ist leider nicht unüblich, ein JIVE macht so was auch zur Genüge, sogar ein KOSMIK tut es bzgl. RPM im Anlauf. Aber das sind systematische Fehler, die kann der Datenempfänger mittels einer State Machine kompensieren, – obwohl man schon erwarten würde, dass der Hersteller seinen ESC erst gar keine Hausnummern als Daten liefern lässt, zumindest, wenn man so vollmundig wie Castle auf die Fehlerfreiheit seiner Produkte pocht. Nun, JLog implementiert so eine notwendig werdende State Machine von Anfang an, eigentlich kein Grund, sich darüber zu ergehen. Wie gesagt, das sind systematische Fehler, die kann man immer “ausbügeln”.
Nun zeigen sich aber immer massiver stochastische Datenfehler, je mehr Anwender einen Castle ESC mit JLog einsetzen, Fehler, die möglicherweise auf der Übertragungsstrecke entstehen, vielleicht aber schon vorher. Und interessanterweise sind diese Fehler in den einzelnen Fällen aber weder generell auf das jeweilige Setup zurückzuführen, noch kann man es an bestimmten Modellen eines ICE/EDGE festmachen, jedes Exemplar desselben Modells kann sich anders verhalten.
Das Spiel, JLog weitere Toleranz gegenüber solchen Datenausreißern einzuhauchen, wurde immer weiter getrieben, letztendlich, für mein Empfinden, in einem Maße, was eigentlich zu weit geht. Irgendwann handelt man sich dadurch Nebeneffekte ein, vor allem, wenn man Daten erst sammeln muss, um sie zu bewerten, die Schlechten in’s Kröpfchen, die Guten in’s Töpfchen, ähh, Log, Telemetrie und Alarming. Die ohnehin nicht überragende Latenz (alle 240ms ein Datensatz, wenn die Gasimpulsfrequenz Standard ist, 50Hz) wird dadurch bereits maßgäblich zusätzlich verschlechtert, wir sind inzwischen schon bei 1 Sekunde bei Standardfrequenz angelangt. OK, das reicht eigentlich immer noch für den Hauptzweck von Telemetrie (Alarme), und im Log gleichen wir es durch Integration aus, damit die Kurven in LogView/DataExplorer immer noch “smooth” aussehen. Aber leider scheint das immer noch nicht zu reichen, es gibt zu viele “Pechvögel”, die einen Castle ESC erwischten, dem selbst so ein hohes Maß an Fehlertoleranz nicht genügt.
Es scheint auch so zu sein, dass HV-Typen mehr Probleme zeitigen als LV-Typen. Ein HV hat kein BEC, er hat zwei Optokoppler am Gassignalanschluss, Gas rein, Datenimpuls raus. Offenbar haben manche Exemplare ein Problem durch den Optokoppler im Gaseingang, wenn der Gasimpuls invertiert geliefert wird, Castle Link Live aktiviert wurde. Das zeigt sich evtl. durch kurze “Anlaufversuche”, nur ein ganz kurzer “Hack” durch den Motor, nicht mal eine hundertstel Umdrehung, bemerkbar, wenn das Ganze lange mit Gas Null rumsteht. Es scheint sich besonders bemerkbar manifestieren zu können, wenn man den Castle ESC durch einen externen “Governor” ansteuert.
Jedenfalls sind wir angesichts der Stochastik, dem unterschiedlichen Verhalten der ESCs je nach Exemplar, so langsam am Ende mit unserem Latein. Liegt es wirklich nicht an uns, an JLog? Nun, offensichtlich im Gegensatz zu Castle, sind wir immer erst dabei, selbstkritisch heranzugehen, nach Fehlern bei uns selbst zu suchen. Der momentan verwendete Prozessor in JLog2[.5] hat kein priorisierbares Interruptsystem, es ist aber eine Vielzahl von Interruptroutinen parallel auszuführen. Somit kann die eigentliche Primitivaufgabe, den Gasimpuls zu invertieren, zu einer “Challenge” werden, was die Zeitgenauigkeit des Erkennens der Gasimpulsflanken im Eingang betrifft. Daher wurde hieran im Zuge der letzten Überarbeitung der Implementierung von Castle Link Live in JLog noch mal “gefeilt”. Das Ergebnis ist nun fast Zeittreue, nur in den Firmwares, die als Telemetrie Futaba oder JETI EX bedienen, gibt es noch einen minimalen Jitter des Gasimpulses im Ausgang, der aber maximal 1..2% erreichen kann.
Es wird immer aufwändiger.. Wie klärt man nun die “Schuldfrage” an diesen stochastischen Erscheinungsbildern? Diese Streuungen über die ESC-Exemplare scheinen auf Castle zu weisen, aber eigentlich untersucht man das in der Hoffnung, eine Idee für Abhilfe finden zu können. Im Klartext: Man hofft, im Grunde genommen, selbst schuld zu sein. – Wie macht man das? Es wurden Unmengen von Aufzeichnungen des Logic Analyzers ausgewertet. Es wurde etwas gefunden, und das bedeutet, es wird auch ausgesendet vom Castle ESC. Aber die endgültige Gewißheit kann so etwas nicht liefern, zu mühsam ist die Methode. Dafür bedurfte es eines Gerätes, was auf Anomalien triggern kann, nur leider kostet so ein Ding mehr als das Doppelte eines Kleinwagens.
Dann erschien Castle plötzlich mit einem neuen Gerät, “Castle Link Serial”. Eigentlich eine Zumutung angesichts seines Preises, $90 USD für ein Spielzeug. Egal, wir wollten es wissen, – wir wollten wissen, ob Castle selbst mit dem Castle Link Live klar kommt, wie es deren ESCs aussenden. Ein Castle Link Serial wurde gekauft, als ESC wurde ein Castle ICE HV40 verwendet. (Dieser ist die Ablösung eines anderen 40HV, selbes Modell, anderes Exemplar. Der ICE vorher war genau so ein Exemplar, was sowohl partout den invertierten Gasimpuls mißverstehen wollte, als auch, parallel und teilweise Folge der Gasimpulsprobleme, massivst fehlerhafte Datenimpulse lieferte. Als ich dann mal, stotternderweise und bei nur einigen Ampere Motorstrom, Halbgas gab, verabschiedete er sich mit Innenbeleuchtung, eine FET-Brücke hatte das Zeitliche gesegnet.)
Was ist Castle Link Serial? Mit meinen laxen Worten: Es ist ein Device für die Doofen und Faulen, in welchem der Meister Castle höchstderoselbst die Gegenstelle zum Castle Link Live Protokoll der ESCs implementierte, – man kann die Daten vom Serial Link über Standardschnittstellen abgreifen. Na bitte, darauf hatten wir gewartet, jetzt zeigt uns der Chef, dass und (hoffentlich) wie es geht. Super, das gibt Anlass, doch noch mal in uns zu gehen, und zu suchen, was wir anders, was wir eventuell falsch machten.
Der Check der Hardware des Link Serial, von dessen Schaltplan, war schon mal ein Schock: Oops, keine besonderen Maßnahmen, die gehen genauso “blind” an das Interface wie wir Zauberlehrlinge es mit JLog tun?! Wir hatten eine “trickhafte” Aufschaltung erwartet, etwas zum Lernen. Andere Details des Schaltplans, auf Seiten der Standardardschnittstellen, bewirkte etwas Kopfschütteln bei uns..
OK, dann mal ran an den Speck, – im Manual gleich Castle erkannt, bisschen geärgert, letztendlich einem Microcontroller das Sprechen mit dem Link Serial beigebracht. Nu lass knacken.. - Ich muss zugeben, ich hatte schon erwartet, dass es besser funktioniert, zumindest war es die Hoffnung, – und ich glaube, auch Linus tat das insgeheim.
Das Ergebnis war ernüchternd. Der Castle Link Serial zeigt dieselben stochastischen Datenausreißer, nur sehr viel mehr als JLog. Kein Wunder, denn Castle lässt den Link Serial völlig schmerzlos jeden Mist 1:1 ausgeben. Es gibt weder eine State Machine, die in bestimmtem Betriebszuständen des ESC systematisch falsch gesendete Daten korrigiert, noch ist irgendein Mechanismus implementiert, der Datenausreißer, tatsächlich gesendet oder Übertragungsfehler, kompensiert.
Castle Link Serial
, SPI. I²C funktioniert an sich, nur intern scheint es einen Bug zu geben, keine Kommunikation mit den (virtuellen) Registern, also unbrauchbar. Danke! Das Ding ist sein Geld wert.
