The Suspected Frsky GUID Issue

[7sp]

I've also asked Eva to tell us whether this is a newly introduced issue or if it's always been there.

I suspect it's relatively new -- otherwise 2-way systems would have been shooting each other down all over the place when used in 1-way mode.

if that's the case, then if you have a unit that's not affected by the problem, your GUID was already set in the 1-way mode anyway so you didn't/won't need to do the 2-way bind and, if you do, nothing will change but you won't have a zero GUID.

I'm thinking...speculating, One of two things is happening.

1) The current batch just recently sold (Earlier ones not affected) were sent out with a step in manufacturing / QC missed or skipped and some modules were shipped without ever being initialized properly once at the factory.

2) That a lot of people mistakenly (or while playing with new toy) tried to bind their new 2-way modules in two-way mode the first time and then realized that need to set the switches for their one-way receivers. This mistake actually triggered the first GUID change to be locked in and saved them from the current problem.

7SP

[karolh]

If you haven't seen it already, check the front page of the RCModelReviews.com website for an important advisory regarding the latest GUID conflict that has occurred with the FrSky system.

Fortunately, there is an easy fix and it needs only be done once.

Well thank goodness FrSky at last did something right this time around, which possibly might help to repair some of the damage to their corporate image caused by their prolonged silence on the "other " conflicting GUID problem.

Karol

[vh7377]

Can someone please help me understand.

If the GUID is "hard wired", i.e. programmed in the factory, into the Tx module, then how can it change due to switching between the D and V series Rx's?

Or is the GUID still randomly generated on board the module ? and, is subject to change when initialised in different modes (i.e. 1 and 2 way) ?

Hutton

[7sp]

Can someone please help me understand.

If the GUID is "hard wired", i.e. programmed in the factory, into the Tx module, then how can it change due to switching between the D and V series Rx's?

Or is the GUID still randomly generated on board the module ? and, is subject to change when initialised in different modes (i.e. 1 and 2 way) ?

Hutton

The speculation is that the UID used by the V8 RX's is zero until initialized by the first 2-way bind done with the 2-way TX module. Once done the value of the UID used by the 2-way is copied in to a location to be used while operating that module in 1-way mode. So if you had a 2-way TX module, but only have or use 1-way V8 receivers you may have never tried to do a 2-way bind. It's also possible that this is normally done by the factory before shipping and now a few have slipped out without ever being initialized properly so to speak.

Would be nice if FrSky clearly stated that this is the case, but that may be asking to much of them. They seem to enjoy creating confusion and keeping their customers always guessing what went wrong and why. At least this time they made an announcement with a simple fix. For that I give them 10 points, subtracting only 5 for not providing a little more complete information. Will give them back the 5 points when they publish more info along with including and "emphasizing" the importance of this procedure in the standard documentation for the 2-way modules.

7SP

[vh7377]

So now I am even more confused. The modules have the UID set at the factory (or do they?). If that is the case, there should be no way that a RX will work without obtaining that UID from the module (done during binding). If that is 00 00 etc then the only way that the Rx could have got that is from the module. Please help me understand how this happens.

[7sp]

Try it this way. The module always has a valid 2-way UID, but if not initialized properly... TX sends out all 000's for the 1-way UID and then the 1-way RX will bind with the all 000's UID. So if your neighbor did the same thing then you would both have bound with a all 000's UID and have a "coincidence" IE: conflict.

Keeping in mind this is true only if FrSky has NOT lied to us and is really still randomly generating even the 2-way UID and then also copying it into the location for the 1-way RX to use as part of the initialization. Something we could not prove unless someone finds a 2-way TX module that is sending out all 000's in 2-way mode. This would most likely never be found because the first binding would trigger the one time initialization and the proof would be lost.

Does that help?
7SP

[RCModelReviews]

I have had an update from FrSky

The problem is specific to certain batches of the product so if you find you don't need to rebind your 1-way receivers after the first time you enter bind-mode in 2-way configuration then you have a unit that wasn't affected.

It's also worth noting that the ID being read by some building a list on RCGroups is *NOT* the GUID -- it is the chip ID, so that list is a bit of a waste of time. The chip ID and the GUID are not related.

[7sp]

Thanks for the update Bruce,

I think someone mistakenly assumed that the UID and GUID were the same from the FrSky upgrade instruction manual.

"Power up the transmitter. After getting the UID number, click the “Download” button to start the firmware upgrade."

The upgrade applet does report it back as a UID, so I'm sure that is where the confusion started.

7SP

[vh7377]

Does that help?
7SP

Thanks 7SP,

I think it does (a bit). But I do remain puzzled.

It really needs someone to actually read the UID from the signal stream to sort the issue.

Will watch this space a bit longer.

Hutton

[RCModelReviews]

I've just unpacked my new logic analyzer today -- I'll be using the analysis of the FrSky dialog between MCU and CC2500 as an exercise in familiarizing myself with this tool.

That should enable me to see exactly what the length of the GUID is in both 1-way and 2-way modes.