Moin Micha!
Mit CC hatte ich noch nie Kommunikation.
Ich habe das rein zufällig bemerkt und nur im CLL Mode getestet. ...natürlich auch nur mit EINEM Opto ESC, 120HV. Habe ja kein Lager von so was.
Ich gehe davon aus, dass es am Opto-Eingang liegt. Castle hat mMn eine etwas hemdsärmlige Ankopplung für CLL nachträglich eingebaut. Der Output (Data Pulse) ist auch nicht galvanisch entkoppelt, der O-Koppler ist 1-way, sondern das erfolgte einfach nur per C, angezapft (Koppler überbrückend).
Ich weiß nicht, ob es daran liegt (eher nicht) oder an einem grundsätzlichen Design-Problem bzgl. des O-Kopplers, reiner Input in den ESC.
Der Koppler braucht natürlich Betriebsspannung an der Außenseite, und die kann dann auch nicht von ihm selbst kommen, wenn man galvanisch trennen will. Ulkig ist nur, dass Gasimpulse stochastisch mißverstanden werden, wenn sich die Spannung in besagtem Fenster befindet. Bemerken konnte ich das auch nur,
- weil das Auswirkung auf CLL hat (Oszi dran),
- weil durch die Verkopplung mit CLL (Interface transceive genutzt) Rückwirkungen auf das Lesen das Gasimpulses entstehen.
Eine Erklärung fällt mir erst mal nicht ein, - ist schon ungewöhnlich für die Applikation eines stino O-Kopplers..
Zum prinzipiellen Verständnis: Das habe ich kürzlich bei HF geschrieben:
Zitat:
Well.., normally only the throttle pulse length is of interest for an ESC.
...pulse frequency as well but not as part of the information to transfer than only as an approximate limit - depending on the design of an ESC.
Important: Wether a pulse is phase true in sequence does not matter in pure unidirectional use of the line.
With Castle's "Link Live" everything changes:
The ESC is not only a pulse receiver, than it works transceive, - pulse receiver / (data) pulse transmitter.
Now in fact it is important
- that pulse frequency is within certain limits, from protocol (CLL) theory 100Hz at max, better to stick with standard 50Hz (Castle does not specify anything regarding that)
- pulse comes equidistant in time, phase true, no frequency jumps
- So requirements for an "elctrically clean" line are higher. There should be no chance to missinterprete a glitch. ..difficult to ensure in practice where ground loops or interference may come into play.
If the above conditions can not be guaranteed:
- Time distance of a data pulse could be read wrong, so stochastically bad data in log, telemetry, alarm condition review.
- The ESC could miss a pulse (throttle) or read some with wrong width.
Everything depends on one another. This receive/transmit changing represents a state machine which should be not confused by interference.
Running on its own governor an ESC could be less sensitive for glitches in pulse length reading, could...
Controlled by an external governor the ESC has no way to implement an anti-hazard. ESC has to follow the input pulse, slavish, "throttle" turns into "pwm" so to speak.
As a preventive measure I changed JLog's implementation for inverting of the input throttle pulse. Originally I just inverted the pulse, but this involves all chances to pass-through problematic issues, improper pulse frequency, frequency and phase jumping. Now "ownpulse" decouples it: JLog produces a frequency and phase stable 50Hz inverted pulse to the ESC. On the input JLog has the condition which an ESC normally has (w/o CLL). JLog as pulse receiver, unidirectional only, does not care about frequency and phase jumping. Unfortunately there is no way for "ownpulse" implementation in JLog2.x if its OPT port is occupied by I²C based telemetry (SPEKTRUM, HiTec).
You can see: If the governor of a FBL system is used as pulse source chances for problems are especially high. On the other hand "ownpulse" should be able to cure most root causes before they can come into effect.
CC+JETI: Which version of JLog firmware did you try, with "ownpulse" or without?
Now, of course, any measure is meaningless if the ESC refuses to read pulses for a pure electrical reason, topic of this thread.
Anmelden
Registrieren
FAQ
Suche
