Getting the RSSI value to show in your Betaflight’s OSD (FrSky based)

I had a question pop up a few days ago in the form of a YouTube comment.  It was how did I get the RSSI value to show in my OSD on one of my Mini-Quads.  In this particular case, I was using the MicroMinimOSD with the MWOSD firmware, but even with the newer flight controllers with OSD’s built in, the technique is still the same… and in some cases, it’s easier.

Here’s a quick guide on how to set things up using FrSky receivers and Taranis radios (The X9D or Q7, they will both work the same).  Let’s start by using a telemetry based receiver, such as the ever popular X4R-SB.

It’s been a recurring issue in RSSI signals that often the OSD wants an analogue (0-3.3v) RSSI signal, but the receiver either has tricky pads to solder onto, or a dedicated servo output in PWM… which would mean building in a PWM-to-voltage filter which is extra stuff, extra hassle and not necessarily that accurate.  But with a telemetry receiver, the radio already knows what the RSSI value is, so the more sensible, more accurate, and easier thing to do is for the radio to send the RSSI value as it’s own RC channel to the flight controller, and have that flight controller pull it out of the SBUS stream.  There’s a bit of faff in setting it up for the first time, but it’s a five minute job at most.

First off, add yourself an input (on the INPUTS page) on a spare channel.  I usually use channel 7.  The input source should be RSSI, and I name the input RSSI as well so there’s no confusion what it is.

But what happens if there’s no RSSI available as the input source?  If that’s the case head on over to the telemetry page, which will probably look something like this –

You will notice we’ve got no values under the sensors.  I don’t know quite why in some cases the sensors (such as RSSI) are automatically discovered or added at bind time, and in other cases, they are not.  But if you end up like this, then scroll down to “Discover new sensors” and (while your receiver is powered up and you are connected to it, click enter.  You should now see that one or more sensors are found, leaving you with a screen similar to this –

You can now go back to the inputs page and RSSI should be available as a source.

Next, make sure this input has a scale and weight of 100

I’ve done this on more models than I can count, but right out of the blue, one of them started putting a unit of measure of dB on the scale.  If this is the case, then set it to a scale of 100dB

Next, go to the MIXER page and add a mix on channel 7.  The source should be RSSI, and now the weird part.  We need to set it with an offset of -100 and a weight of 200.  Why is this ?  Well, without it, the RSSI value would go from 0 to 100, which is good as far as an RSSI value goes, but represents only half the PWM range, so effectively this would only give you and RSSI value to 50 to 100.  By adding the weight and offset values, and RSSI value of 0 is -100 (in Taranis terms), RSSI of 50 is 0, and RSSI of 100 is still 100, so this covers the whole PWM range, although I should note that the simplified values of -100 to 100 have very little to do with the actual PWM value (measured in usecs).

There’s a step to do on your flight controller as well, on the receiver tab, there’s a drop down that lets you set your RSSI RC channel.  In this case show in the screen shot below, this is set to channel 8 (as it’s for the firmware on an XM+) but to go with what I’ve set on the Taranis in the example, this would be set to channel 7.  All you need to do is then drag the RSSI value somewhere on the screen (if you are using the built in Betaflight OSD) or enable the “Use FC RSSI” option if you are using MWOSD.

Since writing this, Betaflight has made the slight change of using the AUX channel number, instead of the specific RC channel.  Basically Aux 1 is channel 5, so can just subtract 4 from your actual channel you use in order to get the correct AUX channel.  in the example below, the RSSI channel of 8 would become AUX 4.

But wait, what about none telemetry receivers, such as the popular and tiny XM+  As it comes out of the box, there are some pads to solder from to give you RSSI, but a far easier solution is to install the RSSI enabled firmware which will set either channel 8 or 16 (depending on the version) as the RSSI channel.  In this way, you don’t have to do anything at all on your radio – instead just setup the RSSI RC channel in the receiver tab, and you are good to go !

If you are worried about flashing new firmware on the XM+, as luck would have it I already made a video to guide you through the process.  You can check it out right here.

The firmware download page for the XM+ is here, In my recent Martian III build, I used the version with RSSI on channel 8.

10 thoughts to “Getting the RSSI value to show in your Betaflight’s OSD (FrSky based)”

    1. I hadn’t considered it to be honest, as the majority of the time we’re talking about 200 sized quads with tiny receivers and using an existing PWM output in an SBUS stream. The l9r makes things more complex in the fact that it has it’s own analogue RSSI output channel. So you’d need a flight controller with an RSSI input pin on it to connect up here and use the RSSI_ADC feature. Sorry if that’s a bit vague – it’s not something I’ve ever looked at before.

    2. Hi Ryan. I just connected the L9R RSSI+GND wires to the RSSI+GND pads on the MinimOSD board. Not sure if I had to enable the “Use PWM” option in the MWOSD configurator. All the best!

      1. Hi Steve – sorry for the delay, you comment got stuck in an “unapproved comment” folder !? The answer, if you haven’t already found it is no. The use PWM option should be used for when the RSSI comes down as a PWM signal – usually when one of the x number of channels in an rx is used as RSSI. Where the L9R has it’s own dedicated RSSI port, it uses analogue voltage between (I think) 0v and 3.3v, which is quite a different signal than PWM

    1. I’m running 2.2.0 on my Taranis, so it shouldn’t be a problem. I did find that the telemetry sources (they are there are ch 32 normally) aren’t there unless you have an internal receiver specified (and by that, I did actually check it on an external, but d8/d16 worked, but a Sim model which uses neither an internal or external receiver didn’t have the source available)

      1. I am running 2.2.1, and 100% certain D16 is selected from RX, as I am using R-XSR and am able to control the quad without any issue, except not having RSSI or any telemetry at all.

        1. I was able to kind of recreate this by creating an entirely new model which defaults to a d16 type receiver, but at this point doesn’t have any of the telemetry available as sources. I now need to work out exactly what happens between when it’s like this and those sources suddenly appear. I do have a quad with an R-XSR in it, so I’ll double check that one as well.

          1. I resolved the problem by rebinding the RX to X7 on the existing model. How did it happen in the first place is probably not a major concern any more, as the solution is relatively painless to implement.
            In OpenTX 2.2.1, during the binding process, it asked to choose channel 1-8 or 9-16, and whether to use telemetry or not. My guess is, during the model creation, it may have defaulted to the option with no telemetry.

Leave a Reply

Your email address will not be published. Required fields are marked *