Watchdog/warning for lost communication frames between ESC and Brain2
I've noticed that some HW ESC's induce a lot of noise on the telemetry signal wire, up to the point where Brain2 stops recognizing telemetry data received from ESC.
What happens in this case is a bit strange - Brain2 readings "freeze" at the last correct received frame, which leads to very wrong mAh calculations.
I had a case of current reading getting frozen for a few seconds at 150A which lead to hitting mAh limit quickly and cutting down power because of that.
There's no easy and user-friendly way of noticing a problem with ESC-Brain2 communication. I can see frozen values in data logs, but average user won't recognize it.
Please add some kind of a watchdog, or at least an alarm in "Events" telling users that data packets between ESC and Brain were lost / frozen / unreadable
Typically, this type of problem occurs on OPTO models of Hobbywing ESCs because the telemetry signal output from the optocoupler of programming port is not referenced to a common ground with that used by the flight control unit, receiver and servos.
On Hobbywing OPTO ESCs, either connect the ground of the programming connector to the ground of the throttle cable near the ESC or purchase the "double signal coupler module of HOBBYWING coded 30850200" accessory from Hobbywing.
On all other Hobbywing ESCs with BECs (the vast majority) this problem has never existed.
This is also written and explained in the "Telemetry" instructions in the DOCUMENTS sections of our three apps.
We are not aware of the kind of problem you reported with Hobbywing ESCs with BEC, but if sometimes the telemetry of Hobbywing ESCs, due to a faulty firmware, gets stuck from time to time and keeps transmitting always the same values, there is no way to know for sure from our flight control units this constant value as a certain error.
Could you send us the flight log where you say you have seen this type of problem and also tell us with which model of Hobbywing ESC the flight log was obtained?
Better if you also send the FCU configuration file.
This occured on HW160v4 with BEC and occasionaly occur on HW80v4 (also with BEC).
I don't have log files anymore, as they've already been overwritten by newer ones in both cases.
On a 160 I first tried moving signal wire away from the motor and power wires and putting it in a grounded shielding - this helped to some extent (less "frozen" readings were visible in logs). Then I've put an opto coupler on and this cured my problems completely.
Me and 2 of my friends experienced similar problems on HW60, with RPM -> GOV input, where under a heavy load the rpm signal was so interrupted by RF noise that Brain interpreted it as a big spike in RPM and shut the throttle momentarly (this can be visible on those two log creenshots):
Moving RPM wire as far as possible from the motor and ESC helped in this case. I knew what to do, but 2 of my friends couldn't figure this out and they amost crashed their helis a few times, not knowing what exaclty is happening. (motors cut out for a split second when heavy loaded - fortunately those ESCs were in airplane mode, so they got back to speed quickly).
I'm not asking for a fix to those problems, as I know it's not possible to eliminate noise just by firmware update.
I'm asking for a warning in the events list, telling user that something is wrong/glitchy with received data.
In case of my HW160 everything was working fine on the ground and in a steady hover, but whenever the motor pulled higher current (= produced more RF noise) the communication got interrupted and lines on the graph were frozen on certain levels. This is why it is quite hard to find out that something is wrong.
The problem of crosstalk has always been well known.
In fact, there has always been a warning in the instructions to keep the telemetry cables away from the power cables. I hope everyone reads the instructions when they need to figure out how to connect their ESCs.
If the ESC does not have a fan and the ground pin on the ESC programming connector is free, simply leave a wire connected to the ESC connector ground and twist it to the telemetry signal wire (without connecting it to the control unit, but leaving it disconnected on the control unit side). In this way, the signal is sufficiently shielded and filtered (coupling the wires is equivalent to two armatures of a filter capacitor). Also the carbon frame that is conductive and can do as shield from other cables and high power signals.
In case of HW160A v4 moving data wire as far as possible, outside the carbon frame didn't help much.
Twisting data wire with ground wire didn't help either. Using shielded wire (grounded shield) also didn't help. The only thing that worked for me was the HW optocoupler. Without it the telemetry data kept freezing in flight.
But tips regarding dealing with crosstalk/interference is not what I'm asking for. I already know well what to do to deal with those problems due to my own experience. And I can read, I've read the manual a couple of times.
I'm asking (for a 3rd time now) for an error message in events log to let the user know that something wrong was happening during flight. ("unreadable esc telemetry data", "esc data packets lost" or however you want to call it)
Those problems are hard to recognize, because it usually happens in flight, while back on the ground everything is working well.
HW ESCs are very popular. Teir data outputs are noisy, thats a well known fact. Other systems provide such info to help users find out why for example is the governor cutting out the throttle mid flight