Clarification regarding sensor data and how fast it is read

openTx has introduced a range of new features, ideas and bling. It is fast becoming the firmware of choice for many users. openTx will run on ALL current hardware platforms, including the gruvin9x and sky9x boards. Work has already started to support the new FrSky X9D radio!
Post Reply
jtroutt19
Posts: 152
Joined: Sat Jan 04, 2014 7:06 pm
Country: -

Clarification regarding sensor data and how fast it is read

Post by jtroutt19 »

I have a guy telling me this

"There is not much benefit to using a 2 sensor baro setup with the FrSky telem system. Doesn’t matter if it is FrSky or OpenX etc. There are a few problems-
- The lag with the sensor doesn’t change with multiple sensors. Whatever lag there is internally at the sensor, or on the FrSky telemetry bus, etc doesn’t drop with more sensors.
- Although a redundant sensor seems a good idea, it requires very strong code behind it. What do you do when you see one reading 13ft and the other 24ft? Is that install bias from air flow (i.e. different install locations for the sensors)? Is it valid data where each sensor is polled 200ms apart and you are changing altitude? Is one sensor messed up? Etc.

Guys- the FrSky telemetry bus is not fast. It isn’t supposed to be. They aren’t bad engineers, they just have limited bandwidth and have decided to user most of it for the TX->RX data path. Most telemetry is this way- it was never intended to be part of an active control loop- not in F1, not in the Space Shuttle."


What I am assuming he is saying that vario sensor data is not accurate enough to use to do anything with because the s.port bus is to slow? Is this correct here. If it is how are guys that fly gliders using it then especially when they are depending on it working. Can someone clear this up for me?

User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Clarification regarding sensor data and how fast it is read

Post by Kilrah »

There is no context of what question this answer was given for, nor what you'd supposedly want to do - impossible to comment. The telemetry bus itself is plenty fast - and depending on how it is used with which sensor and what for can be more than fast enough or not...

It's just like saying an F1 car is slow... well it isn't really, but if your goal is to throw something into orbit then indeed it won't help much.
jtroutt19
Posts: 152
Joined: Sat Jan 04, 2014 7:06 pm
Country: -

Re: Clarification regarding sensor data and how fast it is read

Post by jtroutt19 »

OK so I was talking about setting up hard deck and triggering rescue. Lets say I am practicing a new maneuver and I dont want to drop below 10ft So do the programming in the Taranis to trigger my rescue channel when Vario says I am below 10ft.

That is what that comment it towards. He is saying that it isn't fast enough to do this. Is this correct?

What is the delay to get a sensor reading he is assuming it is 500ms. The taranis can log at 100ms intervals, I would think that would be fast enough. That being said is the 100ms just for logging data and the actually speed is faster?
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Clarification regarding sensor data and how fast it is read

Post by Kilrah »

I doubt such a thing would work, but that isn't even due to the telemetry downlink speed, jsut to the lag introduced by the filtering needed to get a decently accurate altitude measurement from only a pressure reading.

I believe the FrSky sensor sends by default about every 200ms, and can be configured to send every 100ms... but as said I doubt that's even relevant, even an onboard calculator probably couldn't be fast enough anyway.

You might want to have a look at openXsensor in which everything can be tweaked so that you could possibly try to improve the response/accuracy balance for your application, but don't have too much hope.
jtroutt19
Posts: 152
Joined: Sat Jan 04, 2014 7:06 pm
Country: -

Re: Clarification regarding sensor data and how fast it is read

Post by jtroutt19 »

I have been looking into OpenXsensor, but you are saying that it wouldnt work but it is not because of the downlink speed but rather filtering? I was thinking about adding an accelerometer/gyro with the baro as recommended in the openxsensor config description.

Here is an example of what I am wanting to do. It has been done before with just the high precision vario from frsky


http://www.helifreak.com/showthread.php?t=686583

User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Clarification regarding sensor data and how fast it is read

Post by Kilrah »

Well I guess that depends how you fly - I was picturing those crazy guys who make super fast moves and will literally move at 100km/h towards ground at times - The alt reading will probably lag 500ms-1s behind, and at that speed it won't prevent you from crossing that 10ft threshold.

If someone already did it and it works then the question is moot and proves your friend wrong :)
Just set the sensor to the fastest 100ms interval since it can only be better.
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: Clarification regarding sensor data and how fast it is read

Post by Carbo »

It is an easy test. Make a package with RX, sensor, battery. Install a free fall of the package released by a switched servo. Log altitude with 1/10s, the switch is always logged. Care for a soft touchdown :D

You will see exactly when you push the switch and when the altitude sensor reacts. The delay of the servo (useful installation implied), transmitting and logging the data is very low against the filtering delay of the sensor. A very careful estimation of the SPort delay from my tests was 0,06s.
mstrens
Posts: 1435
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: Clarification regarding sensor data and how fast it is read

Post by mstrens »

One other member tested it already with openXsensor. He wanted to activate a panic signal on an helicopter when altitude was lower than a defined level.
We made a loop between Tx and Rx to measure the time lag from RX to TX and back to RX. I think it could be as low as 200 / 300 msec.

I added some code in order to calculate in oXs the expected altitude 1 or 2 second in the future taking based on actual altitude, actual vspeed and actual vertical acceleration. Oxs transmitted the "expected" altitude at time T and a logical switch could activate the panic signal (via a channel) if expected altitude is lower than X. I do not know the result of this development because I did not yet get a feed back.

Note : in order to get a faster reaction time best use a Gy-86 module (baro + accelerometer + gyro) with oXs

Post Reply

Return to “openTx”