Official Futaba 6EX, 7C and TM-7 Service Advisory

[Julez]

	Quote: Originally Posted by 1bwana1
	Julez, Are you saying that Futaba's engineers have confirmed that the GUID can be changed by user action as you reported, or just the fact that some units have a ZGUID?

In the robbe statement, there were listed the issues with ZGUID TXes from the production, and that they "recieved reports about TXes losing their GUID when their battery gets depleted. Tests by robbe and Futaba cannot confirm this."

However, they refer to the problem list by "that problem" so I guess they mean that Futaba's engineers know why the GUID can be changed, and they are doing something so that the GUID cannot be changed any more.

Well, lots of guesses here, at least partially. But I think we should not weigh each word, and take it with a pinch of salt.

At least robbe says that "further details will be published during the next days".

Cheers,

Julez

[DR10044]

I just received a call from Futaba that my 6ex checked out ok, 3 day turn around, including shipping days, not bad. They also said that they wanted to reimburse me for my shipping, which they did. I plan on keeping the invoice showing the transmitter has been checked in my flight box, there is one that I always take with me to the field or any place I fly.

Also, if any receiver ever comes unbound, the transmitter and receiver will be shipped immediately back for service. Since this is never supposed to happen, it is only common sense.

I have been flying 4 different planes with this transmitter. Well over 300 flights, maybe closer to 450. I know 1 plane has over 200+ plus flights. I stopped counting it was so many. It has been a great system so far.

I just received my 12FG 2.4 from Tower a couple of weeks ago. This new system will be used on all my gassers.

[XJet]

	Quote: Originally Posted by Howie
	I'm sure all your embeded designs are flawless and you have never experienced any unexpected errors or consiquences.

Dang, you've been spying on me haven't you? :-)

	Quote:
	It may have nothing to do with the design. It could be related to a batch of components that are out of spec. I have experienced exactly that in one of my designs and it was a devil to track down. (Related to one batch of EEPROMS from one manufacturer.)

No, it's a design issue. The GUID should *NEVER* have been placed in EEPROM, that is a very bad design choice.

The GUID should be in OTP ROM so that it becomes immutable once set.

[Panzlflyer]

surely theres more data than the GUID on the eprom...what else goes missing if it is reset/erased?

[qmulus]

	Quote: Originally Posted by XJet
	Dang, you've been spying on me haven't you? :-) No, it's a design issue. The GUID should *NEVER* have been placed in EEPROM, that is a very bad design choice. The GUID should be in OTP ROM so that it becomes immutable once set.

That method is not at all common from my experience in the automotive and cell phone industries. IF an OTP processor is used, which is NOT common these days in any complex product, EEPROM is still used to hold serial numbers, VINs or immobilizer information in automotive products, and EINs, etc. in cell phones. This method is used for critical data in MILLIONS of products with a statistically insignificant number of issues. In general, these days EEPROM is used both for program data and data that is usually programmed secondarily once a product is tested and set up for specific markets, etc. These products, automotive especially, have code to verify data integrity and disables a device (like in the case of a critical safety device like an airbag controller) and/or sets a error alerting that there is a problem. If done properly, there is nothing wrong with using EEPROM for this type of data.

FWIW, I own a 6EX FASST, which does not (yet anyway) have the problem and will send it in for reprogramming, if that is indeed the issue, when and if they announce the fix. So far I am satisfied with Futaba's quick reaction and response to the issue and will continue to fly the FASST system.

I would also add that while it is fun to guess what is going on and what MAY be the actual issue and even how the equipment actually works, the only people that REALLY know what the issue is is Futaba. The rest of us are just a bunch of guys that just have enough knowledge to be dangerous and anything written here should be taken with a grain of salt, no matter how compelling it may seem.

[NormS]

	Quote: Originally Posted by qmulus
	That method is not at all common from my experience in the automotive and cell phone industries. IF an OTP processor is used, which is NOT common these days in any complex product, EEPROM is still used to hold serial numbers, VINs or immobilizer information in automotive products, and EINs, etc. in cell phones. This method is used for critical data in MILLIONS of products with a statistically insignificant number of issues. In general, these days EEPROM is used both for program data and data that is usually programmed secondarily once a product is tested and set up for specific markets, etc. These products, automotive especially, have code to verify data integrity and disables a device (like in the case of a critical safety device like an airbag controller) and/or sets a error alerting that there is a problem. If done properly, there is nothing wrong with using EEPROM for this type of data. FWIW, I own a 6EX FASST, which does not (yet anyway) have the problem and will send it in for reprogramming, if that is indeed the issue, when and if they announce the fix. So far I am satisfied with Futaba's quick reaction and response to the issue and will continue to fly the FASST system. I would also add that while it is fun to guess what is going on and what MAY be the actual issue and even how the equipment actually works, the only people that REALLY know what the issue is is Futaba. The rest of us are just a bunch of guys that just have enough knowledge to be dangerous and anything written here should be taken with a grain of salt, no matter how compelling it may seem.

I’ve followed this string with a lot of interest as I intend to purchase a TM-8 module for my 9C, assuming they ever get around to shipping it. I’ve found a lot of good information and comments but I think you’ve all missed a couple of points.

First of all, two (or more) FHSS systems could have the same GUID and not interfere with each other, as long as they are turned on at different times. The two transmitter/receiver pairs will each hop through the same sequence of frequencies since the exact sequence is in fact determined by the GUID, but they will never both be on the same frequency at the same time since they were turned on at different times and can not be in sync with each other. (There is an infinitesimal chance that they are in “hop sync” if the second transmitter was turned on just as the first one started to repeat the sequence, but it’s a very low probability thing and would not be repeatable.)

As I mentioned above, the frequency hop sequence is determined by the GUID, which is one of the reasons that the receiver needs to be bound to the transmitter. The binding operation just gives the receiver the transmitter’s GUID, and the two of them run the same process to determine the hop sequence. This process treats the GUID like a binary polynomial and runs it through something call a linear feedback shift register (LFSR), or runs a software algorithm that is equivalent to an LFSR. FYI, a binary polynomial is a long string of 1’s and 0’s; the GUID is just the decimal representation of the polynomial.

The thing is, this entire LFSR approach relies on the fact that the binary polynomial (the GUID) always has at least one 1 in it. If the polynomial consisted of only zeros the LFSR output would never change, and the transmitter/receiver would never hop at all. Now, if two transmitters both have all zero GUIDs they will never hop and will clearly interfere with each other since they will always be on the same (base) frequency. Since there seem to be several cases of interfering transmitters and since only transmitters with all zero GUIDs can reliably interfere with each other, the transmitters almost certainly have an all zero GUID.

I’m an engineer. I have an RF and embedded microprocessor background (hardware and firmware) and I’ve worked on products that have literally shipped in the millions of units all around the world. All of these products had EE or FLASH devices in them and these things do not just lose their data because you power them up and down. They are susceptible to data corruption if there’s a power loss during a write (or erase) operation, but never if they’re quiescent or only being read.

I can’t think of any reason that the transmitter would ever try to write into the GUID device. Bear in mind that the problem has been reported in the TM-7 modules, where the GIUD is clearly held in the module and where the transmitter can not be trying to write into it, so fiddling with the power switch is unlikely to have caused the problem.

So, how did the transmitters’ GUIDs end up as all zeros? In my opinion they were probably shipped that way from the factory. This is clearly a manufacturing process and QA failure but something that should be very easy to address. The only design issue I see here is that the receiver firmware should have been written to check for a valid GUID and not bind to a transmitter with an all zeros code. This would have left the owners with non-functional systems but would not have caused any other problem. Sorry for the long post.

[XJet]

Norm, one thing to remember is that the EEPROM writes are usually page-based and the transmitter does periodically update the timer-count data in that memory.

I suspect the sequence is:

read EEPROM page
update timer count bytes
write EEPROM page

Now, if for whatever reason, the EEPROM page being worked on also contains the GUID, an interruption to the power during the write operation could cause it to be corrupted.

As for the module -- I'm not sure that we've actually seen any reports of the GUID in these being corrupted in the field -- although there are plenty of reports of such corruption occuring the 6/7 transmitters. As far as I'm aware, the only zero GUID module was one found in a supplier's stock (although I may be wrong).

A much better option than storing the GUID in EEPROM (for obvious reasons) would have been to store it in the microcontroller's program-memory when the device is flashed or otherwise programmed.

Your comments inrespect to the lack of frequency hopping with a zero GUID is interesting and actually raises another important issue -- an increased susceptibility to interference for transmitters running with a zero GUID.

A high noise-level/interfering signal on that segment of the band could compromise the RF link in a way that would not happen if the units were actually frequency hopping with a non-zero GUID.

[1bwana1]

NormS,
Thanks for the excellent post, I learned some things. We are is solid agreement, that having an immutable GUID is core to the system. I do think we have to look at your statement regarding the TM-7 module having the problem as proof that it had to happen prior to shipping. The module still gets it's power from the main TX, so whatever is happening on the chip as regards to power issues could still affect the chip in the module. This could still cause the GUID to change. The point is, that Futaba must be certain that the GUID cannot change during the life of the product, or that the system refuses to operate if it does.

I also wonder how Futaba can be so certain that the other products (like the 12) cannot have the problem. Since Futaba claims they can't reproduce it, they can't know where in the system it is happening. If the did know where it is happening, they could make that statement based on knowing that the other systems don't use the same parts or have the same design. They either know things they are denying, or are relying on the fact that it hasn't happened to one of those yet, so apparently it can't. The later is not valid thinking, so I am hoping it is the former.

[NormS]

XJet and 1bwana1, thanks a lot for your comments.

I wasn’t kidding when I said that I’ve worked on products that shipped millions of units. Among other things I designed a series of Ethernet adapters for PC’s that shipped roughly 100,000 – 200,000 units a month, for several years. All of these cards had unique Ethernet MAC addresses on them in a FLASH or EEPROM, and I never heard of any issues concerning data corruption. Some of the more expensive cards wrote etherstat MIB information to the FLASH on a fairly regular basis, and none of those devices ever got corrupted to my knowledge either. I have seen issues in the lab during development where we managed to inadvertently get a couple of adapters with the same address on a network, which totally screws things up. Believe me, we would have heard about it pretty quickly if this happened in the field at a customer site.

I really believe that we’re seeing a manufacturing problem here rather then a design issue. The fact that a TM-7 module in somebody’s inventory exhibited the problem lends credence to that argument, since the module was probably never installed in a transmitter. Nevertheless, Futaba probably could have done a better job and designed the system to survive this obvious a problem.

[gareth.ky]

If they had used an actual GUID it wouldn't have been a problem. They used a much shorter ID so they had to be responsible for tracking the numbers used. Much the same system is used for MAC addresses. Every Ethernet adapter in existence has a unique code (MAC Address) on it thats not a GUID. Manufacturers have to keep track of this. Thats why I was kind of surprised they couldn't pinpoint the serial numbers of the affected transmitters, because they should have kept records for the above reason.

It seems fairly obvious this is manufacturing quality control issue.

No one can see the ID in the radio so no one really knows that the ID has been set to "all zeros". Someone just said they thought that was happening. I wont speculate on the hundreads of ways that might happen. Futaba have said they can't duplicate the issue. It's quite possible it just doesn't exist.

Get your radio tested and then go fly.

[Julez]

	Quote:
	No one can see the ID in the radio so no one really knows that the ID has been set to "all zeros". Someone just said they thought that was happening.

Obviously, the german Futaba distributor thinks likewise. At least, they state that new, unbound RXes have the ZGUID by default, and recommend to test your TX with one of them, to see if it is affected.
Two german users depleted the battery in their 7C, and it has lost the ID. Both affected TXes worked with new ZGUID RXes.
Thus, the conclusion, that affected TXes actually have the ZGUID and not some random, different GUID, is clearly more than just a thought. :-)


BTW, one very good posting:

http://www.rcuniverse.com/forum/fb.asp?m=6959035

[Zrakoplov]

	Quote: Originally Posted by 1bwana1
	... I also wonder how Futaba can be so certain that the other products (like the 12) cannot have the problem....

First of all I'd like to say that while we all know these are unoficial speculations, I have read many interesting opinions, and definitely learned a few new things. The amount of technical knowledge in the RC community is part of the fun and one of the reasons why I enjoy this hobby so much.

Bwana, regarding the tm-14 I've read somewhere (I'm looking for the link, but I've read so many information in the last couple of days that I can't remember where exactly I saw it) a claim that the new software for the 12 and 14 ch TXs are able to test the module for the ZGUID and would display an error if found.

I hope I can find the info and post the link soon.

I'd like also to point out that the official advisory on futaba's website has been updated with some new info regarding the testing of the units.
http://2.4gigahertz.com/techsupport/...m7-7c-6ex.html