Servo's go crazy when saving unit

[Jman841]

Awesome!

Thank you for the support and help as always!

Going to go see a movie so won't be able to test anymore for a few hours. Glad we were able to figure this out!

[ZeXx86]

No, I have to thank you.
Enjoy your movie.

Here is next try: http://spirit-system.com/dl/fw/test/spi ... test21.bin

[Jman841]

Test 21 works with saves and opening the log from the 2 tests I did for that, however, when loosing link with the Tx the servos go crazy with it both plugged into the comp and with it not plugged in. All is normal after link is regained.

[Yak]

Test 21 works with saves and opening the log from the 2 tests I did for that, however, when loosing link with the Tx the servos go crazy with it both plugged into the comp and with it not plugged in. All is normal after link is regained.

I have just run some tests.
About 8 power cycles with only 1 issue.
On one occasion I powered on the Heli, before turning on the TX.
There obviously was no response from the Heli, but the diag screen showed the throttle channel as 31%
Normally the throttle is -102% (off/zero)
After turning the TX back on, there was no response from the heli/diag screen
Power cycling the heli, reset it to normal.
I was not able to get any of the issues with the servo's as previously mentioned.

Zexx do you think I should flash back to test5 and retry test21?

Cheers,
Yak.

Jmann, what are you fail safe values?

[ZeXx86]

Very strange. I am nearly sure now, that failsafe values are confusing protocol processing - there are very same/similar values and it dont know where to start read.

Can you try to change some values?

[ZeXx86]

I was able to finally replicate the issue when I have added big delay into signal processing between frames.
Fortunately I was able to fix it with next protocol control mechanism.
Unfortunately S-Bus do not support any native signal correction mechanism so it is harder.

You can check: http://spirit-system.com/dl/fw/test/spi ... test22.bin

[Yak]

I was able to finally replicate the issue when I have added big delay into signal processing between frames.
Fortunately I was able to fix it with next protocol control mechanism.
Unfortunately S-Bus do not support any native signal correction mechanism so it is harder.

You can check: http://spirit-system.com/dl/fw/test/spi ... test22.bin

That's good when you can replicate it.
Do you know what could be causing the invalid data (frames)
I have installed test22 and run about 6 power cycle tests with no issues.
I also tried (twice) powering on the heli with the TX off, but everything seemed ok.

I have included a screenshot of the settings when the heli was powered on with the TX off.
I note that the throttle was 51%
I know it might be over kill, but would it be a good idea to have a failsafe value for throttle.
Assuming 0 may be a bad idea since futaba can have -ve throttle..

Cheers,
Yak.

[ZeXx86]

Great, you are right.
This is not good.
Fortunately Throttle is not initialized until TX signal is coming.

Thank you very much for your help!

[ZeXx86]

Throttle value should be fixed now.

http://spirit-system.com/dl/fw/test/spi ... test23.bin

[Yak]

Thanks for that.
I have installed it, and retested the log files with the TX off.
Everything is looking good as well as the "start-values" when the heli is turned on, while the TX is off.

As you can see from my screenshot, the throttle is -1%.
While this might be good for me, I think the number of Futaba SBUS users might be higher than the number of Taranis SBUS users. When I switched from Futaba to Taranis I had to reverse the throttle endpoints.
Some futaba users might be using 100% as no throttle, or is this a non issue?

Cheers,
Yak.