Frsky ACCESS and Archer Receivers

[Chris Bott - Moderator]

I'm just dipping my toe into the ACCESS protocol. 

Does anyone know of any decent documentation?

 

I have everything I have - working fine.

I'm just wondering the significance of the registration fields "Reg ID" and "UID" on top of Rx number. 

 

Also, I've set up a Pro Rx with a signal redundancy input on "S.Port In".

Again, working fine, and I found a protracted way to test redundancy, but is there a way to get some indication of the redundancy signal by telemetry? 

[Bob Cotsford]

I don't know a lot about the subject apart from what I've gleaned setting up a couple of receivers.  'REG ID' can be set up in the radio settings iirc, you can set it to whatever you like as it only seems to be part of the registration process.  It will default to whatever is set in settings but can be overwritten on a model by model basis at the registration step.  I have set it the same on both my X10S and X12S so that I can use either tx by simply selecting 'bind' and powering up the model.  I'm not sure about UID and faced with searching several hundreds of pages on RCG to find out my brain simply shut down.  Like a horse refusing a jump, it said 'no thanks' and wandered off in search of grass to graze on. To be accurate, in my case it was hot tea and ginger biscuits rather than grass!

Edited April 10, 2021 by Bob Cotsford

[Mike Blandford]

Reg ID is the name you give to your transmitters. When you register a receiver, it is registered to that ID, so your Reg ID is stored in the Rx.

The UID is the index of which, of three possible, receivers you have registered to a particular model.

This post has a link to a .pdf file that describes how to use the ACCESS registering and binding:

https://www.rcgroups.com/forums/showpost.php?p=41663861&postcount=1670

 

Mike

[Chris Bott - Moderator]

Thanks both, that's really useful information. 

I do wish FrSky would produce instructions that actually helped.

 

Reg ID:-

So if I had more than one Access Tx, I assume I could make the Reg ID the same on both or all of them and I'd only need to register a Rx to one of them for it to be registered with all? 

[Chris Bott - Moderator]

Another question. 

Do I need to be particularly bothered by software versions?

 

I can't imagine different versions will affect using a S.Bus signal for redundancy. But might be worth keeping up to date if leaving telemetry on from both receivers?

 

I see that only telemetry from the 'in use' Rx gets through. So I'm intending to connect on board sensors, only to the main Rx. That way I get an obvious warning if the redundancy Rx gets used.  Is that a sensible way to go?

[Mike Blandford]

Yes to using the same Reg ID on two transmitters.

The different software versions on should be only for fixing problems on specific hardware, not the communication between Tx and Rx.

Could be useful to only connect sensors to the main Rx, although I understood you should be able to connect the SPort of both receivers together. I believe the "redundancy" receiver is actually used on a frame by frame basis, so if the "main" Rx misses a frame, it looks for a valid frame from the other Rx and uses that if present.

This is unlikely to affect the telemetry.

 

Mike

[MattyB]

I really wish Frsky would find a way to report signal strength information from  redundancy RXs. At the moment it’s pretty much impossible to test whether your secondary RX is doing it’s job or not as long as the primary is functioning. I know receiving two separate telemetry streams from two RXs at the TX is problematic, but surely they could engineer a way of passing the relevant parameters back to the primary RX for monitoring at the TX? Can ACCESS do this, or is it lackin in this way as per ACCST? 

[Chris Bott - Moderator]

Using Access, I tested that the redundancy Rx was providing redundancy by creating an original model with main and redundancy Rxs bound. Then a copy of the model and then binding only the redundancy Rx in the copy model. 

 

Starting with the original model selected and green LEDs on both Rxs, switching to the copy model made the main Rx go red while redundancy Rx stayed green. 

At this point the servos still responded fine unless the S.Bus redundancy line was disconnected. 

The Tx was still reporting RSSI, RxBt and VFR. I can only assume that these were now from the only bound Rx, the redundancy one. The (single Rx at a time) telemetry had switched to the redundancy Rx.

 

[Chris Bott - Moderator]

37 minutes ago, MattyB said:

I really wish Frsky would find a way to report signal strength information from  redundancy RXs. At the moment it’s pretty much impossible to test whether your secondary RX is doing it’s job or not as long as the primary is functioning. I know receiving two separate telemetry streams from two RXs at the TX is problematic, but surely they could engineer a way of passing the relevant parameters back to the primary RX for monitoring at the TX? Can ACCESS do this, or is it lackin in this way as per ACCST? 

Matty, to answer your question, I have tried connecting S.Port connections of both Rxs together. This didn't bring up any redundancy Rx data, even with a new 'Discover new sensors' attempt. 

[MattyB]

27 minutes ago, Chris Bott - Moderator said:

Using Access, I tested that the redundancy Rx was providing redundancy by creating an original model with main and redundancy Rxs bound. Then a copy of the model and then binding only the redundancy Rx in the copy model. 

 

Starting with the original model selected and green LEDs on both Rxs, switching to the copy model made the main Rx go red while redundancy Rx stayed green. 

At this point the servos still responded fine unless the S.Bus redundancy line was disconnected. 

The Tx was still reporting RSSI, RxBt and VFR. I can only assume that these were now from the only bound Rx, the redundancy one. The (single Rx at a time) telemetry had switched to the redundancy Rx.

That’s a good test and easier to do than with ACCST, but I am talking about real time, “always on” RSSI reporting from the secondary in addition to from the primary. Being able to do that would give much greater confidence in resilient setup and enable aerial optimisation of the secondary in the same way you can do with a primary. Surely it can’t be impossible? I would think this would be a really popular piece of functionality if it could be implemented.

Edited April 11, 2021 by MattyB

[Chris Bott - Moderator]

2 minutes ago, MattyB said:

That’s a good test and easier to do than with ACCST, but I am talking about real time, “always on” RSSI reporting from the secondary in addition to from the primary. Being able to do that would give much greater confidence in resilient setup and enable aerial optimisation of the secondary in the same way you can do with a primary. Surely it can’t be impossible? I would think this would be a really popular piece of functionality if it could be implemented.

I absolutely agree and was as disappointed as you when no extra telemetry appeared from the redundancy Rx.