Binding FrSky S8R stabilizing receiver

What could be easier than binding a receiver to a transmitter, right? Push the bind button while powering up the receiver, put the transmitter in binding mode, wait a few seconds, done!

Well ... With the FrSky S8R receiver, there are a few "other possibilities"...

The receiver comes with a manual, a piece of double-sided foam tape, and a little bag with two jumper plugs.

First thing to do is to download the latest firmware for the receiver from the FrSky download page, since FrSky are pretty active in developing new features, and there is no telling how long any receiver lays on a shelf before it gets shipped. Plus, there's just no way to determine what firmware is on the receiver, so by re-flashing it, you get to be sure. Flashing that firmware to your receiver is easy, once you have downloaded the latest firmware, and copied it to the SD card of your transmitter. If you are so lucky as I am, you have a Taranis Q-X7S, and you can take a simple servo lead to couple the S-port of the receiver to the S-port of the transmitter (for other models you may need a wire with the red and black wire flipped on one side). long press the menu button, and press "page" once to display the file structure of your transmitter's SD card. Browse to your receiver firmware file (*.frk), and long-press Enter. That will open up a sub-menu that starts with "Flash to S-Port", which is exactly what you want. Press enter and wait it out, the write process takes about half a minute.

(In the picture, you can also see at which side the signal (yellow) wire of the servo lead needs to ga)

But, after doing that, the binding process as described in the intro did not work for me. Double checked that I have the EU version of OpenTX, bootloader, and receiver firmware as well. That can cause the receiver not to bind, if any of those three is not EU/LBT (or FCC if that's your choice of firmware), but that was all OK in my case. So I started to wonder about those two jumper plugs.
There is no mention of the two jumper plugs in the manual. The trick here, is to look at the manual of the non-stabilised brother of the S8R, the well-known X8R. In that manual, it is explained that there are different ways you can bind your receiver to your transmitter.

Basically, it comes down to this: there are 8 rows of pins, which can serve as PWM servo outputs. But the receiver is a 16 channel receiver. All 16 channels are available on the SBUS port. You can decide what range of channels you want to ALSO output on the pins: channels 1 through 8, or channels 9 through 16. Plus, you can use this receiver as a D8 compatible receiver, or a D16 compatible receiver. On top of that, you can choose if you want telemetry or not. No telemetry means more processing power, and therefore maybe less latency, or quicker cycles. Also, you could couple two receivers together to have 16 physical PWM outputs, but only one of them can then have telemetry. Telemetry will then have to be disabled on the secondary receiver.
And all of this is decided when you bind the receiver to your transmitter. On the one hand by selecting the appropriate option in your transmitter when selecting the bind option, on the other hand by bridging channel 1 to 2, and/or channel 3 to 4 with the jumper plugs. Bridge only the signal pins. NEVER put the jumper plugs vertically! If you do that, you either pull the signal pin high continuously, or flat out short your receiver's power lines. Neither one is a good option for your receiver...

Here`s the options in table form:

MODE	TELEMETRY	CHANNEL OUTPUT	JUMPER(S)
Mode 1 (D8)	Yes	CH1 - CH8	CH7&CH8
Mode 2 (D16)	No	CH1 - CH8	CH3&CH4
Mode 3 (D16)	No	CH9 - H16	CH1&CH2
Mode 4 (D16)	Yes	CH9 - H16	CH1&CH2
			CH3&CH4
Mode 5 (D16)	Yes	CH1 - CH8	none

If you want to use the receiver in D8 mode, you do not push the bind button on power-up to bind the receiver. Plus, you get no option to disable telemetry.

My setup will be using channels 1 through 8 as PWM outputs (#8 for flaps anyway), so I will bind in D16 mode, with the option CH1-8, telemetry ON. That means I need no jumpers at all; it is refered to as Mode 5 in the table above. This is the most used case for this transmitter, and if it is for you too, you just read an entire chapter about jumpers you don't need to use ;)


Binding, however, did not work. I got a solid green LED whenever I put the receiver in binding mode, with the radio in binding mode too. Solid green is not listed in the manual as a valid status (which I find strange, because one would expect to see solid graan as a confirmation of "all is OK").
Powering up while not in binding mode shows a few seconds of frantic flickering of the blue LED (indicating "Quick Mode"), followed by a slow blinking red LED (indicating "not connected).

Tried just about everything I could think of. Every possible order of powering up and switching to bind mode in the universe, updated OpenTX (to version 2.2.3), including the bootloader of the transmitter (they can be different). I updated the firmware on the receiver too, taking care that both had the EU version on them, since I am live in the EU and I don't want to be interfering with any other system or frequency.
I ended up searchin the internet, and in the end found the solution to my problem on the RCGroups.com forum.

Solution to get the S8R in bind mode

The solution proverd top be flashing the latest XJT firmware to the internal transmitter module. Weird, since that firmware has been around since early 2017, and my transmitter dates from late 2018. But apparently, transmitters, or at least their XJT modules, lay on the shelf for quite a long time before they are shipped out...

The 2017 XJT EU firmaware

Flash it to the internal module

After this flash, powering on the receiver with the bind button pressed in, there came the blinking red LED next to that green one. And after setting the transmitter in bind mode, the red LED turned off. No matter the order in which the devices are put in their respective bind modes, succesful binding was 100% from then on. So this was definitely the solution to the not-binding-constant-green-LED problem!


Thanks to the contributors at RCGroups forum that shared this information!