ver 1.0 - rev1 - blue - TEST - no wifi/bt, just a test board to get things rolling, learned a lot here and then rev2 changed a whole whack of things to be much, much better
ver 1.1 - rev2 - red - NEAR FINAL PROTO - wifi/bt, batt connector, basically ready to look like a production board but had errors and needed holes moved to line up with final case design
ver 1.2 - rev3 - green - PRE-PRODUCTION - added battery fuel gauge for better battery control and longer battery life, this is another test board that was supposed to be the same board going into production but Notaz and I found some quirks in the OMAP3 chip (such as GPIO's only being GPI's!!!)
ver 1.3 - rev4 - ??? - PRODUCTION - sort of still pre-production but also small run production board (starting soon on a run of 100 test boards to master reflow process which seems to be getting pretty good now). I just need to know that nothing else is bad on rev3 before building these and organizing software efforts to verify this is taking longer than desired.
ver 1.4 - rev5 - ??? - PRODUCTION - there will either be an identical repeat of rev4 and rev5 won't exist or this one will be to tweak mask openings to help solder balls melt better at reflow temperatures and belt speed selected. The plan is to have this right on rev4 already.
It's pretty safe to say that the Pandora board that ships to customers will have been incredibly well tested and we expect to start the second batch without changing a thing. Every single Pandora will have a complete functional test and 24-48 hour burn in cycle. This thing is way too late in shipping to customers, but when it is done, it will be a solid little product you will have fun with over the balance of your summer. Maybe there is some comfort in that. I don't know.
BTW: U18 and U22 are the nub controller chips. We only put those on a few boards to test the new firmware. There was no point putting them on every board until the tests are successful. Rev4 adds programming pins with a "bed of nails" setup so that firmware can be re-flashed on the fly. The chips themselves are capable of self-writing but the company that codes the nub algorithm isn't willing to put the engineering time into adding that code and testing it thoroughly for us (and I don't have access to their source code). The programming pads will be there for us to reprogram the chips right up until the day parts ship to customers, should that be necessary.