Frsky updates

antlerhanger · Post by **antlerhanger** » Sat Jan 25, 2020 10:19 am

And the debate goes on . My only concern is can I use a updated external XJT module in my 9xr pro's for updated Frsky receivers ? Will I still be able to use my MPM in my Taranis for spektrum stuff ( Eflite BNF) after update ? I use ERSKYTX and everything works perfect . I won't update until Mike gives the all clear on compatibility .If even then . I am going to DIY my own receivers as soon as I can figure out how .

Allen

Post by **Kilrah** » Sat Jan 25, 2020 11:12 am

mak wrote: ↑Sat Jan 25, 2020 8:38 am Well, agreed. But in what world users can have a choice if to have or not IP protection mechanisms? If a company is deciding to introduce one, for sure will not put it for users to vote. No company ever did that.

mak wrote: ↑Sat Jan 25, 2020 8:38 am We have dumb cloners, cloning 1:1 products and selling work of others with no value added.

Yes they have a choice - move to systems that don't to such mess, and the best choice for that at this point is ironically just the products that FrSky wants to suppress. Which is why IMO FrSky's decision to add protections is going to end up hurting them more than if they didn't. Instead of proving their superiority and value nearly each of their moves recently make the cloners' products more and more interesting and gives them the value they didn't have.

We already have an example where the protection introduced a serious unneccessary risk with the ACCESS upgrade module for the X10.

By the way the T16 does bring added value with completely independent internal and external modules that can be used fully (control+telemetry) at the same time, which is something we had been asking from FrSky for a long time, and is still not possible with their radios.

Post by **jhsa** » Sat Jan 25, 2020 12:32 pm

Carbo wrote: ↑Sat Jan 25, 2020 6:03 am Imo they should have the chance, to get a firmware with the bugfixes only and without additional goodies. Installation of the goodies should be optional

Carbo, ask Graupner, Futaba. JR, and others if they give costumers an option to install goodies or not

But no one bashes them..

I repeat, I am not taking sides, and I have nothing to do with frsky or any other company. Perhaps this is the reason i can have an objective and impartial opinion.. And due to what I have been seeing lately, I don't even follow the Multi Protocol thread anymore. that is not a DIY project anymore. It is a commercial product.

João

Post by **Kilrah** » Sat Jan 25, 2020 1:44 pm

jhsa wrote: ↑Sat Jan 25, 2020 12:32 pm Carbo, ask Graupner, Futaba. JR, and others if they give costumers an option to install goodies or not
But no one bashes them..

Because none of these have included such code that is unnecessary to the function of their product.

Post by **jhsa** » Sat Jan 25, 2020 2:21 pm

@ Kilrah. Sorry, that doesn't make sense to me.. Of course they do, but you wouldn't know, would you?

And also, if you look into the past you will find out that most (if not all) of them messed up a few times, and then fixed the problem. Yes, Futaba too

I had a very expensive, top of the range Multiplex radio many moons ago, that was the worst P.O.S I ever owned. Used it once and never again as it crashed my model. and no, it wasn't user's error.

went back to my Futaba FF6.
Every company messed up, no one bashed them as far as I know. So why bashing frsky? They are entitled to do what they want. it is their company, their money, their product. Don't like it? don't agree? fine, don't buy it. Just leave it. I am still thankfull that a while ago they did listen to the DIY community, when the DIY community WAS a DIY community. Unfortunately, the DIY community, except from some of us, became a product troubleshoot and service community. and that was when the problems started to arise. When money enters the equation, it just destroys everything. and I am not talking about the few users that developed a few boards for the 9x radio. My deepest respect for them, as they probably even lost money doing so. But yes, those, together with the firmware developers were the ones that really changed the RC world. Of course, Frsky provided a good RF link and a good telemetry implementation. that really helped getting where we are now. And this is what you should be telling OpenTX users before they write some c***p, without knowing the story in all its extent. It is not convenient, is it??

Jumper couldn't even design a little receiver properly, do you want me to believe they have designed their radios?

Laughable..

Even Hobbyking put a bit of effort to design their 9XR-PRO without copying anything..

João

Carbo · Post by **Carbo** » Sat Jan 25, 2020 2:23 pm

jhsa wrote: ↑Sat Jan 25, 2020 12:32 pm
Carbo wrote: ↑Sat Jan 25, 2020 6:03 am Imo they should have the chance, to get a firmware with the bugfixes only and without additional goodies. Installation of the goodies should be optional
Carbo, ask Graupner, Futaba. JR, and others if they give costumers an option to install goodies or not

One smiley should be enough, to show it is irony

Of course FrSky does not give it's customers an option for an adfree firmware. It is the purpose of the drama

Post by **Kilrah** » Sat Jan 25, 2020 2:39 pm

jhsa wrote: ↑Sat Jan 25, 2020 2:21 pm @ Kilrah. Sorry, that doesn't make sense to me.. Of course they do, but you wouldn't know, would you?

No, none of them have included code specifically designed to prevent cloning rather than providing the intended functionality to this day. Even in new protocols released after having been cloned.

jhsa wrote: ↑Sat Jan 25, 2020 2:21 pm Every company messed up, no one bashed them as far as I know. So why bashing frsky?

Nobody goes after them for the initial issue. Happens. But the fix they provided was released poorly with other bugs to the core function, but added unnecessary stuff that must have taken development effort that could have been used to, for example, fix the core function properly.

jhsa wrote: ↑Sat Jan 25, 2020 2:21 pm Of course, Frsky provided a good RF link and a good telemetry implementation. that really helped getting where we are now.

Yes and they've supported a community for years, but are now moving away from it without leaving their customers an alternative other than the very companies they say are hurting them, which is why people are pissed off and the whole situation is ironic.

jhsa wrote: ↑Sat Jan 25, 2020 2:21 pm They are entitled to do what they want. it is their company, their money, their product. Don't like it? don't agree? fine, don't buy it. Just leave it.

That's exactly what's happening. But it can still be discussed, which you have previously insisted about many times in situations that you didn't find right yourself.

Post by **jhsa** » Sat Jan 25, 2020 3:27 pm

Kilrah wrote: ↑Sat Jan 25, 2020 2:39 pm
No, none of them have included code specifically designed to prevent cloning rather than providing the intended functionality to this day. Even in new protocols released after having been cloned.

There is no way for you to know that unless you worked for all of them

In my opinion they will do whatever it takes to protect their property from being cloned. of course they add stuff to prevent that, it would be stupid if they didn't

Nobody goes after them for the initial issue. Happens. But the fix they provided was released poorly with other bugs to the core function, but added unnecessary stuff that must have taken development effort that could have been used to, for example, fix the core function properly.

well, they are probably adding stuff to fix issues and to prevent people from cloning it. You should have understood by now, that they obviously do not want anyone else to use their new protocol. accept it, and get over it

Yes and they've supported a community for years, but are now moving away from it without leaving their customers an alternative other than the very companies they say are hurting them, which is why people are pissed off and the whole situation is ironic.

So, let's just bash them for it, shall we?? You should be glad that they shared their stuff with you for years, no one else did that. And look what happened, it back fired on them.
Jumper uses the multiprotocol module, but all revs around the frsky protocol? why? If it is that bad, do not use the frsky protocol, remove it from the Jumper Multi protocol firmware.. Of course, you are not going to do that, are you? It is good, isn't it?

Then stop complaining about it, consider it a gift..

That's exactly what's happening. But it can still be discussed, which you have previously insisted about many times in situations that you didn't find right yourself.

You are not discussing, you are bashing. there is a big difference..

Yes, I am known for complaining about stuff I don't agree with, don't consider safe, and I don't consider fair, just like now..

And i have been bashed for it, but I have large shoulders..... and belly, but that is another subject

As I mentioned somewhere above, I haven't seen Bertrand (the main OpenTX developer) around here for a while. I (and for sure others) would be interested to read his opinion on all this situation. It is his opinion that matters to me as as far as I know he is the head and owner of the OpenTX project? A link to a post where he expresses his opinion would be very much appreciated.

João

Post by **Kilrah** » Sat Jan 25, 2020 4:24 pm

jhsa wrote: ↑Sat Jan 25, 2020 3:27 pm There is no way for you to know that unless you worked for all of them

Nearly all of them are implemented in multiprotocol...

Post by **jhsa** » Sat Jan 25, 2020 6:09 pm

Oh really? Where is FAST from Futaba for example?

And I guess there is some newer one..

midelic · Post by **midelic** » Sat Jan 25, 2020 6:25 pm

Carbo wrote: ↑Fri Jan 24, 2020 10:06 am Here is another log from Juergen with a documented lockout with ACCST pre2.0. Eventually combined with an unintended roll command, if you look at the pilot's reaction with aileron (blue), but it may also be a coincidence. It took 8 months to find a pilot with an affected TX and the ability to build and use tadango's lost frame counter. Juergen will test V2.0 in the future. In spite of the manipulation with lost frames, lockouts should still be visible. But there is a good chance that FrSky has found the root cause for lockouts and lasting unintended channel data according to Mike's post. The better CRC method should generally prevent incorrect channel data, as far as I understand.
The other anomaly in the logfile is a manual midair telemetry reset
Quax_Lockout2.jpg

I would be interested to see if these lockouts will happen with my D16/LBT DIY RX.My bet is that will not happen.I don't think "poor"CRC calculation is the root cause of their problem or will be solved by a better one.

Post by **Kilrah** » Sat Jan 25, 2020 6:29 pm

jhsa wrote: ↑Sat Jan 25, 2020 6:09 pm Oh really? Where is FAST from Futaba for example?

Was easy enough to decode a decade ago, but since it's long discontinued along with the chip it requires (and only it, so not interesting in multiprotocol) nobody cares about it anymore.

Later S-FHSS is implemented. Newer FASSTest nobody has cared about looking at it so far AFAIK.

Carbo · Post by **Carbo** » Sat Jan 25, 2020 6:54 pm

midelic wrote: ↑Sat Jan 25, 2020 6:25 pm
Carbo wrote: ↑Fri Jan 24, 2020 10:06 am Here is another log from Juergen with a documented lockout with ACCST pre2.0. Eventually combined with an unintended roll command, if you look at the pilot's reaction with aileron (blue), but it may also be a coincidence. It took 8 months to find a pilot with an affected TX and the ability to build and use tadango's lost frame counter. Juergen will test V2.0 in the future. In spite of the manipulation with lost frames, lockouts should still be visible. But there is a good chance that FrSky has found the root cause for lockouts and lasting unintended channel data according to Mike's post. The better CRC method should generally prevent incorrect channel data, as far as I understand.
The other anomaly in the logfile is a manual midair telemetry reset
Quax_Lockout2.jpg
I would be interested to see if these lockouts will happen with a D16/LBT DIY RX.My bet is that will not happen.I don't think "poor"CRC calculation is the root cause of their problem or will be solved by a better one.

Good question. From my pov only a few TX are affected, but this may be wrong, of course. FrSky has widened the AFC window recently for R-XSR and G-RX8 (LBT firmware only), both are very critical for lockouts with affected TX. It seems the combination of a critical TX with a RX with small AFC windows has the best chance for a lockout. Btw. AFC window can easily be tested by tuning MPM frequency in both directions until failsafe. I'm about to flash a R8 with your firmware. I can talk to Juergen, if he is willing to test. I own no affected TX myself.
My suspicion is that TX frequency deviation is the root cause. But I have not enough data to be sure. That's why I've chimed in here.

midelic · Post by **midelic** » Sat Jan 25, 2020 7:13 pm

CC2500 X-tal frequency drift with temperature may happen(and happened with poor quality X-tals) and if happened it will worsen and the rx will not recover.The lockout is limited in time and rx recovered .I don't think the lockout is caused by a frequency drift.

TomasJ · Post by **TomasJ** » Sat Jan 25, 2020 7:20 pm

Bold statement form midelic...If true - that means FrSky made update for copy protection, instead of fixing all receivers firmware...AFAIU AFC window or TX can influence probability of bad data creeping through CRC check (more lost frames - higher probability). Again - that easy to check looking at lost frames %. In case anyone missed testing conditions link. That means 2*9/(5*60*1000)= 6E-5 (or 0.006%) frames slips through CRC check... Maybe bad poly chosen?

midelic · Post by **midelic** » Sat Jan 25, 2020 7:31 pm

I don't see how bad data can creep through by itself.There is one more level(aside CRC) to root out bad data or incomplete.One is reading the number of bytes in RXFIFO register.That is red twice(as per CC2500 errata notes) to root out reading errors.After the data is red there are 3 other checks for packet number bytes received,correctTX id and rxnumber.
I think bad data creeps in because was calculated bad in the first place in TX before the CRC.Lost frames don't pass the CRC or the subsequent checks.It doesn't mean that if you have a lost frame,the CRC was passed over.
I don't deny the problem exists.I challenge the explanations provided by Frsky or others.If you cannot reproduce the fault with a DIY RX( that used the same crc),that means the explanations offered were not valid and maybe other motives were considered.

Carbo · Post by **Carbo** » Sat Jan 25, 2020 7:41 pm

midelic wrote: ↑Sat Jan 25, 2020 7:13 pm CC2500 X-tal frequency drift with temperature may happen(and happened with poor quality X-tals) and if happened it will worsen and the rx will not recover.The lockout is limited in time and rx recovered .I don't think the lockout is caused by a frequency drift.

Eventually it was wrong wording, it is not temperature related, aberration is constant. "Good" TX are about 40kHz below bind frequency, "bad" above bindfrequency - but again, there is not enough data to be sure. Here is an example with two uncritical TX and a critical one:
https://openrcforums.com/forum/viewtopi ... 60#p148099
The lockout occurs imo much more frequently with LBT and the new transmitters, X9D and X9E did not show up.

midelic · Post by **midelic** » Sat Jan 25, 2020 7:48 pm

Carbo,
My DIY RX is tuned closer to the base frequency that tx put out(theoretically in +/- 210 khz deviation).If the tx base frequency is lower or higher with 40Khz the DIY rx is tuned automatically to that.As long as the offset is constant the RX don't care.
As a side note Mike added in his code option for dynamic tuning,that can tune the rx on the fly.That could work ok with original TX but I have my reservation when used with multiprotocol(used tuning in TX).

If the TX is tuned lower than an original rx yes these problem may happen with syncing but that have nothing to do with better crc that will solve that problem.

Carbo · Post by **Carbo** » Sat Jan 25, 2020 8:07 pm

FWIW I've asked Pascal Langer (MPM) about the frequency tuning with FrSky. I think it is OK to publish his answer:

"Re: FrSky frequency calibration
The original frsky RXs don't do it. They might be tuned at manufacturing time once for all.
The clone frsky RXs are doing exactly what you are saying."

In my first post in this thread I wrote, that I'm not a fanboy of the CRC story

midelic · Post by **midelic** » Sat Jan 25, 2020 8:11 pm

Yes exactly that, I said the same 5 years ago.

Carbo · Post by **Carbo** » Sat Jan 25, 2020 8:19 pm

If FrSky does not automatically tune RX, is this a possible cause for the watched lockouts, when TX frequency is out of tolerance? What do you think?

midelic · Post by **midelic** » Sat Jan 25, 2020 8:38 pm

It is possible some interference but I don't think the lockout here was from the tx frequency offset.
Let me explain.The lockout here means that 100 frames were lost(0.9 sec),In the hopping frequency system that means the rx was passing over all channels 2 times(jumping on the next channel every 9 ms) without syncing with tx.
It is improbable that can be cause by an offset in freq as the offset you'll have from the start of the session and worked previously.It will skip one channel out of sync but will catch the next and the lockout will be prevented.

Carbo · Post by **Carbo** » Sat Jan 25, 2020 8:48 pm

OK thanks, the search continues.

midelic · Post by **midelic** » Sat Jan 25, 2020 8:58 pm

I think Mike has a good idea why the lockout happened.

Carbo · Post by **Carbo** » Sat Jan 25, 2020 9:26 pm

Mainly I'm interested, why my TX are not affected.I've made hundreds of testflights with openXsensor and I'm sure, I never had a single glitch with X9D/E.

TomasJ · Post by **TomasJ** » Sat Jan 25, 2020 9:48 pm

midelic wrote: ↑Sat Jan 25, 2020 7:31 pm...If you cannot reproduce the fault with a DIY RX( that used the same crc)...

Did anybody tried? (I guess not...)
I don't see any other way to get uncommanded servo deflection, except CRC fail... (or errors in TX or RX firmware). Lets make a bet: I will check with MPM and DIY RX (have no RX at the moment and no logger)- if I get uncommanded deflection - you make DIY RX firmware open source

Post by **MikeB** » Sun Jan 26, 2020 12:11 am

My explanation of the lock out and servo deflection: https://www.rcgroups.com/forums/showpos ... tcount=204.

Mike

Carbo · Post by **Carbo** » Sun Jan 26, 2020 5:58 am

MikeB wrote: ↑Sun Jan 26, 2020 12:11 am My explanation of the lock out and servo deflection: https://www.rcgroups.com/forums/showpos ... tcount=204.

Very diplomatic. At least the lockout is now kind of official. FrSky and Engel are still talking about servo movements only
Some may wonder, how the RX knows, where to hop, when a frame is completely lost.

midelic · Post by **midelic** » Sun Jan 26, 2020 7:05 am

Hopping sequence is determined at the session start with the 6-th byte(packet no5) in the packet.That byte is sent on every frame.If that byte become corrupted(wrongly calculated by tx or rx,or other reasons that I fail to see now ) ,the rx will jump on different channel with the wrong sequence and continue jumping 100 frames on different channel than tx, out of sync ,causing the rx going in failsafe 0.9sec later.
I think frsky firmware check that packet byte on each frame and adjusted hopping sequence accordingly.That is potentially dangerous.
What is interesting for me is that not all RX or TX are affected make me believe that they used different firmware in the new product line of Tx/RX with D16/LBT protocol.

Carbo · Post by **Carbo** » Sun Jan 26, 2020 8:07 am

midelic wrote: ↑Sun Jan 26, 2020 7:05 amWhat is interesting for me is that not all RX or TX are affected make me believe that they used different firmware in the new product line of Tx/RX with D16/LBT protocol.

I think, there is not enough data about affected RX or TX models to be sure, but it would be a good explanation for my problem, to have no issues at all

There is only one X9D+ with issues as far as I know. The issues happened with 170317 XJT firmware and went away, using the former firmware. I did not take this case serious and thought it is a "individual destiny". Because on the other side, there are a lot of X9D+ out there with 170317 without issues. Is another factor in the game? He was flying far from any interferences, when he watched the servo movements.

https://www.rcgroups.com/forums/showpos ... tcount=238

openrcforums

Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates

Re: Frsky updates