The Suspected Frsky GUID Issue

[kneedrag]

I have been having a long discussion with FrSky around this.

First off all I have been assured that the Telemetry units have Unique GUID's which do not overlap with the V8 GUID's and they will never overlap with each other.

The V8 Units however run on a bit of a weird system.

The GUID are assigned by the sounds of it randomly at the factory in a certain range. Which is why they can not tell us how many share a GUID at this point. Then there is the channel mapping. The 2.4Ghz band has been divided up into 250 channels. Then FrSky will use 50 of those channels. Each unit has a random channel mapping routine at startup which is meant to ensure via a random type calculation that if there are two units with same GUID that they don't end up on the same channels.

However as the two guys here have found there is a bit of a flaw in that as it seems it can overlap.

Seeing this is the first occurrence of this happening FrSky have rightly so requested the units back for analysis to see how big a problem this is esspecially seeing this has been the only recorded case of it happening. If someone else has had this happen to them I would like to hear about it and I am sure FrSky would as well. It may well be that there is something else causing the conflict and there random logic routines are in fact sound. However in theory the GUID sounds the most plausible, so FrSky correctly so want to work with solid evidence rather than working on assumptions. However are not closed to the fact that the GUID most likely is an issue and are in the background looking at ways to correct it if it is proven to be the case. Firmware flash updates or something along those lines may be part of the solution or there may be an easier way they are looking at it.

Unfortunately I am still waiting the one unit to be returned to me so I can package them up and send them to FrSky.

I also asked FrSky about the possibility of them building a unit to detect the GUID's for conflicts at the field. Which in turn can be used to get the units re-flashed with a new GUID. They have indicated that they are looking into that possibility and are best trying to figure out a way to reset GUID's without causing further conflict.

However a lot rests on these two units being analyzed. I have e-mail the user that still needs to send the other unit back however I have not had a response yet. Being the holiday period here in NZ I will e-mail again next week when the majority of people get back from leave to see where the other unit is.

I will let you know as soon as I have received the other unit in question and as soon as I get feedback from FrSky on the analysis I will let you know.

So in short if you want to be assured of a Unique GUID the Telemetry system is your friend.

Until then if there is a new FrSky user at your club double check your systems before flying. From the testing I did at the flying if they have not conflicted in the first 4 power on power off cycles then they are safe. The two units in question had a 3 in 5 chance roughly of taking each other out so it was a high chance and almost guaranteed. So if you have been flying with your buddies and never encountered this then you will be fine. It is the new units the the field you need to watch out for.

[7sp]

I am still waiting for response to questions sent to Frsky and would like to give them a chance to clear this up officially, but I'm not happy about the responses so far. Directly from FrSky.

"Our engineer have changed the software ,in the new products ,the ID can be changed by holding the programming button for more than 8 seconds ."

This means that once we have verified with all the people that we fly with normally that we have no conflicts. Any day, at any time, any one of them can decide that they want to change their GUID and once again we all have the possibility for a new conflict. To me this is the modern version of the old "Dial-A-Crash". (Worst even because at least with Dial-A-Crash we could physically look at the guys transmitter and see that it was set to the wrong frequency and that he had the wrong frequency pin checked out)

This is not even taking into account that we have no control of the guy sitting in his living room 1 block a way from the flying field that assumes it's ok to turn on his Frsky transmitter because he's on 2.4Ghz and has been lead to believe that you don't need any type of frequency control. At least with 72Hhz there was the expectation and understanding that you must do frequency control and had the channels clearly marked. In the 2.4Ghz world it been assumed, because it's been promoted by the manufactures that you do not need frequency control. What is even worst is that nothing is marked on 2.4Ghz and in most cases the average users don't even have a way to determine what GUID you or others are using. I can see the writing on the wall... every time a user "thinks" he has been hit or something happens out of the ordinary he will stand on the button for 8-seconds and change his GUID, starting the whole gambling match again.

It is beyond my logic why they do not simply use a true GUID and solve the problem. We have plenty of numbers in the world more then enough that everyone can have their own. In my opinion so far anyway, FrSky's FHSS: Good concept, failed implementation.

Here is some free engineering http://en.wikipedia.org/wiki/Globally_unique_identifier and the solution when implemented correctly. It's used every day by countless systems, networks, applications and others.

7SP.

[kneedrag]

"Our engineer have changed the software ,in the new products ,the ID can be changed by holding the programming button for more than 8 seconds ."

This is not good in my opinion and I will let them know if this is the case. However I suspect they are copying the way Corona does it as a solution.

Will bring this up with one of my chats with FrSky.

[funtana]

This is not good is a bit of an understatement, if's thats the quick fix solution there so called engineers can come up with then my faith in the system has been damaged beyond repair, time i started unloading.

[FrankS]

This is a bit disturbing if it is true, FRSky are implementing some changes, not neccesarily for the better, but haven't yet examined the units in question. Or do they know something that they are not letting on. It's a shame I am impressed by the system and its been faultless so far, but I couldn't trust using it in a fly-in as there is now the possibility that a another user could reset the GUID after you have checked that there is no interference on your set.

[gruvin]

It's actually better than the previous situation though. I mean, if (GU)IDs were being assigned randomly in the first place, then having the ability to do that again if needed is in fact an improvement. But of course, "randomly" assigning the codes at any time was never a good idea in the first place. Might have been OK if Murphy had made himself better known to the Chinese. But why would he want to give them the heads up?

As far as the two-way systems go (which I use and very much like); my understanding, combined with a little educated guess work, suggests that the two-way modules do not have true GUIDs etiher -- if any at all. I believe the reason they are able to, "never conflict" is entirely due to the way both the receiver and transmitter can spy on the air waves before setting themselves up, and presumably also (more importantly) change IDs/channel-sequence mid-flight if too much noise is heard, since they can talk to each other to organise it. (That system worked for 40 years with CB radio folk -- and they only have 37 spare channels! )

Well, that's how I'd do it anyway. In fact, I'd bet money that the, "can never collide" claim is due to a clever two-way handshaking protocol and NOT linked to any upgraded GUID system, at all. And this, if true, would be a very GOOD thing, IMHO, since it effectively eliminates the whole (GU)ID issue altogether, like it always should have been (but couldn't be in a one-way scenario).

Incidentally, the GUID thing is supposed to be only a back-stop. The channel hopping algorithm is the principal means of keeping off each other's tails (and is linked in part to the (GU)ID for that reason.)

*shrug* Who flies even tiny indoors air craft without telemetry these days anyway? :O)

[7sp]

Sorry I can not see how it's better to knocked out of air by a user generated random GUID then by a factory generated random GUID?

One other thought on this matter. We keep hearing how the telemetry modules are not affected and we keep hearing from the guys using the telemetry modules that they seem to be thinking everything is A-OK because it does not affect them. Well for those not using the telemetry modules yet this problem has the potential of being major issue and the lack of information and support from FrSky so far on this matter should be alarming to you as well.. It may not directly affect you today, But lets keep in mind the current level of concern and support that Frsky is showing in this matter is the same level of support that you can expect to receive tomorrow if or when a flaw shows up in the telemetry systems.

7SP

[RCModelReviews]

As far as the two-way systems go (which I use and very much like); my understanding, combined with a little educated guess work, suggests that the two-way modules do not have true GUIDs etiher -- if any at all.

I believe they have a 24-bit GUID.

Incidentally, the GUID thing is supposed to be only a back-stop. The channel hopping algorithm is the principal means of keeping off each other's tails (and is linked in part to the (GU)ID for that reason.)

Not so I'm afraid.

Since there's no way to ensure that two systems don't use the same piece of spectrum at the same time, the GUIDs must be different. if it were not for GUIDs then when a band-use collision occurred you would get a glitch.

A 24-bit GUID will be more than ample to ensure no collisions occur. The market really isn't that big

[raptor22]

and hence how ig a problem is this really. I see more than a little grandstanding here over GUID's.

the simple matter to fix is how the factory mnages the random GUID generator and keep record of the numbers is spits out.
When a conflicts arises, simply take the the laetest module with the conflict and re-introduce it into the GUID generating process.

In the mean time a shift to a 24 bit number can be implemented.

Really, espite all the technically superior thinking around this it is not nearly as big a train smash as it is being made out to be. I loked outside and the sky is still up there and not down here on my head.

Come on folks, at the end of the day its a great product at a even greater price and it works.

Did the two planes with the conflict crash? I don't recall but it seems they did not so the system still worked for those two pilots which really is an achievement on it's own.
I have no doubt FrSKY will fix the issue but do you expect them to be sitting down typing emails and Facebooking and MS Chatting with Rc piots around the world or getting on with fixing the problem.

the sky is not falling and neither are FRSKY planes....well yet anyway. Currrently any FRSKY users are probably aware of the other FRSKY users at their local airfields so it is known that there are no issues between those users.

[7sp]

Come on folks, at the end of the day its a great product at a even greater price and it works.

I hate to point this out because it does not help solve the problem, but I could not resist. BTW I also think they have a good product or at least one with great potential.

The above is like saying that the Hindenburg and the Titanic were great ships... It did not stop both of them from going down due to fundamental design flaws.

7SP