Frsky updates

erskyTx runs on many radios and upgrade boards
ersky9x was a port of er9x for use on the sky9x board.
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

I think this heated debate of FrSky versus Jumper/clones is because people are invested too much emotionally with a product.
They care.
When a person close to you do something that upsets you ,you feel betrayed.That is because you put that person(or a product) on a pedestal and when the image you have of that person become tarnished you get angry.For this reason you don't care if others did the same.That person betrayed you.It is personal.
Here i finish my pseudo psychological analysis.
Last edited by midelic on Sun Jan 26, 2020 8:43 am, edited 1 time in total.

User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

The other factor is that these rx are using different firmwares.As TX maybe have one firmware ,different RX using different firmware for different purposes. Idk about these rx firmware but the servo glitches can have other explanations( how the timing for servo is generated,the interrupts interrupts priority allocation ) than the corrupt data from tx.
For example here": FrSky G-RX8
This receiver is designed to be used for the Gliders. FrSky built the variometer sensor into the RX8R receiver.The firmware is different added code for a variometer sensor and insert data in sport frames.we don't know what modifications were made in original code to add variometer.
These changes may affect how servo or sbus signal are generated.
TomasJ
Posts: 10
Joined: Sat Jul 13, 2019 4:46 pm
Country: -

Re: Frsky updates

Post by TomasJ »

So, no deal, midelic ?:) I have one idea, how to avoid unwanted servo deflection. If receiver gets bad jump date with good CRC, second packet is not received... Then receiver firmware sets servo outputs to stored channel data from one frame before last good (actually bad) frame. That doesn't solve 0.9s hold (I cannot think a way without breaking tx compatibility), but at least it will hold good channel values - su you can advertise as "sudden servo deflection fixed firmware" :)
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

I was discussing the problem with lockouts with original TX/RX.And I suggested a test with an original TX and a diy rx to see of those lookouts occurred again.And to prove that new crc and a consequence as a complete alteration of the original code( basically new firmware) is not necessary.
And you offered me a deal where you test MPM and a DIY RX for hunting servo glitches.
That is comparing apples and oranges.I have nothing to gain from that.
About bad jump data(hopping sequence) my DIY code simply ignored that and will not take in consideration.If a frame is lost the servo-data is not altered it will retain the same from last good frame(hold).
So a lockout(0.9sec) from that bad hopping sequence is not possible.About unwanted servo deflection as I said before I'm not convinced that deflection is from from bad data received from tx or some magic that passed the crc and other 4 checks on the same packet.Glitches in servo or in an SBUS signal can have as a cause the way the PWM servo signal and SBUS signal are produced after the data is already processed.And I suspect the problem is with new generation of rx with new firmware.

In short I think there was not necessary for Frsky to break compatibility with previous firmware in order to fix lockouts problem.
Last edited by midelic on Sun Jan 26, 2020 3:08 pm, edited 9 times in total.
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: RE: Re: Frsky updates

Post by jhsa »


midelic wrote: In short I think there was not necessary for Frsky to break compatibility with previous firmware in order to fix lockouts problem
Of course not, I think that was intentional.
They clearly want to make future equipment not compatible, so it won't work with the multi module for example.
Their users would just have to flash their old gear, and they should be up and running, and to be able to use further equipment they might buy. I don't see any problem with that nor am I against it as they have all right to do do, but they have messed something up while doing it. And now they will have to fix it. As simple as that. :)
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

TomasJ
Posts: 10
Joined: Sat Jul 13, 2019 4:46 pm
Country: -

Re: Frsky updates

Post by TomasJ »

Interresting read link.
Midelic, why you cannot accept, that CRC16 check can fail? Lets say, there is 50% frame loss. In 20 minutes that's 66666 frames, that was marked as bad and the same number as good. Message length for NEU 240 - EU 264 bits (I get that number from MPM source). For CRC16 at that message length HD=5, that means if there is 6 or more bits corruption, CRC can fail. And it does, I don't doubt it. Question is, how receiver handles that...
It is not clear to me, how receiver jumps to another channel...If correct frame was received it jumps to transmitted byte 4 and 5? If frame lost where it looks for next frame? What is 5 bytes (6-10) transmitted during bind - hopping table? If not that difficult, would you care to explain...
Regarding MPM - it is open source, you can see if any firmware errors was made - so that eliminates TX side as source for error.I also have XJT module(but only two years old) and X10 iXJT (still underway) if you prefer those.
And I'm just kidding about DIY RX making open source - I read your POV about chinese using open source firmware and don't expect you changing your mind...(but I wish...)
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

Let me tell you something that may appear shocking to you.I believe that crc system used by Frsksy cannot fail in these conditions.Yes the HW CRC used by ccc2500 can fail but not the one used by frsky. It is an ingenious system to ensure that correct data is received and in my opinion far superior the HW CRC in cc2500.If somebody can explain to me logically how the actual CRC used by frsky can be beaten, I'm all ears.I want to be proven wrong.
Assuming a possible CRC error there are 3-4 other checks in RX that ensure the frames are the correct ones. My problem is with breaking compatibility with previous versions and the offered explanations.I will test at home ,I will activate the HW CRC and my RX bit 2 in PKTCTRL0 and bit 3 in PKTCTRL1 register(CRC_AUTOFLUSH Enable automatic flush of RX FIFO when CRC is not OK).I want to prove that activating HW CRC is not breaking the compatibility.
About hopping sequence it is fixed at start with packet[5].And it is transmitted in every frame.There are 47 channels.
If the packet[5]=5(I simplify here there are more calculations)the next channel is:
channel = (channel+5)%47;//jumping on the next 5-th channel in the binding table from previous.
Last edited by midelic on Sun Jan 26, 2020 6:46 pm, edited 1 time in total.
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: Frsky updates

Post by Carbo »

I'm also sure the update is a trojan horse. But there are definitely lockouts and unwanted servo movements. You wrote, that TX out of tolerance can not cause this. If a CRC error can also not cause this, what else? Is it simply a firmware bug, like it was with X12 when it came out?
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

I believe the problem is with the new line of TX and RX probably used different hardware and different software.
I would like to hear if somebody recorded the same problem with an TX with XJT module and an old X4R or X8R rx.
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Frsky updates

Post by MikeB »

Any CRC can fail. The CRC is 16 bits, so 65536 (2^16) possible values. For LBT, the CRC is calculated over 28 bytes, which is 224 bits. So there are, potentially, 2^224 different packet contents. For any given CRC value, there are, on average, 2^208 packets giving that value. Don't forget, the packet is sent with the CRC value, and this may itself be received in error.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

Mike.
I remind you that the CRC on frsky is not calculated in Rx is calculated in TX and sent as data in the packet frame.The crc is reconstructed in RX from packet bytes received and checked against the crc bytes again received in the same packet.If they are coming erroneous the frame is discarded.If the packet bytes are wrong the frame is discarded. Along with packet length check with txid checks and rx num checks I really don't see how a bad frame can pass.It can pass if is already calculated and transmitted wrongly by the tx.
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: Frsky updates

Post by Carbo »

midelic wrote: Sun Jan 26, 2020 7:02 pm I believe the problem is with the new line of TX and RX probably used different hardware and different software.
I would like to hear if somebody recorded the same problem with an TX with XJT module and an old X4R or X8R rx.
I'm watching this issue closely from the beginning and have never seen this combination affected.
RCJohn
Posts: 12
Joined: Fri Jan 17, 2020 7:23 pm
Country: -

Re: Frsky updates

Post by RCJohn »

The CRC calculation by the FrSky V1 FW uses a table with only 16 values.
I don't understand why they did not enable the HW based CRC of the CC2500.
User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Frsky updates

Post by MikeB »

The CRC calculation done by FrSky in V1 uses a table of 256 values. The multi-protocol code found a way to reduce this to only 16 values to save flash space (in the original AVR module).
It is curious why they didn't use the hardware CRC of the cc2500, the D8 protocol does use it!

midelic: I just wrote a python script that takes a V1 packet, modifies one of the channel skip bits, then tries all possible 65535 values in two later bytes. The CRC matched with 8 of these, so a single bit error followed by a pair of corrupted bytes later in the packet will sometimes result in a valid CRC. In some cases, only 5 bits of the two later bytes were corrupt.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
TomasJ
Posts: 10
Joined: Sat Jul 13, 2019 4:46 pm
Country: -

Re: Frsky updates

Post by TomasJ »

There's nothing ingenious about CRC...Its old as hell...I'm sure, that Mike perfectly understands, how crc is calculated :) Packet bytes can be flipped in a way, that CRC remain the same.
Anyway, got curious about enabling cc2500 hardware crc, so rebuild MPM firmware with "bit 2 in PKTCTRL0 and bit 3 in PKTCTRL1" from Midelic's post.At first glance everything looks fine - RX8R receiver works, RSSI normal. But that's only 5 minutes test - maybe something else (like Sport or range) are affected (look at FrSky firmwares:). So maybe FrSky breaking compatibility is trojan horse...
Let see, what Midelic will discover.
Another thing - I provided a link, where user, named udo tested and saw problem. And he says "The problem was detectable with any kind of TX/Rx combo"...
I will think more about frequency jumping - then ask some more questions :)
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Frsky updates

Post by Kilrah »

Someone mentioned on RCG that they didn't enable the hardware CRC becasue they expected to change chipset at some point and didn't want to use chip-specific functions...
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: Frsky updates

Post by Carbo »

TomasJ wrote: Sun Jan 26, 2020 10:34 pmAnother thing - I provided a link, where user, named udo tested and saw problem. And he says "The problem was detectable with any kind of TX/Rx combo"...
Correct. But only on the table with high interference level and with certain RX models. I may be wrong, but when FrSky started with D16 a lot of users including me watched the link quality suspiciously until they had build up trust. I do not remember a single lockout/servomovement, since this would have alarmed me. I can not afford link issues on the places I fly.

Imo the issues started when the new TX/RX series arrived.

Btw. It would be nice, if someone might look into the SBus to verify my finding, that FrSky is suppressing until three lost frame informations in a row in SBus with V2. Not OK for me, but I may be oversensitive.

Just saw this post, it matches perfectly my observations. Often the lockout issue causes a "telemetry lost" alarm, but unfortunately not always. A 0.7s trigger for "telemetry lost" will presumably detect every lockout.
https://www.rcgroups.com/forums/showpos ... ount=15418
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

Crc is not ingenious by itself , is the fact that is calculated in TX sent to rx and checked in rx after the packet is received.That is ingenious for me I'm a simple guy.
Your calculation does't say how the bit may change and what is the probability to change and what is the probability that the modified bits to be exactly those that pass a valid crc and what is the probability that changed bits to be in an entire valid packet.
What is the probability that the bit can change in the first place and the probability to be the few bits that changed to be on the same frame with 2 valid TXid(2 bytes check),length,rxnum and 2 valid crc bytes check.And the probability that all bad to happen in a 10-15 minutes flight session.
On top of that according with crc mathematics.
8-bit crc has 99.6094% error detection rate
16-bit checksum will detect 99.9985% of all errors.
32-bit 99.9999% detection rate

HW crc on CC2500 is done on the packets already received from it has not control over the correctness of the packets sent by tx. There is nothing ingenious about HW crc that will solve all the problems.Let's say by chance it is happening on the chanskip bit ,the solution is simple, ignore that corrupted byte and discard the entire frame.There is no need to break compatibility with previous firmware.

D16 is around for many years now.It was tested by many people on this planet(along these years there were many, many drone competitions where all the competitors were using frsky gear(taranis),it is really a wifi interference hell environment).Now suddenly a lot of errors comes out with the new HW and everybody jumps to blame in the entire protocol.
Occam razor.Let's not find fancy explanations.The planet can be hit by a big asteroid and planet can die, what are the odds for that.
This way I can blame the lockouts on solar flares.
Last edited by midelic on Mon Jan 27, 2020 2:15 pm, edited 7 times in total.
RCJohn
Posts: 12
Joined: Fri Jan 17, 2020 7:23 pm
Country: -

Re: Frsky updates

Post by RCJohn »

The strength of any CRC generally depends very much on the potential error pattern which might occur.
CRC is very strong for single bit errors, but becomes very weak in case of continous bit errors with same value, especially 0s.
What can happen for example?
In case of hard-wired LAN, it is vey difficult to induce continous mutiple bit/byte errors.
In case of pure spread spectrum WLAN, it is very difficult to induce mutiple continous bit/byte errors.
In case FFH ( I may call it pseudo spread spectrum), within one Hopp (one Frame), easily continous bit errors can occur.
Within one Frame, FFH is nothing but a simple frequency modulated carrier !!!
RF-Interference as well as Fresnel-, Doubler-Effects can cause sudden frequency shifting, especially when tx and rx center frequencies are not well matched and the AFC (automatic frequncy correction/control) is running at the edge of its contoll range.
It seems quite careless, that FrSky V1 did not use any data-whitening and only one simplified CRC16.
If you talk to data security guys, for them double CRC and encryption is mandatory (which would exceed our avaiblabe time frame with given HW).
Maybe FrSky takes the chance to block competitors from copying the V2 FW, as a side-effect, but the way it is implemented presently in V2, it is too weak to think that this was their main intention. The data-whitening and additional CRC by the CC2500 make the difference, and that has nothing to do with clone blocking.
Last edited by RCJohn on Mon Jan 27, 2020 8:34 pm, edited 5 times in total.
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: Frsky updates

Post by Carbo »

-- deleted ---
Last edited by Carbo on Mon Jan 27, 2020 7:13 pm, edited 1 time in total.
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

For security reasons yes it is weak. Yes the communication over the air is not secure.That was not the intention.There is no point to encrypt data in order to avoid a potential enemy or a person with nefarious intentions to find out what we send over the air.This is RC world.You can send valid data on an unsecured channel.There are worse protocols than this one in RC world.
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: Frsky updates

Post by Carbo »

RCJohn wrote: Mon Jan 27, 2020 9:40 amRF-Interference as well as Fresnel-, Doubler-Effects can cause sudden frequency shifting, especially when tx and rx center frequencies are not well matched and the AFC (automatic frequncy correction/control) is running at the edge of its contoll range.
A piper pilot ;) opened my eyes, to read and understand this sentence. Thank you! This matches my frequency theory. I've stopped reading after "Fresnel -, Doubler-Effects.... because it sounded strange in this context. But the result matches my observations. Comments welcome :)
RCJohn
Posts: 12
Joined: Fri Jan 17, 2020 7:23 pm
Country: -

Re: Frsky updates

Post by RCJohn »

midelic wrote: Mon Jan 27, 2020 10:58 am For security reasons yes it is weak. Yes the communication over the air is not secure.That was not the intention.There is no point to encrypt data in order to avoid a potential enemy or a person with nefarious intentions to find out what we send over the air.This is RC world.You can send valid data on an unsecured channel.There are worse protocols than this one in RC world.
May I ask whether you are considering to upgrade your DIY RX to the V2 FW?
No hurry, just would be interested, whether you continue your project, since the last upate was one year ago.
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

No hurry, just would be interested, whether you continue your project, since the last update was one year ago.
One year ago!?
My new RX projects are here.
https://www.rcgroups.com/forums/showthr ... 9-receiver
https://www.rcgroups.com/forums/showthr ... e-firmware

Yes I continued,and I will continue .ABout V2 if will be cracked probably will be added as 4-th protocol on my rx.
Carbo
Posts: 467
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: Frsky updates

Post by Carbo »

midelic wrote: Tue Jan 28, 2020 8:49 amYes I continued,and I will continue .ABout V2 if will be cracked probably will be added as 4-th protocol on my rx.
I will check merciless, if you also manipulate lost frames with your V2 ;) :D
RCJohn
Posts: 12
Joined: Fri Jan 17, 2020 7:23 pm
Country: -

Re: Frsky updates

Post by RCJohn »

midelic wrote: Tue Jan 28, 2020 8:49 am
No hurry, just would be interested, whether you continue your project, since the last update was one year ago.
One year ago!?
My new RX projects are here.
https://www.rcgroups.com/forums/showthr ... 9-receiver
https://www.rcgroups.com/forums/showthr ... e-firmware

Yes I continued,and I will continue .ABout V2 if will be cracked probably will be added as 4-th protocol on my rx.
Right, sorry I misunderstood the FW naming.
I think it would be interesting to work on an alternative V2 FW, together with the MPM project.
CC2500 with enabled on-chip data-whitening, and enabled on-chip CRC, nothing else, then you dont need to crack, have a solid link, and keep the FW lean. If I had your background in the code, it would go for it.
User avatar
midelic
Posts: 128
Joined: Mon Dec 23, 2013 9:57 pm
Country: -

Re: Frsky updates

Post by midelic »

You are taking about a new protocol or frskyV2?If you add on MPM and a DIY RX data whitening + HW CRC it is like new protocol but I think will not be compatible with Frsky V1 or V2.I need to test that.That can be done very easy.Frksy will not like that for sure.
The problem is that I have no interest to help Jumper company to sell more T16.I don't like their marketing practices.
On top of that I think we can have a "better" link(though I don't really believe that is the problem here) without breaking the compatibility with D16.I have some good ideas.I need to do some tests when I get back home to be sure.Moreover my code has already some protection that avoid some probability of pitfalls that were reported.For sure there is always room for improvement.
RCJohn
Posts: 12
Joined: Fri Jan 17, 2020 7:23 pm
Country: -

Re: Frsky updates

Post by RCJohn »

I mean a new protocol, taking advantage of all CC2500 implemented HW features. It would be limited to the CC2500, but thats enough.
I agree there are ways to a certain limit to improve the link without breaking the compatibility.
Do you talk about LBT or generally?
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Frsky updates

Post by Kilrah »

midelic wrote: Tue Jan 28, 2020 1:05 pm Frksy will not like that for sure.
What FrSky does not like is people using their D8/D16 protocols, so there's no reason they wouldn't like it if someone who has hadware for both a TX and an RX designed their own protocol to use instead of theirs.

Unless they do not like any competition at all, which is totally possible given the history with Crossfire.
User avatar
jhsa
Posts: 19480
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: Frsky updates

Post by jhsa »

Kilrah wrote: Tue Jan 28, 2020 2:02 pm
What FrSky does not like is people using their D8/D16 protocols,
I don't agree. They never complained about the MPM before as far as I know. Only after it became a commercial thing by being sold installed internally inside the Jumper radio.
As far as I know, Frsky even released the D8 protocol to the open source community a few years ago.
So, if they didn't like people using their D8 protocol, why would they do that? :o
You are just trying to find excuses to blame Frsky for everything bad that happens in the RC world at the moment.
I have nothing to do with them, and i don't want to have nothing to do with them or any other company. but I won't keep my mouth shut when people are unfair.
What I can't understand is why and how Pascal, the Multi Module developer, is actually giving direct support to the Jumper radio, unless...... :( :? :roll: and I keep the rest of the sentence for myself, but you know what I mean.

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

Post Reply

Return to “erskyTx (was ersky9x)”