SBUS receiver signal quality by FrameLost status

[nicbk117]

Hello,

The idea here is to use the FrameLost status contained in the SBUS protocol to give an indication of the signal quality of the RC receiver, and use it instead of the analog based RSSI in all the APM system (telemetry, auto RTL,...).

I'm thinking about a sliding average of the last received FrameLost statuses. The length of the average could be 1 second or something, so 70 samples. This will give an indication of the signal quality for the last second.

Best,

Nicolas

[nicbk117]

Issue similar to pull #1712 and related issue and added here on gmorph's branch https://github.com/gmorph/ardupilot/commits/multigcs-sbus-rssi

What about a release date in the official software? (can't see this update in release notes)

[StewLG]

I've been working on this suggestion and it has proved to be essentially sound - we can indeed synthesize a useful Link Quality metric using sbus dropped frames. I've got it up and functioning in the new RSSI framework. I just did a range test where the new metric dropped off just as you'd expect when distance increased, until failsafe when it went to zero.

I still have some work to do. Either it is normal for there to be 25% dropped frames when the radio is next to the receiver (FrSky X8R in this case), or there's something a bit off with my math. If anyone can speak confidently about error rates in RC radios, I'd love to know if this is normal.

If anyone is impatient and would like to test, I can provide a binary for ArudPlane or ArduCopter.

[osmogr]

I can confirm that the taranis next to the rx causes low signal. Causes either loss of telemetry or even full failsafe if I have the TX next to the RX (usually less then 20 inches or so).

This happens in both D and X modes.

On Sep 1, 2015, at 8:15 PM, StewLG notifications@github.com wrote:

I've been working on this suggestion and it has proved to be essentially sound - we can indeed synthesize a useful Link Quality metric using sbus dropped frames. I've got it up and functioning in the new RSSI framework. I just did a range test where the new metric dropped off just as you'd expect when distance increased, until failsafe when it went to zero.

I still have some work to do. Either it is normal for there to be 25% dropped packets when the radio is next to the receiver (FrSky X8R in this case), or there's something a bit off with my math. If anyone can speak confidently about error rates in RC radios, I'd love to know if this is normal.

If anyone is impatient and would like to test, I can provide a binary for ArudPlane or ArduCopter.

— Reply to this email directly or view it on GitHub.

[StewLG]

I've gone ahead done PRs for this code:

https://github.com/diydrones/PX4Firmware/pull/38 https://github.com/diydrones/ardupilot/pull/2798

Thanks for the idea Nicolas - it's a pretty cool one.

[nicbk117]

Glad it will be implemented so fast...

Thanks to you (and to all the other developers of course) for the great work done on all this project :-)

[StewLG]

Beta firmwares here:

https://github.com/StewLG/catfood/raw/master/SbusDemoFirmwares/ArduCopter-sbus-link-quality-demo-v2.px4 https://github.com/StewLG/catfood/raw/master/SbusDemoFirmwares/ArduPlane-sbus-link-quality-demo-v2.px4

Mission Planner won't give you any help for the new RSSI variables, so here's what to set:

RSSI_TYPE: 3

Then run it. If it's working, you'll see some value for rxrssi, although it may not be 100% at close range. Adjust RSSI_SBUS_HIGH to match what you see for a close-range maximum value, and after that it should be scaled appropriately. For example with RSSI_SBUS_HIGH at 100, if you see a maximum value for rxrssi of 74, set RSSI_SBUS_HIGH to 74. Then you'll have a clean 0-100% range for rxrssi.

I'm hoping to hear from people running SBUS hardware about their results. If you do run these, let me know what model of radio receiver you tested with.

Here's a demo video to show you what to expect. Click "show more" to reveal the indexes to interesting points in the trip.

https://www.youtube.com/watch?v=doHNW_8oBng&feature=youtu.be

[robustini]

No news about this interesting PR? I've my X8R linked to the SB port of the Pixhawk with a servo cable, and the "rxrssi" it doesn't work, always 0. The pwm voltage output of the receiver work fine, tested with an oscilloscope, so the problem is inside the Ardupilot firmware. My parameters:

RSSI_ANA_PIN 103 RSSI_CHAN_HIGH 2000 RSSI_CHAN_LOW 1000 RSSI_PIN_HIGH 3.3 RSSI_PIN_LOW 0 RSSI_TYPE 2

[StewLG]

Robustini:

You can read more about the progress of this PR here:

https://github.com/ArduPilot/ardupilot/pull/3274

It has been liked and nudged by several developers, but it never seems to get prioritized.

As to your question, I'm not sure I understand. The setup you quoted above says "RSSI_TYPE 2", which means you are expecting RSSI to be expressed by your receiver as a PWM value on a particular channel, defined by RSSI_CHANNEL = X where X is the channel number. I know some of the newer FrSky receivers put out RSSI on a high channel (like 16), but I don't know about the X8R - perhaps there is a new firmware that does this.

With the PR you are asking about, we add a third type that counts SBUS dropped packets directly, and in many ways this is the simplest of all RSSI types to configure. But this is not generally available in the mainline firmware yet.

I hope that's helpful but if it is not, perhaps start a general support issue? And of course, if you'd like to see this PR get accepted (or any other reader, for that matter), chime in on the relevant thread, which again is here:

https://github.com/ArduPilot/ardupilot/pull/3274

[robustini]

@StewLG, I signed the other PR, thank you!

[robustini]

Yes, i can confirm, with RSSI_TYPE set to 1 all work fine.