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.