Hello,
normally there should be zero losses during transmission. So there is question why they are happening.
We will get same receiver as you to find it, because with receivers that we have this problem is never happening.
We found difference between receivers long time ago unfortunately, each is behaving as if programmed by very different company. So behavior during same circumstances is different which makes it complicated.
I believe that we will find answer and fix the problem in following week.
FrSky Integration with Ethos, S.Port & F.Port
Spirit System developer
What I can say is, I have Archer RS in multiple helis and all behave same. I mean same problem. And at the same time I always have VFR > 90% after flights, so I think everything is fine with ransmission.
Hmm, I hope my x20s doesn't have any problem...
Hmm, I hope my x20s doesn't have any problem...
can I ask you something?
all these type of radios they are set up the same way.
I don't have access but with normal receiver there is a parameter that adjusts to get the best reception and don't lose your signal.
did you do this procedure?
this thing must be done with multi-protocol radio.
With radio plug and play type jeti, spektrum,ecc ecc this procedure no need.
The procedure to have the best rssi, for example if i want to use my radiomaster tx16s (with edge tx is equal open tx) multi protocol with any receiving I have to do this procedure, However I use jeti ds12 Why do the binding and there is no need for this procedure.
Maybe you don't even know what this thing is and you have the problem of signal loss.
It's normal I didn't know anything about it either after seeing an online guide I found out
PS
all multi-protocol radios they have to adjust this setting also frsky it has many firmwares, firmware for radio and firmware for receiver
RF FREQ FINE TUNE (name parameter parameter name I mentioned earlier) it is found when you lose signal and when you have the strongest signal and set the right number
it's explained very well here
https://www.youtube.com/watch?v=n2huRPIvMUc&t=399s
all these type of radios they are set up the same way.
I don't have access but with normal receiver there is a parameter that adjusts to get the best reception and don't lose your signal.
did you do this procedure?
this thing must be done with multi-protocol radio.
With radio plug and play type jeti, spektrum,ecc ecc this procedure no need.
The procedure to have the best rssi, for example if i want to use my radiomaster tx16s (with edge tx is equal open tx) multi protocol with any receiving I have to do this procedure, However I use jeti ds12 Why do the binding and there is no need for this procedure.
Maybe you don't even know what this thing is and you have the problem of signal loss.
It's normal I didn't know anything about it either after seeing an online guide I found out
PS
all multi-protocol radios they have to adjust this setting also frsky it has many firmwares, firmware for radio and firmware for receiver
RF FREQ FINE TUNE (name parameter parameter name I mentioned earlier) it is found when you lose signal and when you have the strongest signal and set the right number
it's explained very well here
https://www.youtube.com/watch?v=n2huRPIvMUc&t=399s
@Thomas
I just realized important factor. We have WiFi networks and other 2,4GHz traffic around. When I test this indoor, there are many networks around. And when I test it in the airport, it is a modelling airport - there are guys with gliders and planes too. And we all share same bandwidth with a couple of channels, with super advanced ways to switch between channels to get some frames delivered to the receiver. Plus on top of that we have some restrictions in LBT in Europe.
So this is maybe something, which is different when you test it. Maybe in your area this can work very smoothly.
I personally don't think any communication which needs a stream of data can work without retrying. Nobody would even assume this in network traffic, where everything runs over wires. We need TCP with retrying to get any reliable data stream. And here we talk about radio communication, with tons of things reusing same couple of channels.
I just realized important factor. We have WiFi networks and other 2,4GHz traffic around. When I test this indoor, there are many networks around. And when I test it in the airport, it is a modelling airport - there are guys with gliders and planes too. And we all share same bandwidth with a couple of channels, with super advanced ways to switch between channels to get some frames delivered to the receiver. Plus on top of that we have some restrictions in LBT in Europe.
So this is maybe something, which is different when you test it. Maybe in your area this can work very smoothly.
I personally don't think any communication which needs a stream of data can work without retrying. Nobody would even assume this in network traffic, where everything runs over wires. We need TCP with retrying to get any reliable data stream. And here we talk about radio communication, with tons of things reusing same couple of channels.
I have set up a new SpiritGT with R10+ and F-Bus at the table.
As a test transmitter, I have Horus X10S Express and Tandem X20S, each with all the latest updates.
Since yesterday I hardly register any malfunctions in the Lua script. Only occasionally does a grayed-out Bank 0 show me that I have to restart the script.
This is remarkable, as both channels with the built-in SpiritGT showed sporadic hangs that could only be ended by RTN.
Also, no errors were reported for serial connections with the terminal program.
I noticed 2 things that are not directly related to the basic problem:
1. the data that cannot be changed is not read out and grayed out, but only displayed as a grayed out question mark (e.g. Bank1 or 2 in General). Correct output when changing from bank 0 to 1 or 2.
2. During testing I kept changing data and left the script without Save Settings via Close Menu and Yes.
The data was apparently saved in the SpiritGT because the values are still there after restarting the script.
However, they are only available until the SpiritGT is restarted.
Is it safe to do this to test different settings and then save these temporary values permanently via Save Settings after a successful flight?
The status diode indicates a safe state by permanently glowing.
If I'm not satisfied, I switch everything off and everything is as before.
P.S.: it's really not a good idea to ship the script compiled because there are so many specialists who could help with debugging.
As a test transmitter, I have Horus X10S Express and Tandem X20S, each with all the latest updates.
Since yesterday I hardly register any malfunctions in the Lua script. Only occasionally does a grayed-out Bank 0 show me that I have to restart the script.
This is remarkable, as both channels with the built-in SpiritGT showed sporadic hangs that could only be ended by RTN.
Also, no errors were reported for serial connections with the terminal program.
I noticed 2 things that are not directly related to the basic problem:
1. the data that cannot be changed is not read out and grayed out, but only displayed as a grayed out question mark (e.g. Bank1 or 2 in General). Correct output when changing from bank 0 to 1 or 2.
2. During testing I kept changing data and left the script without Save Settings via Close Menu and Yes.
The data was apparently saved in the SpiritGT because the values are still there after restarting the script.
However, they are only available until the SpiritGT is restarted.
Is it safe to do this to test different settings and then save these temporary values permanently via Save Settings after a successful flight?
The status diode indicates a safe state by permanently glowing.
If I'm not satisfied, I switch everything off and everything is as before.
P.S.: it's really not a good idea to ship the script compiled because there are so many specialists who could help with debugging.
Updateazaz44 wrote:@Thomas
I just realized important factor. We have WiFi networks and other 2,4GHz traffic around. When I test this indoor, there are many networks around. And when I test it in the airport, it is a modelling airport - there are guys with gliders and planes too. And we all share same bandwidth with a couple of channels, with super advanced ways to switch between channels to get some frames delivered to the receiver. Plus on top of that we have some restrictions in LBT in Europe.
So this is maybe something, which is different when you test it. Maybe in your area this can work very smoothly.
I personally don't think any communication which needs a stream of data can work without retrying. Nobody would even assume this in network traffic, where everything runs over wires. We need TCP with retrying to get any reliable data stream. And here we talk about radio communication, with tons of things reusing same couple of channels.
I just realized, if you are testing on Tandem receivers @Thomas, then probably (as far as I could find) telemetry works over 900 MHz. So I think it might behave completely different than Access.
@Joergz
I think this is normal and have always been like this. Changing data change is in the unit. Saving save is to the flash memory.The data was apparently saved in the SpiritGT because the values are still there after restarting the script.
BTW I agree with statement about compilation. I'm not sure but I think the script is maybe even obfuscated, as it looks really weird after decompilation.
+1JoergZ wrote:P.S.: it's really not a good idea to ship the script compiled because there are so many specialists who could help with debugging.
the otx version is also uncompiled. a lot of people can help debugging if we get the lua code.