werner at openmoko.org
Mon Apr 13 18:39:50 CEST 2009
Steve Mosher wrote:
> 1. Target market selection ( who is the customer)
> 2. MRD ( what are their needs)
> 3. Engineering Spec. ( designs a-n that meet the MRD)
> 4. Business plan review. (budgets and ROI)
> 5. Operations review. ( can we produce it)
> 6. Continue or return to step 1,2,3,4 depending on failure mode.
> ha I just turned it into software. GTA03 was stuck in an endless loop
Hehe ;-) There are some feedback loops there, though. Also, you
sometimes can't close an issue before later, simply because the
negotiations or some tricky engineering problem take more time
than the schedule would like. It's all calculated risks ...
> 7. archetecture and implementation spec
> 8. theory of operations.
> 9. Design.
> 10. Layout.
> 11. Prototype
> 12. EVT
> 13. DVT
I wouldn't break it down like this - there are several prototypes in
EVT and generally also in DVT, all of them at least with schematics,
BOM, and layout changes.
Hmm, Wikipedia for once lets us down on a useful definition for those
TLAs. Here's something that's not so bad:
- EVT: "Is it possible ?"
Make prototypes until at least one of them works in the lab.
- DVT: "Can it be made into a product ?"
Make it work legally also outside the lab.
- PVT: "Can we produce it ?"
Bring the production process to a factory.
> when starting down the path. Werner is rather bottoms ups, or rather
> he like to have all the details known before starting down a path.
> Is that about right werner?
Yeah, I like to have both the "big picture" and to have it mapped out
in sufficient detail that I can see where the unexpected problems are.
In my mind, a project is composed of things that are hard to do (which
take an indeterminate amount of time) and things that are easy to do
(which take a negligible amount of time). So my approach is always to
reduce the number of the hard or not completely understood problems.
Naturally, as you may expect from a sum of epsilons and potential
infinites, my forecasts at how long something will actually take just
> This, coupled with my impatience, makes
> for spirited discussions between us, but our mutual rspect for each
> other keeps the discussion civil. Plus werner plays great tunes.
Hehe, thanks :-) I must say that I also find it very enlightening to
better understand the marketing angle of things. Even as engineers,
there are a lot of implicit marketing assumptions we just make, and
and we don't even realize that they may actually be questionable or
> The next Phone:
> 1. GTA02 cost down
Hmm, that would be
- move BT to the PCB (yield goes up)
- NOR removal (hard to source and eats space)
Need to find a plan B for unbrickability then. Some possibilities:
- do as we did in GTA01 and depend on the debug board
- add a NAND trap-door circuit
- integrate IDBG
- remove one of the acceleration meters (useless)
anything else ?
> 2. GTA02 Glamoectomy - G
The moment of great liberation :-)
> 3. GTA02 -G+E Glamoecyomy, new Edge +E
I'd very much like to see the demise of the Calypso. It's been EOL
for as long as I remember, and while the consequences of working
with a hopelessly obsolete chipset were still surprisingly mild, they
are adding up.
We should also review WLAN. AR6001 is about as dead-ended as the
Calypso, so the least we would have to do is to replace it with an
AR6002. I don't know how bad the driver situation would be, though.
Atheros are working on a "lean" firmware for the AR6002, but that
won't be ready for some more months.
Switching to Marvell would mean that we'd either have to find a
different module than the USI we have right now (because we don't
have a UART for BT), accept that we have a useless BT component on
that module, or upgrade to a CPU with one more SDIO port.
> 4. GTA02 -G+E+P add 6410
The 6410 would give us more connectivity choices (more SDIO, more
UARTs, High-Speed USB, etc.), better overall performance (FPU and
all that), and more flexible clock management.
Drawbacks of the 6410 include relatively new kernel support, more
difficult SMT, and more difficult thermal management.
> then options of camera, 3g etc etc etc.
With the design we have for GTA03, the camera interface works. I
just have to figure out how to get the camera to make good
3G is the great unknown.
For a community-centric approach, I think one important requirement
would be to have a common set of tools, so that everyone can go
through the schematics or layout, look at the CAD data, etc.
In Openmoko, we always had that distinction of engineers with access
to the proprietary EDA and CAD tools and the second-class citizen who
depended on others to provide them with PDFs. This was always
extremely dissatisfying, yielded a disconnected development process,
and eventually caused problems to get overlooked.
I'm not sure how feasible it would be to convert the existing material
into something sufficiently free tools can use. PADS to KiCad, Pro/E
to HeeksCAD ? :)
Another issue is access to vendor documentation. There's a lot of
material that is under some form of NDA and that would have to be made
accessible to the community in order to allow people to understand how
More information about the Gta03