No I hadn't Thank you this is exactly what I wanted to know. I'm printing my translation. There may be more than a few errors.
From the above link.
This report is designed to provide an understandable overview of the "sudden servo deflection" problem.
FrSky remote controls and conversion systems have been around since 2009. Since then, the products have been known to be reliable and are becoming increasingly popular due to their very good price / line ratio.
In mid-2019, isolated information about "sudden servo deflections" came from customers in Germany. A little later the first information from Austria and Switzerland.
There was practically no evidence anywhere else in the world.
We ran many long-term tests under all possible operating conditions, but were unable to reproduce the problem. When the reports of these servo deflections became more frequent and we got more transmitter / receiver combinations for testing where the problem should have arisen, we actually managed to see the error "live" on a servo. Neither we nor FrSky were able to reproduce the error. In the autumn of this year Ewald Möhring and I came together by email and it turned out that Ewald was and is a retired software and RF specialist. We provided him with various Frsky transmitters and receivers to carry out measurements and he was able to measure and reproduce the problem for the first time. Using the high-quality measurement technology available to him, he was also able to generate log files of the problem for the first time. With this information, Dirk Weiler and Udo Nowakowski came on board, who, thanks to their in-depth knowledge, were also able to help localize the problem. Dirk and Udo developed tools that enabled them and us (Engel Modellbau) to record log files and display the error even without extremely expensive measuring technology.
At this point, FrSky was finally provided with information by Ewald and me, which also enabled FrSky to reproduce the problem. From now on it got serious and FrSky recognized the problem. The FrSky company owner personally ordered the problem to be dealt with as a priority.
Which products are affected? ALL receivers and transmitters / HF modules from FrSky!
Is LBT (EU) and FCC (world wide) equally affected? Basically yes! However, with FCC there are only in extreme exceptions more than four faulty frames (that is 0.036 seconds) and the user does not notice the problem. This also explains why until recently there was no evidence of the problem in the United States. The problem occurs very rarely with LBT (EU), but much more frequently than with FCC. This is in the nature of LBT and has nothing to do with FrSky.
Does the problem occur more often with OpenTX or with FrSky OS?
Since the software (user interface) has nothing to do with the transfer software, it doesn't matter whether you use OpenTX or FrSky OS.
How often does the problem occur?
You can't answer that as a blanket because there is no logic. There is credible information from customers that they had the problem several times a day and then again not for weeks. There is also credible information from customers who have had hundreds of flights without any problems when the problem occurred. And there are still a lot of customers who have never had the problem.
But it can happen to anyone and at any time!
What happens in practice? A.) If the error occurs (typically 2-4 faulty frames), it usually manifests itself in a short “servo twitch” without any noticeable servo movement. 2 frames last 18ms, that's too short for one noticeable servo deflection. It's barely visible, just audible. Mostly it affects only one of the 16 servo channels, rarely two. B.) In rare cases under A) not only is a servo value incorrect, but there is a brief malfunction in the execution of the receiver program. Probably because, in addition to or in addition to a servo value, any program-relevant control bits were also incorrectly transmitted. In all tests, this has always taken 0.9 seconds until the receiver "catches" and resynchronizes with the transmitter. Within this 0.9 seconds all servo values are frozen to the latest status. Unfortunately, it is usually the case that a faulty servo value is frozen for 0.9s on any of the 16 servo channels. If a servo is connected to this channel, there is a clear, uncontrolled servo deflection. 0.9s are also sufficient for slow servos to fully position. If one of the 16 servo channels is faulty in this case and is not used, the model cannot be controlled for 0.9s, but no servo deflection can be determined. The same applies if only control bits but no servo values are incorrect. Compared to the short “servo twitching”, this case occurs much less frequently and has so far only affected a few pilots in the EU (LBT) area. The statistical difference between A.) and B.) is simply based on the fact that considerably more servo data than control bits are transmitted from the transmitter to the receiver.
The main cause is the so-called "error detection / encryption" in the firmware. This was developed by FrSky itself in order to remain independent of the chip manufacturers. Because these also provide error detection / encryption. This self-developed error detection / encryption must have worked well for years. Otherwise FrSky would not have earned its good reputation as a safe and reliable RC system to date.
In recent times, however, the operating conditions have increasingly changed due to a significantly higher utilization of the 2.4 GHz band. There is a direct, statistical connection between interference and the quality of the radio link on the 2.4GHz band and the probability with which our error can occur.
In addition, modern receiver chips are more sensitive and therefore allow a longer range. However, they are therefore also more sensitive to the smallest frequency deviations. This is why receivers like the GRX-8 are affected more often than older types. If the scattering of components (there is certainly in electronics) leads to a somewhat unclean frequency adjustment and there are also many disturbances in the environment, then there is a significantly higher probability that the problem will occur.
What is FrSky doing now?
FrSky works very intensively on updates for most products. From today's perspective, only a few receivers cannot be updated due to the hardware. With these updates, above all the "error detection / encryption" mentioned above is significantly improved. Further small measures will also be included, which will also have a positive effect on the transmission quality overall.
Where there are advantages, there are also known disadvantages. Due to the changed encryption, all receivers and transmitter / RF modules that a customer operates must receive an update at the same time.
If you don't do this, only the receivers who have received an update will work with the transmitter.
This is also the reason why the updates will only be available in packages. There will be a package for ACCESS transmitters / RF modules and receivers and a package for ACCST (D16) transmitters / RF modules and receivers.
Due to massive pressure from our side, FrSky was convinced to prefer the ACCST updates. Originally they wanted to finish the ACCESS updates in December and then the ACCST updates in January / February. Now FrSky is working in parallel on the updates for both protocols.
The final tests of the updates started on December 5th, 2019. Ewald Möhring (software and RF specialist), Jan Urbánek RC Studio CZ (electronics technician), Mike Delay (software specialist), Adela (technical staff in development at FrSky) and I are involved.
What's next here?I would like to ask other technical questions to the round under the topic (thread) "Sudden servo deflections". We will then regularly expand this information page with summarized answers if necessary.
P.S.
This is looking like it might not be so heavily biased towards Clone lock out. Actually this is looking a lot like the issue brown out issues we had earlier with Spektrum (1 second reboot). I'm at a loss as to why FrSky hasn't come out with this. Had they come out with this earlier It would have saved a lot of "words" and not have tarnished their reputation.
github.com
frsky-forum.de
