It seems like the root of their problem is that they didn't spend enough time/effort/experience on creating the test system.
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.
"they" had no problem, they contracted manufacturing and shipping to Sparkfun. It was sparkfun that had a huge problem and paid for it (shipping replacements for free).
I didn't get a warm fuzzy from this mea culpa. There is cognitive dissonance in the way the CEO accepts responsibility: "We are really sorry to have messed up... SparkFun are going to make it right..."
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)
Marcus Schappi was on theamphour some time ago, and from what I understood the deal with Sparkfun is a complete takeover of a project - SP handles EVERYTHING and gives you a cut of the profits.
http://www.theamphour.com/189-an-interview-with-marcus-schap...
My bad for calling them contract manufacturers, they are more of a whole package deal.
If you mean "they" as in the group doing the kickstarter, then saying that "they" don't have a problem is missing the point. "They" are having "their" customers receive defective units. The customers don't care who is responsible, but they sure as hell can read the brand on the product and place blame.
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.
It's a little disappointing that most PCs don't come with parallel ports these days - they're extremely versatile for when you need a few PC-controlled GPIO pins, like when flashing firmware on a microcontroller, or a bricked motherboard/tablet/smartphone/etc's BIOS, or reading some EEPROMs on hardware you want to hack, etc...
I am sad that serial ports are disappearing from PCs, but I am glad that parallel ports are gone. They were such a horrifying GPIO interface, and yet their presence meant that every open project used them by default, and if they didn't then they used high priced tools instead. Now that parallel ports are dead, we have an abundance of affordable USB GPIO devices to choose from, from Arduinos to FTDI devices (and many others of course). And best of all, numerous devices can be connected at once via a cheap USB hub, unlike parallel port devices.
Yeah, they just learned a valuable manufacturer lesson: YOU do the QA, not the manufacturer
"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
In larger cities like Shenzhen, there are companies that specialize in ensuring your components are properly sourced (i.e., not counterfeit[0]), assembly, programming, testing, boxing, and shipping logistics are all taken care of. You pay a premium for the services but it's not necessarily "you" who has to do it.
Even in the US you can outsource test engineering. A plethora of little companies have been created -- mostly by ex-engineers from big OEMs and EMS -- to provide exactly these kinds of services. Here's a pretty spiffy test management & parametric data analysis offering created by a couple of ex-Flextronics guys: http://maintainable.com/
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.
> SparkFun are going to make it right and will be shipping a replacement Microview for every defective unit that was shipped.
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.
I wonder how much the attention to crowdfunding debacles will negatively impact it's long term future as a platform for innovation (e.g. We want to make this awesome thing but can't get funded, if you really want it we'll make it) vs just a pre-order / viral sales channel. It's a shame but it's also somewhat expected since the creators are figuring it out as they go. There is no need to cover successful on time deliveries on blogs / HN but plenty of dramatic reasons to cover the troubles.
SparkFun was born out of a class I took at CU Boulder, and the CEO came and spoke to our class mid-semester about growing SparkFun (at the time close to 100 employees) out of his college apartment & classroom experience.
Good to see they're doing right by their customers, I think they're a real standup company.
Looks like a good article, I read about 1/2 of it and skimmed the rest. Would have been better if in the opening couple of paragraphs you actually explained wtf a "microview" is. Cheers.
Indeed, but unless the economics of their project are weird, it means it's easier for them find the money to rectify the problem. Not every project would be able to do that.
Maybe, but a one time charge that is 10% of your entire budget and hits at the very very end of a months/years long financial burn down plan. That's a full semi-truck broadside type hit. I'd guess those funds are coming from future order inventory or bank loans.
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.