If you want to use the Brain2 flight controller’s governor with the Neuron II 80A ESC alongside telemetry, then you cannot use the F.Bus protocol in the receiver; instead, you must use the Smart.Port telemetry serial protocol, which is separate from the S.Bus radio channel serial protocol.

The Neuron II 80A ESCs do not have the motor rotation pulse output required by external governors as a feedback signal; therefore, if you want to use the Brain2 flight controller’s governor, you must use one of the many external electric motor RPM sensor with real-time PPM output pulses to connect to the flight controller’s GOV port (the telemetric RPM signal is too slow (LS=Low speed) to inform the flight controller’s governor of RPM changes in real time).

NOTE: The S.Bus serial protocol used to update the radio channels is “slower” than the F.Bus protocol because the S.Bus serial signal has a baud rate of 100,000 bps instead of the 460,800 bps of the F.Bus serial protocol. The Smart. Port telemetry is slower than the F.Bus serial telemetry protocol because Smart.Port has a baud rate of 57,600 bps instead of the 460,800 bps of the F.Bus serial protocol.

By connecting the blue wire from the ESC to the signal pin of the CH1 connector on the Brain2 flight controller, when powered on, the ESC detects the presence of the Throttle PWM signal on the blue wire. Instead of being controlled directly by channel 3 in the radio channel frame, it is controlled by the PWM signal it receives on the blue wire.

Why, in the event that a PWM signal is present on the blue wire—even though the throttle signal is no longer read from the F.Bus radio channel frame—the telemetry signal is also no longer read from the F.Bus frame, is a mystery that only FrSky can answer and explain why they did not do so.

The same applies to the LUA configuration app, which does not work on ETHOS; in fact, it blocks the ESC’s telemetry and forces you to power cycle the ESC to reactivate the telemetry.
Even the EMBEDDED settings in ETHOS for Neuron II ESCs (Device config => ESC => Current / SBEC) not only are very limited to just two options, but they also do not work.

The telemetry parameters transmitted by the Neuron II 80A ESCs are:
ESC Battery Voltage: OK
ESC Battery Usage: OK
ESC Battery Ripple: OK
ESC Low Speed RPM: OK
Temperature 1: OK

ESC Bec voltage = Servo Voltage

ESC Power Output: NO!
ESC BEC Current: NO!
Temperature 2: NO!

The tests were carried out using: a Tandem X20 transmitter with Ethos version 1.5.3, an Archer RS (not Plus) with FW 2.1.10, a NEURON II 80 ESC with FW 11_5, and Brain2 FW 3.4.158.

How should I wire the ESC to Brain? I use ETHOS Tx with FBUS Rx.

In this specific case, the only parameter that needs to be checked among those included in the default setup of parameters to be logged is “RxFrameRate” (use the “Reset Logs to Default …” command in the File menu).

Since the problem relates to radio signal reception, the other QOS (Quality Of Signal) parameters might be of interest: RxFades, FrameLosses, Holds, RSSI (if the receiver also sends this value).

Unfortunately, in the first log (0646), the “RxFrameRate” parameter is missing.

Fortunately, in the subsequent logs, the “RxFrameRate” parameter is present and indicates major issues with radio signal reception.
In fact, the situation is even worse than in the first log sent on 4/16.

Unfortunately, the latest log (916) also highlights serious signal loss issues, and with such a graph, flying is absolutely not recommended because losing control of the model could cause serious damage to property, animals, and people (damage to the model, even if costly, is far less significant):

What we can suggest at this point is to try installing another receiver if one is available on another model to verify that it hasn’t fallen and might be damaged in some way.

Among other possible suggestions is to twist the cables, as this reduces high-frequency interference on the signal cables to some extent (it has the same effect, albeit reduced, as when ferrites were used to wrap around the cables to filter out high frequencies).

Another suggestion is to secure the connectors to the flight controller and receiver by applying a strip of hot glue (which can be easily removed by peeling it off) between the plastic of the connectors and the upper edges of the flight controller and receiver casings.
This will help prevent potential false contacts caused by vibrations generated by the motor.

Also check that there are no cold solder joints on the six connectors linking the motor to the ESC by bending the wires entering the male and female connectors, ensuring the male connectors are firmly seated in the female connectors and that there are no loose or loose connections.
Perform the same check on the two male and female connectors linking the battery to the ESC.

Check that the screws securing the motor are not too long and might rub against the motor windings during rotation. If necessary, add washers under the screw heads.

The final suggestion—though highly unlikely and to be used only as a last resort—is to apply bearing grease to all bearings (motor, main shaft, tail shaft) to reduce metal-to-metal friction.

Good morning (evening) BrainDev,

I apologize for this taking so long, but I had a lot of Homework to do from your last two Replies.  I'll list the steps taken below, and upload files as I go.

First, I began Continuity Checks as requested. Everything in front of the Tail Boom, with the exception of the ESC Case and the Main Shaft had continuity. The Tail Rotor Assembly had continuity within itself, however, as with the Main Rotor Shaft, the Tail Rotor Shaft had no continuity with through it's bearings to the rest of the assembly, or for some reason, to the Main Chassis/Body.  This is the baseline RT and Events. Dismal.

Next, I completely disconnected the Tail Belt, and ran a short test. The results were very similar, pretty much ruling out significant Tribo-Electric charging from the Tail Belt messing with the Rx, at least as the main driver of this interference.

Now, I turned off the Governor on all Setup Phases (IU1, 2, and 3), and set a straight curve on Normal. Checking ALL wiring, everything was in order, however I did find a broken Rubber Lord Mount under the FBL Plate (Soft Mount), and I replaced that. I also changed the Ground from the Governor Port, adding a Ground Wire and Positive Wire to the SCM on the Output side, from the Governor Port, to the "P" side of the SCM Output. A short test was completed.

Results were still the same.  Now, I completely unplugged the Telemetry Wiring from the ESC Data Port to the SCM, and from the SCM to the 5 Pin of the 4-5-6 Connector, and removed the Ground and Power Pins from the Governor Port Connector that were connected to the SCM Output.  Literally only a Throttle Control Connector to the Ikon2. I also temporarily installed a piece of small gauge wire, as used in Breadboard Prototyping (wire-wrapping) from the Tail Rotor Housing, externally to the Main Chassis, and checked continuity. That was good. I did run a test at this point, however it was still dismal, and the same as the previous tests.

Test results were still horrible. 

I began studying the Hobbywing Documentation for the V4.1 200A OPTO, and the SCM Module that came with it.  I noticed that for some reason, the V4 130A differed from the V4 160A and 200A regarding connections from the ESC to the Brain2 and the ESC Data Port to the SCM Input side, and from the SCM Output side, to the Brain2, which are both wrong on the SCM Output, as they have Users plugging the complete Output Connector into the 4-5-6 Telemetry Connector, complete with Power and Ground. If someone wasn't familiar with the Brain2/Ikon, it would instantly be damaged upon powerup.  Documents are below.

So .. With all things not working so far, I figured go for broke, and follow the Wiring Instructions in the SCM Manual for the V4 130 Opto, instead of the Instructions for the 160/200A.

I removed the Yellow RPM wire (part of the 4 wire bundle from the ESC) from the Ikon2 GOV Port, and put it on the Rx "R" Port of the Input side of the SCM.  Next, I used a M-M Jumper from the SCM Output side, from the Rx Port to the Ikon2 GOV Port. 

The other part of the 4 wire bundle wire (Throttle) remained the same, with the White-Red-Black from the ESC (between the Motor Wires) going directly to Ikon CH1 for Throttle.

The HW supplied Telemetry Y Cable from the ESC Data Port has the Fan on the short Leg, and the other Leg now has it's long wire running to the SCM Input side, to the "P" Pins.  The Output side of the SCM has the "P" Pin going to Pin5, and the "R" Pins (W-R-B) are now plugged into the Ikon2 Governor Port.

With the exception of the Throttle WH-R-BL, now all of the Wiring from the ESC and Data Port is isolated by the SCM.  I ran a test with this configuration, in Linear Throttle, no Governor.  SIGNIFICANT improvement. Not 100%, but much better. It was the Governor Wire introducing the hysteresis into the Brain2/Rx, and messing with things. Files below.

The Events and RealTime Logs still show some random Bank (setup) switching, and there was a very tiny bit of servo jitter, but for the most part, this is a huge improvement. I still have a huge amount of vibration at intermediate Throttle, and I'm going to have to chase that down, and also find out what is causing the small amount of jitter and random Bank switching. There was also a Rx Signal Off, and Throttle gone in Fail Safe Event at the last part of the Events Log, But I believe that is where I unplugged the Flight Battery, shut off the 2S Rx Battery Switch.

I have not included the Config File, as it basically has not changed from the original.  I do apologize for the Book here, but I wanted to cover all the steps completed, and show results for each task. I'm still not 100% confident in the HW ESC and the KDE Motor, and I'm extremely hesitant to fly this combination, even if I do get it 100% worked out at this point. Way too many issues.  I do hope this experience will help someone in the future though, especially with the SCM and a NOS or used HW 200A Opto.

As always, thank you in advance for any information or suggestions.

Harry.

(small movements of the flight controller generate small movements detected by the gyroscopes, which can cause slight movements of the servos—and this is normal)