J-Log.eu - Forum

Damit gibt es ja Probleme, offenbar aufgrund von einem Design Bug und Hardwareexemplarstreuungen in den ICE HV. Investigation is ongoing, es gibt schon "Heilmittel" seitens JLog, einen kompletten Bericht werde ich vorab hier einstellen, wenn geänderte Fimrware für die JLogs draußen ist.

_________________
Tom

So, eben abgeschlossen. Habe nicht wenig Zeit investiert. Siehe Download.
Zitat:

Was war das Erscheinungsbild?

Nun, zunächst gab es gar kein's, bzw. war kein spezifisches durch mich bemerkbar.
Ich hatte das vor geraumer Zeit implementiert, und es lief eben. Allerdings hatte ich immer ICE LV, mit BEC.
Dann gab es 1..2x Trouble, Erdschleifenverdacht, ich achtete aber auch gar nicht auf die Frage, ob es ein ICE HV ist im konkreten Falle, - in meinen Augen waren beide gleich bzgl. Castle Link Live, ICE LV und HV.

Dann wurde es zum ersten Mal verdächtig: Andreas ("helikopterfreund") hatte komische Fehllesungen durch JLog, z.B. utopische Drehzahlwerte im Stillstand. Das war ein ICE HV. Gleichzeitig hatte ich einen ICE LV von Andreas und konnte seine Probleme mit dem LV überhaupt nicht nachvollziehen. -- Wir machten dann so eine "Remote Entwicklung", er hat den ESC, ich code im Blindflug, - und dann war das gefixt. Nur im Ergebnis konnte ich keinen Zusammenhang herstellen, nur vermuten, dass es offenbar immense Exemplarstreuungen bei den CC mit Optokoppler (HV) geben kann. -- Letzteres erhärtete sich sukzessive anhand der Erfahrungen anderer User.

So richtig deutlich wurde es erst kürzlich durch weitere Erlebnisse der dritten Art von einem U.S. User mit ICE 120 HV, durch einen ICE2 HV 40, den ersten HV, den ich in die Hände bekam. Genauer gesagt, es waren zwei. Der erste hat partout meinen Gasimpuls stochastisch missverstehen wollen (willkürliche Anlauferscheinungen im Sekundenbruchteil, Stottern), er verabschiedete sich dann auch bald in die Ewigen Jagdgründe, - der zweite verhielt sich wesentlich ziviler mit JLog, war aber auch nicht koscher bzw. zufriedenstellend.

Somit konnten Linus und ich eingangs nur zwei Dinge konstatieren:

1. Ein ICE HV, also mit Optokoppler, verhält sich anders als ein ICE LV, ohne Optokoppler, mit BEC. Während es mit einem LV nie Probleme gab, konnte ein HV u.U. komische Effekte zeigen, und zwar in beide Richtungen, im Verständnis des Link Live Impulskinos durch JLog, im Verständnis des durch JLog zu invertierenden Gasimpulses durch den ICE HV.

2. Es gibt ganz offenbar Exemplarstreuungen bei den ICE HV. Je nach Glück oder Unglück des Käufers geht es von "problemloses Zusammenspiel mit JLog" über stochastische Ausreißer in durch JLog gelesene Daten und gelegentliche impulshafte Anlaufattitüden des CC, wenn er lange mit Gas Null an JLog steht (man muss drauf achten, um es zu bemerken), bis hin zu ständig und heftig springenden Datenwerten auch im Stillstand und teilweise sogar Stottern des CC im Lauf.

Nun ja.., man schaue sich mal die Steuerplatinen der CC an.. Das graust'n Toten, keine rgelmäßige Ausrichtung der Bauelemente, oft nicht richtig auf deren Pads, systematische Position eines Kondensators auf halb sieben. Nicht nur bei Deutschen Erbsenzählern fiele so was klar unter Ausschuss. Tja, nachdem man das (angeblich) in Kansas fertigte, geht so ein Elektronikschrott 1:1 in Kundenhände. Dass die Dinger preisgünstig sind, rechtfertigt nicht so eine megamiserable Fertigungsqualität. -- Was muss man da wohl hinsichtlich der Design-Qualität mutmaßen?..

Noch was Technisches:

- Im ICE HV sind zwei Optokoppler auf der Gasleitung, einer inbound für den Gasimpuls, einer outbound für den Datenimpuls, den der ESC im Protokoll "Castle Link Live" senden kann, wenn enabled per Setup Tool "Castle Link". Dann muss der Gasimpuls invertiert kommen, statt high-aktiv low-aktiv, was hier Aufgabe von JLog ist, schließlich muss er nach jedem Impuls auf den Datenimpuls des CC hören. Der HV hat kein BEC, die Elektronik im ESC (Prozessor, Driver) versorgt sich selbst. Obwohl es auch ohne geht seitens Castle Link Live, verrät ein Blick auf das Platinenlayout, dass der Outbound-Optokoppler eigentlich erwartet, dass man auf den roten Draht der Gasleitung + R/C-Spannung legt! Castle Link Live erfordert außerdem einen Pullup <=2k auf der Gassignalleitung, den JLog2.5 enthält, per Software zugeschaltet, mit JLog2 macht das JCC.

- Lt. Auskunft von Castle um 3 Ecken verwendet ein Edge HV keinen Optokoppler. - Leider hatten wir noch keinen Edge in den Händen.

----------

Nun zu dem, was getan wurde:

Also, hier will ich nicht wirklich in's Detail gehen, - es würde Euch langweilen, bzw. würdet Ihr Euch nach Bedarf und Möglichkeit auf Euer Nichtelektronikersein zurückziehen. Was man sagen muss: Das Ganze ist komplex. Die verschiedenen Erscheinungsbilder haben nicht alle dieselbe Ursache. Es gibt auch keine Pauschalität hinsichtlich Schuld und Unschuld zwischen CC und JLog. Und wir müssen uns immer noch eingestehen, dass uns nicht wirklich klar ist, warum nur ein ICE HV diese ganzen Probleme zur Erscheinung bringen kann. Dazu bedurfte es eines kompletten Reverse Engineering des ICE, wofür wir weder Zeit haben, noch haben wir im Moment besonders viel Lust darauf. Wie gesagt, das Beäugen der Steuerplatine macht Ekelpickel. Ich habe jetzt auch lieber erst mal das Meinige getan, bevor ich mir eine Demotivationspille abhole, also tatsächlich in Kontakt mit der Entwicklung von Castle trete. Danny, unser Amerikanischer Master Reseller, hat ja einen Kontakt vermittelt.

Ich habe mich also ersatzweise auf die Mitschuld von JLog konzentriert. (Nur, warum wird die nicht praktisch wirksam mit einem ICE LV?..) Das betrifft a) den Weg des Gasimpulses via JLog, b) das zeitrichtige Lesen der Datenimpulse des CC, die Zeit ist ja hier das Maß für einen Wert. Außerdem habe ich zu b) die ohnehin notwendige State Machine um die CC-Daten herum erweitert (der CC liefert, ebenso wie der JIVE und teilweise auch der KOSMIK, in verschiedenen Betriebszuständen ([Nicht}Kommutierung und Anlauf) Mist in den Daten). On top gibt es nun einen ziemlich deftigen Anti-Hazard-Mechanismus, um Fehlimpulse auszublenden, und als Kompensation dessen einen Integrator auf jedem Wert, da der Antihazard den Verlauf der Datenwerte sonst allzu "eckig" macht, was zumindest im Log doof aussähe. Der Antihazard kompensiert auch Unzulänglichkeiten von JLog, nicht immer zur rechten Zeit die Datenimpulszeit feststellen zu können, ist gleichzeitig ein gewisses Pflaster gegen Einstrahlungen in die Leitg., vor allem gegen gelesene Zombie Impulse, die durch Erdschleifen entstehen können.

Eigentlich ist das ja Penauts, den Gasimpuls zu invertieren. Tja.., in Hardware, wenn man diese in weiser Voraussicht auf seinem Device vorsah, nicht aber grundsätzlich gleichermaßen in Software.. Klar doch, habe ich einen Gegencheck gemacht: Nehme ich mir einen Arduino, 10 Zeilen Programm, und alles ist goldgelb. Man pollt den Gaseingangspin (GPIO Input) und gibt auf dem Gasausgangspin das Gegenteil aus. Selbst dabei kann die Impulslänge schon verändert werden, aber eine Mikrosekunde ist eher Peanuts, obwohl bereits ca. 1,25 Promille des Gasweges.
Jlog hat aber parallel etwas mehr zu tun, es gibt einige parallele, zum Teil auch sehr zeitktische (bei bestimmten Telemetrien) Prozesse. Ergo hat einfach alles interruptgesteuert zu erfolgen. Dieses Invertieren des Gasimpulses steuert ein sog. Pin Change Interrupt. Nur leider ist der Prozessor in JLog2 und 2.5 nicht besonders geeignet für einen absolut zeitkritischen Prozess (wir wollen ja absolut just-in-time auf den Zustandswechsel des Gasimpulses reagieren, wir wollen ja sehr genau den Abstand des Datenimpulses vom Ende des Gasimpulses messen). Es gibt weder eine programmierbare "State Machine" in Hardware, wie in einem NXP ARM, z.B., die das Invertieren in Hardware machen könnte, noch eine priorisierte Interrupt Vector Chain, jeder kann jeden unterbrechen in der MCU des gegenwärtigen JLog.
So kann es also passieren, dass JLog zustandsabhängig mit einer gewissen Verzögerung auf einen Zustandswechsel des Gaseinganges reagiert. Die Folge ist eine impulshafte Fluktuation der Gasimpulslänge. Peakt so ein Hazard über 10% relatives Gas, kann der ESC im Stillstand (Gas nominal Null) mit einem hörbaren "Anlaufversuch" reagieren.
In umgekehrter Weise kann sich JLog selbst Fluktuation in die gemessenen Datenimpulsabstände (500..9000us) einbringen, bzw. dekalibriert er sich u.U. stochastisch mal für einen Datenframe, weil er den Kalibrierungsimpuls falsch las, sozusagen zu spät auf die Uhr schaute.

Anhand des hier vorliegenden ICE2 40 HV wurden beide Problemkreise durch Tuning (Gasimpulsinvertierung) bzw. o.g. Filtermaßnahmen solange bearbeitet, bis es absolut keine Effekte mehr gab. Das passierte je Firmware, also je Telemetrie, denn gerade die jeweilige Telemetrie ist es, die Probleme des Interruptssystems zum Tragen bringen kann in Bezug auf die Ausübung von Castle Link Live.
Allerdings ist damit nicht gesagt, dass mit einem Extremexemplar eines ICE HV dadurch auch alles koscher ist, besser wird es auf jeden Fall.

Zu diesem Filter, Anti-Hazard:

Ein Datenframe im Castle Link Live besteht aus 12 Time Slot. Ausgehend von der Standardgasimpulsfrequenz von 50Hz (die man nicht groß überschreiten sollte, der maximale Datenimpulsabstand erfordert das), dauert es also bereits 12x20ms=240ms zwischen zwei Updates eines Datums. Das ist schon mal nicht gerade Rakete, aber noch im Rahmen des Üblichen (R/C-Telemetriesysteme). Der Anti-Hazard will einen definierten Änderungsbetrag eines Wertes 4x hinterander sehen, bevor er ihn übernimmt, - 4x240ms=960ms, tja.., wo gehobelt wird, fallen Späne..
Um jetzt dem Datenverlauf das Eckige zu nehmen, läuft jedes akzeptierte Datum danach in einen Integrator, der macht, dass es im Log sexy rund aussieht. OK, seitens des Just-in-Time kann das bei Weitem nicht mit einem JIVE mithalten, z.B., aber das täte es auch ohne Anti-Hazard bereits nicht. -- Also, nach meinem in mittlerweile 3 Jahren entwickelten "Feeling" für diese Sachen, ist das durchaus noch OK.

Was der ICE selbst macht:

Genau, daher u.A. "komplex", what you see hat eben nicht immer dieselbe Ursache. (Gleichzeitig kann das als "Indiz" dienen, dass auch dem Design der CC nicht zu trauen ist.)

Ubat fluktuiert grundsätzlich, und "genau" ist hinsichtlich einer Messung durch einen CC eh nichts.
Der ICE2 40 HV hier: Die Betriebsspannung beträgt ganz genau 25,0V. Er zeigt im Mittel 24,4V. Die Fluktuation des Messergebnisses durch den CC beträgt ca +/- 0,3V mit Ausreißern. Das misst ER, nachzulesen in seinem eigenen Log, wenn man es mitlaufen lässt.
Noch besser: Mit steigendem Strom steigt auch die Spannung, bei 17A sind es bereits ca. 1,5V mehr, obwohl real die Spannung sinkt.
Tja.., beides hat dieselbe Ursache, designtechnisch direkt als Anfängerfehler zu bezeichnen. Ich würde aber eher sagen, es ist dem Bestreben, es möglichst billig zu machen, geschuldet, und es zeigt ein weiteres Mal, dass Castle hinsichtlich solcher Design Bugs einfach mal absolut schmerzlos ist:
Man misst mit einem Low Side Shunt, also in der Minusleitung zum Akku. Dadurch produziert man sich eine schwimmende Masse. Das Ergebnis ist, dass der Spannungsabfall über dem Shunt sich im Übersetzungsverhältnis des Spannungsteilers auf Ubat addiert. Digitale Artefakte auf der Spannung führen zu dieser ständigen Fluktation i.H.v. ca. 2% und mehr.
Dazu gehört auch, dass der ICE im Stillstand ständig einen Batteriestrom misst, der fluktuiert und bis an 1A reichen kann, - dieselbe Ursache.
Die State Machine in JLog macht das jetzt einfach platt, Null Ampere, wo in Wirklichkeit nix nennenswertes fließt.

Wg. der neuen JLog Firmwares, JLog2.5 und JLog2, siehe Download. Dazu auch ein neuer JLC!

_________________
Tom

Mensch Tom, Linus und Heli-Freund,...
Mir fehlen die Worte !
Ihr habt tatsächlich die/eine Lösung gefunden!

Was soll ich sagen? Danke, Danke, Danke!
Es wird morgen abend noch ne groß-flash-aktion meiner beiden JLOG2 geben.
Samstag dann testen!
Habe die Hoffnung, das nicht nur diese komischen sprunghaften Einträge im Log und Motor-anlaufzucker (äußerst selten bei mir und nur bei einem Exemplar) verschwinden, sondern auch das micro-stottern der Regelung mit VStabi als Govener und dazwischen geschleiften JLOG2.

Super Sache! Ein " Loblied" auf euch!

Gruß

Kay

Erst loben, wenn's bei Dir hilft!

Ich sage Dir, unser nächstes Device wird ein Gameboy, da haben wir wenigstens nur noch Berührung mit dem Anwender.

_________________
Tom

Hallo Tom,
alles sch.. es ist schlimmer wie vorher...
QUAAAATSCH! War Spass!
Im Gegenteil, Test 1 im RJX90 (ICE2 120 HV) erfolgreich bei 4 Flügen bestanden.
Keine sporadischen Temperaturwarnungen mehr (Die im LOG parallel gingen mit GAS-Puls-Ekelpikeln)
Die LOGS sehen Zucker aus jetzt (bis auf eine Ausnahme wo mal die Spannung auf 0 kfr. einbricht)
Siehe selbst in den Logs

Wen morgen der Laos (auch 120er HV) keine GAS-Aussetzer mehr hat (Vstabi Gov.), mach ich ne pulle Srkt auf dich/euch auf.

Ja.., sieht OK aus soweit.

In Logfile 285 gibt es bei 4:25 einen Einbruch von Ubat, der nicht real ist. Tatsächlich muss dort der Datenimpuls sehr oft mit geringem Abstand gekommen sein, oder es wurde was anderes auf der Leitung als Datenimpuls erkannt.

Die zwei DZ-Einbrüche in Logfile 287 werden wohl auch nicht echt sein.

Es ist so: Wenn JLog evtl. schuld sein sollte, dann sind das Wertausreißer in positiver Richtung, aber moderat, JLog schaute zu spät auf die Uhr, gewissenmaßen. Solche Effekte wurde aber mit den jüngsten Änderungen herausgetunt worden. Extreme Positivausreißer sind vom Castle oder von der Leitung, Fremdimpulse. Negativausreißer sind entweder in der Verantwortung des Castle oder Schweinereien auf der Gasleitung, die zu dem Mißverständnis führten.

Insgesamt gesehen, scheint es ja was gebracht zu haben. Das liegt aber neben erwähntem Tuning vor allem an dem aufgebohrten Anti-Hazard, was letztendlich quasi "Schmerzmittel" ist, nicht die Wunde wird geheilt, die Schmerzen werden genommen. -- Es bleibt aber ein Wettlauf zwischen Hase und Igel, - dem Castle ist nicht über den Weg zu trauen, zu viele Modellunterschiede, vor allem zu viele Exemplarausreißer, die Probleme, die Erdschleifen und Einkopplungen gerade bei so einem Protokoll machen können, kommen on top.

----------------
Lies mal hier: http://www.helifreak.com/showthread.php?t=571977
Die ICE scheinen wirklich jeder anders zu sein, die Modelle der ICE-Serie, die Exemplare eines Modells. Obwohl alle einen Low Side Shunt haben, macht der ICE 120 HV nicht den Blödsinn, den der 40 HV macht, offensichtlich. Ist das nun systematisch oder setup-bedingt?
Dafür hauen bei dem Menschen hier wirklich sämtliche Werte ab, sobald Strom fließt, also selbst die Nullwerte Ubec und Ibec rutschen nach oben.

Angesichts des neuerlichen Aufwandes, angesichts dessen, dass es bei Seasick78 einfach nur die Sicht auf weitere Probleme frei gab, angesichts des fortwährenden unverschuldeten Imageschadens für JLog, - hatte ich Linus vorgeschlagen, den CC komplett zu entfernen aus JLog. Linus will aber, dass noch mal investiert wird für Investigation. So soll's also sein..

_________________
Tom

So, ein weiterer Bericht + Logs der 5 Flüge heute Morgen mit meinem Laos (Ebenfalls ICE2 HV 120).
Du erinnerst Dich: hier hatte ich in Verbindung mit dem VStabi Governer alle 20-30 Sekunden kurze sporadische micro-Gasaussetzer, welche sich dann auch mit minimalem Heckschlagen bemerkbar machten.

Auch hier war eure Forschung und Deine Programmierarbeit ein voller Erfolg!
Die Aussetzer begrenzen sich nun auf 2-3 pro Flug, das hört und sieht man, es läuft einfach "runder".
Auch die Log's sind so wie ich das auf den ersten blick sehe völlig ohne Schweinereien.
Was mich allerdings wundert (aber das war auch schon vorher an den Laos Logs so: die höchste Drehzahl müsste um die 1800RPM sein. Der JLOG zeichnet ca. 1700RPM auf, und zwar FLAT, völlig geradlinig. Die PWM ist zwar auch fast permanent per 100%, aber das die Drehzahl 0,0 Änderung haben soll ist irgendwie seltsam (Siehe insbesondere Log0080)

Das die Programmierungsänderung nur Schmerzmittel gegen die Symptome sind ist klar, aber es sind echte gute Painkiller . So wie es jetzt ist reicht mir persönlich!

Kam den ein Ergebnis raus als Ihr Kontakt zu Castle Aufgenommen habt?
Ich meine: damals als sie damals diese brennenden Regler hatten, wollten Sie erst auch nicht einsehen, das das von Ihnen verschuldet war. Erst als sie dann ein Elektrotechnik Spezialist aus dem RC-Groups Forum auf einen fatalen Design-Bug eines Bauteils gebracht hat haben Sie es offiziell zugegeben (bzw. selbst erst erkannt wo der Fehler liegt).

Auch wenn es frustrierend für Dich sein mag, wenn hier einfach nur "Mist" aus manchem Reglerexemplar rauskommt... ein einfacher Anwender wie ich kann nur seinen Hut vor Dir+Linus ziehen! Einfach toll was Ihr da macht, der JLOG2+JLOG2.5 sind jeden Cent Wert!

Hab ich schon DANKE gesagt? --> DANKE, DANKE, DANKE!

Anbei die Logs, nicht über den überwiegend niedrigen Stromverbrauch wundern, heute war meist Low-RPM slowfinger 3D angesagt

Nachtrag:
Krasse Streuung übigens bei den gemessenen Kapazitäten zu geladenen Kapazitäten (gerade zum ersten mal verglichen beim Laos, beim RJX hab ich ja gewusst es passt)
Bei 3 Stichproben beim 120HV im RJX beträgt die durchschnittliche Abweichung +2,1% - Bandbreite 1,2% bis 3,2% (etwas mehr gemessen wie verbraucht) = i.o.
Bei 5 Stichproben des 120HV im Laos beträgt die durchschnittliche Abweichung -23,5% - Bandbreite -18,4% bis -27,5% (deutlich mehr verbraucht wie gemessen) = Shunt-Kalibrierung notwendig.

Vermute: niedrige Ströme verursachen Messfehler (hast ja mal irgendwo geschrieben). Zum Glück bin ich (noch) nach Timer im Laos geflogen.

Ja, ist prinzipiell so, die Auflösung spielt dann eine größere Rolle.

Aber hier wird der Shunt im Castle einfach mehr abweichen.


Das liegt leider an dem Anti-Hazard: Erst macht der den Ignoranten gegenüber Änderungen, die müssen eben 4x hintereinander auftreten, wenn sie einen gewissen Betrag überschreiten, dann bügelt das noch ein Integrator platt. Ich müsste da evtl. noch was am Filter für den RPM-Wert machen, dass der die kleinen Wackeleien durchlässt und nicht glatt-integriert.
Von daher sind Deine Real-Logs sehr wertvoll! Danke!


Nein, mit denen haben wir noch kein Wort gewechselt.
Ehrlich gesagt, ich fürchte zu 100%, dass das eh ausgeht wie das Hornberger Schiessen.

_________________
Tom

Anti Hazzard kam mit welcher Firmware? Jetzt erst oder war da schon früher was???
Ich hab das Problem schon immer mit der hohen DZ und "Flat-Line" bei 1700RPM (in Real müssten es etwas über 1800sein)!
Hab mal n altes Log vom Sommer beigefügt.

Das "Flat-Line" bei 100% Throttle tritt jedoch nur im Laos (mit Vstabi Regelung) auf, im RJX mit Castle-Interner Regelung passt die hohe DZ! Nicht das Du was versuchst rauszumachen was nur bei mir (aufgrund Konstellation ...) wäre...