Receivers going bad while in storage

[Landru]

Good point.

That said, do we know if the OS has it's fingers in RSSI somehow? I guess it must, at very least in a superficial way. Plus, given that some Archer SR receiver functions depend on EthOS (did I get that right?), it seems to me that there might be an unintended differences in RSSI or the reporting of RSSI between the two OS. Of course, all this is speculation on my part. I don't have an SR8 or any EthOS-capable radio to test with.

Speculation aside, I wonder now if your problem SR8 ever worked properly with your X20 and EthOS. Or was its previous successful operation always with your X10S and OpenTx?

 

[ululi1970]

I always used it with the X10S prior to now. I am porting the fleet to the X20 and when I switched the plane it was on i ran into the issue i described

 

[Landru]

Good to know. Seems like it might be an important clue.

Your SR8 + X10S + OpenTx = good combo
Your SR8 + X20 + EthOS = bad combo

 

[ululi1970]

Let's see if Wayne has something to say

 

[doug35]

Have you updated all of the firmware on the TX and RX? SR8 should be at 2.1.10, Ethos should be at 1.4.6, and Tandem RF Firmware 2.2.2

 

[alm_nl]

It's not that receiver numbers are being reused for other models, right?

 

[Landru]

I just stumbled on a report on RCG of unreliable telemetry reporting on the X20 from some receivers in some cases.

Could @ululi1970's RSSI weirdness be related?

The relevant discussion starts in this post by RCG user @Jeddy. The response I quote below is by a different user, @johnboy74au (bold is mine):

Jeddy - I don't have a fix, but experience the same issue with my x20s and a sr8 pro on access - only way i can get it to work, is go into rf settings, select the receiverand select "set" then options ( i think from memory) then the telemetry "wakes up" and reports as normal ( rpm, temp, etc from a gas suite sensor hub) i habe to do this evertime i power the receiver / radio on.......bit of a pain, but might work for you?

P.S. I'd be curious to know if a range test to the point of link failure confirms that the reported RSSI reflects actual signal health.

 

[ululi1970]

@doug35 I have updated Ethos to 1.4.6 and the FW for Tandem is 2.2.2. Same exact behavior. Over a period of a couple fo seconds the RSSI oscillates between 90 to 40 and back.

@Landru It occurred to me that the reported RSSI may not be the actual one. I will perform an actual range test soon, but I noticed that when the RSSI drops to the 40, the green light on the S8R blinks...

 

[getsuyoubi]

What happens when you place the TX about 10 feet away from the receiver?

 

[ululi1970]

It's just as bad or worse. When RSSI drops to 30 I also start losing telemetry, which suggests that the low RSSI is real.

 

[Landru]

If you confirm that the control link and telemetry remain solid with the same receiver on OpenTx, we’ll have a very interesting mystery on our hands.

 

[Wayne]

This is an SR8? What is the VFR values? Curious.

Sorry guys we have the darn flu going through the ranks here AGAIN! and have been all hands on deck with shipping. We are a few days behind on FrSky subjects.

 

[ululi1970]

Bummer for the flu! Hope you guys get well soon. It is a S8R, not VFR on V2. I am tempted to try flash the UNI for the X8R, but I am afraid to brick it.
Alternatively, I could hook up an arduino board to monitor the failsafe bit on the SBUS stream...

 

[Wayne]

OK - I thought it was the S8R but above it was mentioned as SR8.. FrSky really needs better names. LOL

 

[Landru]

FrSky really needs better names. LOL

Amen to that.

Users get turned around all the time by errors with -- or misunderstandings of -- the naming convention. Me too from time to time.

 

[ululi1970]

Well, I hope that when they come out with a stabilized version for Tandem they don't call it STD R18, that would be bad optics...

 

[jure]

good news from Jarron: he reports that he could bring back to life my otherwise dead ( not bindable ) G-RX6 , by upgrading to the UNI firmware.
Give us some more details Jarron, please ! Many Thanks for your investigation and result !
PS: could it be that the improvement comes from the UNI auto-tune feature at binding time ?
quoting the UNI instructions:

Binding is very similar to the FrSky method, but may be a little slower as it searches for your radio type.
Power on holding the bind button on the receiver, Initially the red LED should be on solid, then every 0.5 seconds it should blip off, indicating it is trying a different mode. (If it is flashing slowly, then it did not enter bind mode and is indicating no Tx signal, try step 1 again.) In the transmitter set the bind mode to D16 and enter the bind mode option.
Monitor the LEDs on the receiver, when the bind completes, the red LED is off and the green LED is flashing. (With the Rx in binding mode, the red LED is blipping off every 0.5 seconds indicating changing the protocol mode.
When a Tx is then in bind mode, first the red LED stops blipping off, indicating the Rx has detected a particular protocol, and is then tuning. Any received packet then causes the green LED to flash on. Finally, at the end of binding, the red LED goes off and the green LED flashes.)
Power off the receiver and turn off binding in the transmitter. You are done. When you turn the receiver back on and it connects to the transmitter you will observe that both LEDs (red and green) will both be on indicating that all is good. (The green LED actually is on for 7mS every time a packet is received correctly. Packets should arrive every 9mS, so the green LED appears solid, but will flicker if many packets are not received OK.)
During binding, if signal pins for channels 3 and 4 are jumpered, then the SBUS output becomes a normal servo pulse output.

 

[Landru]

Gotta love that!