Universal ACCST Firmware (UNI)

[jmorrow]

I took a look at EdgeTX release notes and it appears that they updated to Lua 5.3 in 2.11.x. There are incompatibilities with Lua 5.2 used in earlier versions of EdgeTX. I suspect that since the bit32 library has been deprecated, the UNI RX scripts will need to be updated to use the bitwise operators in Lua 5.3.

Here is the list of Lua 5.2 to 5.3 incompatibilities: https://www.lua.org/manual/5.3/manual.html#8



When I get some time this weekend I'll try reverting to EdgeTX 2.8 and see if it works.

Attached is a version of the Activate script where I updated it to use the new bitwise operators, but it still didn't work correctly on EdgeTX 2.11.3.

 

[MikeB]

I've dug out my prototype X9Dplus and put Edge 2.11.3 on it. I can confirm the LUAs are not working, but do not show any errors.
I've tested the activate script using erskyTx and it works correctly. ErskyTx is now also using LUA version 5.3.
It seems something has changed in Edge.

Mike

Edit: The script is OK if using an external MultiProtocol module.
Edit2: It appears there is an issue on Edge (2.11) regarding sending data to the Rx when using a XJT module.

 

[jmorrow]

I've dug out my prototype X9Dplus and put Edge 2.11.3 on it. I can confirm the LUAs are not working, but do not show any errors.
I've tested the activate script using erskyTx and it works correctly. ErskyTx is now also using LUA version 5.3.
It seems something has changed in Edge.

Mike

Edit: The script is OK if using an external MultiProtocol module.

This commit may have something to do with it. https://github.com/EdgeTX/edgetx/commit/30b89220964faedb157a39470587d118d71f9cf6

I reverted back to EdgeTX 2.10.6 and the script worked correctly.

 

[alm_nl]

The order of reading the channels is also out of order when using EdgeTX 2.11.x with the UNI-Statistics.lua script (using the XJT module inside the X9D Plus).

 

[davemcddd]

Have you tried Edge 2.10.6 to see if it works OK?

 

[alm_nl]

Yes, EdgeTX 2.10.6 (and below) did not have the issue I mentioned.

 

[ScottyDsntKnow]

Recently picked up a cheap Horus 10S Express off of RCG to run Edge with ACCESS and had not really messed with UNI too much before but set up a S6R with UNI and I gotta say I like it better than the new Archer+ as far as how stab is setup and the interface and the ease of it. And then looking at the whole picture, is there any real benefit to move several ACCST planes I have over to access when UNI exists? I'm not seeing a reason if I'm not using TD or TW or needing more than 16ch. Latency, resolution, signal etc... all seem similar for what I'm doing. And all the FrSky sensors work fine with UNI. Maybe I'm missing something?

 

[MikeB]

About the only advantage ACCESS has is it sends packets every 7mS instead of 9mS for ACCST, so just a small reduction in latency.
When running UNI on ACCESS capable receivers (e.g. G-RX8) you do get the improved sensitivity so may set the RSSI warning values to 35 and 32.

Mike

 

[JeromePilot]

hi,
first : congratulations for this great job
Any chance to see a UNI firmware for the ACCST 900mhz receivers ? dual transmitter would be great...

 

[MikeB]

Probably not. The 900MHz uses a different RF chip. I would need to see how this works and see what the protocol is as well. Some of this I could likely find from the multiprotocol code, but would be quite a bit of work to sort all the timing out and test it.

Mike

 

[JeromePilot]

thk for your reply Mike.
I'll find an other solution (on my x9e I can't just swap the module, I need to open it)

 

[OlleG]

Hi
The UNI FW is super! I have not used for SxR as I didn't know until recently that it was supported. A question; are the stabilization algorithms the same as FrSky original FW or modified?
/OlleG

 

[MikeB]

They are not based on FrSky algorithms, I don't know what they use. There is a project on Github for the openXsensor running on a RP2040 processor. This includes stabilisation software so I took ideas from that to implement UNI on the S8R/S6R.

For general information, I now have the ACCESS protocol running in UNI firmware, I'm testing it now. The only UNI supported Rx I haven't built with ACCESS is the RXSR, but I should be able to add that as well. I even have ACCESS working on a D8R-iiPlus. The only significant feature not yet implemented is the Share function.

Mike

 

[OlleG]

Thank you Mike,
This is very interesting as I see the original algorithm as there is "room for improvement".
Br/OlleG

 

[OlleG]

Is the stabilization you implemented described in same kind of manual? Which channels to use to turn on/off the stabilization and adjust gain?
/OlleG

 

[MikeB]

Use exactly the same channels as the FrSky firmware to control stab./auto-level and master gain. Note that hover and knife edge are not implemented.
The individual gain and direction settings are set using the same script (LUA or BASIC) as for the FrSky firmware.

Mike

 

[OlleG]

Thank you!

 

[pct06]

Hi
It looks like the UNI firmware could help me but I would need your feedback, I read a lot but not sure of my conclusions.

I am using X6R/X8R/X8R Pro and would like to add extra servos above the PWM physical outputs, respectively 6 and 8 channels, by using the SBUS port.

If I need ony one extra servo, the UNI firware allows to use the SBUS port as an extra PWM output, which is awesome.

Now if I need 2 extra servos, I do need to use an SBUS to PWM converter. Lets use X8R as an example.

First option is to use the Frsky SBUS to PWM convertor. While the FrSky SCC (Servo Channel Changer) is discontinued, I saw an Windows app using the Frsky STK to set the channel ID per PWM output, thus having the 4 extra PWM output on CH 9 to 12 (https://www.rcgroups.com/forums/showthread.php?4776841-SBUS-Channel-Changing-(FrSky)&perpage=20). Am I correct ?

Second option, take a 4 CH SBUS-PWM converter from AliExpress but it looks like they are "hard coded" to read the SBUS id 1 to 4 only. So the issue might be that the converter will take the id 1 to 4 on the SBUS, thus duplicating the physical PWM port 1 to 4 of the receiver, and therefore not adding 4 extras PWM output.
(on some 8 CH converter, you can choose 1-8 or 9-16 by solder a shunt, but theses converters are much bigger and also more expensive for just 2 extra channels).

Can UNI Firmware remap the physical PWM output of the receiver to channels 5 to 12 ? (PWM1 - CH5, PWM1 -CH6 etc) so that CH1 to 4 will go to SBUS and the converter and CH5 to 12 to PWM1 to 8 physical output of the receiver ?

Thanks for your advise.

 

[MikeB]

Yes to using the STK and Windows app to change the FrSky SBUS to PWM converter channel assignments (I wrote that as well as UNI!).

Yes to changing which channels are output on the PWM signals in UNI, any channel to any pin. Use the UNI setup LUA script.

Mike

 

[Jeronimo770]

Receiver battery voltage problem.

I have an X4R in a small electric plane. I just updated the firmware to UNI_xsr_84sm.frk powered with a 2S LiPo giving about 7.8v say.
My Tx is an X18 running Ethos 1.6.5 with the Rx set to ACCST D16 bound with telemetry Ch1 - 8
Discover sensors gives me RSSI, RX (?), RxBatt, VFR and ADC2 (?)
The RxBatt voltage is reported as ~5.8v and does not change as I run the battery down on the motor. In Telemetry I have tried changing the Ratio (to show ~7.8v) and the Offset (separately) but the reported voltage does not change.
I cannot set up a Low RxBatt warning because the reported voltage does not change!

Advice appreciated, thanks.