Spirit System

I'm using x20s with Ethos, but not sure if this question was to me.

@Thomas do you know maybe when some logviewer is coming?
It's only a question, not a complain. I just wonder if to try to bake sth quick and dirty on my own just to have logs in the field.

azaz44 wrote:BTW. do you know how much of a problem is it, if you fly with Spirit left in "settings" mode (LED blinking)? Documentation mentions that LED should be steady on. But if it's blinking Spirit just works like normal, allows to start the motor etc. Is there any risk when flying like this? I'm asking because current script versions sometimes leave the LED blinking. And I'm a bit paranoid to always check this, but this is problematic and in some of my helis LED is not easily visible, especially in daylight. I wonder if there's any risk.

Of course you have to test on desk this at home.
Always end the session via the buttons of Spirit Settings ( you was asked to close...) and check if the FBL is showing a steady LED...
Tip: if you have accidently kill the LUA restart it and shut down via the buttons - FBL will stop blinking and it is save to fly

Of course you have to test on desk this at home.
Always end the session via the buttons of Spirit Settings ( you was asked to close...) and check if the FBL is showing a steady LED...
Tip: if you have accidently kill the LUA restart it and shut down via the buttons - FBL will stop blinking and it is save to fly

Yes, but this does not work reliably. Once per 5-10 times FBL stays in blinking mode.
I just had it yesterday on newest script version. It happened after script was unable to read and show data. If it fails to read some data (you enter for example "Limits" and it does not show any numbers), then in most cases it stops working at all. You have to restart the script. And in such case, exiting the script (with menu) will always leave it in blinking mode. But you can start the script again and it will work.

I think there's no retry anywhere in the process, and things only work if there are no packets lost in radio transmission. But if a single packet is lost, things break. But that's just a hypothesis.

For me it's a problem to check LED, because in some of my models it's not visible unless you remove the canopy.

What is your receiver?
We have here Tandem receivers and ACCESS and it has zero packet losses.
Maybe only if you have receiver and radio too close.
We will check with same setup to see and compare.

ZeXx86 wrote:What is your receiver?
We have here Tandem receivers and ACCESS and it has zero packet losses.
Maybe only if you have receiver and radio too close.
We will check with same setup to see and compare.

I made a video: https://youtu.be/8qtwiTczDMs
Problem starts to happen at 0:53.
It fails to read data on one screen, and then leaves FBL in blinking state.
Radio and heli are ~2 m apart.

Unit is Spirit GT, and receiver is Archer RS.
I have this combo (GT + RS) in 4 helis and it happens in all of them.

Hello,
I have that problem too also with an Archer RS and Horus X10S Express, see in the other therad from me... There must be something wrong in the script...

Regards

R10+ F-Bus and Tandem X20S (latest Firmware) after up and down in the menue (for 1 minute) i can see the problem and no item were updated.
But changing bank by tapping screen reactivites the script.

R10+ F-Bus with HorusX10Express, Firmware 1.4.8, ISRM-S_X10E, HW: 1.1.0 FW 2.1.6(EU-LBT)
here General/Receiver Type is always showing "???"
After a while up and down through the menues scrippt stops and cannot be reactivated

I hope this helps

@Thomas

I grabbed terminal output from the radio. Spirit script does not generate a lot of output, but when it works, then every screen (on enter) generates "Event received" (when entering the screen) and "dis" (when it read data).
However when it fails to read data, it does not print "dis". Example output I got:

Code: Select all

dis
Event received: 0       97      0       0       35
dis
Event received: 0       97      0       0       35
Event received: 0       97      0       0       35
Event received: 0       97      0       0       35
Event received: 0       97      0       0       35
Event received: 0       97      0       0       35
Event received: 0       97      0       0       35
Event received: 0       97      0       0       35
Event received: 0       97      0       0       35

Here it went fine with one screen, but then it failed to read data. And further going around screens will always fail. And in such case it always fails to set FBL to "LED steady state".

I also looked at LUA API calls script is invoking at runtime (I hope you don't mind this bit of "reverse engineering"). Observations are:

Sometimes LuaSensor:getParameter returns nil. I assume this is because of lost frame, either when requesting data from telemetry, or getting it back. This results in some parameter value missing and text box being "greyed out"
Sometimes scripts falls into infinite loop of trying to get parameter. it is calling `getParameter` all the time, always receiving `nil`. In such case it fails to read any other data, for any screen, and fails to set FBL to "steady" state on exit. I can go around screens and UI works, but is not transferred anymore.
I didn't check deeply, but on first look it seems, that this "infinite loop" starts, if script fails to read the first parameter on each screen, which is requestParameter(138).

I don't paste detailed outputs here as I'm not sure if it is fine. The script is precompiled for some reason, so I suspect you don't want to share its details maybe.

But to me it seems that frame loss is always going to happen, and script has to accomodate for this.
I could not find any detailed information about this LUA API of `requestParameter`, `getParameter`, `writeParameter`, but I assume they do not have any built in retry protocol.

I hope this helps and sorry for reverse engineering if this is any problem.

One more observation:

- it happened to me, that I went to one screen, got all parameters displayed and everything was fine. But when I exited the script, FBL was left in "blinking" state. I think this is because this frame was lost. I think script needs to send this several times, over multiple lua cycles, to be sure it works.

Also:
- the scripts asks for confirmation "Do you want to close the menu [ Yes | No]" if some data was changed and not saved. But it also happened to me, that it asked even though I didn't change any data.

Hello azaz44,
what you have brought out is great!
That means for me at the moment that the script has to be revised a bit so that it doesn't get stuck anymore and there is a good chance of getting it under control after all -

Best Regards !

Spirit System

FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port

Re: FrSky Integration with Ethos, S.Port & F.Port