Topic: product dev/testing/certification

perhaps you'll could consider the next step in openness...

I would love to know your thinking process in designing and developing the whole application. I.e. things like :
- hardware layout (why choose certain components over the other, why make certain routing/layout decisions etc).
  - Where you typically source PCB's (do you make panels)
  - where do you assemble it (how do you manage QFN and BGA parts)
  - how many revisions do you typically go through before a final release

- plastics :
  - do you get rapid prototypes?
  - how many iterations before a injection moulded part?
  - do you make a production die?

- testing/certification :
- what kind of certification are you planning to get: UL/CE/FCC etc?
- how do you do inhouse testing (what kind of equipment do you have)
- do you send out for pre-compliance tests?

I'm developing a small zigbee based product and this is my first foray into the hardware development process and I would love to follow along and see how real pro's do these types of things. Obviously I can understand that some of the info is sensitive to your organisation but I would love to get some idea on things you do to save cost/optimize processes etc.
Maybe you'll can set a new standard on hardware development lifecycle bestpractices so people can learn/share from this model- even more so than what you'll are currently doing. For a start just a few blog entries would be great.

thanks much.

Re: product dev/testing/certification

Welcome to the forum Kaiki! Great post!

I am a moderator here but I am not employed by chumby so I don't speak for them. These are just my thoughts.

I think you have a great idea there, I am very curious about the design and manufacturing process surrounding the soft casing myself. I think you may have to wait for a little while for the Chumbians to be able to do this though, as it is a small startup company and I know the guys are really busy working hard, trying to deliver the best chumby they can to the public by Q207. It is definitely something to pop on their long to-do list though.

Re: product dev/testing/certification

kaiki wrote:

perhaps you'll could consider the next step in openness...



I'm developing a small zigbee based product and this is my first foray into the hardware development process and I would love to follow along and see how real pro's do these types of things. Obviously I can understand that some of the info is sensitive to your organisation but I would love to get some idea on things you do to save cost/optimize processes etc.
Maybe you'll can set a new standard on hardware development lifecycle bestpractices so people can learn/share from this model- even more so than what you'll are currently doing. For a start just a few blog entries would be great.

thanks much.

VERY good questions and awareness of why/how such information rarely gets "Open Sourced"
And Zigbee is potentially a glueware usable to Chumby add-ons. I wish you sucess!
Because  Zigbee linked items may change many rules- including THESE invoked by me!



Let me share some observations both  Chumby and your Zigbee project may  face from page zero.

Serial # 00001 may indeed have a "cost" of >$1M, wheras serial # 1,000,001 has a NEGATIVE cost!- See below.

Using Rapid Prototype methods for initial production is a coin toss for viability demanding diligent evaluation.

Last observation- study the "one time use" cameras/camcorders for some "how not to do it" history.


To explain my observations-

History has shown certain initial entry to a market segment products has made pennies on the dollar compared to support/supplies/accessories.
EX-The automobile and TBA/Fuel/repair/insurance etc. The PC and Software...
Record Players and the music industry.

Rapid Prototyping materials risk a Fragility perception that could doom otherwise viable products. The reversal?
OVERBUILDING initial production for robustness and survivability generates legends often exceeding the wildest  expectations of a product's creator- Zippo lighter? Leatherman Tool? Vice Grips? ALL having in common early production sale units were OVERBUILT...


The "Cameras" mentioned? Their financial model was dubious at best both at price point and customer market segment acceptance.   Being both "Closed Source" yet "hackable" created a schiziod relationship with the hackersphere. Then the "Wrong end of the price spectrum" USB camcorder basically revamped from the "One time use" Camcorder shows further allergy to  getting it right.. Had they been able to offer a still frame camera of the specs
in their OTU model at the same price point  but "unlocked" they'd perhaps have had the next "Kodak Brownie".
DO note that a drug store photo clerk mentioned on the camerahacking forum that "customers will pay to have prints made from customer owner cameras especiall if the cameras are cheap enough!

PLEASE consider  adding YOUR observed examples in replies to this post.



Disbelief in the listed concepts are quickly dispelled by looking at the "approved accessories" cash flows for certain high market penetration systems. Give the razor away and sell a gigabuck of blades is humbled by the Mp3 accessory field for leveraged markups. 

A codicil here- with sincere respect to the vision concept of a server based "Chumby network"
The demises of I-opener,CueCat,Kerbango and other "server revenue stream" plans should be studied carefully!
Secondary and tertiary cash flows from "server paid content" ARE of viable worth in my admittedly shallow perception BUT- ALL push  media sadly are endangered species if Broadcast  Flag DRM reincarnates- public backlash spreads- and our paradigm goes places we can't even speculate beyond wild guesses. Such as a savior from DRM  hell.  Like -"AdHocracies" exemplified in for example - "Podcasts" could be a content source for Chumby.

" Disrupting established markets creates more profits than losses"

Oren Beck

Re: product dev/testing/certification

orenbeck wrote:

A codicil here- with sincere respect to the vision concept of a server based "Chumby network"
The demises of I-opener,CueCat,Kerbango and other "server revenue stream" plans should be studied carefully!
Secondary and tertiary cash flows from "server paid content" ARE of viable worth in my admittedly shallow perception BUT- ALL push  media sadly are endangered species if Broadcast  Flag DRM reincarnates- public backlash spreads- and our paradigm goes places we can't even speculate beyond wild guesses. Such as a savior from DRM  hell.  Like -"AdHocracies" exemplified in for example - "Podcasts" could be a content source for Chumby.

We've certainly studied these devices and the reasons why they failed.

I really don't think *any* of these devices failed because of DRM - they failed for reasons of basic economics.  In all of the devices DRM didn't actually present much of a barrier - they were typically hacked within days.  It's possible DRM might have eventually become an issue, but they didn't exist long enough to find out.

Take the i-opener. The biggest problem there was that the device cost substantially more than the company charged for it - there is speculation that it cost the company $400, while they charged $99. We're planning on passing through the chumby more or less at our cost.  So, if you're one of those folks that's planning on hacking it, well, we haven't lost money on you at least.  The other big problem with i-opener was that is attempting to replace a device that was already cheaper and more full featured - by the time you added the cost of the device and the *required* subscription, you were paying more that you would for a more powerful general purpose computer.  Chumby is designed to find a place in the home where a computer is simply not appropriate or useful, and provide a function for which a computer is overkill.

Many of these subsidized computer device companies ended up selling devices to wither hackers or people too poor to pay for "real" computers - neither group was ideal for creating a recurring revenue stream.

CueCat suffered from a different problem - it required too much third-party infrastructure over which they had no control.  They needed people to print the barcodes everywhere, and they needed all the e-commerce sites to support them.  Without a critical mass of support, the product was pointless.  They tried to buy that critical mass by carpet-bombing devices, and hoping to generate consumer pull-through - they thought that folks would naturally demand CueCat content once they had the device.  Unfortunately for them, people simply don't shop that way, and didn't see the utility.  The content providers also saw no reason to add yet another cost (a royalty to CueCat) to their products.

As hackers, we tend to be more focused on the Slashdot viewpoint of such devices or services - on how "hackable" they are.  But hackability is in no way an indicator of the commercial success of a product.

Tivo, for instance, is the perfect counterexample - it's *barely* hackable, but it's a subscription-subsidized device who's business model is not totally unlike the devices mentioned above.  The Tivo succeeded where the others didn't because it was *useful*.  Tivo's only weakness is that there are better financed cable, satellite and DSL companies that provide the content that can eliminate them by peddling DVRs directly to the customer and spread the subsidy across other services.

So, why are we catering, at least at this early stage - to hackers?  Well partly because *we're* hackers, and we're excited about the device and want to share that with other folks like us.  But we're also doing it because the hackers are going to play with the device *anyway*, and we'd rather embrace that rather than get all huffy about it as these other companies did. But here's the thing - hackers will never be more than a percent or so of the user base, if chumby succeeds.

So will chumby succeed?  Dunno - we'll find out.