Nightmare…

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

“throttle relative”, berechnet durch meinen Datenempfänger an Link Serial:
Wie man sieht, werden ganz schmerzlos auch Werte ausgegeben durch Link Serial, die völlig sinnlos sind, hier PWM>100%:
RPM: Der Mist beim Anlauf wird nicht unterdrückt, obwohl der ESC der Herr über die PWM ist. Wenigstens der CSL hätte das ausblenden können per einfacher State Machine, wie es JLog schon immer macht. – Der Peak am Ende kommt durch das abrupte Gaswegnehmen, sollte aber nicht sein:
Ausreißer.., CSL gibt es einfach weiter per SPI. Der stromproportionale sofortige Anstieg ist eine Fehlmessung im ICE durch schwimmende Masse. Das Lookup Table im CSL ist katastrophal ungenau, wie man sieht, – auch Steps von 5 Grad Celsius in diesem Bereich:
Das ist meine Berechnung der Temperatur aus den raw NTC Daten:
Wie man sieht, auch hier Ausreißer:
Selbst hier.., obwohl es bis dato gar keinen Castle ICE/EDGE mit linearem Temperatursensor gibt:
Die ICE liefern kein Ubec, – angeblich sollen das jetzt die EDGE können. Der CSL gibt seine Irrtumsmessungen des Impulses ungeniert aus:
..
Tja.., was ist da los?… Was soll so ein beschworenes Device wie Link Serial, warum juckt es Castle nicht, dass dieses überteuerte Ding praktisch unbrauchbar ist, wenn man als Anwender nicht all das tut, was JLog machen muss?
Wir fürchten, die Antworten werden uns klar vorgelegt..
Schauen wir uns doch mal nur die Platine des 90-Dollar-CSL an:
*Räusper*
Hier dessen Manual.
Ich muss zugeben, ich war schon pappensatt, bevor der CSL die etablierte Castle Link Katastrophe ausgeben durfte:
- Ein asynchron-serielles Protokoll mit TTL-Pegel wird als “RS232″ bezeichnet
- Ein einzelner Servoimpuls ist “PPM” nach Auffassung von Castle. Nun ja, es gibt Verwandtschaft.
- Ob die 16Bit-Register Little oder Big Endian appliziert werden, darüber schweigt man sich aus. Probier’ doch..
Das Ding hat 3 Interface-Optionen “nach hinten weg”, I²C, asynchon-seriell , 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.
Irgendwie drängt sich der Verdacht auf, dass Castle “Qualität” ganz klein schreibt, Hauptsache günstiger Verkaufspreis, alles andere ist egal. Der Preis wird die Käufer überzeugen. OK, da ist was dran. Aber dann, liebe Leute, warum soll sich JLog damit abplagen, sich gar noch in Verdrehung der Tatsachen als der “Pfuscher” hinstellen lassen, obwohl es doch eher andersherum ist?
So sehen Platinen von Castle ESCs aus, alle! Einige Bauelemente sitzen sogar systematisch auf Halbsieben, immer dasselbe in derselben Position.
Das sieht aus, als hätte man die Bauelemente mit dem Salzstreuer auf der Platine platziert, und viele Lötstellen sehen aus wie kalt. So etwas wird bei den meisten Fertigern nicht mal unter verwertbarer Ausschuss durchgehen, es fände seinen direkten Weg in die Tonne.  –  Made in Kansas? Hmm.., deren Pick & Place Machine kann eigentlich nur so aussehen.
Aber auch im Design scheint es zu hapern, bzw. ist es Castle schlichtweg egal. Der ICE 40HV hier verwendet einen Low Side Shunt zur Strommessung auf Batterieseite dergestalt, dass sich die Masse der Messungen “anhebt”, sobald Strom fließt. Sprich, Ubat, was ohne Strom schon mal 22,3 statt realer 25,0V zeigt, steigt, sobald Strom fließt, obwohl die Spannung in Wirklichkeit etwas sinkt. Gleichzeitig haut die Temperatur ab in’s Phantasia Land, um wieder in den Bereich der “Castle-Genauigkeit” zurückzufallen, wenn kein Strom mehr fließt. Also,… ich finde so was schon etwas dreist.
Gibt es noch irgendwas zu wundern?
Wir werden den Castle ESC Support in JLog belassen, wir können aber nur jeweils auf das Obige hinweisen, eine Funktionsgarantie kann es nicht geben. Da kann man als Anwender nur an der “Castle Lotterie” teilnehmen bis es denn funktioniert. Viel Glück!
Es scheint aber auch viel mit dem Setup des jeweiligen Anwenders zu tun zu haben, diese “analoge” Impulsgeschichte des Castle Link Live kann nun mal leicht durch Erdschleifen und Einkopplungen von Leitungen, die von viel impulshaftem Strom durchflossen werden (Motor, Akku), gestört werden.
Beispiel: Markus aus der Schweiz hat einen CC120HV, und bei ihm wollte das auf der ganzen Linie nicht ticken, regelrecht megakatastrophal. Nun ist sein ESC bei mir, und, abgesehen von den üblichen systematischen Fehlern (teilweise fehlerhafte Daten, die der CC tatsächlich so sendet) und einer Temperaturausgabe, die extrem daneben ist (obwohl sie im CC-Log stimmt), – tickt sein CC bei mir absolut rund.
Außerdem scheint so Mancher das Problem zu haben, dass seine Gasimpulsquelle, Empfänger oder FBL, eine zu hohe Impulsfrequenz verwendet, er aber nicht weiß, wie er das überprüfen bzw. verändern soll. Johann durfte das letztendlich auch herausfinden, nicht wahr, Johann?

Die Kommentarfunktion ist geschlossen.