We don't need to redesign anything. They just need to put Snake on the CED 7000.
We don't need to redesign anything. They just need to put Snake on the CED 7000.
(Following up my own note; sorry.)Originally Posted by lairdb
Couple of different angles:
Develop device:
Quick assumptions on developing a hardware device (rather than an app for someone else's):
- Trade repair-ability for robustness.
- Communication is important for downloading and/or live feed and upgrade-ability.
- Minimal capitalization for development.
Quick-starting: Use the ArduinoBT as the development platform. (Benefits: bluetooth; analog and digital inputs and outputs; strong development suite and community.) Add: LCD display module, microphone, 4 or 6 buttons, one horn. Make provision for stop-plate jacks, but don't include in the base build.
Development target hardware: ~$500 bench cost, plus some assembly labor. That allows for some slop, so presume that fielded prototypes for testing and evaluation run about $300.
Final production: Some engineering investment comes in here, to duplicate the ArduinoBT circuitry (it's open source, but you'd want to redo the layout to add your own components and optimize for production) and to build a switch array and body. Build with a battery tube taking 2xAA and a screw-on o-ring sealed cap. Epoxy pot the whole thing; the only exposed parts are the display-and-button assembly, the horn and the battery cap. SWAG at the naked COGS is about $110. Add $20 for retail packaging and shipping overpack, you're at $130 sitting on the dock ready to ship. You need at least 40% GM, distributor and retailer each need at least 20%. $130*1.4=$182 to the distributor; $182*1.25*1.25=$284. $299 retail; markdowns are the retailer's problem.
All of this assumes that development labor is essentially free, or at least deferred compensation to be paid back over time out of the profit.
Develop software for another device:
[Fairly obvious (both upsides and downsides); left mostly as an exercise. In your answer, do not neglect the necessity of application design, be sure to address compromises inherent in using a non-purpose-built target; be sure to address licencing costs. Neglect for the moment any issues of cross-platform development and dependency on third-party hardware.]
Don't develop:
Crowdsource the requirements and application design. We have a ready-made crowd here who are SMEs in multiple possible fields-of-use. Iterate and refine, with the engineering and business literate members being the Designated Grinches.
Once we reach a requirements set and UI design that appears to be there, Todd approaches CED, PACT, etc. with an offer to license the design and his endorsement. Let them leverage their existing hardware and firmware groups, manufacturing partners, and distribution channels.
Last edited by lairdb; 05-19-2011 at 01:59 PM. Reason: fixt speling.
It's not cheap though. I work for a contract product design house. This kind of product is exactly the sort of thing we do. Off the top of my head, I'd ballpark the design work in the $100k-$150k range.
It's funny, I don't really know what most of the local shooters do. It would probably be a great networking opportunity if we talked about it more.
The board design and software is definitely the easy part, but that's probably partially colored by the fact it's the part we know how to do.
Bluetooth is pretty expensive to put in a product at this volume. There are two broad approaches, buy a ready made bluetooth module and integrate it or buy a bt radio chip and roll your own. Modules run about $20 in quantity. Rolling your own is cheaper, but there's a much larger development cost, FCC testing, etc. You'd need a market of at least 10k/year to consider it.
I'm guessing an electronics-inclined friend of Todd's is or will soon be in a basement somewhere working on this. Anyone care to start an over/under on time until the next gadget announcement?
Same for mine.....
GeorgiaCarry.Org Life Member
"Opportunity is missed by most people because it is dressed in overalls and looks like work." Thomas Edison
Ad addendum to Todd's list:
Display: Polarized glasses friendly. I hate the rainbow effect the new timers get when you're wearing polarized glasses.
The Arduino looks like an interesting setup. My experience is with the Intel 8051 and Microchip PIC products but that was 15 years ago. A lot has changed since then.
The biggest concern I can see is the speed of the inputs, especially when timing to .01 second resolution.
-Seconds Count. Misses Don't-
Pfft.Ten milliseconds is an eternity, easily handled in software, unless we try to do lots of other things simultaneously.
Heh, this is true.The board design and software is definitely the easy part, but that's probably partially colored by the fact it's the part we know how to do.
I'm currently working on something that times down to 333ns. It could easily go to 1/4 that if necessary. Actually, it just occurred to me I could use this as a shot timer. It's an ultrasound range measurement system. It does sound pulse threshold detection in hardware with a software controlled threshold. Replace the ultrasound transducer with a microphone and you're there. Of course it can only generate a square wave beep, which would sound pretty nasty.Pfft.
Heh, this is true.
ETA: my brief glance at arduino says it's great for hobbyists, but I wouldn't use it in a commercial product
Doing the threshold detection in hardware would unload the processor a LOT, but it would also make it a little less flexible. In my noodling, the only specific-purpose hardware was the horn -- and if we could get decent volume out of a speaker, that could be general-purpose too. (And it's not like the processor is doing a lot else; the ATMega is ludicrously overpowered for a shot timer. PIC would be a cheaper choice if variable costs were pivotal -- but using the Arduino building blocks would be *so* quick a path to having a mature and robust development target.)
(In fact, the project might be able to recoup some costs by selling the resulting device to the Arduino hobby community without the shot timer software as a general-purpose platform.)
(jar, how are you handling echo cancellation? Echo cancellation and auto-sensitivity are bouncing in the back of my head as the tricky bits; the rest is dirt-simple.)
P.S. for the geek squad: if you haven't read Cory Doctorow's Makers, give it a try.
Reply With Quote