Es stellte sich nun heraus, dass das "Protokoll" Castle Link Live wesentlich empfindlicher auf zu hohe Gasimpulsfrequenz reagiert als befürchtet.
Die goldene Regel heißt: Verwende eine Impulsfrequenz von 50Hz (20ms Impulsrate, Standard). Bisher hatte ich aber hochgerechnet, dass es noch bis 100Hz gehen könnte. Die Rechnung erfolgte ohne Kenntnisse über das Timing im CC ESC beim Umschalten zwischen Empfang (für invertierten Gasimpuls) und Senden (für den Datenimpuls).
Die Testerei hier bei mir bedeutet immensen Aufwand. Ich hatte mir seit geraumer Zeit angewöhnt, den Gasimpuls immer nur aus einem Empfänger zu beziehen, während die Telemetrie über einen Empfänger des jeweiligen Systems geht. Dieser Empfänger ist ein HoTT GR-16, und der liefert glatte 50Hz Impulsfrequenz.
Ein Aha-Effekt resultierte daraus bereits vor einiger Zeit: Ein FrSky X8R liefert keine konstante Gasimpulsfrequenz. Die Firmware des Rx ist schlecht programmiert, weshalb sich die Frequenz sprunghaft ändert in regelmäßigen Abständen. Auch bzgl. eines "Gov" (VStabi) muss ich unterstellen, dass dessen Impulsfrequenz nicht konstant ist. Habe das aber bisher nicht gemessen im Gegensatz zum X8R.
Phasensprünge sind Gift für dieses krude Protokoll von CC, geboren aus einer Sparnummer (wie der ganze ESC..).
Nun kam Aha-Effekt #2, nämlich, dass es bereits bei nur 67Hz Impulsfrequenz dazu kommen kann, dass JLog nicht mehr alle Typen Datenimpulse lesen kann vom CC. Rudi1025, Mod im Futaba Forum, bemerkte das Problem. Ich konnte es nachvollziehen mit einem R7008:
(Typisch: Castle äußert sich überhaupt nicht zur Gasimpulsfrequenz, Null Specs, obwohl das essentiell ist.)
Also war ich mal wieder undiszipliniert, unterbrach laufende Entwicklung und baute eine Heilung ein, - zunächst nur als Test Firmware für Rudi, - JLog2.6 und Futaba Telemetrie:
JLog muss ja den Gasimpuls invertieren. Er bekommt ihn auf einem Pin von einem Rx oder FBL, er schickt ihn invertiert auf einem anderen heraus, auf dem er transceive (Senden/Empfangen im Semi-Duplex) mit dem CC kommuniziert. Sprich, die Frequenz ist die des Gasimpulses, wie er JLog angeboten wird.
Jetzt macht er es anders: Er misst die Gasimpulslänge und generiert selbst den invertierten Gasimpuls, und zwar mit einer konstanten Frequenz von 50Hz, die völlig unabhängig ist von der Frequenz des Eingabeimpulses.
Das scheint's zu bringen, jedenfalls geht mein R7008 dann im Setup, während vorher, wie bei Rudi, ein paar Daten fehlten bzw. verfälscht wurden.
Wenn Rudi positiv getestet hat, werde ich einen Sack voll neue CC-Firmwares machen für alle JLog, - 2, 2.5, 2.6. Freude, schöner Bockbierhumpen..
Ein weinendes Auge bleibt: Nicht machbar ist diese Änderung in Firmwares für CC mit Telemetrie HiTec oder SPEKTRUM. Die Geschichte von JLog beweist 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 nicht.
Attachment: OK, das Capture ist aus der Entwicklung, noch ungetunte 50Hz.
Anmelden
Registrieren
FAQ
Suche
