Yes, I figured it could be useful.

Huge shout out to Thomas J. for doing the work and posting the files.

Sometimes I wish RCGroups had a 'like button'.

Originally Posted by Kilrah

Remember a user/customer doesn't give the slightest damn about what's original and what isn't, all they see is they bought something that worked for them and now it doesn't anymore, and the break has been caused by FrSky so that's whom they'll consider responsible for it.

Well, I'm a user who hasn't bought any clone receivers at this point other than to use a plug-in module that allows me to use the receivers that are made to be used with that module.

That said, IF I had bought clones from another company, I would not at all expect FrSky to be responsible for making sure that those clones worked with FrSky radios.
Realistically, and fairly, I would expect the clone company to adapt to any changes that came from FrSky and not the other way around.

What you're suggesting is a basic violation of fairness by an average customer, and I just don't think that exists.
And knowing full well up front that any clone I would buy, even at a great price, could at any moment be orphaned due to FrSky changes is why I have always bought RX's that were made by the same people who made the TX's (or add on module).

I'm as unhappy with FrSky at this point as many are, but I'm not willing to throw them to the dogs for not supporting products made by other companies that cloned them. That is simply not right.

I also don't have a problem with encryption for the reasons of making it harder to clone their products. What I do have a problem with is the trashy implementation of it along with the rush-to-the-market "improvements" that have ended up being big steps backwards for the very same customers who have been supporting them all along.
FrSky needs to have tag teams of techs working 24/7 to get this stuff in order. Any less effort by them adds even more to the wrecklessness (mispelling intended) we've been going through this last many months.

I think this a straw argument. Most are simply unhappy with frskys sloppy work viz it’s own products. The cloners are able to fend for themselves.

Eureka! Found it... I had downloaded the rx8r instead of the x8r that I needed. Doh!

JohnH

There are well-reasoned arguments in the posts above.

It seems to me that one important issue boils down not to whether FrSky had the right to add encryption (for whatever reason they saw fit) but rather to whether it was in their best business interests to do so.

Time will tell on that question, I suppose. Personally, I hope FrSky can succeed for the sole reason that they contribute technical innovation. Jumper, Hobby Porter, RadioMaster, etc. are parasites that contribute nothing of significance and degrade the market's appreciation of the work and cost involved in developing successful new products.

Another significant issue is -- as it has always been, alas -- the insufficient level of testing and QA at FrSky. Volunteers and possibly individual contractors have clearly done a stalwart job on the unwanted servo movement bug. The fact that the released firmware contains bugs is in no way their responsibility. It is FrSky's alone.

Last paragraph, amen.

On the second to last paragraph, imagine the gall it takes for a parasitic Chinese company to steal the ip of another Chinese company. It shocks the conscience, I tell you!

Originally Posted by I_SOAR

Eureka! Found it... I had downloaded the rx8r instead of the x8r that I needed. Doh!

JohnH

Good news John,

Mike

I think it is normal if a company protects its investments. Every one of us would do that.
Every development costs money and returns only by selling products. This should be clear to everyone.
I always buy original equipment to get support when needed. I'm not rich enough to wait until someone steals an FW or electronics design to save a few dollars. For me the prices of FrSky devices are reasonable enough and I understand that they have to cover development costs. So I hope FrSky will have enough money to develop other instruments because clones are not developing anything.

Originally Posted by landru

Another significant issue is -- as it has always been, alas -- the insufficient level of testing and QA at FrSky. Volunteers and possibly individual contractors have clearly done a stalwart job on the unwanted servo movement bug. The fact that the released firmware contains bugs is in no way their responsibility. It is FrSky's alone.

Testing and QA is a very hard nut to get right and even the biggest and best get it wrong. Just look at Boeing and the lives that were lost.

The products I tested got their bugs fixed and so far with the 2.0.1. released firmware they seem to be doing well. One possible exception is the intermittent sensor lost issue and I'll see if it shows up on the products I tested. If so I missed it. The 2.0.1. release is especially difficult because it involves almost every product made and products that are no longer made. Like a X9D that was made in 2013!

Not trying to make excuses for FrSky, just some insight on the project and as someone said the users do not give a rat what it takes for FrSky to fix their issues.

Mike

Originally Posted by landru

There are well-reasoned arguments in the posts above.

It seems to me that one important issue boils down not to whether FrSky had the right to add encryption (for whatever reason they saw fit) but rather to whether it was in their best business interests to do so.

I might not have explained the encryption part clear enough. The has to do with the RF data link between the TX and RX being encrypted and that adds more protection to the link.

One of the MPM guys said on one of the threads that he would have 2.0.1. decoded in no time and working on the MPM. So once again MPM users get to take advantage of FrSky's newest protocol including the encryption.

Mike

Is this edge case un-commanded servo movement problem documented/explained anywhere?

I would like to know more about those edge cases which case it. I have seen some very very rare instances where this issue may explain it, and I want to see if I can now explain those. Just to satisfy myself.

Sent from my Pixel 3 XL using Tapatalk

There is apparently no clear cause identified beyond "noisy RF environment".

Originally Posted by Jet_Flyer

I might not have explained the encryption part clear enough. The has to do with the RF data link between the TX and RX being encrypted and that adds more protection to the link.

One of the MPM guys said on one of the threads that he would have 2.0.1. decoded in no time and working on the MPM.

Mostly interested in seeing whether the claims and explanations are valid.

MPM is open source. Anybody can look at the code for CRC used for ACCST protocol... Is it really too weak? How about other protocols - DSM, Hott, FHSS?
Another bug (or "feature") "..people using SBus with V2.01 can not trust the lost frame information..." Looks like it's time to build link quality sensor/logger...

Originally Posted by Kilrah

Mostly interested in seeing whether the claims and explanations are valid.

Andreas Engel has done a nice job explaining the issue here. Will need to use your browser to change the text from German to what ever https://frsky-forum.de/thread/3404-h...%C3%B6tzliche/

My unwanted servo movement event was on CH 1 and gave full aileron deflection making a perfect aileron roll. Very scary! At the time I thought it was a bad servo and I changed it out, but now I know it was not the servo.

Mike

Originally Posted by Jet_Flyer

Andreas Engel has done a nice job explaining the issue here. Will need to use your browser to change the text from German to what ever https://frsky-forum.de/thread/3404-h...%C3%B6tzliche/

My unwanted servo movement event was on CH 1 and gave full aileron deflection making a perfect aileron roll. Very scary! At the time I thought it was a bad servo and I changed it out, but now I know it was not the servo.

Mike

Thanks for sharing this article Mike - puts everything into far better perspective - we all should read this to have a better understanding of the history and hence, the current situation that we've been largely speculating over, therefore more accepting and patient, perhaps...