AP_Frsky_Telem: VSpd is missing in serial protocol 4

[Target0815]

Issue details VSpd, vertical speed in cm/s, is missing in FrSky S.Port telemetry output (serial protocol 4). If you already have a Baro on board, you should be able to use it as a Vario, but VSpd is needed.

(VSpd is output with protocol 10 (S.Port passthrough), but external Lua scripts should not always be used ...)

Version Plane, latest version (master)

Platform [ ] All [ ] AntennaTracker [ ] Copter [x] Plane [ ] Rover [ ] Submarine

Airframe type For gliders, without need for external Vario.

Hardware type In this test Matek F405-Wing.

[SquashSquishSquaw]

I'm very much missing this feature on my Matek F405-Wing build with ArduPlane.

Especially on small, lightweight gliders I don't want to have to buy and install a separate Vario, so I'd be very happy and grateful if someone could please take the time to implement it.

[hobby1946]

A major disadvantage of Arduplane is that the value VSpd is not transmitted with the FC 405 in FRSKY in telemetry mode 4, although the value is present in the FC.

Thus the Varioton cannot be used in the transmitter. This is very important for glider models.

I know many pilots who therefore use INAV, although they would also like to use Arduplane.

In the hope that this value will soon be transferred as well

[auturgy]

Have you considered using protocol 10 and the Yaapu script? http://ardupilot.org/plane/docs/common-frsky-yaapu.html

[hobby1946]

Yes. I also tried Yaapu. But I want to run my model without the Yaapu-Lua. (Yaapu also doesn't allow to run other LUA scripts, aborts OTX operation of the transmitter, etc.)

With the Yaapu script VSpd is available, but not usable. In the Missionplanner VSpd is ok. But not usable via Yaapu in the transmitter ! Here are often arbitrary values, you have a long delay, do not change for seconds (>4s), indicate sinking when climbing.

I want to use my OTX normally and the normal Frsky telemetry (4).

This was also not possible until the latest firmware, because the values were transmitted very irregularly and the GPS was constantly suspended. This was finally fixed in the last days.

Now it would be advantageous if the value VSpd was still present.

Translated with www.DeepL.com/Translator

[hobby1946]

Correction: in the newest version (latest) VSpd shows at Yaapu correct values.

[yaapu]

@Target0815 , @auturgy , @hobby1946, @SquashSquishSquaw
I added VSpd to protocol 4 but the patch needs some testing, can any of you test the patch? https://github.com/yaapu/ardupilot/tree/pr-frsky_telem_vspd_proto4

[Target0815]

Whow! Thank you Alex!

We would like to test, but have not installed a development environment ourselves. Could you do a build for the Matek F405-Wing?

[yaapu]

Sure, MatekF405-Wing plane and copter builds from branch https://github.com/yaapu/ardupilot/tree/pr-frsky_telem_vspd_proto4

[Target0815]

Thanks! We will test this asap ...

[Target0815]

Test is for me ok. I'll waiting of another response ...

[hobby1946]

So I tested the new firmware. VSpd is now available in Mode 4.

Thanks for the quick change. Now you can finally fly sail models without an extra vario.

[SquashSquishSquaw]

Thank you very much Alex! :-)

Could you please elaborate: How is the VSpd being transferred? Does it originate directly from the F405-Wing's barometer, and is it unaltered/unprocessed when we get it onto the Taranis? Or is it calculated indirectly from altitude changes?

[yaapu]

Hi, it's the same value you see in the osd, for I used the OSD code as a reference. If the AHRS has a valid vspeed estimate (baro+gps+imu) that's the reported value otherwise it falls back to baro climb rate

[hobby1946]

Hello, I have noticed that the GPS value is no longer transmitted so quickly and regularly. He has also abandoned it (rarely). see: https://workupload.com/file/7aQ9SL7u

Without VSpd it was transferred twice as often. see: https://workupload.com/file/exUP2LmS

[yaapu]

Hi, I can reproduce it, please try this fix

Alex

[SquashSquishSquaw]

Thank you very much Alex, much appreciated! Also the other great work which you do! :-)

[yaapu]

Ok, so is it working the way it's supposed to?

[Target0815]

GPS is updated approximately every 2 seconds. Depending on the GPS and the number of SAT-networks this delivers the data with 3-5 Hz. It should be possible to get an update every second. In the 2nd video of @hobby1946 (where the VSpd was not yet there) you can see how it is actually optimal.

But I don't know if the output of VSpd delays the update of GPS. It all seems to be connected ...

[yaapu]

Unfortunately it's a MatekF405-Wing specific issue, a Pixhawk or an OmnibusF4 do not exibit the problem. I can try to find a workaround but to dig out the bug I really need Tridge's help!

[Target0815]

@yaapu For my needs the data transfer works fast enough. But you are welcome to contact @tridge, if he has a hint how to speed it up. In the end it might be a resource problem, which can't be solved on the F405-Wing.

[hobby1946]

The Vario works perfectly.

It shows a slight ascent/descent immediately without delay. It couldn't be better. And that with a BMP280 !

VSpd is constantly transmitted. There are no pauses. This is actually not necessary. 2-3x/s would be sufficient.

But GPS could be transferred more often. Only that the GPS delivers only all 2s data is not so good. Sure enough for RTH or waypoints (except landing). But with outlandings already a little bit inaccurate to find the model again.

Why this should be due to the F405 wing is not quite clear to me, because VSpd and GPS work very well with INAV.

As with INAV, this would be optimal: https://workupload.com/file/xQUJCpUP

I hope it will be possible to transfer the GPS data more often.

[hobby1946]

I checked the GPS again.

The last version in which the GPS is working properly is still the dev 1d00d26b.

Here the GPS position is displayed fast enough and does not stop.

In the latest versions there are no more dropouts. But the GPS position comes only every 2 seconds.

Maybe this will help a little.

[yaapu]

I found a workaround but it requires to rediscover the GPS sensor. protocol 4 uses the old "1 byte" frsky telemetry system while all other stacks like Inav, PX4 and ardupilot protocol 10 use the newer "2 byte" telemetry. I moved the GPS sensot to the new standard and it looks to me is much faster check it here

If this works I don't know how OK it is to break the GPS sensor compatibility with older firmware

[Target0815]

I just flashed this build v3. Works very well ..,

protocol 4 uses the old "1 byte" frsky telemetry system while all other stacks like Inav, PX4 and ardupilot protocol 10 use the newer "2 byte" telemetry.

At some point old traditions must be cut off ...

[hobby1946]

I also tested build V3. It now works fine. The GPS position is now about 3x/s transmitted. All values are now transferred very fast and evenly. Now the Frsky Mode 4 telemetry works very well.

Many thanks for the fast solution.

[SquashSquishSquaw]

I also did a test with the V3 build. Sensor data for both GPS and VSpd are rushing in quickly and stable.

On my system, when at rest and every once in a while (like as in every 2 to 5 minutes or so), VSpd tends to get a bit unsteady. It starts to display random values between maybe -1.5 and +1.5 m/s for a few seconds. Maybe that's a hardware problem though, I'll have to do some more testing with another FC soon.

Meanwhile, also the VSpd of protocol 10 seems to be working lag free, so I'm really happy that I'm now able to use the Yaapu Telemetry Script.

Many thanks again for the great job you've done, Alex! :-)

[yaapu]

@hobby1946 @Target0815 glad it worsk now @SquashSquishSquaw check your OSD, protocol 4 and OSD use the very same source for VSpd: if they match the problem is not the patched code.

@SquashSquishSquaw yes, the v3 build I posted uses my dev-tree which has the new protocol 10 scheduler, VSpd is much smoother and that's the reason why it is more usable.

[hobby1946]

So now I've checked VSpd for a long time.

Initially VSpd fluctuates in the range of +/- 0.4 m/s in the Missionplanner. This is a bit too much, because a climb/sink of 0.3m/s is already evaluated in the Variton. The Varioton beeps more often, although the model lies quietly on the table.

In telemetry mode 10 (Yaapu) this is better solved.

The longer VSpd is in operation, the greater the fluctuations in telemetry. After 15 minutes it may happen that short-term VSpd values of +/- 20 m/s are displayed. In the Missionplanner the values remain the same.

Something does not fit here !

The value is also constantly transmitted. Maybe this is too fast?

Here are the Videos :

https://workupload.com/file/uaxU4njk

https://workupload.com/file/kfsDgCBY

https://workupload.com/file/C4B34tz2

[yaapu]

@hobby1946 Hi, did you fly with it? VSpd indoor is affected by GPS,IMU and baro so it probably drifts a lot! Can you compare the VSpd sensor with what you get on the matek built in OSD in same conditions?

[hobby1946]

Hi, I'm afraid I don't have an OSD. I compare the values with the Missionplanner. The experimental setup lies quietly on a table with 12-16 satellites.

At the moment I test change V2.

The VSpd value shows normally (unfortunately not always) 0, even if the value in the mission planner fluctuates.

As soon as I lift the F405 slightly (20cm), a Varioton sounds. This is very good.

Unfortunately the GPS only sends the position every 2s at V2.

I will then test V3.

[hobby1946]

So now I also tested V3.

The GPS position is transmitted 2-3x/s regularly. That's OK !

VSpd works the same as V2. Would also be ok,

if :

VSpd is not so GPS dependent.

if the number of satellites changes, or there are few satellites, VSpd fluctuates strongly. All this can happen in flight.

And you can't use VSpd without GPS (see video).

https://workupload.com/file/4Vxj9VDc

But this should be possible ! Because the sensor BMP280 is standard. GPS not.

The F405 wing is mainly used because of its sensors. And for glider pilots VSpd is a very important value.

[hobby1946]

The initially detected error of the strongly fluctuating VSpd values can be related to the GPS values.

I didn't notice that.

[yaapu]

@hobby1946 if you really need an independent VSpd value you should consider adding an external vario, the VSpd provided in this patches is the same VSpd "seen" by the autopilot, Arduplane cannot fly without a GPS, and a compromised GPS would yield an EKF failsafe. If ardupilot cannot get a VSpd vector from AHRS (GPS malfunction or imu error) if will use the baro instead, so it already works the way you'd want it to work:

• all sensors working: imu+gps+baro
• ahrs errors ==> use only baro

I can provide a patch for a stable Arduplane version so you can evaluate (and fly) the code the way it's now, I'm confidend it will work just fine

[Target0815]

I can provide a patch for a stable Arduplane version so you can evaluate (and fly) the code the way it's now, I'm confidend it will work just fine

Hi Alex, please yes ...

[hobby1946]

Hi Alex, YES ! I'm really looking forward to it!

[yaapu]

OK, I patched plane stable, please test it and report back :-)

plane 3.9.11 MatekF405-Wing

[hobby1946]

Well, I tested that.

Preliminary result:

The VSpd value is now perfect when 8 satellites are received. It then fluctuates around +/- 0.1 m/s.

If less than 8 satellites are received, the fluctuation is large ( approx. +/- 0.5 m/s).

But it is not nice that the GPS already sends position data if it does not have a 3D fix yet (already with SatF 1). It would be better if the GPS data is only transmitted when it is correct. You can send zero before.

I continue testing ...

[yaapu]

You can do at least two steps to tune VSpd:

• You should probably set the parameter EK2_ALT_SOURCE = 0 (Baro)
• You can tune when GPS is taken into account to estimate accelerations with the parameter AHRS_GPS_MINSATS which defaults to 6.

You can also try to play with the parameter EK2_ALT_M_NSE

[SquashSquishSquaw]

Many thanks again for all your work, Alex! :-)

May I please ask you: On a glider, VSpd needs to be as realtime and as accurate as possible. Many people seem to use additional sensors which contain a barometer and a gyroscope/accelerometer. As far as I know, these sensors don't have a GPS inside.

Does GPS really add any benefit to a variometer? Or are GPS data so inaccurate and slow, that it would be best to ignore them for this purpose? In other words, for a variometer, is (barometer+gyroscope/accelerometer) VSpd maybe better than (barometer+gyroscope/accelerometer+GPS) VSpd?

If so, then would it maybe be possible to send (barometer+gyroscope/accelerometer) VSpd in a separate, new sensor (e.g. "Vrio")?

[yaapu]

@SquashSquishSquaw I'm afraid that adding a new type of "VSpd" is out of the scope of this issue. Personally I'd stick with what ardupilot provides and would play with the parameters to tune it to my needs. If this is not enough you should consider adding an external vario.

[hobby1946]

I also think that a GPS is not necessary for VSpd. What is the use of GPS. The altitude GALT. And it is inaccurate by many METERS (+/-20m).

With other sensors I have also made my experience. I have built myself some with openXsensor. And a good Vario is expensive, even if I build it myself.

It is much cheaper to use a GPS at Ardupilot (e.g. Beitian BN-220 for12 Eur).

If I lift my model in my hand 40cm, the Vario already responds (beeps). And this without delay, which many Varios have (2-3s).

I am very satisfied with the current solution.

[hobby1946]

So the 3.9.11 works with GPS and VSpd very well and fast. Finally a useful solution for normal Frsky telemetry. Good and fast work. Thank you very much.

But I will stay with V3.10 V3 for now. Because I want to be able to trigger the arming from the transmitter with a signal (CHn).

I do this with RCn_Option 41. Unfortunately this is not possible with 3.9.

I check via OTX all parameters which are necessary for switching on the motor.

[SquashSquishSquaw]

@SquashSquishSquaw I'm afraid that adding a new type of "VSpd" is out of the scope of this issue. Personally I'd stick with what ardupilot provides and would play with the parameters to tune it to my needs. If this is not enough you should consider adding an external vario.

Yes, I will do that. And I'm really happy that you've implemented this great fix, many thanks Alex! :-)

[Target0815]

I think we can conclude this topic now. Alex's changes are great! Now all we have to do is to get it into the official builds (3.9.x and 3.10.x).

[yaapu]

@Target0815 I'd rather leave this open until the fix gets merged.

Thank you all for the feedback

[SquashSquishSquaw]

Hi Alex,

on October 18, 2019, a new 4.0.0 beta version has been released... could you please tell me if it contains your latest Frsky telemetry GPS and VSpd fixes?

Many thanks Jenny

[yaapu]

Hi Jenny, no plane 4.0 beta does not contain the update.

[SquashSquishSquaw]

Ok, thank you Alex :-) I'm hoping it will find its way into the final, stable 4.0 version.

[WillyZehnder]

@yaapu Hi Alex, is anybody working on the pulling of your improvements? Tridge startet to pull the Soaringupgrades of Sam Tabor https://github.com/ArduPilot/ardupilot/pull/12210 and your improvements would be an ideal completion of that. So it should be released together. Update: Sorry, I just found out that it's still connected in #12352

[yaapu]

This is for Matek F405-Wing latest master if anybody wants to check it out once more after the changes requested by tridge arduplane_master.zip