FrSky Major Update for most TX and RX

[Frank Skilbeck]

Posted by Robert Welford on 17/01/2020 15:44:07:

Posted by MattyB on 17/01/2020 15:13:45:

I don't think there is a manufacturer out there who hasn't got something like that in their 2.4GHz implementation history at this point.

Edited By MattyB on 17/01/2020 15:15:56

Not Multiplex 2.4GHz M-link

Not quite MPX did one RF firmware update, but it didn't require any Rx updates only a rebind.

[GONZO]

Oh how I long for those past times when you bought a Tx and Rx plus additional Rx and just kept on using. Now it seems a constant treadmill of chasing ones own backside updating firmware. Its become a hobby in its own right.

[GONZO]

Well I'm in a bit of quandary. Got an early Taranis on an early OpenTx which needs to be updated to work a multi protocol Tx plug in module, the module also needs to be brought up to the latest spec. The module has various useful protocols including LBT (required for my Meteor65 SE indoor FPV quad). Also got a new Jumper T16 running OpenTx with an internal multi protocol Tx board, both of which need updating as I seem to have a problem on set up, AETR and mode 2 selected swaps aileron and rudder on Rx outputs.. I was aiming to get them all up to the same spec before using. For all other use I only run RoW RF on FrSky not LBT. I have many D series Rx and X series Rx which I don't want to loose the use of or go through the considerable trouble of re flashing. Plus, I have 'D' TX modules for my Futaba Tx's and a spare 'X' external module for the Taranis. I need to retain compatibility throughout. I've been to the OpenTx site and read the publication dated 15/1/20 but, is the problem just with the Tx operating system, or with the RF system as well? Looks like I've chosen the wrong time to get new bits and update. I'm drowning in update options. I could just sit back and hopefully let things sort themselves out and get a clearer picture but I've got itchy fingers. As I know the Taranis etc all works I'm thinking I'll start with the Jumper T16 due to its odd channel behaviour and work on logically from there. Unless anyone has a better idea. Is there any further info and whether updating affects earlier protocols?

[Mike Blandford]

The update from FrSky,, which this thread is really about, only affects the RF modules and receivers.
I've updated a Taranis plus internal module and a X8R for testing (and reverse engineering). The updated module still binds to a "D8" receiver (in D8 mode). In D16 (X) mode, the module and receiver will only bind to each other.

The X8R will not bind in D8 mode, even though linking channels 7&8 and powering it on does start it in bind mode.

If you update a module, it will only bind to an updated receiver, and vice versa.

The multi-protocol module will not bind to an updated receiver (yet!).

Mike

[buster prop]

Posted by GONZO on 17/01/2020 21:13:43:

Well I'm in a bit of quandary. Got an early Taranis on an early OpenTx which needs to be updated to work a multi protocol Tx plug in module, the module also needs to be brought up to the latest spec. The module has various useful protocols including LBT (required for my Meteor65 SE indoor FPV quad). Also got a new Jumper T16 running OpenTx with an internal multi protocol Tx board, both of which need updating as I seem to have a problem on set up, AETR and mode 2 selected swaps aileron and rudder on Rx outputs.. I was aiming to get them all up to the same spec before using. For all other use I only run RoW RF on FrSky not LBT. I have many D series Rx and X series Rx which I don't want to loose the use of or go through the considerable trouble of re flashing. Plus, I have 'D' TX modules for my Futaba Tx's and a spare 'X' external module for the Taranis. I need to retain compatibility throughout. I've been to the OpenTx site and read the publication dated 15/1/20 but, is the problem just with the Tx operating system, or with the RF system as well? Looks like I've chosen the wrong time to get new bits and update. I'm drowning in update options. I could just sit back and hopefully let things sort themselves out and get a clearer picture but I've got itchy fingers. As I know the Taranis etc all works I'm thinking I'll start with the Jumper T16 due to its odd channel behaviour and work on logically from there. Unless anyone has a better idea. Is there any further info and whether updating affects earlier protocols?

Reading this makes my brain hurt. Think I'll stay with Spektrum (DSMX), it just works and has been reliable. All I want to do is fly my planes, don't need all that hassle.

[Tim Ballinger]

I see all the Rx’s and Tx’s on the site still list all the previous firmware as well as this latest update and just to be safe I have all the relevant Rx ‘old’ firmware files downloaded just in case I need them.

At some point I will inevitably want to upgrade the Tx firmware to take advantage of any updated features that I might find useful ( Bug fix notwithstanding, that is after all one of the benefits of being able to install new firmware) , at that point assuming all has settled down to my satisfaction I will upgrade the Rx’s.

Tim

[Peter Christy]

Thanks for the update, Mike!

That's a pain, stopping X series receivers binding in D8 mode! I've got at least one set up like that, so that I can fly it with my single-stick Tx, using a "hack" module. Of course, if FrSky brought out a D16 hack module, it would solve all my problems, but I suspect that if they were going to, we would have seen it by now!

I wonder how long they'll keep producing D-series receivers....

--

Pete

[Allan Bennett]

Posted by MattyB on 17/01/2020 13:28:08:

I can see your point Allan, but that's not really comparing apples with apples. Your 30 year old Futaba was almost certainly not a digital 2.4GHz TX, but an analog 35MHz predecessor.

True, I'm really just moaning that in the past we never needed to upgrade anything -- it just worked first time out of the box, and kept on working. Maybe I exaggerated the age of my Futaba slightly (can't remember when I bought it), it has both 35MHz synthesised and 2.4GHz modules, and still works with my remaining couple of 35MHz and FASST receivers.

A lot of the 'upgrades' are for regulatory reasons (e.g. EU LBT), but I wonder how many are because manufacturers have released equipment that hasn't been adequately tested in a real-world environment.

[Andy48]

Posted by Allan Bennett on 18/01/2020 11:57:52:

A lot of the 'upgrades' are for regulatory reasons (e.g. EU LBT), but I wonder how many are because manufacturers have released equipment that hasn't been adequately tested in a real-world environment.

I think you are being very optimistic to believe manufacturers could possibly test every conceivable situation in the real world. I've had no end of updates with all sorts of equipment. Cars for example, nearly every car I've had in the last 10 years has had a software update. My year old Ford Transit motorhome went in for an update last month. Think how many Transits they sell a year.

The point of the Frsky system and OpenTX is its flexibility, and with that comes the drawback of needing updates. No different to cars, smartphones, computers or even smart TVs. Its only in real world use and feedback to the designers that we have the quality of the kit we have now at a price we can afford.

There are ways to mitigate some of the inconvenience. A simple one is to have an S Port lead permanently connected to each receiver. That way receiver updates are very simple no matter how deep the receiver is buried.

Another one is to standardise. One poster above has created a nightmare of different configurations with multiple different transmitters. With a 60 model memory one only needs one transmitter, and possibly a backup. Keep to your own standardisation of receivers by deciding which types will cover your modelling needs. I've tended to sell off the occasional odd one I bought, fleabay makes that easy, and someone is always prepared to pay over the odds. I've also sold of a couple of Frsky transmitters already.

Thirdly, keeps the system up to date. By this I don't mean update the first day an update comes out, but once its settled down, then update. (OpenTX 2.3 is a good example here). That way updating is straightforward, as there is usually plenty of current info on the web, and plenty of others around who have just done it to help. But try updating from a very old version and most have forgotten what they did so help is sparce. Winter time can be utilised to perform major updates that require quite a bit of work.

Lastly, update everything, don't leave some receivers on old firmware and then when you dust the model off months later wonder why the receiver won't work any more.

[Mike Blandford]

I've seen reports that early Taranis transmitters (not plus) do not work with this module update. I can confirm that my prototype Taranis does not work, it binds OK but operation fails with the green LED on the Rx flashing occasionally and servos moving intermittently.

Mike

[Allan Bennett]

Posted by Andy48 on 18/01/2020 12:43:35:

. . . I think you are being very optimistic to believe manufacturers could possibly test every conceivable situation in the real world. I've had no end of updates with all sorts of equipment. Cars for example, nearly every car I've had in the last 10 years has had a software update. My year old Ford Transit motorhome went in for an update last month. Think how many Transits they sell a year. . . .

Oh dear, I am living in the past! My car is almost as old as my transmitter (well, 15 years), and has never had a recall or an update, or a breakdown. It's going to be a shock when I have to buy a new one

[Tony Richardson]

Well being the distrustful beggar I am I'm doing nothing at the moment, the lack of information about why makes me wonder - me being not very computer literate or web wise - if this is maybe a spoof or site hack of some sort? I have been flying with a Taranis X9D and Horus for a lot of years now and never experienced any of these anomalies so for me its going to be carry on as before.

Tony....

[Martin Harris - Moderator]

I can't really comment on FrSky but my own system has had a number of software upgrades, largely due to the maker taking on board feedback and suggestions from users. Since buying a dedicated transmitter in 2013 to replace my previous module based setup, it has had major upgrades in both functionality and performance. While I could still be operating happily on the original firmware which functioned faultlessly and offered wide ranging functions I would have missed out on so many great features and improvements.

7 years after buying the transmitter, I have what, in pre-upgradable equipment days, would represent a new transmitter with many enhanced and new features, half as many channels again and LUA functionality - all at no cost! I'm also fortunate that all my receivers, some dating back to 2009, still function perfectly with the system - something my manufacturer has taken care to ensure throughout the process.

While Pete's advice to hold back and let others take the pain of early adoption is very sound in general, the relatively small RC community along with many informed users means that problems are likely to be picked up quickly and communicated so upgrading is normally safe with only a small waiting time should you be wary of your manufacturer's software testing capabilities.

[Martin_K]

Posted by Tony Richardson on 18/01/2020 22:06:45:

Well being the distrustful beggar I am I'm doing nothing at the moment, the lack of information about why makes me wonder - me being not very computer literate or web wise - if this is maybe a spoof or site hack of some sort? I have been flying with a Taranis X9D and Horus for a lot of years now and never experienced any of these anomalies so for me its going to be carry on as before.

Tony....

I am reading about this as an ex computer networks person, not as a FrSky user. Data networks require an error detection mechanism.

My understanding - A bug has been found in FrSky RF transmission error detection that normally has only a momentary effect on one or two channels, so is barely noticeable. However, it can sometimes delay program execution in the RX for long enough to cause a loss of control. The understanding of the problem is consistent with a higher incidence reported in Europe, using LBT firmware.

The fact that any one user has not previously experienced this does not mean it is less likely to happen to them in future.

[John Privett]

Martin - yes, that's what I got out of the (translation of) that German forum article too. The problem is a rare occurence that affects the European LBT firmware more than the global firmware which Tony R. will almost certainly be using over in Canada.

For me - Taranis user for several years, Horus X10 user for nearly 2 years - and having used the LBT firmware since before I even got the Horus, I will update. But not today!

The issue mentioned is not one that I've ever personally noticed, but I will update anyway. I'll probably do so in the next week or two, but early enough in the week that any delays don't affect my weekend flying!

[GONZO]

Mike B

Interesting what you found with early Taranis. My Taranis is pre plus. It is the one just after the initial model. So, I surmise from this discovery that updating more than likely becomes a non starter. Even more so as I don't use EU LBT and don't want to. The more who use LBT the more, RF speaking, they'll make way for my transmissions.

Martin_K,

From my quick scans of the other forums it does seem to be related to LBT(correction from those who know better welcomed). A phrase used to describe LBT I saw in the past likened it thus, 'a mutual and polite degradation of service for users as band usage increases'. Unfortunately in a real time active situation like model flying you can't afford too much degradation of service. Could the FrSky users on the continent be generally operating in areas of greater band traffic/usage(near urban areas) and thus suffering this 'degradation of service'(increased skipped data transmission due to more busy frequency slots) resulting in this deficiency in error detection becoming noticeable? Or, is the up date to the servos position slowing down to such an extent that a momentary 'failsafe' is occurring that would look like a spurious position command? Additionally, I would guess that not all the other band traffic(non RC) is LBT. Due to our 'anti social' status in the UK we generally fly in out of the way locations. Have there been any reports of this problem here? IMO this makes a good argument for users who can to remain non LBT.

As a general observation FrSky, to my mind, seems to be using this as an 'opportunistic' way of implementing a degree of obsolescence to complement their brand 'lock in' by way of 'ACCESS' thereby enhancing their commercial position.

[Don Fry]

My experience of continental flying is the sites are as remote as the UK. I also reckon that fuel motors and particularly 2 strokes, are more common. Noise regulations generally are more lenient, but the clubs still just keep out of the way. Just easier to operate with some space, and Europe as a whole, has far lower population density than the UK.

I do echo your yearning for radio sets that stayed the same Gonzo. Read the instructions, end of learning curve for that set.

[GONZO]

Don, the epicenter for this issue seems to be Germany. Does your experience of flying site stretch to there? Is there something specific to Germany?

Ah, nostalgia is not what it used to be. Or, in my case it is. That's why I still have and use my Futaba FF8, FF9 and super along with my T12FG all on FASST. Occasionally my Futaba FP-T5LK(modified) with plug in RF boards for 27mHz/35mHz/40mHz and switchable 2.4gHz 'hack' FrSky module, dating back to the early 80's, gets an outing. I still have my original Futaba Digimax 4(mid 70's) on 27mHz in working order. Just can't throw stuff away or sell it. Call me Steptoe!

[Don Fry]

Only experience of 2 sites in Germany. One in the Ruhr valley, that's a populous area. Site was a mile outside a village. Other site was Munich area. Eight to 10 miles outside the city, two miles from a town, rural looking.

When I say they are similar to the UK, I mean it. All sites across Europe seem to have a common layout. Parking, pits, 40 yards safety space, pilot box, runway, dead area in front. I haven't come across a site over here with shared access to the dead area, i.e. The club uses the site, and can crash in safety.

Read the BFMA handbook, and translate as necessary.

Lots of very serious obsessive engineers in Germany?

[Tony Richardson]

Maybe I should clarify my thinking on this, I do not mean the Open Tx system itself has been compromised, my concern is that the need for an upgrade may be a spoof planted on FrSky website for whatever reason what I am asking is, is the original source totally reliable? the lack of information on the FrSky site as to why and how to proceed is what makes me suspicious..

As John P says my protocol here is a little different to yours on that side of the Atlantic and that may well be where the issue is rooted, I know I am a cranky 71 year old but my suspicions have held me in good stead so far as I said before I shall carry on as before, if and or when I am sure it is a problem I will certainly upgrade. Just my humble opinion..

Tony..

[Mike Blandford]

The problem was noticed first in Germany, although when it was described some people in other parts of the world realised they observed the same problem. One person in Germany did extensive testing on the bench, and managed to create the problem in controlled conditions repeatedly. FrSky have been working on a fix for a while.

The original "D" protocol used a CRC built in to the RF chips, but, for some unknown reason, the "X" protocol didn't use this, and the software CRC check used apparantly missed some errors.

Mike

[David Holland 2]

Gents, I have mentioned recently that I am a convert to FrSky, having bought a Horus X10 Express a few months ago. I am using FrOs and have now just about got the measure of it and am thoroughly enjoying using it. This update issue has me in a mild panic, the FrSky website lists the transmitters and modules affected but it specifically says "not Horus x10 Express" and does not mention the ISRM-S-X10 internal module as needing an update. Soooo....can I assume that my transmitter is ok? But how about receivers, I'm using mostly RX6Rs with ACCESS and a couple of S8Rs with D16. My head hurts and I will have to master "flashing" my Rx's which prospect fills me with dread. Thanks,

David

[Tim Ballinger]

David,

Many users are trying to get their heads round the implications for the many permutations of Frsky kit so you are not alone.

Mike Blandford , is our resident guru and is generally quick to correct us when we go wrong

However as I understand it.

Frsky has not yet released the firmware upgrades for the ACCESS protocol radios such as your x10 Express, so you can do nothing yet. the ISRM module is however expected to need this upgrade so you will more than likely feel the pain in due course. ( I have only quickly scanned the RC groups forum but there seem to compatibility issues with several flavours of the Taranis radios too.)

For the moment do nothing especially do not try upgrading rxrs until your specific Tx upgrade is released or you will end up with a mismatch that will not work.

Perhaps not surprisingly I see several users on RC groups now suspecting they have experienced the actual issues that are being addressed by these upgrades and are a little agitated.

For my part my horus X10 and Rx series Rxs all have firmware upgrades released and while not actually doing anything yet I am preparing for the inevitable.

For my part I am a little confused as to why there is a separate firmware upgrade file for the IXJT module as I thought the internal RF module on the HORUS could only be updated with the Fros firmware update. Perhaps the IJXT firmware is actually for the external module?

Can Anyone put me right here ?

Tim

[Andy48]

Tim

Thanks to Mike's efforts it is now possible to update the internal module using the bootloader with OpenTX version 2.3. Thus it is no longer necessary to reinstall FrOS.

[Tim Ballinger]

Andy,

Thanks for that. Since I am still using FrOS its the OS update for me and ignore the specific IXJT firmware update .

Tim