Setback: A $58,000 lesson in mid-volume manufacturing
kickstarter.com
kickstarter.com
Using things like cap-sense buttons would be very much frowned upon by most contract manufacturers, you can't use cap-sense buttons with dirty hands, gloved hands, and there's no tactile feedback to show that you actually pushed the button. This is OK for a consumer end-user mode of operation, especially if you can have haptic feedback or the screen light up or something, but in manufacturing seconds count and the operator will be doing this same motion thousands of times, making it very clear that they pushed a button is critical.
That the unit would overheat if left in the test jig for too long is a huge oversight. The functional test jig should never have this kind of issue.
That critical portions of the product were not actually tested in the test jig, it sounds like they didn't test the serial interface at all, is a huge oversight as that's a critical interface that customers will notice if it fails.
Making a functional tester for a contract manufacturer to use in mid or high volume is not an easy problem to solve. It takes almost as much effort as making the actual product work correctly in the first place.
I'm glad they found out after only 2000 units went to customers and it sounds like they're fixing the problem for their customers in a very classy way. Kudos.
If you hire a contract manufacturer, when there's a problem, it's your problem. It doesn't matter who's eating the cost of rework or replacement, your brand is getting the ding from the customer.
If I buy an iPhone and it becomes defective an hour later, I'm not going to blame Foxconn. I'm going to blame Apple or the Apple Store I bought it from.
Going out on a limb here, but I bet "they" (MicroView) were the root of the problem. It's never mentioned in the article, but I'm guessing MicroView is eating the $58K bill.
There was a production test procedure that should have been performing 'ship-ready' verification of test-able requirements, along with an engineering deliverable (containing analysis, software compilation records, etc) that covered everything else that couldn't be tested. Between these two docs, verification of all requirements (physical, functional, non-functional, etc.) via 1 of 4 verification methods (inspection, test, analysis, or demonstration) should be documented. And the lead engineer from MicroView should have ultimately been responsible for ensuring all requirements of his (MicroView's) design were adequately verified. He should have been signing off that the product delivered is as-was designed. (Unless Sparkfun owned the whole shebang, but I doubt that is the case...)
If Sparkfun is smart (and I'm guessing they are), it should be written in the contract that they are only responsible for delivering a product that meets what MicroView's lead engineer ultimately signed on. And what was ultimately signed on was a verification method that clearly missed checking the correct software components were loaded into the HEX mix. Hence, the miss was with MicroView, so they eat the bill.
source: test and verification engineering and 3yr subcontract manager for world's largest defense contractor (ugh... shiver)
My bad for calling them contract manufacturers, they are more of a whole package deal.
http://www.arduino.cc/en/Hacking/ParallelProgrammer?from=Mai...
But I like that they give the instructions on how to flash the firmware on it - and are encouraging people to fix these themselves.
Despite their mistake, I particularly like testing jig with capsense buttons (although I wonder why?)
"The test procedure correctly tested the Microview’s functionality (display graphics, toggled GPIOs, etc) but did not test the upload functionality (minor detail...)"
True, but they can test for the presence of the bootloader ;)
I'm not blaming them really, manufacturing something and shipping is hard
A good QA process is complex. Most manufacturers will offer/do a basic QA (usually with a test/simplified firmware)
However, a lot of times, this is not sufficient.
On second thought, their problem (in the article) is not necessarily a production/QA issue (as in, a defect in producing), but in assembling the image to be saved. The (incorrect) image was saved correctly.
> Can I fix the bad unit once I get it?
> Yes you can, but it’s not easy.
Given that it's a fixable problem, I'm wondering why they don't ask users to return the product for a free repair/replacement. There could be a couple reasons I can think of for this. First, the headache and hassle of dealing with thousands of incoming packages they have to track, fix, and ship back... it quite possibly cheaper (parts, manpower, opportunity cost) just to send another out. Second, from a customer service perspective, immediately sending out new units is just the Right Thing to do.1) It's a slick PR move and a gesture of goodwill to provide instructions for how to unbrick the device 2) For a $30 product, the cost of shipping a unit back would be approximately equal to the BOM so it's almost as cheap to just throw it away.
Theres a few problems with this.
1. Time - Its not my fault you sent me a broken product. Send me a new one and i'll send you back the broken one.
2. Its a terrible customer experience.
It sounds like Sparkfun is footing the bill for replacement anyways so it's much easier to just let them go through with that rather than setting up the equipment to quickly burn the bootloader into all the defective units. Setting up that equipment wouldn't be trivial either, if they're dealing with the full ~2k defective units they'd need something more durable than the breadboard setup the article showed. It's a lot of effort and another point of failure since they'd really need to test the units again after this process incase there were any issues with their repair process/equipment.
Good to see they're doing right by their customers, I think they're a real standup company.