What's new
Aloft Forums

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

M+ as a redundant receiver.

Woodstock1

New User
Joined
Feb 9, 2019
Messages
15
Reaction score
1
I am currently flying SR8 pro access receiver and have been flying that for several months using A current sensor to count milliamps. I decided to use an M plus access receiver as redundant to SR 8. While flying it today somehow the telemetry reporting switched to the M plus and I lost the telemetry from the SR8 receiver causing a loss in the count of milliamps consumed ,which killed a battery. while using an M+ as a back up receiver to the SR8. Should I have disabled the telemetry and will that illuminate the loss of the sr8 telemetry. Or am I missing something else. Kiwi4
 

Woodstock1

New User
Joined
Feb 9, 2019
Messages
15
Reaction score
1
No.

If you kick over the the backup receiver, it is used for RC control. sensor telemetry is not needed in this case, aircraft survival is the key. Chances are it will switch back to the main receiver in a second or two anyhow.

With telemetry for both receivers being logged you can compare RSSI.
In an incident I had ,the redundant receiver switched to the back up. Since the backup had no connection to the telemetry sensors for consumption. the redundancy never switched back to the main which I did not know at the time continue to fly without consumption reporting and ran out of battery. fortunately I had enough flight control power to land safely. But the back up receiver does not know the rest of the the required telemetry from the primary receiver. Kiwi4
 
Last edited:
Upvote 0

Woodstock1

New User
Joined
Feb 9, 2019
Messages
15
Reaction score
1
Not true acccording to the rdundancy posts for the x20 and my own experience, it will not switch back in access unless the M+ hits an rf alarm. There is also no way to send a recievers native telemetry as an s.port out to another rx (like altimeter or A2 from a gr8). Its an unfortunate hole in frsky redundancy. I actually posted in github describing it, hopeing notes will get back to rf team.
You are correct once the redundancy has switched in it will not switch back without a power cycle In my experience. I love having the redundancy but I need to know when it switches because I also lose my milliamp consumption counting and that causes me to crash airplanes. Im flying Fpv and really can’t be looking at my screen ,and I don’t have it in the OSD. with this redundancy system and Fpv I am flying distances I never thought were possible I just need to know when they switch or make them switch back ,whichever is easier. Kiwi4
 
Upvote 0

Woodstock1

New User
Joined
Feb 9, 2019
Messages
15
Reaction score
1
I am very pleased with my redundancy system I am able to fly behind thick lines of trees and sometimes below ground level out of line of sight. Absolutely bulletproof even at a distance. Check out this video. Kiwi4.
 
Upvote 0

Landru

Strong User
Joined
Jul 25, 2018
Messages
548
Reaction score
84
Location
Vancouver, Canada
Is that a functional analog gauge on the instrument panel?

My guess is that it's a small servo programmed to indicate throttle position.

Pretty neat whatever it is. Is it your own invention? I haven't come across anything like it before.
 
Upvote 0

Wayne

Administrator
Staff member
Joined
Nov 29, 2017
Messages
7,798
Solutions
2
Reaction score
4,476
Location
Novato, CA USA
I have altered Frsky's main programmer that this really needs to be addressed. Think I did the same a while back, but this time made sure it went to a couple of the top people there.
 
Upvote 0

Landru

Strong User
Joined
Jul 25, 2018
Messages
548
Reaction score
84
Location
Vancouver, Canada
Good to know that FrSky has been alerted at the top level.

I wonder if the failure to switch back may apply to other receiver combos. There has been speculation. I've run into an unexpected result, too.
 
Upvote 0

Wayne

Administrator
Staff member
Joined
Nov 29, 2017
Messages
7,798
Solutions
2
Reaction score
4,476
Location
Novato, CA USA
Yes, pretty sure this is a bug Frsky has in most all of the redundant receivers. We have run into it with our Universal ACCST testing. Looked to see if it was something we could cure via Universal or not.

It may be possible with ACCESS to be notified when the switch over occurs. If you bind the second receiver without telemetry, then when the switch occurs, you should get a telemetry lost message from the radio. This is a theory, so you would need to test it. You would only get the one warning.
 
Upvote 0

Landru

Strong User
Joined
Jul 25, 2018
Messages
548
Reaction score
84
Location
Vancouver, Canada
Thanks, Wayne. That's really helpful to know.

A while back, I ran into a very odd occurrence with a non-redundant R9 / RX6R set-up on ACCESS. Can receiver switching ever occur when the receivers are NOT connected via S.bus or S.Port? All the info I've come across suggests that it's just not possible -- even if there were a bug.

Apologies if this is just too O/T for this thread.
 
Upvote 0

Wayne

Administrator
Staff member
Joined
Nov 29, 2017
Messages
7,798
Solutions
2
Reaction score
4,476
Location
Novato, CA USA
Anything is possible, but I have not seen anything reported. The way it works is it needs to be getting valid Sbus IN data for redundancy to be active, so if nothing is plugged in and supplying a good data stream, then it should not be active.
 
Upvote 0

Landru

Strong User
Joined
Jul 25, 2018
Messages
548
Reaction score
84
Location
Vancouver, Canada
Thanks. There was no S.bus input in my case so the explanation likely lays elsewhere. Unfortunately, I haven't been able to reproduce the issue at will. At least, not yet.
 
Upvote 0
Joined
May 15, 2019
Messages
44
Reaction score
15
I feel like there is a lot of incomplete or missing info in this thread and about the topic of redundancy. I really want to understand this and/or help everyone figure it out. I'm not trying to say anyone is incorrect, just that maybe information is missing for me to see it from their perspective. Maybe I'm totally wrong but I can't know without enough information.

@Woodstock1 wanted, as I understand, redundant control signal so he doesn't lose his craft, and does not want to lose telemetry. In that case, running second receiver through S.Bus only and disabling telemetry on the backup receiver should work. If telemetry on Rx2 is off, then there's no chance of it blocking the main Rx telemetry.

He originally asked if he could have just turned off telemetry and have it work, and it seems like the answer is 'yes' but then the conversation went somewhere else before the question being answered. Maybe there are other solutions but wouldn't that have worked?

Woodstock1 is also saying that 'redundancy' never switched back to Rx1 (similar to what Flying Dutchman reported,) while I'm wondering if it was just 'telemetry' never switched back to Rx1. According to the Aloft manual for my FrSky radio, control signal (should) change constantly to 'best' signal, and telemetry only switches when signal is lost from the receiver. So how are people determining which receiver is in control if one of them has telemetry off? And is it possible that telemetry is only reporting the signal strength from the Master Rx, even though Rx2 is actually the one receiving the signal?

I understand Access can do things beyond what the manuals say, but it would really be helpful if people talked about how they hooked things up and what they were expecting. Maybe there are ways to accomplish what you want, maybe we can help figure out what went wrong, or maybe we can all just learn from each other.
 
Upvote 0

Wayne

Administrator
Staff member
Joined
Nov 29, 2017
Messages
7,798
Solutions
2
Reaction score
4,476
Location
Novato, CA USA
I may be totally wrong, but it is my understanding that it will switch off to the second receiver if the main receiver is getting pretty weak feed. When it switches, it switches all control including telemetry. As soon as the main receiver is doing well, it will switch back control to the main receiver. (It should also switch back the telemetry, but seems there is a bug with this.) I am not aware of a way to know what receiver is actually in control at any given time. It the telemetry switching was occuring correctly, then there are methods that could be used to see when the switching is occuring.
 
Upvote 0

Landru

Strong User
Joined
Jul 25, 2018
Messages
548
Reaction score
84
Location
Vancouver, Canada
Over on RCG, a fellow modeller posted instructions and code for building an onboard S.bus data logger. He called it the Receiver Snoop.

Rick has posted details on a number of discoveries he made with the device concerning FrSky gear. Most relevant here are his tests of redundancy. As I recall, those results suggested that data from the redundant receiver might replace that from the primary receiver on a frame-by-frame basis.

I don't recall if the tests were extensive enough to suggest that redundancy always works that way with FrSky gear. However, the discovery does seem to be consistent with your remark, @Joe Garfield, about the manual claiming that the "control signal (should) change constantly to 'best' signal".

The Snoop is a very powerful little device. I built one to try to learn more about a problem I ran into with R9. It proved very useful. However, as Rick found, my results ended up raising new questions.

Kindly,
Andrew
 
Last edited:
Upvote 0

Flying Dutchman

Strong User
Joined
Mar 2, 2020
Messages
236
Reaction score
88
Location
Scottsdale, AZ
@Joe Garfield I assumed that telemetry was being sent by the Rx that was in control (as reported by my Tx), but I don't know if that is actually true or not. I guess it's possible that the two Rx's don't resolve the control vs. telemetry conflict. I never did experiments to answer that question as I already took out the M+ and just use the GR8 without redundancy (but best possible antenna placement).

As you know, a couple of guys on RCG have dug into this pretty deeply, but I don't recall whether any of them pursued the above question either. I don't believe Rick's Snoop experiments addressed it specifically. I'm glad to see you working on this as well, and using a methodical approach. Collectively we should able to figure it out eventually.

At this point I wonder whether this is an M+ specific issue, i.e. would an RS or another GR8 do the same?
 
Upvote 0

choochoo22

Active User
Joined
Feb 26, 2021
Messages
133
Reaction score
41
Location
San Diego, USA
FrSky apparently misled people somewhat by saying that with a redundancy hookup, control switches to the rx with the stronger signal. The way it is actually working approximates that so it's only somewhat misleading and simplified but signal strength doesn't determine which rx is in control. If you think about it, it really couldn't work that way, nor would you want it to. That behavior would require that the primary have access to the secondary RSSI and typically it does not. It would require some clumsy algorithm for determining which signal was better and for how long before switching. And what about 3 rx? Also, signal strength isn't a great indicator of link reliability, just better than nothing. Signal strength can be very high while interference is wiping out your control packets. Control packets can be coming through fine with low signal strength in a quiet RF environment.

Here is how it works. If the primary rx has a good packet from the tx it uses it and ignores the secondary input. If the primary detects a bad packet it ignores that and uses the frame from the secondary sbus. It's that simple, and that determination is made on each frame. Even if the primary has a strong signal it will still drop a few packets. When that happens it takes the frame from the secondary. If the signal to the primary deteriorates it will replace more and more frames until eventually all frames are from the secondary. There is never a point where it "switches control" to the secondary.

The reason I can make these statements with confidence is that they can be seen clearly in the Snoop logs to which Andrew referred. The full write-up is here: https://www.rcgroups.com/forums/showpost.php?p=46575667&postcount=66

What was done was to contrive a setup in which the two receivers were listening to different signals from the same tx. A test channel was established such that the primary rx was getting a constant high value on that channel and the secondary rx was getting a low value. By logging the sbus out of the primary it could be seen which rx was the source of each frame. I'll attach graphs for two segments of the log file. In the first graph the primary rx has a good link and most frames are derived from that rx as can be seen by the graph being mainly high with only an occasional low value indicating the frame came from the secondary. In the other graph the opposite was true, the primary had a poor link and nearly all frames were coming from the secondary. All-in-all this seems like a superior methodology to the popular but wrong idea that is somehow switches control from one rx to the other based on signal strength.

a14661647-202-Good%20signal.jpg

a14661645-154-Bad%20Signal.jpg


It works this way with both ACCST and ACCESS.
--------------------------------------------------------------------------------------------------------
Nothing above has anything to do with telemetry which is completely unrelated electronically. I don't know too much about how the telemetry works with recent firmware but there have been some changes. Here are some things I think I know:

* It would be impossible for telemetry to indicate which receiver is in control in the above scenario since frames can come from either receiver determined every few milliseconds. The telemetry is much slower and couldn't keep up. Perhaps the best that could be done is which rx is providing most of the frames, or a percentage.

* It used to be necessary to shut off the telemetry on the secondary receiver to prevent the secondary telemetry from interfering. Newer ACCESS systems get around that and can provide telemetry from both (3) receivers.

* Mike Daily provided a hookup for "Trio" telemetry with a redundant rx hookup. This setup connects all s-port sensors and the receivers in parallel. Here: https://www.rcgroups.com/forums/showpost.php?p=47398449&postcount=8918

* I've done some superficial testing of this hookup and the external sensor data seems to come through to the transmitter just fine with telemetry active on both rx. (I tested it with two R6 ACCESS receivers, a Variometer, and a Current sensor)

* In testing the above, I tried disconnecting one rx at a time. The external sensor data was received by the tx with only a momentary pause during transitions as a receiver was connected or disconnected. It's not clear how, but the receivers seem to work out which is in control of the s-port.

* I feel there is a lot I don't know about how the telemetry works with current ACCESS firmware but it seems to be evolving in parallel to Ethos.
 
Last edited:
Upvote 1

gnichola

Very Strong User
Joined
Jan 23, 2018
Messages
573
Reaction score
191
@choochoo22 What's odd then is the behavior I noticed when doing my own little test which I posted here: What I noticed with Access was that the rssi dropped as I walked away until the point of "switchover" where the rssi bounced back up. I am not exactly sure how this plays into your demo above, but perhaps the behavior is different with Access.
 
Upvote 0
Top