Governor acting werid in 3.4.013

Rereading the release notes and from memory we do not remember to have introduced changes in the governor routines even if obviously we will do a thorough check.
Checking the flight log sent to us we notice some RPM oscillations typical of when both the ESC governor and the flight controller governor are active and conflict with each other. Regardless of the fact that with the old firmware 3.4.000 the problems seem to disappear, are you sure that the ESC governor is deactivated?
Have you tried firmware 3.4.012? How does it behave?
It would be useful to have also a flight log with firmware 3.4.000 with the exact same configuration as the flight log already sent to us.

       

Posted by: @customercare

Rereading the release notes and from memory we do not remember to have introduced changes in the governor routines even if obviously we will do a thorough check.
Checking the flight log sent to us we notice some RPM oscillations typical of when both the ESC governor and the flight controller governor are active and conflict with each other. Regardless of the fact that with the old firmware 3.4.000 the problems seem to disappear, are you sure that the ESC governor is deactivated?

I'm sure nothing changed in Brain or ESC settings between 3.4.000 and 3.4.013. 
I'm also 100% sure that governor in the ESC wasn't activated, because Neuron does not have it's own internal gov.

On 3.4.000 everything works great  - spoolup is smooth, bailout works nice, Headspeed is stable and "strong" during entire flight.

The moment I switch to 3.4.013 - everything gets screwed up, it sounds like ESC is trying to burn my motor.

I wasn't able to download and upgrade the firmware to 3.4.012 - this version didn't show up on the list on my phone. Now when I connected Brain to my PC I can see it - I'll try flying on this firmware and get back with results.

I've asked on FB group about this issue and if seems like I'm not the only one to notice something strange 

Thank you for the information and clarification.

Ok, so I tried flying on 3.4.012 today.

Not flyable - same thing as with 3.4.013.

I had to go back to 3.4.000.

Are there any news regarding this potential bug? Is it safe to update now, or should we wait for 3.4.014?

Thank you for reopening this post from four months ago.
In the meantime, we had rechecked the firmware and saw that there is actually no "bug".
In the firmwares 3.4.012 and 3.4.013 we had only modified the RPM reading routine by reducing the filtering of the rotation pulses received from the GOV port and used also by the Governor of our FCUs.
This allowed to obtain a very small improvement in the governor response speed. Since the improvement obtained was very small, we did not even report it in the Release Notes.
However, we have also received via E-mail, via Form on our website and via "Support Request" some other negative feedback from some users who use electric models with ESCs that transmit particularly "dirty" rotational pulses. In particular, with Castle Creation ESCs. No user with Nitro or Gasser models has ever reported any problems.
Only very few users with other ESC models have reported problems but they were due to cross talk of the RPM pulse cables with the power cables of the battery and/or motor. Problems were solved by moving the cables or twisting them to obtain a minimum of filtering and shielding.
The problem of this small part of users is generated when the flight control unit does not receive valid and "clean" pulses for a long time and therefore considers that the engine has stopped and then reactivates the soft start to restart the engine gradually.
Also in these cases it is enough to activate in ADVANCED the checkbox "Governor use Bailout" to obtain a fast restart of the engine as soon as the pulses become normal again.
Almost all users who had this problem landed using the normal autorotation procedure that is normally used in case of mechanical transmission failure, motor failure or ESC failure.
Regardless of the Firmware version used, it is possible to check the "quality" of the rotation pulses received by our flight control units. Just select in DIAGNOSTICS one of the two parameters "Main Rotor 0-3000 RPM" or "Main Rotor 0-6000 RPM" (depending on model size) that display the curve of the signals received BEFORE filtering and compare them with the curve of channel 11 of Flight Logs that displays the signals AFTER filtering and used by the governor. If the two curves are identical or very similar there is no problem. Otherwise, if the unfiltered signal curve is very dirty, it is necessary to intervene in the rotation impulse cable passage by moving or shielding it (you can also use the carbon frame as a filter by passing the cables externally or internally to separate and shield them).
Although the problem has been reported by very few users, since the improvement obtained was really very small, in the new firmware versions (the official one will not be 3.4.014 because we have already arrived at Alpha 3.4.034) we have already restored the filtering to previous values.

Thank you for the clafirication and information.
The low amount of reports may be the result of the fact that there's not a lot of people using FBL governors, most of the pilots I know holds on to internal ESC governors firmly.

From my experience some ESCs tend to produce more crosstalk on RPM and telemetry output wires - the HobbyWing ESCs appear to be most problematic. All my friends using Brain governor with HW had to switch to external RPM sensors, due to sudden power cutoffs (the RPM readings in logs were showing crazy high RPM peaks, like 200000, so the governor was cutting the power). This usually happened under high load - higher currents produce high density EM field, hence worse crosstalk on the RPM input.
External sensors always fixed those problems, up until the 0.12 and 0.13 was released.
Do you know if using opto-isolator on the RPM wire would fix those issues?
I've spend quite a lot of time and effort forcing my HW160 telemetry to work, until I've installed the HW own optocoupler (p/n 30850200) which fixed all my problems immediately. 

HobbyWing's optocoupler (p/n 30850200) was created by HobbyWing only to solve the problems of their Platinum "OPTO" ESCs (without BEC) of which now only the 130A OPTO is left in the catalog.
From the HobbyWing website it appears that the other OPTO ESCs (e.g. 200A OPTO) are no longer available. However, there may still be some available from distributors, stores and users.
All ESCs with BEC do not need this accessory.

Their manual clearly states that it should be used with HW130, HW160 and HW200, which can't communicate with Brain and other FBLs without problems https://www.hobbywing.com/products/enpdf/RPM&Telemetryen.pdf

I can confirm that, as I couldn't force my HW160 to cooperate with Brain2, no matter how good the telemetry wire was isolated, shielded of winded around ground wire 😉 

I still have one spare optocoupler left, maybe I'll give it a go with my HW RPM sensor.

But this is getting outside of the scope of this topic. Sorry for that.

Thanks for correcting the problem in the upcoming firmware ?