Universal ACCST Firmware is coming.

[choochoo22]

If I understand correctly, the test you posted subsequently only pertains to s-bus "cross-connected" receivers, not to my scenario. But the doubt arose in me since you posted that as a seemingly direct reply from my post!

Sorry to confuse. Yes the test only relates to cross connected redundancy.

 

[MikeB]

I've tested a RX4R and a G-RX8 with "cross-coupled" SBUS. The result is it works SOMETIMES! Each Rx on a different RxNum, and I can swap the RxNum on the Tx and both Rx drive their servo outputs all the time.
If I change the RxNum so both Rx lose signal, I get failsafe on many occasions, but sometimes I don't.
It is possible the same would happen with my previous test (RX8R and RX8R-PRO) but that I didn't try it enough times.

My general thought was this connection is not a good idea, A Rx goes into failsafe if it has no signal and no valid SBUS in. If both Rx lose signal, each may therefore keep the other active via the SBUS signals.

Mike

 

[MikeB]

Any idea what the state of the "Lost Frame" bit is in the SBUS packets when neither Rx is receiving a signal?
Maybe this is nor being set correctly (e.g. saying no lost frame because of a valid SBUS in frame), or maybe I'm not handling "no signal" and all SBUS in frames have the lost frame bit.

Mike

 

[gnauck]

My general thought was this connection is not a good idea, A Rx goes into failsafe if it has no signal and no valid SBUS in. If both Rx lose signal, each may therefore keep the other active via the SBUS signals.

In general cross-connect or no-cross connect should make no difference, or I am missing something.

A redundant master-slave setup can be also used in combination with a flight controller that requires the SBUS signal, or a redundancy box that also requires the SBUS signal.
When there is an issue with the SBUS out signal then not only redundancy setup with cross connect should be affected.

Or is it supposed to work only with the PWM receiver outputs?

Thanks for all your intensive testing, looks like I started quite a discussion

Alex

 

[choochoo22]

Any idea what the state of the "Lost Frame" bit is in the SBUS packets when neither Rx is receiving a signal?
Maybe this is nor being set correctly (e.g. saying no lost frame because of a valid SBUS in frame), or maybe I'm not handling "no signal" and all SBUS in frames have the lost frame bit.

Mike

This is the same log as last posted, zoomed in. At the beginning of this interval rx2 is receiving signal, then rx1, then neither. The green line roughly indicates the change points. LF is in pink

The LF bit is set for 17 frames during the transition from rx2>rx1, coinciding with the glitch in the wave during that transition. This makes sense. At this point rx1 has no signal. When the ID is switched, rx2 will lose signal shortly before rx1 syncs up, so LF is set.

There is a stray LF at about 48:52 which is probably unrelated.

Later when the ID is changed to zero and both rx lose signal it gets a bit bizarre. LF sets for 13 frames then begins alternating on-off. This persists for almost 100 frames then shuts off for good. Perhaps a race condition of sorts that gets resolved as the sync between the rx drifts or another stray disrupts the pattern? But it would seem the correct value should be on, not off, as no signal is being received.

 

[choochoo22]

In general cross-connect or no-cross connect should make no difference, or I am missing something.

A redundant master-slave setup can be also used in combination with a flight controller that requires the SBUS signal, or a redundancy box that also requires the SBUS signal.
When there is an issue with the SBUS out signal then not only redundancy setup with cross connect should be affected.

Or is it supposed to work only with the PWM receiver outputs?

Thanks for all your intensive testing, looks like I started quite a discussion

Alex

The cross-connect is the problem. The issue under discussion does not arise if connected as primary/secondary, only when you cross-connect to create two primarys.

In a "correct" redundancy connection, control information flows one way; from the secondary to the primary to any connected controllers or servos. This works fine as intended. If the primary is connected back to the secondary a feedback loop is created that initiates sort of a chicken n egg problem that makes it difficult for the firmware to determine what data is good. It would seem the LF bit could be a help in resolving the issue in the firmware. FrSky, however, has compromised the LF bit to the point of being useless. Uni firmware is not constrained by that but seems to have similar issues and, even if resolved could still have issues if mixed with FrSky if that resolution relies on LF.

The bottom line for me is don't do it. Any theoretical benefit that might derive from cross-connection isn't worth the risk of defeating failsafe. FrSky warns against cross-connection and this is good advice. The diagram in the German manual should be removed IMHO, it's a dangerous connection.

Here's FrSkys advice in an RX8R-Pro manual. Not all manuals contain such a statement. Manuals from ~2020 on seem to list redundancy in th feature set but say nothing about connections.

 

[gnauck]

The RX8R Pro is the only receiver where I have seen this note in the manual yet.

 

[MikeB]

I agree with "don't cross couple SBUS". Failsafe on UNI, with CROSS COUPLED SBUS, doesn't always work, so it is not safe.
Given everything is working with redundancy otherwise, I don't feel it is necessary to try changing anything to make this work reliably as any changes would then need careful checking and testing to make sure "normal" redundancy is still fully working.

I notice in the code that there is at least 1 condition where the lost frame bit from SBUS in is propagated to SBUS out. So with cross coupled receivers this is a potential feedback loop.
Since a valid configuration is to use 3 receivers, with SBUS daisy chained, the Rx in the middle does need to operate with both SBUS in and SBUS out, and propagating the lost frame bit under certain conditions makes sense (Rx in failsafe, SBUS in has LF bit set).

Mike

 

[Hlaalu]

Failsafe on UNI doesn't always work, so it is not safe.

I'm sorry Mike, the other details are well beyond my understanding, but is the above an absolute statement about the UNI firmware or was it referred specifically to the scenario described above by the user gnauck (receivers cross-connected by sbus)?

 

[choochoo22]

The RX8R Pro is the only receiver where I have seen this note in the manual yet.

...Given everything is working with redundancy otherwise, I don't feel it is necessary to try changing anything to make this work reliably as any changes would then need careful checking and testing to make sure "normal" redundancy is still fully working....

Agree with both.

I think we agree on the lost frame as well. A given rx should set the bit if it has no new frame data to supply, either internally or from input.

 

[choochoo22]

I'm sorry Mike, the other details are well beyond my understanding, but is the above an absolute statement about the UNI firmware or was it referred specifically to the scenario described above by the user gnauck (receivers cross-connected by sbus)?

That was in the context of cross-connected sbus. (in which case failsafe on FrSky firmware doesn't work reliably either.) If you prohibit such cross connection, failsafe works fine on both.

 

[MikeB]

I've edited my post to make it clear it is only cross coupled SBUS that causes a failsafe problem.

Mike

 

[MikeB]

I only want to do "safe" changes to UNI.
I'm wondering if the following would "fix" the cross coupled problem while remaining safe in all other situations.

When a SBUS frame is received check the "lost frame" bit and if set, increment a counter (to a maximum of 200) while if clear set the counter to zero. This counter will then count how many consecutive SBUS frames are received with the lost frame bit set.
If the counter reaches 100, then consider the receiver sending the SBUS frames has lost signal so should be in failsafe and act accordingly. So if this Rx has lost signal as well, the Rx goes into failsafe.

Mike

 

[choochoo22]

There is only a "cross coupled problem" if someone connects cross coupled redundancy. The only reason for someone to do that is for each receiver to benefit from the redundancy of the other, which was never an objective or feature of FrSky's redundancy. Making this work, then, is not so much fixing a problem as it is adding a feature.

What you suggest is quite reasonable as a way to add this feature to Uni firmware. However... It depends on reasonable behavior from the "other" receiver. If both rx are Uni that may be controlled. If the other rx is FrSky it gets tricky and a bit risky.

I presume Uni does the obvious thing and sets the LF flag whenever an incoming packet is bad or missed. FrSky used to do this but does not anymore in any current firmware I have tested (I certainly have not tested everything). For a few years now FrSky firmware does not set the LF flag until several consecutive packets are lost, and the number required differs from one firmware to another.

At best, this just means that counting 100 LF may delay the onset of failsafe by maybe 10 frames as FrSky didn't start setting the LF flag until 10 packets were lost. This wouldn't hurt. At worst, the FrSky rx might react differently to the incoming frames from Uni and the two rx might enter failsafe at different times or maybe only one enters failsafe somehow with greatly differing results depending on how the user connected the channels. If the Uni rx had already lost link and counted 100 LF from the FrSky rx, it would seem that Uni setting FS would cause the FrSky rx to also engage failsafe but this would require some testing which, by nature of the situation, could never be complete.

I would suggest that if you want to add this feature to Uni that it be made clear that both rx need to be running Uni firmware. Allowing the other rx to be FrSky, or any non-Uni firmware, opens a pandora's box of potential issues beyond your control that might defy testing and could change unnoticed in future FrSky releases.

If you want to persue this I would be happy to help testing with whatever hardware I have on hand. Though perhaps this discussion belongs back in the beta thread.

 

[jdmckeown]

The receivers are built by FrSky, but are no longer a normally listed item for other dealers. We team up with the other FrSky Service Dealers to combine our buying power allowing us to order up a production run of receivers. This was a very nice offer from FrSky to offer this service to us and to help support their customers and the Service Dealers. So far 2 ACCST receivers have been brought back from extinction.

Really! That is a step in right direction.

 

[WombatDave]

Hi Guy's



I am having problems loading the activation Lua file on to my x20s, it's running the latest firmware

according to Ethos Suite. My Rx is a RX8Rpro and have successfully loaded the UNI_rx8rpro_59sm.frk on the Rx using a STK adaptor. The Rx binds to the TX as per the Uni-Rx Guide and it's this next step where I have run into a problem.

Which file do I use for the activation Lua script to work on my TX ? Second question where is it loaded on the TX?

Look forward to your helpful replies



Dave

 

[MikeB]

You need the specific LUA for Ethos.
On the SD card, in the "scripts" directory you should have a directory called "uniActi".
In this directory you need 3 files:
engelmt.bmp
main.lua
main.png

The script files may be downloaded from here: https://github.com/offer-shmuely/frsky-accst-uni-rx-scripts/tree/main/ETHOS
You may also get the setup and stat scripts from there.

To run the script, go to the "System" (touch the "gear wheel"), then scroll the icons left, UNI-Activate should appear as an icon, just touch it to run it.

Mike

 

[gnauck]

I only want to do "safe" changes to UNI.
I'm wondering if the following would "fix" the cross coupled problem while remaining safe in all other situations.

When a SBUS frame is received check the "lost frame" bit and if set, increment a counter (to a maximum of 200) while if clear set the counter to zero. This counter will then count how many consecutive SBUS frames are received with the lost frame bit set.
If the counter reaches 100, then consider the receiver sending the SBUS frames has lost signal so should be in failsafe and act accordingly. So if this Rx has lost signal as well, the Rx goes into failsafe.

This sounds good to me.
When I started testing the cross connected redundancy my assumption was that it works already like you described.

Alex

 

[Miami Mike]

I tried binding a UNI-Rx RX8R in "Telem OFF" mode and everything appears to work okay except that the receiver still transmits telemetry! I need to turn that off so that I can use it in conjunction with another receiver. My RX8R is currently flashed with rx8r_rom54sm.frk. If I flash it with rx8r_rom57sm.frk will that fix the problem?

Or do I have to flash it back to the original Frsky firmware to be able to stop it from transmitting telemetry? That won't be a simple process for me because the Frsky website only has ACCST D16 v2.1.0 Rx8R firmware and my radios still have ACCST v1. Unless I can find the original ACCST v1 firmware for an RX8R it looks like I'd have to re-flash my radio just to have one working receiver that doesn't transmit telemetry.

Addendum: I tried bridging across the CH3 & CH4 signal pins during bind, but that didn't work either. Then I tried an X8R receiver, first by selecting "Telem OFF" and then by bridging CH3 & CH4 signal pins, but I got the same results that I got with the RX8R.

 

[Mikej]

I tried binding a UNI-Rx RX8R in "Telem OFF" mode and everything appears to work okay except that the receiver still transmits telemetry! I need to turn that off so that I can use it in conjunction with another receiver. My RX8R is currently flashed with rx8r_rom54sm.frk. If I flash it with rx8r_rom57sm.frk will that fix the problem?

Or do I have to flash it back to the original Frsky firmware to be able to stop it from transmitting telemetry? That won't be a simple process for me because the Frsky website only has ACCST D16 v2.1.0 Rx8R firmware and my radios still have ACCST v1. Unless I can find the original ACCST v1 firmware for an RX8R it looks like I'd have to re-flash my radio just to have one working receiver that doesn't transmit telemetry.

Addendum: I tried bridging across the CH3 & CH4 signal pins during bind, but that didn't work either. Then I tried an X8R receiver, first by selecting "Telem OFF" and then by bridging CH3 & CH4 signal pins, but I got the same results that I got with the RX8R.

Not necessarily obvious. The UNI firmware for the newer receivers (RX4R, G-RX6 etc.) actually turns the telemetry on, regardless of the bind option, if the Rx is not activated.
I'll see about putting this in the UNI firmware for the older receivers.

Mike

Miami Mike

Not sure if you have seen the message above from Mike B a few pages back - this could explain what you are seing. The suggestion is to activate and then rebind with Telemerty off after activation Post number 524 in this thread.