The Suspected Frsky GUID Issue

[Phil_G]

I believe I have eliminated the memory issue in a couple of ways:
- I had one 7 channel one way receiver still in the original package, so it was a binding virgin. When bound to the 8103 only the 6102 will operate it.

You bind it to one transmitter and only the other will operate it? Up until then I was thinking its almost as if the rx is storing previously bound guids as well as the currently active one, but to bind to one module then operate only to another is very strange behaviour
Intriguing.
Cheers
Phil

[funtana]

Phil i think you have slightly mis read that last post, when that new receiver is bound to the 8103 only the 6102 will also operate it, i think your taking it as when bound to the 8103, only the 6102 will operate it, if that was the case then we would really be in the deep shhhhhh

[indyjem]

Poorly worded on my part i guess. Receiver was bound only to the 8103 with a two way hack (DHT) module, bound and worked fine. Turn off the 8103 and turn on the 6102 with a different DHT module and it works with it as well, but never bound to this module, so no chance of memory from a previous bind. I assume to the receivers these two modules are the same entity, the question is do they have the same 24 bit GUID, or are the one way receivers only using 16 bit's of the unique 24 bit, and in truncating it eliminating the uniqueness. Receiving these at separate times really bothers me, odds are there are more than two out there, or I need to be buying lotto tickets because I am so lucky.

[karolh]

It would be an intresting exercise to see if that problem could be duplicated using those same two Tx's but with two way Rx's.

Karol

[indyjem]

Agree, wish I had one, but I just have a bunch of one way receivers. I just went to the DHT modules to get GUID security, who knew!!! I think the two way test would go a long way to answer if the one way reciever truncate the 24 bit GUID and may cause an issue with 2 way modules.

[SteveM]

With regards to DHT...... moved to this module for same reason as indyjem (the promise of unique guid).....have 3 receivers already installed in aircraft that I would hate to lose, and 8 awaiting installation (mix of V8Fr/D8R's)
-
Please keep the momentum going on this thread...... obviously feeling uneasy about this whole issue once again, as I am sure many of you are.
-
Seem to remember Bruce was trying to source some kind of analyser to attempt to clarify things.
-
Rgds, Steve

[SteveM]

Eva's response on RCGroups:-
-
"ID of DFT/DJT/DHT is encoded one by one and stored in a seperate chip, I consulted with product engineer and he guess the reason would be either chip fault or ID storage fault. We have been in contact with indyjem, and he will post the two units back to us for further inspection immediately."
-
Steve

[RobC]

Isn't the GUID displayed at the start of the firmware update process? My DFT module came with a lead, does the hack module? If so, could Indyjem run the firmware upload as far as displaying the GUID? This would be a quick way to confirm whether or not it is an issue with 1-way/2-way combinations without waiting for FrSky.

[SteveM]

I emailed (Chase Wu) with regards to whether the DHT module used the whole 24-bit GUID in both modes.
-
The response was as follows:-
-
"Yes, DHT module uses the same 24-bit GUID in both telemetry and V8 modes."
-
Rgds, Steve

[karolh]

For us lesser mortals who are still using the one way V8 series module and Rx and without incidence, what was the official word if there was ever any, or what is the concensus of opinion in regards to the alledged conflicting GUIDS.

Karol