Still have uncommanded throttle dropping after switching from FBus to FPort

Could you better clarify how you connected the three receivers (Archer RS + R9M + R9Mx) to the flight controller?

We read on Facebook that you also use an ADV GPS sensor connected to the F.Port bus. WARNING. ADV sensors work only with F.Bus protocol. With F.Port protocol they cannot synchronize with the signal of the receivers and consequently become a strong source of F.Port signal noise.

If you are interested and would like to try, we can unlock your FCU so that it can load our latest Beta firmware where we believe that the problem of interference between YGE ESCs with simultaneously active also the three Dials and F.Bus / F.Port protocols have been completely solved but where with F,Bus there still remain some small problems of transmitter "Telemetry lost" message (but only when the FCU is connected to Windows / Android / iOS apps).

Sure.

Archer RS is connected to ikon2 ch 3 using FPort.

R9MX enhanced sbus out goes to Archer RS sbus in.

GPS adv sensor is connected to R9MX using Sport.

R9M 2019 is the 900Mhz module in the radio.

If you guys think you have this solved I'll definitely give the beta a try using FPort. (The reason I was wanting to use FBus previously was to have the GPS on the same bus but with the GPS connected to the 900mhz receiver I don't have a need for FBus.)

Regards,

Steve B.

Also just edited my Facebook post to include the fact that the GPS is connected to the R9mx with SPort.

First flight of the day & it happened again, but this time the 50Hz logs caught RxThrottle dropping to 0 for a single data point. ~20 milliseconds.

Is this something that's happening b/c of the YGE telemetry? B/c it just doesn't make any sense at all. No fail safe or anything & ONLY the throttle was affected for what I'm assuming was probably only a single frame, but there were no frame losses either.

I flew again, this time with only basic telemetry enabled, and had no issues. But that's hardly definitive b/c this isn't an issue that shows up at regular intervals. So I'll continue to fly it like that to see if it shows up again.

Logs for both flights are included in case they might be useful.

If this is an issue that's related to using YGE telemetry & FPort, I'd now love to try out the beta of your fix!

Log 6 has issue. Log 8 & config are w/o YGE telemetry.

The serial number 001621D35A711F56 of your FCU has been enabled to download Beta versions as well.

If you perform a "Manual Firmware Upload ..." from the File menu, the latest beta firmware 3.4.096 should also be visible in the list of possible firmware that can be downloaded and installed in your FCU. Select it and upload it to your FCU.

Let us know.

Thank you.

Tried out the beta and still had the issue plus now getting uncommanded rxthrottle up spikes.

Log 3 shows the one instance I had of the throttle out to zero at around 112 seconds.

Same log and others show a bunch of RxThrottle up spikes and some down spikes that don't go all the way to zero.

Prior to flight 5 I set the channel range for the R9M 2019 module outside the ch1-ch16 range handled by the archer RS b/c I thought the whole redundancy thing may not be functioning correctly and that's when the events log for flight 5 got weird. Alls kinds of bouncing around between speed 1/speed 2 selected, but I actually had speed 3 selected.

Not sure if my changing the channel range invalidates the whole flight log/event log or if that actually shows something useful.

EDIT: I've also set up an alarm in otx to alert whenever ch-3 drops & it's never gone off unless I've actually switched speeds or activated throttle hold.

As you correctly noted, now the ThrottleOut and RPMs drop only when the RxThrottle signal goes completely to zero.

In all four Flight Logs, it has never happened again (as it did before) that ThrottleOut and RPMs go to zero even when the RxThrottle signal is regularly present and stable but due to the reception of the YGE ESC telemetry and Dials reading.

This is a significant step forward and is what we wanted to achieve.

Therefore, it seems that the problem now is only in the signal received from the receiver.

It would therefore be much more useful to log the Rx Fades parameter and/or the RxFrameRate parameter instead of the Frame Losses parameter.
The Frame Losses parameter only goes up if "at least" 45 Fades occur, which must also be all 45 consecutive without ever a valid frame return. Instead, there seems to be a short error in the signal received from the receiver that surely lasts less than 45 frames but brings the governor signal down.

In addition to this, it would also be interesting to try only one receiver at a time (either the Archer RS or the R9MX), to see if there is a problem in the firmware of either receiver when they are linked together to achieve redundancy.

This is also because the radio channel values are accepted (and thus processed and logged) only if at the same time: the expected number of Bytes is received, the checksum received matches the checksum processed for the bytes received, neither the Frame Lost bit nor the Fail Safe bit has turned on in the received frame, and the RSSI of radio signal value is greater than zero.
Otherwise, if even one of these is invalid, the received frame is considered invalid and the last valid value (Fail Safe Hold) is held for the various radio channel values, the value of RxFades is incremented, and the RxFrameRate value (time between two valid frames) doubles.

Thus, it appears that the abnormal throttle signals were transmitted by the receivers within a valid frame, otherwise they would not have been used and logged.

I'll switch the logging when I fly tomorrow. I went away from frame rate b/c it has been solid at 7ms in the 20 or so flights I was logging it.

I had been using fades as well, and they would pop up, but never coincided with any odd behavior.

But they are definitely more useful parameters & I'll change to them.

Plan for tomorrow is to separate the Rx:s & maybe try an Archer R4 if I can repair a vaporized trace.

I thought maybe they weren't playing well together but I couldn't separate the Rx's at the field which is why I tried to run the R9M on different channels for my last flight. 

It would be useful to also log at least one other radio channel (pitch or aileron or elevator or tail) to see if these disturbances present on the Throttle channel are also present on the other radio channels.

One question: were all 4 flight logs done with F.Port protocol or also with F.Bus protocol?

All flight logs are with Fport between the Archer RS and ikon2. 

Posted by: @srberger

↑

I went away from frame rate b/c it has been solid at 7ms in the 20 or so flights I was logging it.

Reading that question gave me severe anxiety b/c I wasn't sure when I stopped logging frame rate!

But I believe that was with both FPort & FBus. I'll have to dig around in the morning to confirm the FBus frame rate.

Here are my latest logs (still on FPort) that show 7ms frame rate & are as clean as whistle except a few RPM spikes on the unfiltered RPM.

Only hardware changes here are no GPS ADV sensor connected to the R9MX Rx & no buffer pack connected. I needed the space to mount an Archer M+ & Archer R4 Rx's in anticipation of some comprehensive testing.

But mounting those took me far too long so I only got one flight in at dusk, so it was only hovering relatively close to me.

If the weather holds I should be able to do quite a bit of testing tomorrow.

I'm gonna be really pissed (yet happy) if this was as simple as having a buffer pack/GPS connected for some reason or having the cable for the GPS routed too closely to the Archer RS.

Not really sure why either would cause tweaking of frame data unless it was merely having a sport device connected to the R9MX affecting redundancy operation.

So lots more has been added to my test plan going forward.

We see with pleasure that now all your problems seem to have been solved.

This demonstrates the usefulness of the DIAGNOSTIC section in optimizing the entire operation of the models. Unfortunately, many users never check their logs and thus cannot notice any problems.

There is now no disturbance on the RxThrottle signal.

Disturbances on the unfiltered RPM signal are normal especially during RPM changes (we introduced the governor-managed RPM signal filter early on for this very reason). It is good that there seems to be no disturbances caused by crosstalk with other cables as sometimes happens to other users before separating the cables.

We also see that the governor can compensate the RPMs well while pitch pumps are being performed. Also evident is the increase from the beginning of the ThrottleOut signal to compensate for the constant battery discharge.

When the ESC governor is not used but the governor of the ESC is used, it is normal and obvious that the output power curve (internal PWM signal of the ESC) used by the ESC perfectly follows the ThrottleOut signal sent to the ESC. It is therefore a useless parameter to log. It would be better and more useful to log another parameter.

The vibration level of the model is also very good. They only approach the 200% limit during fast collective pitch reversals during pitch pumps.

Apologies for a bit of a lengthy post!

Got in a few flights today & saw a spike in the last one.

Don't think I have enough flights to say for sure, especially b/c they've all been fairly short range, but it appears to be something with the GPS ADV sensor & buffer pack wiring.

I took a shortcut to be able to keep the GPS powered from the buffer pack with everything else shutdown to avoid cold start fixes. So I originally had the buffer pack connected to one port of the GPS sensor, which went out of it's 2nd port to the R9MX, then to the Archer RS & finally to the iKon2. All in parallel but relatively long flat servo style leads (instead of twisted pairs) between the devices so the battery was quite far from the iKon2 & the noise suppression cap connected to the ikon2 servo rail. 

I rewired that today so the GPS sensor isn't in "series" with the battery. (Pretty sure both ports on the GPS ADV are actually paralleled - I want to deglove it b/c I see an ipex connector inside & it would be awesome to be able to use a remote antenna but I wanted to fully solve the current issue before adding possible problems)

Think I'll try to run the GPS to the R9MX as a signal only and/or signal + ground to get rid of the Vcc loop that the R9MX currently has. 

But the real head scratcher is the spike being exactly the same as the RxThrottle for speed 1 selection. Makes me wonder about the transmitter but with zero knowledge of the FW & redundancy operation of the Rx's, I don't know if maybe it gets stuck in RAM or something as the last non-zero delta?

Just weird.

Anyway. Just wanted to leave an update.

And I absolutely LOVE the diagnostic feature of the iKon2/brain2!!

I'm a mechatronics engineer by trade & it is really an invaluable feature! Not only for troubleshooting stuff like this, but also for tuning. Being able to view things such as RxTail, Tailout, and TailRotationRate is just stupidly valuable information when trying to fine tune the control loops for the 3 axis + governor + other stuff such as tail drag by looking at elevator rotation during a pure pitch pump/punch out.

Honestly though, I think I'd be slightly more than a glorified beginner pilot w/o all that stuff b/c I tend to geek out on the data driven tuning. But that's just an occupational hazard & I enjoy it anyway. 😀 

I expected RPM noise during pitch intensive maneuvers b/c of the large associated current spikes. Lots of switch noise there probably making zero crossing detection difficult (or whatever method they're using). But I'm glad Maciej pointed out the unfiltered RPM logging. I was using that & ESC PWM out to make sure the ESC was reacting to the iKon2 ThrottleOut% & not any noise picked up on the lead between ESC & iKon2. But I'm satisfied with that performance so the ESC out parameter is no longer needed. Thanks for pointing that out though as I tend to get tunnel vision.

Not sure if it helped on cross talk but I did relocate ESC forward & left a small amount to get a bit more distance between motor & ESC BEC slave & BEC/signal leads, then ran all ESC cables outside the right side of the frame around the motor at the suggestion of Maiciej, as well as moving motor leads outside the left side of the frame. Also ran all 3 ESC leads through ferrite rings during my 1st rebuild of this machine after a flyaway crash from what I think was interference of some sort. This is what inspired my install the 900Mhz module/Rx/GPS in the first place. I NEVER want that happening again. (My favorite flying site is quite full of 2.4ghz noise)

But I think YGE's use of twisted leads likely helps a lot as well.

The vibration logging feature is also vastly underused!! Perhaps a little more documentation would be helpful here, especially for those relying on auto level  and/or rescue. If folks better knew how to interpret the readings perhaps they'd utilize it to fine tune tracking & balance. I've yet to install a pair of perfectly balanced blades that didn't greatly benefit from placing a piece or 2 of tracking tape through a bit of trial & error to tweak balance & blade efficiency while looking at the vibration logs. Especially on the tail.

Some will vehemently resist as always, but who knows? Plaster it in 30 point text on the rescue page?

Not sure where it was documented but learning that the 1000 sensor is global vibrations has been a great help as well. Makes it easy to track overall health of stuff like dampers when not using the apps to look at logs.

Anyway, thanks for your help in working this issue with me.

I'm probably going to keep the Archer R4 & M+ Rx's on the heli until I get some more normal flights in & make sure I can run the GPS w/o issues, so if you're looking for any data involving those let me know & I'll try to oblige.

Logs/events attached in case they're usefull for anything but they're just more of the same. (events 12 captured events for all flights)

Apologies again for the lengthy post!!

Regards,

Steve B.