—————————————————————————————————————————————————————
Jun 2016: Achtung, in allen Darstellungen zum JCC für JLog2 sind die beiden Servo (Pin) Ports für ESC und Empfänger/FBL (Gasimpulsquelle) vertauscht! So ist es richtig:
—————————————————————————————————————————————————————
11/15/2015 Neu New
Achtung! Dieses Chapter des Manuals wurde überabeitet, und zwar am 28.3.2015. Also bitte noch mal lesen! *rolleyes*
Hier muss man leider ein wenig in die Materie der Datenübertragung ESC–>JLog einsteigen, denn sie ist direkt auch verknüpft mit der Gegenrichtung, Gasimpuls –>ESC. Man muss das Prinzip daher verstehen, damit man als Anwender im Falle von Problemen mit vom ESC empfangenen Daten oder mit dem Verständnis des Gasimpulses durch den ESC das Richtige tut. (Leider ist es auch so, dass Castle viele Design Flaws mitbringt, mit der Hardware, mit der Firmware. Beispiel: Die Firmware 4.20 ist nicht verwendbar (wurde durch Castle auch zurückgezogen). Die Fertigungsqualität der Geräte ist alles andere als gleichbleibend…)
Castle’s Datenprotokoll ist eine Sparnummer. Statt digital zu übertragen, vergewaltigt man den “Signal”anschluß des ESC (für den Gasimpuls) zu einem Transceive-Interface, was mit einem dazu fähigen Device, hier JLog, im Semi-Duplex kommuniziert. Nach dem Ende eines Gasimpulses, JLog ist Tx, ESC ist Rx, wechselt man die Rollen, ESC ist Tx, JLog ist Rx, und der ESC sendet einen Datenimpuls. Der zeitliche Abstand des Datenimpulses zum Ende des Gasimpulses kodiert einen Datenwert.
Diese “begeisternde” Idee nennt sich “Castle Link Live” (CLL) und muss explizit im ESC per “Castle Link” aktiviert werden. Leider dokumentiert Castle Creations nirgends, welche Modellreihen CLL unterstützen. Seitens ICE und EDGE ist inzwischen gesichert, dass sie es alle tun, – es gibt aber Grund, anzunehmen, dass inzwischen alle Modellreihen CLL sprechen.
CLL ist daher so “begeisternd”, weil es extra empfindlich ist für Störsignale auf der Leitung, inbesondere im Falle von Erdschleifen. Nicht nur das Prinzip ist sensibel (eine Datenintegritätsprüfung ist ausgeschlossen), insbesondere der Datenimpuls ist es, denn es handelt sich um eine Impulsnadel, die das detektierende Device (JLog) leicht mit Störimpulsen verwechseln könnte.
Damit CLL funktioniert, muss der Gasimpuls invertiert werden. Das hat nichts mit dem im R/C gängigen Begriff “Pulse Reversing” zu tun, sondern die Zustände Low und High des Gasimpulses tauschen die Plätze. Nach Aktivieren von CLL im ESC versteht der natürlich keine normalen (nicht invertierten) Gasimpulse mehr.
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 CC 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 9 Nutzdatenimpulse, zzgl. zweier Kalibrierungsimpulse:
Und hier noch mal der Daten-Nadelimpuls, etwas idealisiert, weil mit dem Logic Analyzer erfasst:
Das war sie fast schon, die Theorie in Bildern. Fast… Wir müssen noch über “Ecken und Kanten” von CLL in Praxis sprechen:
Protokoll – Traps and Pitfalls
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.. Conclusion: RPM-Datenwertebereich vom ESC nur hinreichend bis 10-Poler.
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.
Der zeitliche Abstand zweier Gasimpulse, auch “Impulsrate” genannt (also die Impulsfrequenz) ist also signifikanter Bestandteil des Protokolls CLL. Nun, wundert es irgendjemand, dass Castle Creations nirgends darauf hinweist, die max. Impulsrate nicht spezifiziert?… . Aus obiger Rechnung, die sozusagen ohne den Wirt (inneres Timing des ESC beim Umschalten von Tx auf Rx) gemacht wurde, könnte man also sagen, bis 100Hz Impulsfrequenz von der Quelle, Empfänger oder FBL, funktioniert es. Leider gefehlt: In der schon relativ weit zurückreichenden Vergangenheit, in der JLog Castle ESCs unterstützt, sah es häufig so aus, als dürfe die Gasimpulsfrequenz tatsächlich zwischen 50 und 100Hz liegen. Möglicherweise hat Castle inzwischen auch diesbzgl. an deren Firmware gedreht, jedenfalls muss man heute (März 2015) feststellen: Maximal 50Hz Gasimpulsfrequenz!
Anbei ein Beweis, festgestellt mit der bisherigen Firmware für JLog2.6, CC + Futaba Telemetrie:
Der Futaba Empfänger R7008 liefert 67Hz Gasimpulsfrequenz. Bietet man den invertierten Gasimpuls dieser Frequenz dem ESC an, stolpert er zwar noch nicht über das Gas, aber die Datenübertragung funktioniert nur teilweise.
Noch ein möglicher Stolperstein, der die Anforderungen an die Gasimpulsquelle bestimmt:
Dadurch, dass der Gasimpuls das Timing im Protokoll CLL steuert, darf er nicht nur eine max. Frequenz haben (s.o.), sondern seine Frequenz muss auch konstant sein. Frequenzsprünge, damit Phasensprünge, sind totales Gift für CLL. Der invertierte Gasimpuls muss phasensynchron bleiben zu den Reaktionen des ESC im CLL. Leider gibt es Empfänger, die aufgrund mangelnden Designs derer Firmware mit instabiler Impulsfrequenz daherkommen, z.B. FrSky X8R, z.B. HiTec Optima 7. Auch bzgl. des sog. “Gov” im Vbar muss ich das unterstellen, auch wenn ich es bisher messtechnisch nicht verifizierte.
Um dem Gasimpulsproblem im Rahmen des Supports nicht weiter hinterherrennen zu müssen, gab es nun eine grundlegende Firmwareänderung in JLog. Sie existiert im Augenblick (28.3.2015) noch als “experimentell”, und zwar für Futaba Telemetrie, wird aber in den nächsten Tagen für alle Telemetrien und aktiven Typen JLog (2, 2.5, 2.6) veröffentlicht werden:
Bisher hat JLog einfach nur den Gasimpuls der Quelle invertiert. Dadurch hat der Impuls die originale Frequenz und folgt auch jedem Blödsinn wie o.g. Frequenzsprüngen. Jetzt trennt JLog beide Prozesse konsequent: Auf der Seite zur Impulsquelle hin misst er einfach nur die Impulslänge. Frequenz und Frequenzsprünge werden dadurch nebensächlich, – JLog selbst tangiert das nicht. Auf der Seite zum ESC hin generiert JLog die Gasimpulsfrequenz selbst, und zwar mit konstant 50Hz, die Länge der ausgesendeten Impulse ist die im Input gemessene der Quelle. — ..und siehe da, unser Fallbeispiel oben mit R7008 (67Hz Impulsfrequenz) und Futaba Telemetrie: “Plötzlich” funktioniert’s.
(Ok, wer genau hinguckt: Das sind noch nicht genau 50Hz, da ist ein Scope Shot aus einer frühen Entwicklungsphase. )
Die Modifikation nennt sich “Own Pulse”.
–> Der Anwender muss sich nun nicht mehr darum kümmern, mit welcher Frequenz der Gasimpuls von seinem Empfänger oder FBL gesendet wird, und welche Kapriolen dabei vorkommen (Frequenzsprünge etc.). Crux ist ja auch, dass das meist nicht vom Hersteller spezifiziert ist, und Otto-Normalo hat wahrscheinlich keinen Oszi oder Logic Analyzer in der Werkzeugkiste.
Leider kommen Castle ESC User, deren Telemetrie SPEKTRUM oder HiTec ist, nicht in den Genuß: Die Geschichte von JLog zeigt immer wieder, dass es dessen Entwicklung leider an hinreichend hellseherischen Fähigkeiten mangelt, was spätere Anforderungen an die Hardware des JLog betrifft.
Für Fachleute: Das Problem ist, dass mit SPEKTRUM/HiTec der “Option Port” besetzt ist, weshalb in diesen Fällen mit den Pins von “COM” das Impulskino in beide Richtungen gemacht wird. Leider gibt es je Anschlußpin an “COM” jeweils auch nur 1 Prozessorpin. Diese beiden Pins befinden sich aus anderen Gründen in derselben Pin Change Interrupt Gruppe, müssen durch dieselbe Interrupt Routine bedient werden. Bisher war das kein Problem, weil das Invertieren des Gasimpulses und Castle Link Live Impulsprotokoll phasensynchron zueinander erfolgten. Jetzt aber sind das zwei zueinander asynchrone Vorgänge, auf der einen Seite die Impulsquelle, auf der anderen JLog mit CC.
Am “Option Port” sind zum Glück weitere Prozessorpins je Anschlußpin konnektiert, die sich in unterschiedlichen Pin Change Interrupt Gruppen befinden, an “COM” gibt es den Luxus leider nicht.
Im Klartext heißt das: JLog Firmwares für Castle ESC und Telemetrie SPEKTRUM oder HiTec müssen unverändert bleiben: Der Gasimpuls von der Quelle wird einfach nur invertiert, folgt daher deren Frequenz und Phasenlage.
SPEKTRUM: Getestet wurde mit zwei Exemplaren AR8000. Beide liefern 50Hz Impulsfrequenz, konstant. Zumindest mit diesem Typ SPEKTRUM Empfänger bedarf es zum Glück nicht des “Own Pulse”.
HiTec: Getestet wurde ein Optima 7. Dessen Frequenz ist ok, liegt leicht unter 50Hz (drunter ist nie ein Problem). Allerdings steigt die Impulsfrequenz schlagartig auf 75Hz, wenn der Empfänger in den Failsafe Mode geht. Nicht gut.. Nicht gut ist auch, dass die operative Impulsfrequenz von ca. 50Hz mit Frequenzsprüngen aufwartet (nicht aber im Failsafe Mode). Da muss man sehen.. Bisher gab es hier (beim Entwickler) keine Probleme dadurch.
-
CC ESC mit Opto Eingang (11/15/2015)
Manchmal ist es der Zufall, der einem zu neuer Erkenntnis verhilft: Ich hatte mich gewundert, dass sich ein paar Anwender so vehement über diese “Anlaufversuche” bei Gas Nullimpuls beschweren (“piep”, der Motor dreht sich um 5..10°). Ich kannte das bisher nur von der Nicht-Ownpulse Variante, wenn eine Gasimpulsquelle angeschlossen ist, die Phasensprünge verursacht. Aber auch dann war das eher gelegentlich. Heute hatte ich zum ersten Mal den Fall, dass das sehr häufig passierte, bis zu zweimal pro Sekunde. ESC war ein CC 120 HV (also opto), die Betriebsspannung höher als sonst in meiner Testumgebung (sonst ca. 5V): Der Optokoppler braucht eine Betriebsspannung von außen, natürlich. Die Spannung kommt via das Splitter Kabel von der Gasimpulsquelle, Empfänger oder FBL. Es stellte sich nun heraus, dass für o.g. Effekt weder die Impulsquelle verantwortlich ist (Pegel und Phasenlage blieben lt. Messung konstant), auch nicht JLog, auch dann nicht, wenn er den Impuls nur invertiert (mit SPEKTRUM, HiTec Telemetrie), – sondern der ESC selbst ist der Verursacher.
Die Betriebsspannung für den Optokoppler im CC hat ein verbotenes Fenster: >=5,9V, <=6,8V. Also zwischen 5,9 und 6,8V sollte sie sich nicht befinden! Messungen zeigten, dass der Optokoppler sonst selbst derjenige ist, der den Gasimpuls oft nicht erkennen will, dabei auch Fehler seitens des Datenimpulses vom CC provoziert. Die Sende/Empfangsumschaltung des ESC wird asynchron zum angebotenen phasentreuen, invertierten Gasimpuls, produziert dadurch Synchronisationsverlust, Phasensprünge. Das ist ein Bug im Schaltungsdesign des CC ESC.
Nun ist es natürlich schwer für den Anwender, garantieren zu können, dass die Betriebsspannung im praktischen Betrieb niemals in dieses Fenster gerät.. Schließlich produzieren die Servoströme Spannungsabfälle.. Zumindest sollte die Lehre daraus sein, beim Einstellen der nominalen BEC Spannung dieses Fenster weiträumig zu meiden.
Ja, lange hat es gedauert, viel Zeit kosteten Untersuchungen. Nun wundert es nicht mehr, dass manche Anwender “Gasstottern” in bestimmten Situationen beklagten. Mit einem externen Gov wird der Effekt vermutlich noch ausgeprägter sein.
-
CC ESC with opto-coupler input (11/15/2015)
Sometimes it’s coincidence which helps one to new knowledge: I had wondered that a few users complain so vehemently about these “startup attempts” at throttle zero pulse (“beep”, the motor revolves around 5..10 °). I knew that so far only by the non-Ownpulse variant when a throttle pulse source is connected, causing phase shifts. But even then it was more occasionally. Today I had the first time that this frequently happened, up to two times per second. ESC was a CC 120 HV (ie opto), the operating voltage was higher than usual in my test environment (usually about 5V): The optocoupler needs an operating voltage from the outside, of course. The voltage comes via the splitter cable from throttle pulse source, receiver or FBL. It has now been found that for above-mentioned effect neither the pulse source is responsible (level and phase position remained constant according to measurement). Also not JLog, even not if it only inverts the pulse (with SPEKTRUM, HiTec telemetry); – but the ESC itself is the causative agent.
The operating voltage for the optocoupler in the CC has a forbidden window: >=5.9V, <=6.8V. So the voltage should not get between 5.9 and 6.8V! Measurements showed that the optocoupler otherwise itself is the one that often does not want to recognize the throttle pulse. That provokes failure on the part of the data pulse from the CC. Transmit/receive switching of the ESC goes asynchronous to the offered (phase true) inverted throttle pulse, thereby producing loss of synchronization, phase jumps. This is a bug in the circuit design of the CC ESC.
Well, of course it is difficult for the user to be able to guarantee that the operating voltage in practical operation never gets in this window.. Finally, servo current causes voltage drop.. At least the doctrine from that should be: in setup of the nominal BEC voltage keep away from the mentioned voltage window as far as possible.
Yes, long did it take, cost a lot of time for investigations. Now it is no longer surprising that some users experience “throttle stuttering” in certain situations. With an external gov the effect is likely to be even more pronounced.
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:
Das Kabel gibt es z.B. hier.
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 es die zu hohe Gasimpulsfrequenz aus dem 7008 zu hoch war. s.o., 67Hz statt max. 50Hz.
Je nachdem, wie man den CC auf den Gasimpuls einlernte, kann es offenbar passieren, dass der CC nach dem Einschalten von Link Live eine andere Sicht auf den Gasweg hat. Ergo: Neu einlernen/einstellen oder mit dem Gas runter an der Quelle, Empfänger oder FBL.
Nicht verwechseln! ”Invertiert” macht nur JLog hier, das hat nichts mit “Reverse” zu tun, was man im allg. R/C-Jargon so kennt. Also nicht irgendwo zusätzlich revertieren an der Gasimpulsquelle!
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. (der Shunt befindet sich low-side, hebt das Massepotential an bei Spannungsabfall)
Folgende Werte bekommen wir per CLL von einem Castle ESC:
Ubec ….. steht immer auf Null, die ESC messen Ubec nicht (wird besetzt durch Ubec aus einem HV²BEC)
Ibec …… steht immer auf Null, die ESC messen Ibec nicht . (wird besetzt durch Ibec aus einem HV²BEC)
Ubat …..Antriebsspannung (V) (wird besetzt durch TPV aus einem CVS-16)
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.
Datenwert “Gas” (throttle)
Leider liefert der ESC nur die Impulslänge im Mikrosekunden, wie er sie maß. Das sagt nun gar nichts über das Gasverständnis des ESC aus, macht den Wert geradezu sinnlos. JLog berechnet daher zusätzlich ein relatives “Gas” 0..100%, dass er loggt und auschließlich in den Telemetrien verwendet. Er macht das so:
throttle=(CCdata[3]-1100)
1100µs==0%, 1940µs==100%
Das passt auf jeden Fall zu den Default Einstellungen eines CC. Wenn jetzt jemand an den Endpunkten dreht im Setup, dann verschiebt sich natürlich alles. Da es keinen wirklichen Grund gibt, die Endpunkte anzufassen, sollte man es einfach bleiben lassen.
“Gas” und “Summensignal”
Wie man sieht, am Servoimpuls “Gas” (throttle) hängt einfach alles bzgl. CLL. Abgesehen davon will eh jeder ESC einen Sevoimpuls, nimmt den Stellwert “Gas” nicht aus einem “Summensignal”.
Die beiden folgenden Abbildungen dokumentieren es:
.
