Telemetry from both G-RX8 receivers. Possible?

[camber2]

Trying to find out how to get telemetry from both G-RX8 receivers. It works with 2 different rx's
X9D+2019, OTX 2.3.7, G-RX8 ACCESS
Both rx's are running pwm and connect via subus. I get the 6 basic sensors from 1st rx and try to discover new sensors but cannot get 2nd rx to show sensors. If I unplug the main rx it will grab the sensors from 2nd rx. Any ideas? Is it possible to change ID to alt on second rx?

 

[Konrad]

Not sure what you are doing? Are you using 2 RXs in one aircraft? If so how are you using the two receivers? Is one a channel expander (1 thru 8 and the second 9 thru 16)? Or are you using the second receiver as a redundent RX. Reading the manual is say that both of these configuration the second RX must have the telemetry disabled.

P.S.
FrSky ACCESS Trio control states you should, in fact be able to do as you plan.

 

[camber2]

Yes as redundancy. Both in one fuse. Running Access!
Trying to read sensors from 2nd rx. First (main rx is showing the standards telemetry but I am trying to get the 2nd rx (another G-RX8) to show it's telemetry on the X9D+2019.
If you use 2 different receivers all sensors are viewable. Using 2 G-RX8 I see only one set from either the 1st or the 2nd rx. I am trying to get both. Wondering if it is the ID of the sensors that are the problem.

 

[Landru]

My understanding was this was possible. Mind you, my experience with ACCESS is very limited.

Along similar lines, I've been trying with no success to get telemetry from two different receivers when the second is set as a channel expander.

In my case, channels 1-8 are on a G-RX8 ("Receiver1") and channels 9-14 are on a G-RX6 ("Receiver2").

It's odd, too, that the G-RX6 only supports 6 channels in this case. I would have expected 9-16 to be available since it does have SBUS capability.

ACCESS 2.1.0
QX7 ACCESS tarnsmitter

 

[Cole Hallman]

TELEMETRY

you can connect 2 receivers with telemetry using access. BUT only one at a time actually updates values. Which one is set determined by which is connected first. You can switch by powering down the current one. Automatically switches to the other.
I find this dissapointing primarily because I would like 2 get rssi updates from both in a redundant setting

 

[Kilrah]

Telemetry from multiple receivers is a feature that was advertised for ACCESS from the start but has never actually materialized so far.

 

[Wayne]

Interesting. The way I had perceived the feature was that telemetry was now able to switch from 1 receiver to the other as needed. Something that did not happen in ACCST. So in my mind this does exist in ACCESS. I do agree though, it would be nice to be able to log the RSSI from each receiver as a minimum. I don't think I would want warnings from the system for each RSSI source though, only if the strongest one is getting weak. Can you imagine a flight, "RSSI from receiver 2 is low", "RSSI from receiver 3 is critical", etc..

 

[Kilrah]

The way I had perceived the feature was that telemetry was now able to switch from 1 receiver to the other as needed.

Yeah that's what it is now but it was supposed to be the fancy thing at the end, but for some reason a year and some ago FrSky said they couldn't get it to work... which we never understood since it seems trivial. We gave pointers but nothing came out of it.

 

[Konrad]

Kilrah, are you an OpenTX developer, or contracted programer for FrSky?

Yeah that's what it is now but it was supposed to be the fancy thing at the end, but for some reason a year and some ago FrSky said they couldn't get it to work... which we never understood since it seems trivial. We gave pointers but nothing came out of it.

All the best,
Konrad

 

[Kilrah]

OpenTX developer. Was the one who pushed hard for OpenTX to run on the original Taranis so that our software could be used by people on something that didn't require them to mod a 9X to run it.

 

[Konrad]

Coming from the high end Multiplex Profi 4000 mc, I thank you. I really hate menue driven commands. Ok, I hate any programing but the mixer driven programing make so much more sense.

 

[Wayne]

Agreed. Thank you!

And thank you for the many years of answering questions and helping folks, not to mention the programming.