We have a new diagram on http://neo900.org/#donate that shows roughly how we expect things to proceed. A few explanations:

First of all, this is meant to show the overall structure of the project, at a high level and only qualitatively. So the progress axis is not to any scale, the number of prototype runs (green circles) doesn't necessarily reflect the real number or prototypes we'll make, etc.

We're now in the R&D phase, where the design is being developed and prototypes are made to test that things not only work on paper. The design phase is customarily followed by the phase where one goes shopping for components, then production, etc.

However, in real life things are rarely as neat, and Neo900 has a few unique challenges when it comes to sourcing: there are parts that are hard to find and, worse, that are no longer being manufactured and may thus disappear from the market for good. Needless to say, this isn't the sort of surprises we'd like to encounter days before production.

Therefore, the idea is to purchase certain "risky" parts as early as possible. There are two categories: components that go on the PCB (chips, connectors, etc.), and N900 "spare" parts (case, display circuit, etc.) needed to make whole new devices.

The number of "risky" items in the first category should be fairly small and their cost comparably low, i.e., only a fraction of the total BOM cost. But we still need to know how many parts to order. That's where the EUR 100 threshold comes into play: for donations of EUR 100 or more we assume that a device (either just PCBA or fully assembled Neo900) will be bought in the end and we can order any "risky" parts for that already.

This activity runs in parallel to prototype development. Also, the process is not as neatly defined as the diagram suggests. E.g., some "high-risk" parts have already been bought, some part we had no reason to worry about can become "risky" at any time, sometimes you find a huge stash of parts you thought would be a pain, etc. That's just how things work in the industry, nothing unusual.

Another thing that needs buying are case parts for those who prefer a complete device instead of a board to upgrade their existing N900. Since these case parts are no longer being produced we depend entirely on the stock in the market. To cover the cost of purchasing these parts, we'll start taking partial orders in a while (my personal estimate would be in something like 1-2 months.)

Once R&D is nearing completion, we can calculate the final pricing and start to take real orders. Finally ! Then the parts for production can be bought. This will also be an opportunity to increase any stock of items we risk-bought earlier, but there will be a higher risk of things having disappeared from the market by then (hence the only dotted line.)

Once everything has been ordered, PCB production can begin. For boards of this complexity, this usually takes a few weeks. Next come soldering (SMT) and testing. At that point, we can start shipping PCBAs to those of you who plan to upgrade an existing N900, and assemble, test, and then also ship complete Neo900 units for those of you who will have chosen that option.

- Werner

First of all, there's now also a "standalone" version of the roadmap:
http://neo900.org/stuff/werner/web/plan.html

I tried to go light on the jargon in my previous post, but some of it may still be puzzling. Here is what it means, with a bit of background:

PCB (printed circuit board) refers to either a bare board (without components), or a board with components (but not assembled into a case or such). When the meaning could be ambiguous, "PCB" is used for the bare board and PCBA for the board populated with components.

PCBA (PCB Assembly) is a PCB on which all the components have been soldered (SMT). A PCBA is the product of a) making the PCB, then - in the case of SMT - b) placing the components, and c) soldering them. A PCBA can typically perform a large number of functions and can be conveniently tested in isolation, before putting it into a case or similar.

In the case of the Neo900 project, we'll call the PCBA "NeoN" and the assembled device (i.e., Neo900 PCBA plus case and circuit parts from a Nokia N900) "Neo900".

SMT (Surface Mounted Technology) refers normally to the technology as such or to anything that is related it, but in jargon it also refers to the soldering process used for such components. An SMT factory typically has one or more production lines in which bare PCBs are first covered with solder paste, then the components are placed on the boards, and finally the result passes through an oven where the solder melts and forms the contacts. If a board has components on both sides, the process is repeated for the other side.

BOM (Bill Of Materials) is a list that includes all the parts that go into a product. A typical BOM would include entries that contain things like "24 Resistor 0402 10kOhm 5% 1/16W", possibly a list of locations where this resistor is used in the circuit in question, and often also a part number. The part number can be a manufacturer part number, e.g., "Samsung RC1005J103CS" or an orderable part number of a distributor, e.g., "Digi-Key 1276-4400-2-ND ".

Priced BOM is a BOM that also includes current pricing information. E.g., for the resistor above, it may say "USD 0.00125" per unit, "at 30000" units. Note that not all pricing can be found by just looking in a catalog, so adding this bit of information can involve some haggling.

I didn't use "BOM" or "priced BOM" in the article above, but "BOM cost". The BOM cost is what it costs to purchase all the materials that go into a PCBA (or possibly the whole device.) The BOM cost is only a small part of the total cost of manufacturing a device, especially at quantities that aren't in the millions of units.

- Werner

Everybody loves diagrams. Please let me introduce a new one:

http://neo900.org/stuff/neo900-block-diagram.pdf

This block diagram is our current working draft for the specification of the next prototype, called GTA04b7v2.

Before I describe what it shows, a quick disclaimer: few things in there are truly fixed. Where we mention part numbers and such, this is meant to indicate what we currently think can do the job and generally looks nice. But we may still discover that it doesn't work, that it's not so nice after all (e.g., hard to source), or we may find something we like even better.

A quick explanation of what the colors mean: the background color of a box shows the origin of the part or subsystem design: light "gold" is from GTA04A4, darker "gold" is an earlier version of GTA04b7, be it the v0 or v1 prototype, or the pre-reorg v2 design. Yellow indicates some other origin or something we do from scratch.

A red background marks things we're still working on or where we will decide later what to do.

The frame color indicates what is to happen with the part or subsystem: black means that we keep the existing design. Red means that we change something or that the whole item is new in the v2 prototype.

A light blue frame indicates that the part or subsystem will not be implemented in v2 but has to wait a little longer. For example, v2 will not have its own CPU and memories because this would drive the PCB cost up. Instead, we plan to attach an external CPU board to drive things.

Inside or near each box is the name of the subsystem and the part number(s) of the principal chip(s) we think of using. Note that this block diagram is far less detailed than real schematics and there will be many more smaller support chips and an army of passive components in the real circuit.

The lines connecting boxes are signals or buses. They're labeled with tentative signal names or a very short description of what they do. Since I2C plays a very important role in this design, these buses are drawn in blue, to make them easier to spot. Assignment of devices to I2C buses is somewhat arbitrary and may change.

A dashed line indicates a connection we're not yet sure we want to make. The invisible connection means that the part is just there for mechanical testing. Did you spot it ? It's for the backup battery, which will actually become a "supercap".

The small numbers are not pin numbers but show how many signals the line contains.

There also plenty of question marks to indicate parts and other details that still have to be chosen or defined.

For future reference, this is what the diagram looks like at the time of writing this post:
http://neo900.org/stuff/werner/web/g...2014070921.pdf

The link at the beginning points to whatever is the current version, which will be updated as we progress.

- Werner

I made a quick update, with the main changes being that the memory sizes were those of ancient N900 and not the 1 GB + 512 MB of Neo900, and that the microphone was all wrong, analog mono instead of digital stereo.

Link to the revision:
http://neo900.org/stuff/werner/web/g...2014071105.pdf

- Werner

We now have interactive block diagrams:

http://neo900.org/stuff/block-diagrams/

The PDF versions show the various functional blocks and the names of key components.
The HTML versions show the same information and when moving the mouse pointer over one of the boxes, a menu with additional information (mainly links) pops up.

In addition to the Neo900/GTA04b7v2 block diagram, we now also have one for the Nokia N900, ancestor of the Neo900 design. This is to facilitate technical comparisons, which will be particularly relevant when it comes to adapting N900 software for the Neo900.

When a subsystem we have in Neo900 also existed in N900 and we only changed some chips, then the pop-up shows the N900 information in italics, followed by a horizontal rule and then the Neo900 information.

Please note that the main purpose of these block diagrams is to support the on-going engineering effort. They may change frequently and will often contain transitional, somewhat cryptic, and sometimes erroneous information.

The source data and the scripts used to generate the block diagrams can be found in the following repository:
http://neo900.org/git/?p=misc

- Werner

With the new block diagrams we can also do another useful thing: cache data sheets.

The issue is as follows: for development, a very large number of documents is needed. There are data sheets, errata, application notes, and so on. These document are not only needed by those who design the circuit but also by those who review it, and in some cases also when developing software, and so on.

The easiest way to work with such documents would be to collect them and to put them in a repository, for anyone interested in Neo900 to share.

This would provide a uniform access, would protect us from documents being deleted or renamed at the source, sites going down or being unreachable, and so on.

Unfortunately, these documents are virtually never distributed under terms that would us allow to do this.

We can however link to them, and I've written a script that extracts links that look like pointing to PDFs from the block diagram. This script can then download them to a local cache and rewrite the links to point to that local cache.

The process is described in this README:

http://neo900.org/git/?p=misc;a=blob;f=block/README

- Werner

@wpwrack,

Thanks. It worked, with a few minor issues.

(1) syntax is "./localize <folder> < input > output"
(2) requires GNU-awk (-e). mawk worked but always gave a warning about -e

It went through quite quickly and downloaded 68 files (87MB). All of them PDF (but 4 of them didn't get a .pdf extension).

I'll keep my cache in case it becomes necessary.

Ah yes, forgot the "./". Fixed, thanks !
I also added an explanation that "cache" is a directory and not, say, some keyword.

Fixed, too. Thanks !

That sounds right. The script uses various heuristics to determine what can be cached, and some companies get extremely creative in making their data sheet links not look like PDF at all.

Does having some of the file names not end in .pdf cause problems ? They seem to work fine with all the browsers I've tried (current Chromium, Firefox, Konqueror, rekonq, plus an ancient Firefox).

That's the secret plan: keep many copies in safe places, so if something happens, at least some will survive :-)

- Werner

Well the ./ at the beginning is just because most people will not move the script to a place included in $PATH, but the real issue is that the script requires a directory name (hence the "<folder>").

But now that I see this..

I notice that the README already had that. I seem to have read:

localize < bla bla > bla bla, i.e. without the "cache" word in there. Maybe I was confused.

Of course not. Just reporting in case somebody gets different results ;-)

Cheers, and thanks a lot.

You may have already heard of the 2.5D scans of the N900. They live here:
http://neo900.org/stuff/werner/scans/

Scanning has been a background activity for a good while (the scanner is slow, with a high-resolution scan of a larger part taking several days), and I've now scanned all the surfaces I think will be important for our project.

This is about half the surfaces that are in N900 in total, but the ones I didn't scan are either trivial, outsides, or sub-parts of larger assemblies we'll treat as a whole anyway.

One purpose of these scans is to accurately measure dimensions of the case and of N900 components. For this, I've written a quick and dirty visualizer with a measuring function. Here's a screenshot:

http://neo900.org/stuff/werner/tmp/n900-av-y.png

This example shows the width of the audio jack. The jagged blue lines on the sides are height profiles (with some rendering artefacts, hence the "dirty"

Usage instructions:
http://neo900.org/git/?p=misc;a=blob;f=meme/README

The code lives here:
http://neo900.org/git/?p=misc;a=tree;f=meme

The STL meshes can be downloaded from the scans page.

- Werner