After passing complete functionality testing including rescue, 15 minutes of blades-off spooled up bench time, vibration analysis, failsafe testing, range checking, and the Spirit BEC tester routine, I've still had an incident of sustained un-commanded full collective/cyclic on each of my first 2 flights. Activating 'hold' seemed to clear up the problem (or coincidence, I wasn't waiting for long) and I was able to regain control and auto in. If activating hold 'is' what cleared up the event, why? Strange relationship.

Here is my second flight with incident at end:
https://youtu.be/jqZ8odI31GA

Spirit v1.2.1, latest SPIRIT.bin and REX7.bin, DS-16 with v3.02
Here is my wiring detail with redundant power to Spirit (2 ports) and rx (4 ports):
Kosmik 200 Master (with ferrite ring) – Spirit AUX
Kosmik 200 Slave (with ferrite ring) – REX7 port 5
ThunderPower 2S-250mah backup/buffer lead#1 - REX7 port 4
ThunderPower 2S-250mah backup/buffer lead#2 - REX7 port 3
JLog2.6GW (red wire removed) - REX7 Ext
Spirit EXBus (+,- to RUD, signal to ELE/PIT/RUD) - REX7 E1 (configured as EX bus in device explorer)



These events did not activate motor off ( but I didn’t wait 1.5 seconds either), and did not act like I would expect in hold.

My Jeti and Spirit logs show some signal losses and that is definitely a serious issue, but is it the root cause? There is lost signal recorded in Jeti log after the 2nd landing, but not during or prior to the loss of control in the 2nd flight, or at all in the first flight. My antenna placement on the boom is a proven configuration on my other Goblin 700 running an R3 rx, UDI and VBAR.

Jeti and Kosmik logs confirm solid power available/delivered throughout all testing to date (BEC set to 8.0v with 2S lipo backup/buffer).

Very, very strange.

Ideas or suggestions?

Very strange!

Have you configured channel ranges to be -100 - 100% in the Diagnostic tab?
If you have seen signal loss even with Jeti receiver, then anything related with unit will not solve the problem.

Is your REX7 updated with latest firmware?

_________________
Spirit System developer

Thanks Zex.

Yes, all limits configured to +/- 100.

My REX7 has the firmware that it came with. It is in the first batch of REX receivers shipped in the US after FCC approval a few weeks ago. There is no update for the REX available on the JetiUSA/EspritModel or JetiModel websites. Is there an update somewhere else I need to apply?

Using the latest spirit.bin.
Using latest REX7.bin as provided by Zb a few weeks a ago as well.

Also using the default frame rate in the REX7 of 17ms. Is this what you have used in testing?

I have a thread going in the Jeti section of HF as well. Here are a bunch of Jeti log screenshots around the second incident:
http://www.helifreak.com/showpost.php?p ... stcount=15


I'm using 100hz on transmitter and the default frame rate in the REX7 of 17ms. Is this what you guys are using?

Very interesting.

Yes, we are using very default settings, same as you are.

_________________
Spirit System developer

Will Spirit logging show anything for:
- static hit (like a VBAR "checksum error") ?
- invalid input stream (like VBAR "Single line receiver generates invalid input") ?


I haven't seen any errors like this in my Spirit logs, but that doesn't mean anything if Spirit isn't programmed to report them.

This kind of issue is reported as "Receiver signal lost". In case of EX Bus this event can show if the signal is not valid or not present for more than 1 second.
So most probably Jeti receiver stopped to send the data completely (maybe it was restarted because of some issue).

_________________
Spirit System developer

The signal loss reported by Spirit log was only after the incident and auto into the tall grass.

IF at the exact time of the incident, the signal stream from REX to Spirit had any errors, would there be a log entry for it?

Sounds from what you just said, the answer is 'no' If the duration is less than 1 second. That's not good at all. Logging needs to flag/record any corruption in input stream for diagnostics.

I didn't tell the heli to do full sustained collective/cyclic. Somehow though, that's what it did.

Sorry Thomas. I do appreciate your help and passionate involvement in supporting Spirit.

It's frustrating that I have a dangerous situation in hand without tools like detailed logging to understand the root cause of the error. A -v option in my Spirit logging would be awesome.

A checkbox option for verbose logging for troubleshooting maybe?

Is the failsafe in your receiver disabled so it is handled by the unit?

If no, then the only possibility when receiver will stop to send the signal is when it is restarted. Alternatively if the cable connection is bad, but in this case it will happen much often and not for long time and return back to normal after few seconds.

You can check range test and do tests with spinning rotor on the ground (without blades).
First you have to reproduce it on the ground.

Normally static discharges can be the reason for delayed steering, but not loss of the control completely (if receiver is not restarted because of this).

_________________
Spirit System developer