RC Model Reviews

Posted: **Thu May 19, 2011 8:31 am**

I suspect the 2-way system is using a 16-bit packet-based GUID plus the 8-bit address field intrinsic to the CC2500 -- for a total of 24 bits.

It's possible that the 1-way uses only the 8-bit address field and another 8-bit field within the data packets defined by the FrSky firmware.

The 8-bit address field is probably randomized so as to reduce the chances of two FrSky systems encountering signal collision during operation.

I'll be using my logic analyzer to take a close look at the FrSky system in the coming week or so and that should provide a definitive answer in the absence of any input from FrSky themselves.

If Needs be, I'll knock up a GUID-reader using a FrSky receiver as the front end so that the GUID of any transmitter can be read and displayed.

Posted: **Thu May 19, 2011 8:32 am**

pchewn wrote:We are collecting our FRSKY UID numbers into a list to find potential conflicts.

Please participate if you use FRSKY. See here: http://www.rcgroups.com/forums/showthread.php?t=1441839

Thanks pchewn
Great Idea, I only wish there was a simple way to obtain and report the UID for the non-telemetry modules also.

7SP

Posted: **Thu May 19, 2011 8:43 am**

RCModelReviews wrote:I suspect the 2-way system is using a 16-bit packet-based GUID plus the 8-bit address field intrinsic to the CC2500 -- for a total of 24 bits.

It's possible that the 1-way uses only the 8-bit address field and another 8-bit field within the data packets defined by the FrSky firmware.

The 8-bit address field is probably randomized so as to reduce the chances of two FrSky systems encountering signal collision during operation.

I'll be using my logic analyzer to take a close look at the FrSky system in the coming week or so and that should provide a definitive answer in the absence of any input from FrSky themselves.

If Needs be, I'll knock up a GUID-reader using a FrSky receiver as the front end so that the GUID of any transmitter can be read and displayed.

That's great news Bruce, If you could work it out and publish how to hack together a receiver to spit out GUID's seen and log it some way. I'm sure that there are some people that would be more then happy to sacrifice a receiver to have a scanner for personal, groups or club use.

7SP

Posted: **Thu May 19, 2011 8:49 am**

SteveM wrote:Please advise the feedback gained from Frsky, with regards to the two original modules in New Zealand.....did they ever state they were duplicated?
-
If they never officially responded, I wonder what chance we have of determining the cause of indygem's issues.
-
Steve

Steve,

I am one of the two that clashed in New Zealand.

I was told the offical (sorry, i don't have a link), but from the official dist here in New Zealand that FrSky were/are using random GUIDs for the 1 way modules. This means (ignoring 0 guids and other things) you have a 2^16 chance of a clash with another random GUID.

Maybe Rob or Bruce have a offical link, but the above is what I know as the customer that had the problem.

EDIT: And yes, it was confirmed that had the same GUID.

Posted: **Thu May 19, 2011 4:10 pm**

Guys, pardon my ignorance but what does a GUID having a 2^16 chance of conflicting mean.

Karol

Posted: **Thu May 19, 2011 6:48 pm**

The chance of a 16 bit binary ID number being duplicated is 2 to the power 16. In ASCII characters that's 2^16 or 1 in 65536

Posted: **Thu May 19, 2011 7:37 pm**

IMHO: I'm not sure what good repeating the 2^16 does for anyone except confuse the issue because it really does not apply to the real world and is only meant to be used for mathematical theory.

That is unless someone can verify the the random number seed used and repeat the sequence...
That is unless someone can verify that only one station generated all the the numbers for all the modules ever built.
That is unless someone can verify that the station used to generate the numbers was never restarted or reseeded..

7SP

Posted: **Thu May 19, 2011 8:50 pm**

Kozmyk wrote:The chance of a 16 bit binary ID number being duplicated is 2 to the power 16. In ASCII characters that's 2^16 or 1 in 65536

This explanation is good enough for me.....thanks.

Karol

Posted: **Thu May 19, 2011 8:54 pm**

SteveM wrote:Attn Lplus,

The exact content of my email sent to Eva was as follows:-
--
-
"Eva.... does this mean that the DHT module uses the same 24-bit GUID in both telemetry and V8 modes??
Or...... is it only using a 16-bit portion of the 24-bit GUID when switched to V8 mode??
-
Please can you clarify this accurately.
-
Many tks, Steve"-
--
Her response was as per my previous post, that 24 bits used in both modes.
As to what extent there was a mis-interpretation of my/her wording, I cannot tell.
-
By all means contact Eva on evafrsky@gmail.com and sales4tech@gmail.com....I really think the more pressure put upon Frsky, from as many concerned users as possible, the better.
-
I am sure that there are 1000's of Frsky users worldwide that are blissfully ignorant of these forums/threads discussing this issue.
-
I am going to visit a friend tomorrow who sourced his DHT module from the same place as myself, in the UK, a few days after I purchased mine.
-
Presume the dealer would have been supplied some from a sequential batch....will chk if mine/his interact, and let you know.
-
Steve

So the transmitter module sends out an id using 24 bits for both 1 and 2 way, fair enough, my question was whether the receiver can identify all 24 bits or does it discard some information.

Maybe it has to accept it all and use it, I don't know, but I'm sure that sort of query has been voiced before

Posted: **Thu May 19, 2011 9:44 pm**

Lplus wrote:
SteveM wrote:Attn Lplus,

The exact content of my email sent to Eva was as follows:-
--
-
"Eva.... does this mean that the DHT module uses the same 24-bit GUID in both telemetry and V8 modes??
Or...... is it only using a 16-bit portion of the 24-bit GUID when switched to V8 mode??
-
Please can you clarify this accurately.
-
Many tks, Steve"-
--
Her response was as per my previous post, that 24 bits used in both modes.
As to what extent there was a mis-interpretation of my/her wording, I cannot tell.
-
By all means contact Eva on evafrsky@gmail.com and sales4tech@gmail.com....I really think the more pressure put upon Frsky, from as many concerned users as possible, the better.
-
I am sure that there are 1000's of Frsky users worldwide that are blissfully ignorant of these forums/threads discussing this issue.
-
I am going to visit a friend tomorrow who sourced his DHT module from the same place as myself, in the UK, a few days after I purchased mine.
-
Presume the dealer would have been supplied some from a sequential batch....will chk if mine/his interact, and let you know.
-
Steve

So the transmitter module sends out an id using 24 bits for both 1 and 2 way, fair enough, my question was whether the receiver can identify all 24 bits or does it discard some information.

Maybe it has to accept it all and use it, I don't know, but I'm sure that sort of query has been voiced before

I can logically see that it may accept it all and discard the extra bits, but use them that is another matter. It would have required them to have foreseen the problem or meant that it was originally designed for 24 bits and they butchered the code because they mistakenly thought they would never need that many bits.

7SP

RC Model Reviews

The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue

Re: The Suspected Frsky GUID Issue