FrSky Major Update for most TX and RX

[Allan Bennett]

Is the v2.1 firmware really ready?

I've been holding off upgrading to v2.1 firmware, partly because I wasn't allowed to fly and partly because I'm reading about too many problems with it on RCGroups. But now that we're allowed to fly again I need to make a decision -- do I stick with v1.x, which has been reliable for me for a couple of years, apart from what I think was an uncommanded servo movement on 19th January this year, do I go to v2.1 because it's supposed to be more reliable, even though it hasn't been around as long as v1.x for people to discover any possible bugs, or do I wait for 2.1.x or 2.2 to give FrSky time to really shake out all the bugs?

Most of the RCG thread currently is technical RF stuff, which is way over my head, but it makes me nervous that they're finding so many issues. Perhaps they're of no practical consequence, and would have been revealed in v1.x if it had come under the same amount of scrutiny.

[Rob Buckley]

I've done a fair bit of bench testing with arduino signal quality checkers and range testing with the V2.1 on QX7 and X10 transmitters with RX8R pro and X8R receivers. I didn't see any problems at all and all the telemetry worked properly.

The RCG thread seems to have gone into the depths of the G series receivers, but I have no experience at all of them.

[I_AM_MARKEVANS]

It’s been a long time since I logged into this forum but I was gonna come and ask about those RCG tests.

The issue I see is we have always thought the Frsky link was ‘rock solid’ but we have never really known what was going on behind the scenes. The tests they are doing are showing up things like 9 thousand frame losses on a test stand during an hours test, that’s absolutely shocking. Say what you will about Spektrum but flying my dlg for an hour and landing out in long grass multiple times only ever got me a max of 1K.

Maybe all the Frsky equipment over the years has performed this poorly but we’ve never known cause frame losses has never been tested? It might have provided bigger ranges over other brands but what’s the point when the link looks like it’s always been patchy at best?

[Bob Cotsford]

One word of caution Mark - method! What method do Spektrum and others use to determine link quality compared to the various ways being used and discussed by those on the RCG thread that you are talking about? Most of it goes way over my head but from what I can make out much of it started because of results found with MR flight controllers. The G series issue is another separate matter and seems to have taken the conversation into frequency matching and drift.

I can only speak for my own experiences with VFT/VnR, DFT/DnR module setups, Taranis X9D and Horus X12 with various XnR receivers. I've always found the link rock solid with all three flavours of ACCST, unlike other club members using one brand in particular who have on occasion filled their black bin bags despite few reported lost frames.

Edited By Bob Cotsford on 15/05/2020 09:41:17

[Peter Christy]

I can only agree with what Bob has said. I've been using FrSky gear for over 8 years now, and the only failure so far has been one receiver which was dead on arrival, and promptly replaced by T9 (excellent service, BTW).

A couple of my receivers are buried away inside models, and not easily accessible to upgrade. I also have a LOT of FrSky receivers! This makes the update particularly unattractive, especially seeing as, so far, I've never had an issue!

I'm a great believer in the maxim of "If it ain't broke, don't fix it"!

Reading the original reports of "uncommanded servo movements", they all appear to have occurred at specific locations, mainly in built-up areas (and mostly in Germany!). This makes me wonder if its some kind of interaction with other 2.4 GHz equipment that is unlikely to occur at a rural flying field.

Sooner or later I will probably have to bite the bullet, but for the moment, I'm content to carry on with what I have!

--

Pete

[I_AM_MARKEVANS]

Thanks guys,

The issue I'm seeing on RCG with G-RX8 though is extremely high frame losses and numerous failsafes, this in turn has turned the conversation into frequency matching and other things.

I would have assumed that those new series of rx's, the G-RX6&8 and the RX4&6R would all have the same RF front end so not sure why only the G-RX8 is the culprit with all the problems at the moment.

If someone was coming coming into Frsky today or needed a new tx, then the newer ACCESS version is pretty much their only choice along with the latest rx's, so the older equipment like V and D series isn't an option and can't be used with the new radios anyway.

The one I don't get, is in the tests the one guy did, his test equipment and logging reported numerous failsafes yet he says he didn't notice some of them in flight? how is that possible? I only fly sailplanes but I'm sure even with these I'd notice a failsafe, more so since my FS settings are to go to full flaps.

Basically I was gonna move to back to the newer 2019 ACCESS X9D+ with either some G-RX6 or RX6R rx's but all that talk on RCG has me very nervous as the new gear seems hit or miss at the moment.

Edited By I_AM_MARKEVANS on 15/05/2020 10:32:20

[Bob Cotsford]

Mark, I think a lot of these issues last fractions of a second, at most enough to cause only minor servo deflections which possibly won't show on a sailplane. Even the larger servo deflections may not last long enough to cause serious flight deviations.  From what I can make out the newer systems when run under Access protocol rather than ACCST seem to give better results, or am I misunderstanding the test results?

I think the V1 issues first came to light after the losses of high speed models flying low where recovery from glitches wasn't possible.

One question I have regarding the frame losses but am scared to ask over there - if a frame is skipped under LBT because the transmitter finds the planned frequency busy, does the receiver count that as a lost frame or does it recognise that it's a feature of LBT and ignore it?

Edited By Bob Cotsford on 15/05/2020 10:50:45

[Devon Slopes]

There are also some UK experiences with upgrading on another thread.

[I_AM_MARKEVANS]

Thanks bob,

It does seem there are less issues using the new radios in ACCESS rather than ACCST, and that is a good question, but one I also won't ask on RCG lol.

I think it looks like if you already have a pre 2019 Taranis then it looks like you are better off staying on ACCST V1 where there were a lot less issues and not many cases of the USM bug. 

Edited By I_AM_MARKEVANS on 15/05/2020 11:20:35

[Tim Ballinger]

I have monitored this situation pretty closely since it started in January and have decided in recent weeks that the time is right for me to undertake the upgrade. I do not use stabilised Rx’s so those remaining issues do not bother me. I have had no problems at all in 2 years of operating my Horus X10 so my motivation is simply to keep up to date and remove any minor risks of the sort noted in Germany. I have under a dozen separate Rx’s so the task , for me, is not immense. I plan to start the upgrade next week while I am waiting for my club to reopen .

Tim

[Bob Cotsford]

I'd go so far as to say that if you have a pre-Access radio running XnR receivers or RX8Rs you are unlikely to see a problem under 2.1.0, though of course it would be only sensible to test thoroughly at ground level before committing aviation. G-RX8Rs seem to be a different pot of poisson.

[Allan Bennett]

Hmm, I think I've missed the bit about problems with 2.1 and SnR receivers. Unfortunately I've got some of these in my favourite models.

[Tim Ballinger]

Just thought I would post my results of upgrading to the latest FrSKY OS ( TX & Rxs) on my HORUS X10.

The Tx upgrade is now at 1.3.07 and the Rx firmware at V2.01.

I use the Horus OS not OpenTX.

I upgraded 8 Rx's 4 RX8Rpro, 2 RX6R, 1 RX4R and a GRX8R and of course the Tx.

Upgrade process was as per manual and no problems.

I had held off until now as the G series Rx's were the last to be updated/released following Beta testing in March/April . (S series are not there yet but I have none)

My flying site is still in lockdown but I can fly anything without an undercarriage from fields next to my house. Hence flight tests completed with a glider using both the GRX8R and the GRX6R. I will flight test the RX8Rpro in the glider as well but as soon as the wether is good enough.

Yesterdays weather was brilliant for thermaling so I had 2 flights of around 20 mins each up to heights go 650 feet on which to collect data.

All went well with no problems or discernable difference to pre upgrade flights.

Detail telemetry pictures and comment to come in the next post.

Tim

[Tim Ballinger]

The picture below shows the before and after telemetry plots for the GRX8R.

I am very happy with this as there are no dropouts over the course of the 20 min flight and the RSSI levels are virtually identical both for the preflight range check and the flight itself. The lowest recorded in flight was @50dB at 650 feet. The vert speed I have omitted for clarity but suitably bounded and combined with an audible beep I find makes thermaling much easier.

The next plot is for the RX6R. I belatedly realised I had not kept a pre update telemetry plot for the RX6R but the RX4R must be virtually identical ( firmware is the same) so I used that .

Given that the flight profile for the RX4R was much different ( Gnat as opposed to a glider !) I am again very happy with the correlation.

I guess I had never looked closely enough at the absolute levels of RSSI value between different Rxr's but they do seem to vary. I have heard that the RX6R has a greater range than the RX8R so perhaps there is some design consistency ( especially I guess since we probably all use the same warning level from one Rx to another ). I'll leave that one for those that know to elaborate on if necessary.

I will test fly the RX8Rpro as soon as the wind drops but all in all I am very happy to go fly with the upgraded firmware.

Apologies for the perhaps excessive detail but I thought it might just inspire confidence in those yet to undertake this upgrade.

Tim

 

Edited By Tim Ballinger on 22/05/2020 13:59:42

[Devon Slopes]

Nope, the detail was not excessive, Tim. But could I ask one further question? Was this ACCST or ACCESS?

thanks, Devon.

[Tim Ballinger]

Devon,

This was ACCST D16.

Tim

[I_AM_MARKEVANS]

Hi Tim,

I'm guessing you saw non of the issues on ACCST V2.1 for the G-RX8 that the guys on RCG are seeing?

[Tim Ballinger]

Mark,

last checking I did was on the beta testing on GitHub, that was probably a month ago now and about the same time as FrSky published their March (the something) issue of that Firmware. The last impression I got from RCG was that if you delve deep enough you can always find someThing that could be better.

Do you think I missed something significant ?

Tim

[I_AM_MARKEVANS]

There's a lot of posts but it seems the G-RX8 in particular is still suffering from failsafes on ACCST 2.1 during bench testing. Although I think a lot of the guys on RCG are now trying to test the other rx's in the range so there's a lot of posts to wade through.

I find it difficult to keep up with what's going on but it seems at present, testing is still ongoing. the last update to the beta firmware for the G-RX8 was 3 days ago.

[Tim Ballinger]

Well I flew with it for 20 mins and as you can see from the plot, no drop outs, no failsafe.

Since it’s wet and windy I’ll have another read and see if I can fathom what they are talking about. As I say when I checked the beta testers on Github they seemed happy and then the firmware was issued ( not a beta).

Tim

[Tim Ballinger]

Mark,

I have just checked Github where the beta testing is discussed. I see no current issues over failsafe.

There is an ongoing discussion over the accuracy/noise levels on the vario's vert speed output. Some users want the same quality as can be achieved with a dedicated vario  sensor , some are quite happy that the altitude output is accurate to +/- 5 m , others are not. Frsky altered the vert speed output filter between v 2.01 and ver 2.1 which gave better response at the expense of more noise . It may revert to the lower noise/greater lag filter in a future release.

From anything I have ever experienced or logged the vert speed has always been noisy . If used raw with audio it has always been unusable. Thats why i gate the value I use to create the logic sw that for me triggers the audio alert ( = vario beep). Long way from ideal as a vario but it works. In my opinion none of this has anything to do with the Rf upgrade which was the raison d'être for V2.01 and subsequently V2.1.

This is of course is only my view and only strictly relevant to ACCST D16 and Horus X10 as I tend to read past the other variants.

tried checking on RCG chat but sort of lost the will to live .

Tim

Edited By Tim Ballinger on 23/05/2020 18:55:08

[I_AM_MARKEVANS]

They did introduce new beta fw to correct the vario issue but it looks like on GitHub Frsky have yet to comment on the failsafe issue the users on RCG are experiencing.

Users like Landru are experiencing multiple failsafes while bench testing the G-RX8 on ACCST 2.1.

But like you said, there is now a lot of posts to read through, but it looks like the testing is still ongoing so you can read back a few pages from the end and not have to read from the beginning.

Although if you haven’t experienced anything yourself then it may be hit or miss.

[Devon Slopes]

Posted by Tim Ballinger on 23/05/2020 18:54:03:

Thats why i gate the value I use to create the logic sw that for me triggers the audio alert ( = vario beep). Long way from ideal as a vario but it works.

Oh, that sounds clever. I've tried turning the sensitivity down by making the beeps only happen at larger vertical speeds, but am frustrated by the noise. So please tell, Tim, how do you do it?

[Tim Ballinger]

Mark,

I isolated the user testing in RCG you highlighted. I note the following:-

Not surprisingly all testing in FCC not LBT as we use in Europe. This could be very significant depending on RF environment. It certainly represents a significantly different test scenario.

All testing done with the latest Taranis QX7 which is delivered as access protocol and was used in ACCST mode . Again a significantly different test scenario. 

The user may have tested other Rxrs but not in the thread I viewed. They were all G-RX8. So not clear whether he has highlighting a Rx/Tx or RF issue.

I have had none of the telemetry loss or failsafe warnings this user has experienced with any of my Rxrs but my testing was with the HORUS X10 using EU/LBT ACCST D16 V 2.1 . The telemetry plots I showed bear witness to this as drop outs would be easily seen even if missed real time during the 20 min flight .

I am not qualified to comment on the real significances of the different test hardware perhaps others that are will do so.

I am still happy to go fly with the V2.1.

Tim

 

Edited By Tim Ballinger on 24/05/2020 10:57:31

[Tim Ballinger]

Devon,

My solution to the noisy vario is not much different to yours. I do not use OpenTx so any filtering is done within the confines of the Horus OS.

This is what I do.

1. Set a logic SW for Vert Speed outputs > 2.0 ft/s. Set the duration of this LSW to 1.0s . ( If my interpretation is correct this means the test must be true for all samples in a 1 second window for the LSW to be set true. The manual does not make the description terribly clear !)

2. set a special function to play the vario if the LSW is true and the Flight mode is thermal.

3. I use a flight mode switch to turn on a 'thermaling' mode, principally to give me an automatic trim change. However when coupled with the LSW above I only have to listen to beeps when I need them.

As I say, a long way from perfect and there is obviously a lag between the beep and the model entering the lift so you just learn to compensate. Clearly if your Mk1 eyeball is A1 then you will see the model react anyway !

Tim