The Suspected Frsky GUID Issue

[Heather]

While the problem is known

So is it a manufacturing fault or a design flaw? Were the suspect Tx modules sent back to the manufacturer to confirm the cause?

Heather

[RCModelReviews]

FrSky have already confirmed the *possibility* of a clash, albeit a very small one.

This leaves two potential situations:

1. there was a legit clash and both radios had the same (non-zero) GUID

2. there was another issue which set the GUIDs of these two systems to zero (quite possible -- as we know, interrupted EEPROM writes in microcontrollers can cause data-corruption/loss -- that's how the Futaba zero GUID situation came about and it's also why JR and some Spektrum radios develop the infamous "Backup Error" message if the power is disconnected while they're shutting down.

It would appear that if it's a design error, FrSky is in some very elite and well-heeled company

But, as LV Martin used to say "It's the putting right that counts".

[SteveM]

Just a thought, and maybe I have this totally wrong, but what I am trying to understand is the following......
It has been suggested that the GUID may somehow be used to determine the frequency hopping order throughout the 2.4GHz spectrum.
If this is the case, even if duplicate GUIDs existed, surely it must be virtually impossible for any two flyers to be hopping absolutely "in sync", considering the sheer speed these frequencys are changing.
-
Watching with interest, as about to slowly migrate all 9 x aircraft/helis over to Frsky 2.4.
-
Steve

[kneedrag]

So I have been asked to send the customers units back to FrSky. Seems the initial look into it has revealed nothing and the actual units which caused the issue need to be looked at.

I am sending replacement units to the customers and will be sending the units causing the issue back to FrSky. The one unit is a DIY module so I will not be rushing the customer to pull his tx apart and let him do it in his own time. Will update once FrSky have the "culprit units".

[Ken Henderson]

So I have been asked to send the customers units back to FrSky. Seems the initial look into it has revealed nothing ......

Does this imply that there is no fundamental design related issue i.e. FrSky TX´s do not use a 16 bit pseudo random allocated GUID after all?

[indyjem]

While this does not worry me too much, as at my flying field I believe I will be the only Frsky flier, my three converted transmitters (1 JR mod, 2 DYI) do not step on each other, and I rarely attend significant events. I do feel we need more info from Frsky, and it should be available at this point:
- Is the GUID 16 bit? I have seen 24 mentioned elsewhere.
- How is it assigned? Random (multiple assignments possible) or sequential
- Is 24 bit possible? IF so can it be re-flashed? Or with the extra digits could a Julian date be inserted, in which case a 64 bit number following would surely be unique.

I am not sure about the statement that investigation to date has shown nothing, surely they know bit length and generation method, sharing that would help everyone understand how remote the possibility of conflict is.

[aesmith]

If its only 16 bit then that's a bit worrying, as pretty soon they'll be running out of numbers whether sequential or random. I guess they could go to a longer length but that would not be compatible with existing receivers. I note their comment that the two-way sets are not vulnerable to the issue, so I wonder if they use a longer code.

[indyjem]

Is there any information from frsky yet?

[RCModelReviews]

I have heard nothing -- but nor have I heard of any other ID clashes. I believe the equipment in question is being returned to China for inspection.

[kneedrag]

That is correct, I have sent replacement units to the two people with the issue, I am just waiting for the suspect units to be returned and then I will be sending them back to FrSky for a look.