Jump to content

Universal Receiver ACCST firmware


Mike Blandford
 Share

Recommended Posts

  • 4 weeks later...

I have a problem activating UNI firmware.

Firmware seems to flash to the rx fine.

When I run the activation script it returns a code of 888888.

I have tried two rxs, both return a code of 888888.

Rxs are X6R flashing with x8r_rom57sm.frk.

Activate script is filed with the firmware on the sd card in FIRMWARE/ACCST UNI/

It also generates a file called activate.luac

Anybody able to shed any light?

Link to comment
Share on other sites

The code returned by the Rx is a 12-digit code, two lines above the 888888. The 888888 is where you enter the code from the dealer to activate the Rx.

What Tx and what firmware are you running (erskyTx/Ethos/openTx/edgeTx)?

Are you binding with telemetry enabled (you need to bind before running the activation script).

 

Mike

Link to comment
Share on other sites

Taranis X9D+ with OTX 2.3.15 and ACCST V2.

It is the binding bit I am getting wrong.

 

To recap:

Flash Rx, unplug from Tx 

Bind

Run ACTIVATE. LUA 

email T9 the code

Run Lua again and insert activation code received from T9 

Rebind if necessary.

 

Thanks for the quick response Mike.

Link to comment
Share on other sites

I have "UNI" running on a few D8R's now with the version d8rii_rom080121.

Has there been any updates since that I should be considering please ?

I have read somewhere that "UNI" will autotune to the transmitter frequency. Is that true or have I misunderstood that? 

If so and used with say a Multiprotocol Tx would this negate having to "fine tune" the Tx after binding ?

 

Cheers

John

Link to comment
Share on other sites

30 minutes ago, John Wagg said:

I have "UNI" running on a few D8R's now with the version d8rii_rom080121.

Has there been any updates since that I should be considering please ?

I have read somewhere that "UNI" will autotune to the transmitter frequency. Is that true or have I misunderstood that? 

If so and used with say a Multiprotocol Tx would this negate having to "fine tune" the Tx after binding ?

 

Cheers

John

The full list of the latest versions are here.

 

FULL LIST.

 

I have to hand it to @Mike Blandfordhe has done a fantastic job on this.

  • Like 1
Link to comment
Share on other sites

I wrote the firmware for the D8R receivers first, then ported it to the D16 receivers when it became "UNI". I have since added changes made when testing UNI back into the D8R firmware, the file is on post #640 of the RCG thread "FrSky D16 firmware for D8 receivers". I added a note on the first page earlier today pointing to that post.

 

Yes to "UNI" tuning to the Tx during binding, this has been in the D8 version for some time, so tuning a MPM should not be needed.

 

Mike

  • Like 1
Link to comment
Share on other sites

1 hour ago, Mike Blandford said:

I wrote the firmware for the D8R receivers first, then ported it to the D16 receivers when it became "UNI". I have since added changes made when testing UNI back into the D8R firmware, the file is on post #640 of the RCG thread "FrSky D16 firmware for D8 receivers". I added a note on the first page earlier today pointing to that post.

 

Yes to "UNI" tuning to the Tx during binding, this has been in the D8 version for some time, so tuning a MPM should not be needed.

 

Mike

Thankyou very much Mike for the reply.

But the numpty query now is how to flash the D8R,s with the new Bootloader ?

Can I flash using my Tx (TX16S) as I have done on some of my other receivers ? ie - copy the file to Tx SD card and then flash to D8R .

Or do I need to use the serial device as per original ?  Without shorting out the pads ??

 

Many thanks.

John.

 

 

P.S Found this video - Just the first half deals with D8R flashing .

 

 

 

Edited by John Wagg
Link to comment
Share on other sites

First versions of the firmware did not have a bootloader.

December 2019 I added a bootloader.

January 2021: "I did a small change to the bootloader, to fix a problem when needing to bind with certain links fitted. One link could cause the Rx to stay in the bootloader."

So there are two versions of the bootloader.

 

The bootloader is included in the .bin file.

For a first flash of a receiver, or to change the bootloader, you need to flash using the original instructions that include shorting the two pads on the Rx.

After that, you may flash using AvrDude and a serial adapter, you cannot flash from the Tx.

 

If you flash with AvrDude, and you have a different bootloader on the Rx, you will get a verification error. You may ignore this error.

The update on post #640 includes the later bootloader, there is a version with the earlier bootloader on post #638.

 

So if you have the bootloader already on a Rx, you still need to use the serial adapter method, not the Tx. If you get a verify error, you probably have a mismatch of the bootloader. You may either just ignore the error, or flash the file with the "other" bootloader in it, or go back to shorting the pads and flash the file with the new bootloader.

 

Mike

  • Thanks 1
Link to comment
Share on other sites

48 minutes ago, John Wagg said:

Thankyou again Mike.

I flashed my first D8R Feb,22 and have done half dozen D8R versions now.

It's only reading through the various posts on the web had me wondering if I needed any update.

 

Something to do now while it's raining. 

Cheers

John

 

Job done. 👍

I couldn't get it to flash using AvrDude so reverted back to shorting the pads etc.

With the shorting of the pads (soldering) I was always concerned that I wouldn't clear the pads properly after soldering.

I had seen though, in another of your posts, that the pads only had to be shorted at powering on. Also note that no LED should be lit either.

I used a pin head temporarily across the pads while applying power and checking no LED lit. ✔️

Just need a range test now as proved O.K. on the desk. It took a couple of goes to bind (EU/LBT) before the green LED came on.😃

As a note - I did the fine tune and virtually zero so no need to tune. ( showed -10 before. )

 

Cheers

John

Link to comment
Share on other sites

Just checking you are following the correct procedure. The Rx is only bound to one Tx at a time. To swap, you need to bind to the other Tx. This is done by setting the other Tx into bind mode, then switch the Rx on. The Rx should then rebind, then you need to power the Rx off and on and take the Tx out of bind mode.

 

Mike

Link to comment
Share on other sites

9 hours ago, Mike Blandford said:

This is done by setting the other Tx into bind mode, then switch the Rx on. The Rx should then rebind, then you need to power the Rx off and on and take the Tx out of bind mode.

Having bound to both txs, followed above procedure

Link to comment
Share on other sites

Rx sits with red light flashing but does not rebind to other tx. It remains bound to the first tx.

The two txs are clones of one another in that the sd cards are copies of each other and the model info has been synced via companion. Not sure this is relevant as the rx is looking for the id of the rf section.

Edited by Wookman
Link to comment
Share on other sites

Intend to buy another RX6R from T9 in the next few days. See that he offers the option to download Uni SW but given I only have a single Horus X10S Tx with open Tx is there advantages of using the new software or do I just stick with EU LBT as per all my other Rx's?

Link to comment
Share on other sites

There are things that UNI will do that are useful. The full list of features is not hard to find. I suppose the the question is whether you are aware of any short comings in the firmware you are using? 

Fine tuning the rx to the tx is a good feature but works in the background.

Channel mapping might be useful.

The ability to customise outputs to suit digital or analogue servos.

Link to comment
Share on other sites

UNI sends back a telemetry value of VFR (Valid Frame Rate). This is sometimes a better indication of link quality than RSSI. RSSI is just the received strength of received packets, but if a packet is missed RSSI doesn't change. VFR indicates how many of the last 100 packets that should have arrived actually did. So you could have a RSSI of 70 (Good) but a VFR of only 40 (bad) indicating a problem.

 

UNI also fixes a few telemetry oddities where you may get incorrect values occasionally (I've seen "wild" values for altitude from a vario sensor).

Otherwise you might consider whether you could use any of the other features of UNI:

Ability to configure the SBUS output as a servo output (so the X6R can have 7 servo outputs).

Ability to configure individual servo outputs to be 9mS or 18mS rate.

Ability to map any servo output to any channel.

 

Mike

Link to comment
Share on other sites

2 hours ago, Wookman said:

Rx sits with red light flashing but does not rebind to other tx. It remains bound to the first tx.

The two txs are clones of one another in that the sd cards are copies of each other and the model info has been synced via companion. Not sure this is relevant as the rx is looking for the id of the rf section.

Please confirm the revision of firmware you have on the X6R (Reported using the "Stats" script). Then I can run more tests using the same firmware.

I just tested using a X8R (but currently running firmware with some changes since the last release) with 4 different Tx modules, and dual bind worked every time.

 

When you power the Rx on, it looks for a bind packet from the "other" Tx for just a short time. If it sees a bind packet, then the green LED turns on (with the red already on). Sometimes this bind is sensitive to how far away the Tx is. You might try with the Tx very close, 50cm away and 1m away. If this bind is going to work, it will happen almost immediately. With V2 EU LBT, a normal packet looks very similar to a bind packet and causes the green LED to come on when looking for a bind packet, even if it is not a bind packet.

 

Mike

Link to comment
Share on other sites

I've just flashed a X6R with V57 and tested it. It works correctly.

I first bound a X9D+ (my early prototype) using V2EU. The X6R did have some trouble binding the red LED was blipping, then held solid for a bit so it saw the X9D but didn't receive enough valid frames to continue binding, so continued blipping then the red LED held solid for a time (Rx was doing the tuning part) then the green LED came on as it did the bind and finally the red LED went off and the green LED flashed indicating bind OK. Power cycling the Rx and taking the Tx out of bind mode gave control of a servo OK.

Then I bound the X6R to a X9LiteS, running ACCESS in ACCST mode, V2EU again. THis bound very quickly, and again, after power cycling the Rx and turning off bind on the Tx I had control of a servo.

Turned off the X9LIteS and the Rx, Powered up the X9D+ and put it in bind mode. As soon as I powered the Rx it completed binding (red LED on, green comes on for a short time, then red off and green flashing.

I swapped back to the X9LiteS, then repeated with the X9D+ and it worked again.

 

Did you try with the Tx at different distances? Just move the Tx further away and power the Rx on again.

 

Mike

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...