Mit diesem ESC wird es ein bisschen “komplizierter”, zu verstehen. Relevant sind nur Typen der Serien Castle Creations “ICE” und “EDGE”. Der ESC hat keinen extra physischen Port, um dort Daten auszugeben, stattdessen wird der gelbe Draht (“Signal”) des Servokabels dafür mitbenutzt. Weiterhin geht hierüber der Gasimpuls an den Steller, zwischen zwei Gasimpulsen gibt es aber einen Datenimpuls, der Daten aus dem ESC transportiert.
Das Ganze nennt Castle “Link Live”. Das Feature muss man zunächst mal erst einschalten im ESC, das geht per “Castle Link” USB Interface und die zugehörige PC Software. Hat man “Link Live” aktiviert, versteht der Steller keinen normalen Gasimpuls mehr, er will ihn stattdessen invertiert. Das hat nichts mit “Throttle Reverse” zu tun, wobei sich “langer Pulse” mit “kurzer Pulse”, die Enden des Stellbereiches tauschen, sondern es bedeutet, dass sich der digitale logische Pegel des Gasimpulses umdreht, aus “Low” wird “High”, aus “High” wird “Low”. Das macht kein Empfänger und kein FBL. Das muss derjenige machen, der den Datenimpuls des ESC empfangen will, also hier JLog.
So sieht der normale Gasimpuls aus dem Empfänger/FBL aus,
er wird JLog zugeführt, und so sieht er aus, wenn JLog ihn invertierte:
Zwischen zwei Gasimpulsen sendet der ESC seinen Datenimpuls, eine Nadel gegen “Low”, den “Tick”:
Der zeitliche Abstand des Datenimpulses vom Ende des vorangegangenen Gasimpulses ist das Maß für den Wert, der mit einem Datenimpuls übertragen wird. Es ist ein kleines bisschen komplexer, denn ESC und Datenempfänger (JLog) müssen noch ihre Zeitbasis abgleichen, genauer gesagt, JLog muss die Zeitbasis des ICE/EDGE lernen, damit er den durch den ESC gemeinten Zeitabstand verstehen kann. Uhrenvergleich, sozusagen.
Es gibt 11 verschiedene Datenwerte vom ESC, ergo 11 Datenimpulse. Der zwölfte “Impuls” ist kein Impuls, es ist ein ausgelassener Datenimpuls zur Synchronisation. Genauer gesagt, handelt es sich nur um 9Nutzdatenimpulse, zzgl. zweier Kalibrierungsimpulse:
Und hier noch mal der Daten-Nadelimpuls, etwas idealisiert, weil mit dem Logic Analyzer erfasst:
Das war eigentlich schon die ganze Theorie in Bildern. Jetzt geht es um die Schlußfolgerungen für Setup und Anwendung, um Anschlussweise und “Ecken und Kanten” des Übertragungsverfahrens:
Protokoll
Wie dargestellt, macht sich der Wert eines Datums vom ESC am Impulsabstand fest, Datenimpuls zu vorangegangenem Gasimpuls. Definiert ist ein Maximum von 5000 Mikrosekunden. Je Datentyp ist eine Umrechnungsformel gegeben. Der ESC beschneidet die Impulslänge tatsächlich hart bei 5000µs im Maximum. Der Wert “RPM” ist wie üblich 2-pol-normalisiert, der ESC gibt aus, was er vom Motor an Nulldurchgängen beim Kommutieren sieht. Castle spezifiziert max. 100.000 und einen Umrechnungsfaktor von 20.416,7 rpm/ms, was dann exakt max. 102.083,5 Umdrehungen/Min wären. Das wird aber zum Teil nicht ausreichen: Nimmt man an, dass ein Motor max. 25.000 dreht, und handelt es sich um einen 14-Poler, dann wären das bis zu 7*25.000=175.000. JLog akzeptiert Impulsabstände bis 8.572µs (entsprechend 175.000 rpm), nur sendet der ESC nicht mehr als 5000µs. Es kann also eng werden mit hochpoligen Motoren..
Ein Datenwert “Null” entspricht nicht auch einem Datenimpulsabstand von Null, sondern von 500µs. Somit wird ein Datenimpuls max. 5.500µs nach dem Ende des vorgegangenen Gasimpulses erscheinen. Nun hat noch der Datenimpuls eine gewisse Länge, und nach ihm braucht es einen Sicherheitsabstand zum Beginn des nächsten Gasimpulses, der ESC muss ja wieder auf Empfang gehen für den nächsten Gasimpuls, der Partner (JLog) seinerseits auf Senden, – sagen wir mal, wenigstens 500µs. Ein Gasimpuls hat laut Standard eine Mittenimpulslänge von 1.520µs, kann also max. 3.040µs lang werden. Manche Sender erlauben ein Verlängern um bis zu 25%, plus Ungenauigkeiten und Sicherheitsreserve haben wir dann wenigstens 4.000µs für den Gasimpuls einzuplanen. In Summe sind das dann 4.000+500+5000+500=10.000µs für den gesamten Frame, also 10ms Gasimpulsabstand, was einer Impulsfrequenz von 100Hz entspricht. — Man merke sich also: Die Gasimpulsquelle, Empfänger/FBL/…, muss so eingestellt sein, dass sie keine höhere Gasimpulsfrequenz als 100Hz verwendet! Am besten, man bleibt beim Standard, 50Hz. Das Ganze geht selbstverständlich davon aus, dass es sich um Standardimpulslängen handelt, Mittenimpuls bei 1.520µs, nichts anderes!
Zusammenfassung zu “Protokoll”: 1) “RPM”-Datenwertebereich vom ESC nur hinreichend bis 10-Poler. 2) Gasimpulsfrequenz max. 100Hz.
Anschlussweise
JLog braucht zwei Pins für die Geschichte, weil zwei Ports zu seinem Microcontroller: Auf dem ersten geht der Gasimpuls von Empfänger/FBL/… in Jlog herein, aus dem zweiten kommt der invertierte Gasimpuls heraus, um ihn dem ESC zuzuführen, via dessen Servokabel. Gleichzeitig lauscht hier JLog zwischen den vom ihm invertiert ausgegebenen Gasimpulsen auf die Datenimpulsantworten des ESC.
Ganz oben haben wir ZWEI schematische Anschlussweisen dargestellt. Warum zwei? Eigentlich wäre es für diesen Anwendungszweck nett, dafür zwei Anschlüsse für Servostecker am JLog zu haben. Dabei könnte dann aber immer nur ein Signal je 3-Pin-Anschluss an JLog behandelt werden, Gas rein oder raus. Das ist aber nicht vorhanden. Der Platzbedarf von Servoanschlüssen ist nun mal monströs im Verhältnis zu dem der Elektronik, zur angestrebten minimalen Gesamtgröße des Geräts. Im Kapitel “Anschlüsse und Stromversorgung” ist beschrieben, dass Servoanschlüsse an JLog immer zwei Signal-Pins haben, der mittlere Pin kann, durch die Software gesteuert, aber auch als Stromversorgungspin verwendet werden (Nur Output, nur für spezifizierte Sensoren!), wenn erforderlich. Außerdem ist dort beschrieben, dass und wie Pins an JLog intern multifunktional verknüpft sind, dass sie nicht alle vollständig unabhängig voneinander sind. – Somit entsteht beim Anschließen von JLog mit einem Castle Creations ESC die Aufgabe, eine Art “Y-Kabel” zu haben, was die beiden Signalpins EINES Servoanschlusses (3 JR-Pins) auf zwei Servokabel mit Standardbelegung bringt, das eine zum Gasimpulslieferanten, Empfänger/FBL/…, das andere am ESC.
Dafür verwenden wir den Port “OPTions” an JLog, jedenfalls dann, wenn das Telemetriesystem MPX, JETI, HoTT, Futaba, JR oder FrSky (OpenTx) ist. Handelt es sich aber um SPEKTRUM oder HiTec, dann kann “OPTions” nicht verwendet werden für die Gas-/Datenimpulse. SPEKTRUM und HiTec Telemetrie verwendet I²C, und das liegt auch auf dem “OPTions” Port von JLog (parallel auf der Buchse “X-Bus”). Deshalb weichen wir mit SPEKTRUM und HiTec auf JLog’s Port “COM” aus für die Impulse, und daher sind oben zwei schematische Darstellungen der Anschlussweise angezeigt.
Wer jetzt löten will, kann das natürlich bereits anhand eines der beiden Bilder tun, das muss aber nicht sein. Wir bieten ein fertiges “Y-Kabel” an (eigentlich ein “X”), was für alle Konstellationen plug&play verwendbar ist:
Die genaue Verschaltung, abhängig vom Typ der Telemetrie, die Sie verwenden, entnehmen Sie bitte der JLog Home Page, Anschlussbilder JLog2.5/2.6.
Sofern wir nicht den “COM” Port an JLog verwenden müssen für die Impulse (wenn SPEKTRUM oder HiTec Telemetrie), ist die Anschlussweise an JLog2 identisch zu JLog2.6, 2.5, nur, dass der “OPTions” Port hier “Sensor/Alarm” heisst, bzw. “K4″. Ist die Telemetrie Futaba (S.Bus2), benötigt man noch zusätzlich das Interface “JSend”, auf das JLog2 aufgesteckt wird. Etwas “aufregender” wird es, wenn mit SPEKTRUM oder HiTec Telemetrie der “COM” Port des JLog2 zu nutzen ist für die Impulse, da “COM” bei JLog2 kein Servoanschluss ist, sondern eine Molex Buchse, für die ein spezieller Stecker benötigt wird, der auf ein Kabel zu crimpen ist. Dafür gibt es zu JLog2 die Option “JCC”, die JLog2′s “COM” auf zwei Servoanschlüsse umsetzt. (Noch komplexer wird es mit SPEKTRUM, wenn der JLog2 keinen modifizierten Bootloader bekam. Dann wird zusätzlich, zum TM1000 hin, “JSPEK” benötigt.) Details, abhängig vom Typ der verwendeten Telemetrie, entnehmen Sie bitte Anschlussbilder JLog2, beachten Sie auch das Manual zu JCC.
Aus obigem Bild (insbesondere aus den Anschlussbildern zu JLog2) ersieht man, gerade anhand des vierten Beins am “Y”, was ein “X” daraus macht, dass wir ein Thema noch nicht behandelten, – die Stromversorgung von JLog und R/C-Komponenten mit einem Castle ESC und Link Live:
Zunächst muss JLog mit Betriebsspannung versorgt werden. Das geht über den JR-Stecker mit einem Draht oben im Bild, atypisch belegt, weil er an den “JIVE” Port von JLog kommt. Das “Y-Kabel” verbindet Plus Empfänger (/FBL/…) mit Plus ESC und besagtem Stecker am “X-Bein” des Kabels. Mit JLog2 ist das der einzige Weg zu dessen Stromversorgung. JLog2.5, 2.6 kennen auch zwei Alternativen, “KOSMIK” Port, hier nicht relevant, und “X-Bus” Port. Wenn unsere Telemetrie SPEKTRUM ist, versorgt der TM1000 bereits JLog2.5, 2.6 via die “X-Bus” Buchse mit Betriebsspannung, der “X-Stecker” kann unangeschlossen bleiben, muss es aber nicht.
“Kniffliger” wird es um die Frage der allg. R/C-Stromversorgung im Modell und um die Rolle des Castle Creations ESC dabei, – BEC, ja oder nein, wird dessen BEC verwendet?
Hat der ESC ein BEC und soll es verwendet werden, dann sorgt das “Y-Kabel” für die notwendige Verbindung zum Empfänger/FBL/…, von wo aus die restlichen Verbraucher versorgt werden. Die Kabelquerschnitte des “Y-Kabels” sind adäquat, zudem ist das Kabel relativ kurz.
Handelt es sich beim ESC um einen HV-Typ, kein BEC eingebaut, dann hat dieser hinter dem Servokabel einen Optokoppler, genauer gesagt, zwei, den zweiten für das Einkoppeln des Datenimpulses aus Link Live. Der O-Koppler will Betriebsspannung, die bekommt er via “Y-Kabel” vom Empfänger/FBL/…
Hat der ESC ein BEC, will man das aber nicht verwenden, dann kappt man irgendwo den roten Draht, am besten zieht man ihn aus dem Stecker am Servokabel des ESC.
JLog2 + SPEKTRUM, HiTec: “JCC“, der ja den ESC konnektiert, hat Hochstromanschlüsse, um hier dessen BEC-Spannung verlustarm auskoppeln zu können und auf eine geeignete Spannungsschiene der R/C-Stromversorgung im Modell zu führen, zum Empfänger, z.B.
Hier eine Anleitung von Marcus und Kollegen, EDGE 120HV und Microbeast, Futaba-Telemetrie. Das Problem war, dass Castle Link Live nicht funktionieren wollte, der EDGE den invertierten Gasimpuls nicht verstand, wenn der Impuls direkt aus dem Futaba-Empfänger (R7008) stammte. Daher verband man Empfänger und Beast per S.Bus und zweigte den Gasimpuls aus dem Beast ab, um ihn JLog zwecks Invertierung zuzuführen. Meine Vermutung ist, dass die Gasimpulsfrequenz aus dem 7008 zu hoch war. Für Castle Link Live sollte sie Standard sein, 50Hz, maximal jedoch 100Hz.
Elektrische und andere Probleme von Castle Link Live
Vorangeschickt: Es gibt leider eine Art “chronischer Erkrankung” der ganzen Sache um Castle Creations und deren “Link Live”, nachzulesen hier, viel Vergnügen.. Eine Aussicht auf Heilung besteht bisher nicht, der Patient scheint ein Arztmuffel zu sein. Ob also die “Erkrankung” im jeweiligen Setup in Erscheinung tritt, steht solange in den Sternen, bis man es mit seinem ESC und seinem Setup probiert hat.
“Seinem Setup” ist ein Stichwort: Dieses Protokoll, “Castle Link Live”, operiert nicht mit diskreten Pegeln, ist nicht digital. Es ist daher relativ störanfällig, zumal der Datenimpuls nur ein Nadelimpuls ist. Eine Erdschleife, ein Verschieben des Massepotentials, kann eh leicht jedes TTL-basierende Protokoll stören. – (“TTL”: Bis 0,8V==Low, >0,8V(nominal >2V im Output)==High. In Praxis: 0..0,4V==Low, 0,4..0,8V==verbotener Bereich(undefiniert), >0,8V==High.) — Die Probleme, auch mit digitalen Pegeln um Telemetrie etc. nehmen allg. zu, denn die Koexistenz mit hohen Antriebs- und Servoströmen ist nicht einfach, dafür haben wir aber immer mehr elektronisches Geraffel in unseren Modellen. Fließt viel Strom auf der Masseleitung, dann ensteht hier eine Fehlerspannung, die die engen Pegelgrenzen von “TTL” leicht überschreiten kann. Außerdem kann es zu elektromagnetischen Einkopplungen in die Kleinsignalleitungen kommen. Eine “Masseschleife” kann entstehen, wenn verschiedene Massepotentiale in der Verkabelung sich addieren, die Fehlerspannung durch Stromfluß auf der Masse addiert sich zum Kleinsignalpegel, der verschiebt sich bis zur Unleserlichkeit des Signals. Da die Fehlerspannung von der Höhe des Stromes abhängig ist, kommt es zu einem dynamischen Effekt. Wenn jemand beobachtet, dass beispielweise seine SPEKTRUM Telemetrie ausfällt, sobald richtig Motorstrom fließt, dann hat er mit Sicherheit so ein Problem. – Leider ist die ganze “Plug&Play-Verkabelung” mit Servokabeln bester Nährboden, leider ist der Spannungsabfall (->Spannungs-differenzen auf den Massen) auf diesen “Strippen” meist hoch, weil der Innenwiderstand so hoch ist, insbesondere der der längst nicht mehr zeitgemäßen Servostecker vom Typ “JR” oder “Futaba”.
Mit “Castle Link Live” reicht schon die Dynamik des Ganzen, Pegelverschiebung on top, – es ist leider relativ leicht durch o.g. Ursachen, einen Datenimpuls zu simulieren.
Leider kann man dazu keine Allheilanleitung fertigen, man kann nur appelieren, sauber zu verkabeln:
Eine Maßnahme wäre schon, o.g. fertiges “Y-Kabel” zu verwenden, und nicht in Vertrauen in eigenen Durchblick irgendwas selbst zu basteln.
Beim Verkabeln immer durchdenken, welche der Masseleitungen von höheren bzw. impulshaften Strömen durchflossen werden. Weniger ist dann u.U. mehr zur Heilung, ein Gerät nur an einem Typ Masse im Modell anschließen, wenn zwei Geräte mit Kleinsignalen miteiander kommunizieren (z.B. ESC–JLog, JLog–TM1000 bzw. JLog–Empfänger/FBL/…) , dann nur eines von beiden an Masse anschließen, das andere bekommt die Masse vom Kommunikationspartner, und die gemeinsame Masse ist ja das Bezugspotential zum Bewerten ausgetauschter Signale.
Kleinsignalleitungen möglichst fernab von Hochstromleitungen verlegen, – Akkukabel, Motorkabel, Servokabel, Zentraleinspeisung in die R/C-Spannungsschiene, z.B. Spannungsversorgungkabel zum Empfänger, Kabel vom BEC-Ausgang. Keine Schlaufen bilden (Antennen), keine Kabel durch Schlaufen ziehen (Induktion), Kleinsignalleitungen nicht länger parallel zu Hochstromleitungen verlaufen lassen, auch, wenn ein paar Zentimeter entfernt.
Besonders prickelnd bzgl. Masseschleifen kann es bei Verwendung eines externen BEC werden, wenn dieser Primär- und Sekundärseite nicht galvanisch trennt, Ausgangsmasse identisch Eingangsmasse ist. Es gibt bis dato eh nur einen BEC weltweit, der galvanisch trennt, HV²BEC. Wenn ich jetzt meinen externen BEC primärseitig irgendwo an den Antriebsakku anschließe, dessen Ausgang an die R/C-Elektronik, dann habe ich mir eine Brücke vom Masse-Anschlusspunkt am Antriebsakku zur R/C-Masse gelegt. Allerdings läuft die Minusleitung des Antriebsakkus noch weiter, und darüber fliesst vieeel Strom mit entsprechenden Spannungsabfällen, dann landet DIESE Masse am ESC, und via dessen Servokabel (Gas) kommt sie zurück in die R/C-Elektronik. Eine Ground Loop aus dem Bilderbuch..
Was von all dem im Kopf hängen bleiben sollte: ”Es kann nur Einen geben..”, – ja, vielleicht nur einen Highlander, aber leider in der elektrischen Praxis nicht bzgl. der Masse, – es gibt viele! Wir müssen aber darauf achten: Masse == Null Volt, soweit als möglich, doch leider meist unmöglich. Unsere Aufgabe ist Schadensbegrenzung.
Hazard Filter in JLog
JLog verwendet verschiedene Filter, die Fehllesungen des Datenimpulses aufgrund o.g. Ursachen, im Ergebnis herausfiltern sollen. Es gibt einen Grundfilter, der zunächst systematische Fehler beseitigen soll. “Systematisch” sind tatsächlich vom ESC falsch gelieferte Daten in bestimmtem Betriebszustand von diesem. Z.B. spielt die Drehzahlausgabe verrückt im Augenblick des Anlaufens aus dem Stillstand. (Das ist nicht wirklich ehrenrührig für Castle, ein JIVE tut das auch, selbst ein KOSMIK macht es.)
Weitere Filter richten sich aber gegen Fehllesungen aufgrund von Störungen, seien die nun extern begründet (Kabelsalat nebst Erdschleifen und Interferenzen), oder der ESC hat mal einen Husten. Diese Filter sind kaskdiert, ein’s nach dem anderen. Ab JLog2.6 (z.Z. nur mit JLog2.6) kann der letzte und schärfste Filter im JLC an/ausgeschaltet werden.
Die Konfiguration “Filter2″ lässt den letzten und schärfsten Filter weg. Das hat folgenden Sinn: Beobachte ich keine Kommunikationprobleme ESC–JLog, dann probiere ich mal “Filter2″ anstatt “Filter3″, und wenn das auch geht, bleibe ich dabei. Diese Filter erhöhen nämlich die Latenz im Update der Daten vom ESC, mit “Filter3″ beträgt sie schon 1 Sekunde bei 50Hz Gasimpulsfrequenz, 0,5s mit 100Hz! Damit das dann zumindest im Log von Jlog immer noch “smooth” aussieht, integriert JLog die Ergebnisse, macht sie “rund”. Schön ist das nicht für Genauigkeit in forensischer Anwendung. Also nimmt man den Filter zurück, sofern es das Exemplar Castle ESC und mein Setup (Kabelsalat ) erlaubt.
Einige Modelle ICE/EDGE senden aber auch permanent Fehlmessungen, teilweise exemplarbedingt. Z.B. kann die ausgegebene Temperatur stark abweichen. Es gab sogar schon den Fall mit einem ICE 120HV, dass der selbst die richtige Temperatur loggte, aber falsche Werte via Link Live ausgab. – Ein anderes Problem stellt der Punkt der Strommessung (Batteriestrom) im Castle ESC dar. Das ist in vielen Modellen ein schaltungstechnischer Design Bug, dergestalt, dass sich die gemessene (gelieferte) Antriebsspannung erhöht mit steigendem Strom (oft auch die Temperatur!), obwohl sie eigentlich real fällt durch Innenwiderstand der Zuleitungen und des Akkus. Der Grund ist, dass es zu einer Masseverschiebung kommt für den messenden A/D-Wandler im Microcontroller des ESC, eine systematische Masseschleife, sozusagen.
Folgende Werte bekommen wir von einem ICE/EDGE:
Ubec….. steht immer auf Null, die ESC messen Ubec nicht Ibec…… steht immer auf Null, die ESC messen Ibec nicht Ubat …… Antriebsspannung (V) Imot…… Motorstrom (A), – eigentlich handelt es sich um den Batteriestrom Power…. (W) Uripple… Ripple Spannung (V) Gas……. Gasimpulslänge (µs) Gas-relativ. relatives Gas 0..100%. Das errechnet JLog selbst, indem er annimmt: 1100µs=0%, 1940µs=100% ……………… Leider sagt uns der ESC mit seinem Gaswert nichts über seine Bewertung des Gases. tFET ……. Endstufentemperatur (°C) RPM …… 2-pol-normalisierte Motordrehzahl. JLog macht daraus rpmMot und daraus dann rpmRotor (rpmUni)
Die Temperatur kann von einem nichtlinearen (NTC, bisher immer der Fall) oder von einem linearen Sensor (nie gesehen) im ESC kommen. Es gibt die Datei “CCinfo.txt” auf der SD, die erzeugt JLog und schreibt hier hinein, welchen Typ Temperatursensor er sah, also “NTC” oder “LIN”. JLog ist eh auf diese Information angewiesen (gewesen, im Lauf davor), um die Datenimpulsdistanz richtig umrechnen zu können in den Temperaturwert.