Aloft Forums
Welcome to Aloft Forums. 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!
Universal ACCST Firmware (UNI)
- Thread starter Wayne
- Start date
I have been flying pretty much exclusively the Uni-FW with legacy ACCST receivers for the last couple of years and its performance and extended telemetry features is without equal. I’ve had zero issues. That said, I have various receivers, mostly RX6Rs and X4Rs. The versions installed span from v57 and v83. Some are embedded in planes and a tad difficult to reach. I only use PWM servos.
My question: Is there a minimum FW version that I should be running that has all important bug fixes for PWM operation? Is v57 good enough? I’ve read through the logs and can’t quite determine this detail.
Thanks for all your work on the Uni-FW and keeping ACCST available and working well for the community of FrSky users.
Ollie
My question: Is there a minimum FW version that I should be running that has all important bug fixes for PWM operation? Is v57 good enough? I’ve read through the logs and can’t quite determine this detail.
Thanks for all your work on the Uni-FW and keeping ACCST available and working well for the community of FrSky users.
Ollie
MikeB
Very Strong User
Since V57 the following has been done:
Changes to get the D8 Rx version to run correctly
V58 Slow SPort polling if fifo getting full. Stop sending 0xF000 total dropped packet count sensor. RX8R-PRO fix SBUS as servo setting lost through power cycle.
V59 fix RX8R-PRO servo twitch bug.
Add CPPM on CH1 for D8 receivers
V80, FBUS added
V81 Servo rates global, not specific to Tx. D8 add Fport2.
V83, includes SXR
V58 slow polling only helps if you have a very poor RF link for telemetry.
V59 only affects the RX8R-PRO
V80 only needed if you use FBUS
V81 only relevant if you use 2 transmitters with dual bind.
Mike
Changes to get the D8 Rx version to run correctly
V58 Slow SPort polling if fifo getting full. Stop sending 0xF000 total dropped packet count sensor. RX8R-PRO fix SBUS as servo setting lost through power cycle.
V59 fix RX8R-PRO servo twitch bug.
Add CPPM on CH1 for D8 receivers
V80, FBUS added
V81 Servo rates global, not specific to Tx. D8 add Fport2.
V83, includes SXR
V58 slow polling only helps if you have a very poor RF link for telemetry.
V59 only affects the RX8R-PRO
V80 only needed if you use FBUS
V81 only relevant if you use 2 transmitters with dual bind.
Mike
Mike, thank you for breaking down the release history. I don’t see anything in the releases after v57 that directly affect the receivers I’m using or my use case of PWM only.
Ollie
I went back reading the exchange we had on this thread back in autumn 2023, but I still can't quite figure the following part out.
If I have:
An R-X8R Pro as main receiver, with UNI firmware ---> to which there's an XM+ S-BUSed to it as redundancy...
...do the failsafe actual settings of the XM+ ever matter in any circumstance I might run into?
Or are the FS settings of the R-X8R Pro the ones that will be in every case applied to the servos?
Thank you
If I have:
An R-X8R Pro as main receiver, with UNI firmware ---> to which there's an XM+ S-BUSed to it as redundancy...
...do the failsafe actual settings of the XM+ ever matter in any circumstance I might run into?
Or are the FS settings of the R-X8R Pro the ones that will be in every case applied to the servos?
Thank you
MikeB
Very Strong User
As long as the XM+ sends SBUS with the FS bit set when it is in failsafe, then the XM+ FS settings will not be used.
If you use "Custom" FS setting, sent from the Tx, then the FS settings in both receivers will be the same if both receivers are bound to the one Tx module.
Mike
If you use "Custom" FS setting, sent from the Tx, then the FS settings in both receivers will be the same if both receivers are bound to the one Tx module.
Mike
Thanks Mike. I am not sure I get the first sentence but if I am getting your whole point right, the XM+ failsafe settings have no practical relevance, since they are going to be either ignored in favour of the R-X8R Pro settings, or identical to the latter (and even in this case, they will be ignored anyway, should the system enter into failsafe). Am I correct?
I have been running UNI for almost 2 years without a problem, but I now want to upgrade to revision 83 since I have an R-X8R Pro and I see v. 83 fixes some issues with this Rx.
But I am a bit confused:
1. Post #1 says that all updates "now" use the Sub-Master version, but changelogs don't seem to be listed chronologically, so it isn't clear since when all updates use the SM version. Files attached below the page aren't SM version, while on GitHub I find both versions of the same release (sm versions are under /raw subfolder). What is Sub-Master anyway? What should I be downloading for which use case?
2. Also: some of the attachments in post #1 and #2 seem to overlap. UNI_setup6, UNI_setup7, UNI_set: is the latter different from the previous 2? Are the attachments of the second post only meant for Ethos?
3. Same thing for XxStatv5 and UNI_stat: does this mean the first file is only for Xx receivers and the other for all receivers? Or only for non-Xx receivers? To further complicate things, on GitHub I find UNI_Statistics.lua. Is this which version of the script?
I am sorry if I am asking the obvious, but coming back to this thread after a while I find it a bit difficult to navigate it through.
Thank you!
P.S. "Universal ACCST Guide" doesn't seem to have been updated on GitHub, which hosts the older version.
But I am a bit confused:
1. Post #1 says that all updates "now" use the Sub-Master version, but changelogs don't seem to be listed chronologically, so it isn't clear since when all updates use the SM version. Files attached below the page aren't SM version, while on GitHub I find both versions of the same release (sm versions are under /raw subfolder). What is Sub-Master anyway? What should I be downloading for which use case?
2. Also: some of the attachments in post #1 and #2 seem to overlap. UNI_setup6, UNI_setup7, UNI_set: is the latter different from the previous 2? Are the attachments of the second post only meant for Ethos?
3. Same thing for XxStatv5 and UNI_stat: does this mean the first file is only for Xx receivers and the other for all receivers? Or only for non-Xx receivers? To further complicate things, on GitHub I find UNI_Statistics.lua. Is this which version of the script?
I am sorry if I am asking the obvious, but coming back to this thread after a while I find it a bit difficult to navigate it through.
Thank you!
P.S. "Universal ACCST Guide" doesn't seem to have been updated on GitHub, which hosts the older version.
Last edited:
MikeB
Very Strong User
The first post of this thread: https://forum.alofthobbies.com/inde...mware-release-files-universal-accst-d16.3270/
has the file "UNI_all_V83sm.zip" attached. This contains all the Sub-Master files.
The first time a Sub-Master version is flashed it needs to be activated. Once activated, a later Sub-Master version may be flashed and that will work immediately, no further activation is needed.
Originally a "User" version was available (u instead of sm in the filename). This was used to update a receiver that had been flashed by a dealer, before the activation process was created.
Mike
has the file "UNI_all_V83sm.zip" attached. This contains all the Sub-Master files.
The first time a Sub-Master version is flashed it needs to be activated. Once activated, a later Sub-Master version may be flashed and that will work immediately, no further activation is needed.
Originally a "User" version was available (u instead of sm in the filename). This was used to update a receiver that had been flashed by a dealer, before the activation process was created.
Mike
Could someone please explain to me the difference between:
- UNI-Statistics.lua
- uniStat (containing main.lua and lang.lua)
- XxRStatv5e.lua
Also:
I checked the hex streams of "sm" firmwares and "non sm" firmwares, and they're not identical. I wonder, if the latest versions only are meant to be "sm", why on GitHub there are also "parallel", non sm versions of the latest releases.
Sorry for the questions, but before entrusting expensive models with a firmware, I'd like to know exactly why I'm installing what.
Thank you
- UNI-Statistics.lua
- uniStat (containing main.lua and lang.lua)
- XxRStatv5e.lua
Also:
I checked the hex streams of "sm" firmwares and "non sm" firmwares, and they're not identical. I wonder, if the latest versions only are meant to be "sm", why on GitHub there are also "parallel", non sm versions of the latest releases.
Sorry for the questions, but before entrusting expensive models with a firmware, I'd like to know exactly why I'm installing what.
Thank you
Last edited:
Great! I think I just fried an R-X8R Pro...
I was about to flash the 83 version (sm), at first the Rx LED blanked red and green, then it switched off and the radio says "Error: device not responding".
If I try again, the Rx LED doesn't even light up.
And now the receiver doesn't even power up when I connect a battery to it, neither works trying to flash original FrSky firmware...
What could I have done wrong to cause this?
Thank you
I was about to flash the 83 version (sm), at first the Rx LED blanked red and green, then it switched off and the radio says "Error: device not responding".
If I try again, the Rx LED doesn't even light up.
And now the receiver doesn't even power up when I connect a battery to it, neither works trying to flash original FrSky firmware...
What could I have done wrong to cause this?
Thank you
The LED flashed green and red briefly before dying, so I'd think that if it were the wiring that was incorrect, it should have fried it instantly, having no time to even light up like that.
I don't know what to think. I have done the procedure multiple times in the past, even using the same physical wire that I had rewired as per FrSky instructions.
The only thing that I noted was different is that instead of saying "flash external device", the radio said "flash SBUS device" or "flash external module". Probably a change in OpenTX I hadn't been aware of. I chose "flash an external module" -- but getting this wrong shouldn't have cause a receiver to physically fail anyway.
I don't know what to think. I have done the procedure multiple times in the past, even using the same physical wire that I had rewired as per FrSky instructions.
The only thing that I noted was different is that instead of saying "flash external device", the radio said "flash SBUS device" or "flash external module". Probably a change in OpenTX I hadn't been aware of. I chose "flash an external module" -- but getting this wrong shouldn't have cause a receiver to physically fail anyway.
I am sure of that part. I have been using R-X8R Pro receiver(s) for years.
The problem is that there two versions of the same v. 83 firmware, one marked "sm" (which is the one I tried flashing) and the one not marked. The HEX streams are not the same.
The "sm" version is downloadable from the first page of the release thread. The non-sm version is donwloadable from GitHub, where it is said that releases are maintained.
I'll be honest. I truly appreciate the effort made here by Mike and the others, to create this project, which I thank. But as it is presented now, it's a bit chaotic. It isn't clear what all those files scattered between this forum and GitHub are for, and it doesn't seem that questions asked here get a clear response.
Again, I am not trying to be provocative. I am just pointing out that this otherwise amazing project could be made to be a bit less criptic in the way it's presented.
The problem is that there two versions of the same v. 83 firmware, one marked "sm" (which is the one I tried flashing) and the one not marked. The HEX streams are not the same.
The "sm" version is downloadable from the first page of the release thread. The non-sm version is donwloadable from GitHub, where it is said that releases are maintained.
I'll be honest. I truly appreciate the effort made here by Mike and the others, to create this project, which I thank. But as it is presented now, it's a bit chaotic. It isn't clear what all those files scattered between this forum and GitHub are for, and it doesn't seem that questions asked here get a clear response.
Again, I am not trying to be provocative. I am just pointing out that this otherwise amazing project could be made to be a bit less criptic in the way it's presented.
MikeB
Very Strong User
I build the release files and post them on the release files thread here on Aloft, so these are the "original files" and have the "sm" included in the filename.
The "sm" stands for sub-master. These are files that may be flashed by the user and then activated. They also work to upgrade an already activated receiver.
Originally receivers had to be flashed by a dealer using a "master" file, then users could use an update version ("u" in the filename) to update.
Other people have added the Github storage.
I just checked the X8R (not R-X8R) files here and at "https://github.com/offer-shmuely/frsky-accst-uni-rx-firmware", and all three files are identical.
I'm looking into the various script files, I wrote original scripts, but others improved the display on colour screen transmitters.
Mike
The "sm" stands for sub-master. These are files that may be flashed by the user and then activated. They also work to upgrade an already activated receiver.
Originally receivers had to be flashed by a dealer using a "master" file, then users could use an update version ("u" in the filename) to update.
Other people have added the Github storage.
I just checked the X8R (not R-X8R) files here and at "https://github.com/offer-shmuely/frsky-accst-uni-rx-firmware", and all three files are identical.
I'm looking into the various script files, I wrote original scripts, but others improved the display on colour screen transmitters.
Mike
Thanks for the response Mike.
I do have a spare old R-X8R Pro that I could try using for a new test, but now I am afraid to fry that one too (I am in no way implying that UNI had something to do with the frying, just to be clear).
I am not English native and I took the sentence "Script files are being maintained [on GitHub]" to mean that GitHub was the place where all the scripts (i.e. your scripts) were held. From now on, I'll only refer to the first page of your thread for downloading files -- even though I don't see an activation LUA script in that page, which , indeed, I only see on GitHub.
This is the file I tried to flash: UNI_rx8rpro_83sm.frk, from the first page of your thread (40 KB in size). I have always used the flashing method that FrSky shows, I don't particularly like it but I guess there are no alternatives for these kind of receivers:
I do have a spare old R-X8R Pro that I could try using for a new test, but now I am afraid to fry that one too (I am in no way implying that UNI had something to do with the frying, just to be clear).
I am not English native and I took the sentence "Script files are being maintained [on GitHub]" to mean that GitHub was the place where all the scripts (i.e. your scripts) were held. From now on, I'll only refer to the first page of your thread for downloading files -- even though I don't see an activation LUA script in that page, which , indeed, I only see on GitHub.
Similar threads
- richardsearcy
- FrSky
