[NSRCA-discussion] Futaba FASST System

Sun Jan 27 09:16:04 AKST 2008

Not criticizing Futaba, as to its procedures ISO or otherwise, but it's even more cynical than this with respect to ISO.  An ISO rating proves little more than at the last audit, the employees interviewed by the auditers were able to satisfactorily respond that they know that a work instruction, procedure or policy that is relative to their job function exists, and how to find it.  There is no inspection of process artifacts to prove whether the procedures etc were actually followed.
Ed

> From: lld613 at psci.net> To: chad at f3acanada.org; nsrca-discussion at lists.f3a.us> Date: Sun, 27 Jan 2008 12:05:31 -0600> Subject: Re: [NSRCA-discussion] Futaba FASST System> > Quote,> "If Futaba is an ISO outfit (which I am sure they are) they also should > be able to easily trace this."> > I wouldn't place a lot of confidence in this...ISO really only means a> company has documented processes that they follow which are established by> the company itself.> > With that said, some companies are better than others in being able to drill> down and trace problems. Futaba may have a good chance. I wouldn't be> surprised if they can't trace the Tx to the Module (ref RVP's e-mail). I> would expect that this testing would have been done prior to production. If> testing for this issue was not in the test matrix in development stages, it> becomes an exposed risk once it's in the field. This most likely explains> the reason that Futaba took the strategy that Chris Hammond referenced:> > " The 6ex, 7c and TM-7 modules are an issue as more and more people are> reporting the ZGUID code. Several hobby shops have the testers now so we> should soon know how wide-spread the issue is."> > To collect the data cost money and will drive cost. The only customers I had> that required traceability were Automotive (QS & TPS), Medical (FDA), DoD,> and High $$$ PCB Assm's (spec'd out by the customer).> > Larry Diamond> > -----Original Message-----> From: nsrca-discussion-bounces at lists.f3a.us> [mailto:nsrca-discussion-bounces at lists.f3a.us] On Behalf Of Chad Northeast> Sent: Sunday, January 27, 2008 11:13 AM> To: NSRCA Mailing List> Subject: Re: [NSRCA-discussion] Futaba FASST System> > Hi Ron> > It should be a simple matter during manufacture to assign a code against > that particular products serial number, whether that be module or tx > etc. Any modern day PDM software can easily handle this.> > If Futaba is an ISO outfit (which I am sure they are) they also should > be able to easily trace this.> > Basically this would be a question for Futaba's QA department :)> > Chad> > Ron Van Putte wrote:> > Let me play devil's advocate. If the FASST transmitters have the > > unique code in the transmitter and ordinary transmitters with a FASST > > module have the code in the module, does Futaba keep track and make > > sure that a FAST transmitter with the unique code in the transmitter > > and a FASST module with the code in the module won't have the same code?> >> > Ron Van Putte> >> > On Jan 27, 2008, at 10:26 AM, John Pavlick wrote:> >> > > >> That makes sense. The only problem is you can't assign this code > >> yourself> >> even if you could see what it is and you DID find that it was re- > >> set to> >> 0000. Not a good thing. Kinda defeats the whole purpose of using > >> 2.4GHz in> >> the first place. Another brilliant accomplishment for "Dr. Murphy"!> >>> >> John Pavlick> >> http://www.idseng.com> >>> >> ----- Original Message -----> >> From: "Chad Northeast" <chad at f3acanada.org>> >> To: "NSRCA Mailing List" <nsrca-discussion at lists.nsrca.org>> >> Sent: Sunday, January 27, 2008 11:11 AM> >> Subject: Re: [NSRCA-discussion] Futaba FASST System> >>> >>> >> > >>> On the 14 (and I think the 12) the code is in the TX not the > >>> module, and> >>> is I think visible to the user, but I am not sure where.> >>>> >>> On the TM-7 (and probably TM-8) the code is in the module which is > >>> where> >>> the problems occur as you have no way of identifying you have a > >>> default> >>> code. Then you re-bind your rx and now its default as well....so > >>> anyone> >>> that has a default code can now shoot you down.> >>>> >>> I don't believe there is a guarantee that you will reset the code by> >>> re-booting your tx within 5 seconds...but the fact you cannot see > >>> if a> >>> problem was caused is the reason for the precaution. I think > >>> anyone who> >>> has to re-bind a rx that has already been bound, should have a few ??> >>> dancing through their head and send the system in to ensure its> >>> operating properly.> >>>> >>> Chad> >>>> >>> John Pavlick wrote:> >>> > >>>> Ron,> >>>> Great question. One way to find out would be to find someone who > >>>> has> >>>> screwed up their FASST system Tx (re-initialized the ID to 0000) > >>>> and see> >>>> if> >>>> your Tx controls their Rx too. I'm thinking that the ID that we're> >>>> concerned> >>>> about is stored in the FASST module NOT the Tx itself though. > >>>> Think about> >>>> it. You can put a FASST module in a 9Z. When the 9Z came out, > >>>> 2.4GHz was> >>>> only popular in car radios. It's very unlikely that the 9Z has a > >>>> unique> >>>> ID> >>>> assigned to each Tx. I could be wrong but I bet the ID is > >>>> embedded in the> >>>> module NOT the Tx itself. One way to verify this would be to take 2> >>>> identical FASST systems that are working correctly (i.e. each one> >>>> controls> >>>> it's own Rx) and swap Tx modules. If they now control the "other" > >>>> Rx then> >>>> the ID is embedded in the module.> >>>>> >>>> Unfortunately you still can't verify that your module / Tx / > >>>> whatever has> >>>> not been re-set to ID 0000 unless you have a known "bad" system. > >>>> What a> >>>> bummer. The ID should be completely non-volatile, not stored in > >>>> EEPROM or> >>>> Flash. I guess Futaba doesn't use Maxim / Dallas ID chips.> >>>>> >>>> John Pavlick> >>>> http://www.idseng.com> >>>>> >>>> ----- Original Message -----> >>>> From: "Ron Van Putte" <vanputte at cox.net>> >>>> To: "NSRCA Mailing List" <nsrca-discussion at lists.nsrca.org>> >>>> Cc: "Mel Duval" <duvalj at cox.net>> >>>> Sent: Sunday, January 27, 2008 10:29 AM> >>>> Subject: [NSRCA-discussion] Futaba FASST System> >>>>> >>>>> >>>>> >>>> > >>>>> I've been thinking about the problem that occurs with the Futaba> >>>>> FASST system when the owner turns on the transmitter and turns > >>>>> it off> >>>>> within the 5 second "boot up" period. Namely, that the > >>>>> transmitter's> >>>>> code defaults to 0000 and the owner must rebind the receiver to the> >>>>> new transmitter code. However, EVERYONE who does this now has a > >>>>> 0000> >>>>> "unique" code in their FASST system and can control other airplanes> >>>>> with the same code.> >>>>>> >>>>> I wonder what happens to the ordinary transmitters with a new > >>>>> FASST> >>>>> system module plugged in. Do non-FASST transmitters also have this> >>>>> code and, if I've turned on my transmitter and turned it off within> >>>>> the 5 second "boot up" period, has my transmitter gone to the > >>>>> default> >>>>> code? I know I've done this with my transmitter and I'm sure > >>>>> I'm not> >>>>> the only one. For example, I decide to do some transmitter> >>>>> programming and turn on my transmitter. Then I decide to go to the> >>>>> mode in which my transmitter's RF section is not transmitting, so I> >>>>> shut it off and go to the "no RF" mode, all within 5 seconds. > >>>>> Did I> >>>>> just make my transmitter's code default to 0000?> >>>>>> >>>>> This could be really bad if the situation I described is true.> >>>>> Please tell me it isn't like this.> >>>>>> >>>>> BTW, check out this url: http://www.rcgroups.com/forums/> >>>>> showthread.php?t=807785#post9017413> >>>>> The thread involves modeler's experiences of testing their FASST> >>>>> systems at local hobby shops with Futaba's "FASST test station".> >>>>>> >>>>> Ron Van Putte> >>>>> _______________________________________________> >>>>> NSRCA-discussion mailing list> >>>>> NSRCA-discussion at lists.nsrca.org> >>>>> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion> >>>>>> >>>>> > >>>> _______________________________________________> >>>> NSRCA-discussion mailing list> >>>> NSRCA-discussion at lists.nsrca.org> >>>> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion> >>>>> >>>>> >>>> > >>> _______________________________________________> >>> NSRCA-discussion mailing list> >>> NSRCA-discussion at lists.nsrca.org> >>> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion> >>> > >> _______________________________________________> >> NSRCA-discussion mailing list> >> NSRCA-discussion at lists.nsrca.org> >> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion> >> > >> > _______________________________________________> > NSRCA-discussion mailing list> > NSRCA-discussion at lists.nsrca.org> > http://lists.nsrca.org/mailman/listinfo/nsrca-discussion> >> > > _______________________________________________> NSRCA-discussion mailing list> NSRCA-discussion at lists.nsrca.org> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion> > > > _______________________________________________> NSRCA-discussion mailing list> NSRCA-discussion at lists.nsrca.org> http://lists.nsrca.org/mailman/listinfo/nsrca-discussion
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nsrca.org/pipermail/nsrca-discussion/attachments/20080127/ce4e0a1c/attachment-0003.html 