Updated my Taranis to 2.1.0

[Kevin Fairgrieve]

So today I bit the bullet and updated my Taranis to Firmware version 2.1.0

 

Now my taranis is quite an old one with a production date of B01 UK T9 27-06-2014. So batch 1 UK version sold by T9.
I have heard story`s that a few older models were not updating, so took things slow and steady.

First thing I did was to update the TX to Open TX 2.3.7 the latest version. I usually do that a few days after any release just to let any issue`s come to light.

So downloaded the new Firmware from the Frsky website along with the frk file for the sole model I have on my Taranis. I use this pretty much only with my trainer and my BNF models using a home made Spektrum module. If it all went pear shaped then it would be no great loss. I could just transfer the module to one of my two Horus X12S.

So with both files transferred to the SD card time to go.
First off the 2.1.0 upgrade.

I chose to use the FCC version for my experiment`s I will change it to LBT further in.

That went well.

Next onto the RX. I use the pins in the module bay to update the firmware on my RX so the lead connected to TX and RX the correct file was selected for the upgrade.

 

And there you have it.

No fuss no drama. and no problems either.

There was no need to rebind, (but I did) and all model settings were transferred. I will now add a few sensors for testing as this was an area where the earlier 2.0.1 version fell down.

 

If you choose to do it then take your time and check each step.

Edited By Kevin Fairgrieve on 31/03/2020 14:15:30

[Bob Cotsford]

That's encouraging Kevin. I also have a version 1 Taranis that I keep as my backup, that's on 2.3.5 at the moment. With no flying I'm waiting a little longer to see what comes out of the woodwork. 'Bionicbone' on RCGroups has been doing a lot of testing and so far 2.1.0 looks to be giving good results though the XM+ backup receiver and the S series stabilised ones were still undergoing further development as they had proved problematic. Unfortunately I have both XM+ and S series receivers...

[Kevin Fairgrieve]

I was indeed encouraged Bob. As I mainly use older V8 and X series RX I thought that I would give it a go.

I do use a couple of S series but they are very much staying on my X12S.

I am keeping up to date with the thread over on RCGroups, there is a lot of information on there that goes way above my ability, but I am grateful for those who are able to test and sort the issue`s out.

[Bob Cotsford]

I think that a lot of the debate over the RSSI v link quality is getting a bit esoteric for fixed wing flyers and really relates to fpv and multirotors with flight controllers. As a fixed wing only flyer it's way above my paygrade!

[Devon Slopes]

That is indeed encouraging. I have also have a B01 T9 Taranis, dated April 2014 and so was also holding off in part because of statements that the early Taranis had problems with 2.0.1. I'm still waiting, though, because there is no update for the G-RX8 glider receiver on the Frksy website (though confusingly I think it is in the test release). However I would like to get on with it whilst my flying time has to be devoted to workshop activities. But anyway, thanks again Kevin for blazing the way and setting my mind at rest on at least one possible issue.

[charlie holdford]

Hi All

JUST FOUND the file under XJT Module...….

Dilemma, the X9D+ is now discontinued and therefore no update file is available from FrSky.

Presumably, as some updates have failed on earlier versions.

I have also got a Horus X12S which really needs the update.

If I update the Horus and all the Receivers I have will my X9D+ still work or have they just bricked my Taranis?.....

Cheers

Charlie

Edited By charlie holdford on 09/04/2020 17:27:44

[Ron Gray]

Updates are still available as FrSky still support discontinued products FrSky

[Devon Slopes]

I was holding off the upgrade as the software for the G-RX8 was still in testing, that excuse has now passed, but then I discovered the S8R is still awaiting V2.1.0, so I have an excuse to carry on balsa bashing for a while yet!

[Ron Gray]

[Chris Bott - Moderator]

Interesting to see you used the FCC version Kevin. Any reason?

[Kevin Fairgrieve]

Posted by Chris Bott - Moderator on 06/05/2020 22:40:44:

Interesting to see you used the FCC version Kevin. Any reason?

My TX is a very early one, FCC was installed from new and as I was just doing a "test" I left it as was.

Once my testing is over, I may go back to V1 or I may change to EULBT V2 I have yet to decide.

Grandfather rights apply!

When and If I update my Horus it will use EULBT, as they do not have the same rights.

I am well aware of the confusion running two separate systems, and am very careful when testing to keep the systems separate.

[Allan Bennett]

I flashed my Taranis X9D+ 2019 transmitter to firmware v.2.1 last week, and eventually managed to install ACCST v.2.1 to my RXSR-FC receiver. For the receiver I had to access the ~+- S.Port pads to connect for the download, for I couldn't get the serialpassthrough method to work with the USB port.

Anyway, just posting to say that after five 10-minute flights with it in my 250 racing quad I'm very happy with the result, and more confident about updating my more-precious/fragile models to v.2.1. With v.1.x in the RXSR I was getting at least a small glitch every flight (usually a single beep, and a momentary height loss of about 6" ), but today no noticeable glitches at all.

Edited By Allan Bennett on 31/05/2020 20:22:57

[Allan Bennett]

Because of last week's success with my RXSR flights, and having flashed several XnR receivers to v.2.1.0, I decided to have a go with the beta version for one of my S8R receivers, since I'd read elsewhere of a few people using it without any problem other than telemetry. The update process itself went fine, and I bound the receiver to my v.2 transmitter, but then I found that all controls were reversed, as were all the switches that I tried.

Rather than faff around reprogramming that model in my transmitter, and reprogramming its stability functions, I decided to flash the receiver back to the current v.1.x firmware, and re-bind it to my v.1 transmitter. Thankfully ground checks show that all seems to be working as it was, including the direction of the stabilisation corrections. I'll wait for the official v.2 release before I try again.

[Kevin Fairgrieve]

Have you seen this Allan?

RCGroups Post

Typical FrSky mess up.
It was not broken (well not much) so why fix it!

Edited By Kevin Fairgrieve on 07/06/2020 08:33:56

[Allan Bennett]

No, I hadn't seen that, though I've been following another long thread there about the v.2.1 updates. Thanks Kevin. It probably explains what I was experiencing. I'm not going to try again until it's officially released if I have to go through all that palaver. My original Taranis is still on v.1 firmware, and I've never experienced a problem with my S8R receivers, so they'll stay on v.1.x for the moment.

[Kevin Fairgrieve]

I have reverted my Taranis back to V1 as well.

There was no real need for me to go to V2, so back it went.

Once everything is out of BETA and stable (could be a long wait) I may have another go, but for now.

[Allan Bennett]

I'm still persevering with v.2 firmware, and I've come across a couple of minor issues.

First was an X8R in my flybarred TRex 500 heli. After updating the firmware to v.2.1.0 LBT ACCST without any problem, I then copied the OTX file that the heli had been running with for a couple of years, across to my v.2 Taranis X9D+ 2019 transmitter. Everything seemed to work, except I had no collective so couldn't take off. Checking the OTX file I saw that collective was assigned to ch9 (don't know why, but it worked with v.1 firmware!). Since it's only an 8-channel receiver, I reprogrammed collective to ch8, and all is well.

I would have thought nothing more of it if it wasn't for the fact that I had a similar ch8/ch9 issue after converting my RXSR-FC to v.2.1.0 LBT ACCST. It's in a quadcopter running with iNav, and this time one of the modes was assigned to ch9, which should have worked because with SBUS connection to the FC it's a 16-channel receiver (isn't it?), but once again I had to reprogramme that mode to ch8 to make it work. I had already updated and flown another RXSR-FC equipped quad, but the issue hadn't come up with that one because it didn't use ch9 for anything.

My X8R is specified as 8 channels in the OTX setup screen, which begs the question why ch9 worked in the past; but my RXSR-FC is specified as 9 channels. Both the setups are the same in my v.2 transmitter as they were with v.1.

Not a big issue because things are working now, and the fault is probably mine somewhere. But I'd be interested in your thoughts about it.

[Allan Bennett]

FrSky came out with an offical v.2.1.0 firmware for my S8R receivers this week, so I've updated them now. The first one I've done (but not test-flown yet due to the weather) is in my TwinStar, and seems to have been successful without me having to extricate the receiver from the fuselage to recalibrate it. All surfaces move in the correct direction in response to stick inputs and also in response to automatic stabilisation and recovery mode when I waggle the model.

I have noticed a couple of oddities though in the .otx files which were originally created when the receiver was v.1.x, and which have been copied over from my laptop to my new v.2. trannie: All four main controls are correct, but some of the switches programming in the Inputs tab have been altered -- two of them had offset of 8 or 9 percent added where there was none before, one of them had offset of 4 percent when it had been 50 percent before, and one of them had Curve50 added where there is no such curve specified and there shouldn't have been any curve on the control anyway. Correcting the offsets was no problem, but in OTXCompanion 2.3.7 trying to edit the 'Curve 50' to 'Diff' wasn't accepted. Instead I had to change it to 'Curve ------' to remove the Curve from the switch.

Another oddity is in the simulator mode in OTX Companion 2.3.7: My spring-loaded switch SH is programmed to put the S8R receiver into recovery mode for as long as I hold it, and to voice 'Recovery mode' at 5-second intervals, and 'Panic over' when I release it. On the actual transmitter it works like that, but in OTX Companion it starts voicing 'Recovery mode' as soon as I activate simulator mode, even though SH is 'off' by default. Switching SH 'on' and returning it to 'off' stops the voice, and after that it then works as intended. In the simulator display SH also has a little padlock symbol against it -- I haven't seen that before.

As I mentioned, I've transferred to a new transmitter at the same time as updating to v.2 firmware, but you need to watch out that similar anomolies don't occur when you're doing the update on the same transmitter.

[Allan Bennett]

I've been thinking more about the oddities I mentioned yesterday: They're both on functions that I've never used since I first configured and set up the models, and hence wouldn't have noticed any problem with the programming if it changed after the maiden flights. That was in the days of .eepe files with OTX Companion 2.1, and I'm wondering if the corruption (added/changed offsets etc.) came about in OTX Companion's conversion from .eepe to .otx files.

Also, I seem unable to edit my previous post, so should point out that I'm on OTX Companion 2.3.9 at the moment, not 2.3.7.

[Allan Bennett]

Yesterday I updated one of my X4R receivers to v2.1.0. It's in a flybarless heli, connected to a BeastX controller by CPPM, but after the update the BeastX was reporting 'no receiver'. I eventually found out that there seems to be no CPPM capability with X4R v2.1.0 ACCST LBT firmware With v1 firmware it was simply a matter of jumping channel 2 and 3 signal pins together while binding, but now that doesn't work. I see there's a beta version on Github which is supposedly to restore the CPPM functionality. Pity they didn't mention in the release notes that CPPM was not available -- it would have saved me a lot of head-scratching.

[Allan Bennett]

X4R CPPM sorted!

It seems FrSky 'forgot' to mention in their manual that the method of binding to get CPPM functionality has changed: In the past one could bind it to the Tx in CH1-8 mode with or without telemetry. Now it seems one must bind it in CH9-16 mode to be able to get CPPM output.

[Kevin Fairgrieve]

So to bring this up to date!

I couple of months ago I bit the bullet and ordered an ISRM module from Horus RC to convert one of my X12S to ACCESS.

I have been flying with that for a few weeks now, but not with ACCESS only using X receivers running ACCST V2.1.0. Rock solid and reliable.

I have a number of RX4R and RX6R that are ACCESS capable and I will shortly be moving all the models on this TX to ACCESS. But first things first, and one at a time. One model has now been upgraded to ACCESS, and flight trials will commence as soon as the weather permits. I shall report back when I have done so.

Today as it was very much a no flying day I have upgraded my other TX12S to 2.1.0 running ACCST only, this mainly so that I can still use the couple of dozen V range receivers that I have. That was a challenge as many of my older X4R type RX are buried deep inside models. All of course needed to be pulled and the firmware upgrading. Had to dig out my FrUSB-3 (FUC-3) / USB to S.Port adaptor. I could have used the TX via the module bay, but felt that using the wrong lead could have caused disaster. For some reason I could not get them to upgrade via the STK. Probably my bad.

The Taranis has been running ACCST V2.1.0 for some time now. But that is only used for my trainer these days when I am using my old DX7 as a buddy box.

I guess now I am firmly routed to V2 and will not be going back. It is also strange looking at some of the older Rx that are still good and performing great guns after all these years.

[Viv Letherby]

See my new thread.

Edited March 11, 2021 by Viv Letherby
start new thead.