On the software side, we’ve also undergone quite a bit of evolution.
In its previous incarnation, the Exbiblio system comprised components written using a variety of computer languages and technologies, such as C, C++, Objective-C, C#, AppleScript, Visual Basic for Applications, and Java (many or all of which will resurface over time). We were trying to leverage each contributor to their fullest by keeping them working in their most familiar environment, at the cost of more complex communication between the components. We were also trying to build in a lot of flexibility by having separate processes communicating with each other, at the cost of simple installation and maintenance. (more…)

I feel a bit intimidated by the idea of presenting what we’ve done since we last posted updates on the software and hardware development. I think I’ll let the overview slip a bit, and get started with a few recent tidbits.
We just reached some very exciting milestones on the hardware side, in that we got our first form-factor boards in, as well as early samples of the case. The boards don’t yet have the components placed on them, but they will be “stuffed” shortly. (more…)

by Jeremy Faludi

Now that we’re using a metal extrusion for most of the main body, we also need to use some glue to stick plastic bits to it (such as the window you see the display through), since there just isn’t enough room in the tiny body for strong snap-fits. This makes recycling harder, for two reasons: first, because now the device is harder to disassemble into its component materials; and second, because now the component materials will have some gunk on them (adhesive residue) that cause problems in recycling the metal or plastic.

Don’t Be Too Strong

Fixing the first problem is fairly simple: you just use weak enough glue (or a small enough amount of strong glue) that whoever disassembles the device can just pop the parts out by hand, overwhelming the strength of the glue. This way, disassembly doesn’t take significantly longer than it would with snap-fit parts. If the glue is too strong, you have to pry things out with a tool, or (if the glue is stronger than the plastic itself) you have to release the glue somehow. Most glues can be released by dissolving them in nasty solvents like acetone, or burning them off in a furnace, but some glues dissolve in water, and other glues melt at low enough temperatures that your plastic parts won’t be affected. The advantage of dissolving or melting your adhesives is that then they can be removed from your parts, avoiding the problem of getting gunk in the recycling furnaces.

(more…)

by Jeremy Faludi

This week’s episode of green design for Exbiblio is about metal. They recently decided to change plans about how the first release of the oPen will be made–instead of the whole body being recycled injection-molded plastic, most of the body will be an aluminum extrusion with holes machined into it for the screen and buttons, and there’ll just be plastic bits on the ends, much like an iPod Nano. The reasons for this had to do with schedule and design flexibility–we have a very tight schedule to make, and need to get to production as soon as possible, but still have not nailed down all of the design considerations. Using an extrusion with machined holes gives us a great deal of flexibility, as machining can be reprogrammed at any time to cut different holes, and extrusions are fast and easy to get into production–easier than injection-molding.

Using aluminum instead of plastic does increase the device’s environmental impact, in three ways: first, aluminum is more energy-intensive to produce than plastic; second, it’s more energy-intensive to manufacture with and requires harder tooling; third, having the case be made out of multiple different materials makes it harder to recycle because it needs to be more carefully disassembled and sorted. With a device this small, we need disassembly time to be extremely short, otherwise it won’t be worth anyone’s while to recycle it, because the amount of plastic and metal you get for the amount of time spent is small. I’ll talk more about design for disassembly in a later post.

(more…)

It was a morale boosting morning meeting this morning. The prototype for the oPen (Exbiblio scanner pen) was dragged across some text, and lo and behold, after about 15 to 20 seconds, the text appeared on a big projection screen. Yeah! The wait has to be reduced to one or two seconds, of course, but it’s a step in the right direction. The whole process of integrating the hardware and software has been taking rather longer than planned.

The hope is that when mark II is ready towards the end of the year, it won’t have these integration problems, as most of the software kinks will have been ironed out.

This is a follow up to the entry about the electrical shorts in the printed circuit boards last week.

After a few days of “beating [his] head against the wall”, Brian Piquette from Synapse took both the working and non-working circuit boards back to the manufacturer to get them X-Rayed.

The X-Ray revealed solder bridges which caused the short circuits and the manufacturer was able to fix most of the boards in a few hours. The photos below show the solder bridges circled.

Most of the shorts were under the board-to-board connectors and it was determined that the problems were a result of a manufacturing problem, not a design problem.

The manufacturer is going to X-Ray all future boards before delivery to confirm that the manufacturing process is now turning out good boards.

Adam has posted an email from Brian (pictured left), an electrical engineer at Synapse, the consultants working for Exbiblio on its first product, the oPen (pocket scanner). Adam mentions hitting some “challenges” . Over here in England, we still call those “problems”, but you can get a sharp rebuke for uttering that word around Exbiblio.

Exbiblio, once again, is to be commended on its openness – but on this occasion, Synapse deserves credit too. As it happens, I was planning to write an account of my visit to Synapse.

Synapse is based in a former tram depot in a suburb of Seattle. Immediately I walk in, I get a different feel from Exbiblio – it’s open-plan, chatty, but business-like. The depot makes me think of the Google Garage. It has some of the make-shift romance of a start-up, though Synapse was founded in 2001 and employs around 40 people. Exbiblio, as I have mentioned before, is in the center of town, and has a bookish, intellectual feel, with the workers dispersed in offices along corridors, where they beaver feverishly away at their projects.

On its website, Synapse says it does technology- intensive product development. Since June, it has been working with Exbiblio to develop the oPen. Its other clients come from all over the world and include Microsoft, Samsung, Philips, Intel, Logitech, General Electric – well you name it.

The five-strong engineering team working on the oPen is managed by Dave Zucker (holding the notepad in the picture). You will often see Dave and other Synapse people around Exbiblio. Exbiblio’s Ian MacDuff (in the middle of the picture) is often at Synapse. It all seems very well integrated. They seem like a happy team, though I hope Ian won’t mind me saying that he looks a little stressed now that the project is behind its ambitious schedule.

I’ve heard Dave say a couple of times that the Synapse way is to “fail early, and fail often” – in other words to go all out for rapid development of prototypes, see what works, what doesn’t, and then quickly do another one, and then, if necessary, another one.

That is what has NOT happened with the oPen. Dave told me:

“We had said at the beginning that this was a two month project.”

I interject, “Was that possible?”

“It was possible. But Martin and I had discussions along the way where we made conscious decisions to push out the schedule in return for something – either we learned more, or got a design that we liked better. When you shoot for a prototype in two months, you definitely are going to make some compromises. You certainly couldn’t design something for production that was exactly for final version in two months.”

And so the deadline slipped, partly as a trade-off for more features and knowledge, and partly just because it slipped a bit.

The first prototype – videoed last week – is about one and a half times bigger than the desired size of the final version (this was planned). The idea of this prototype is to learn about memory, processor, and battery-life requirements. The engineers are also looking for ways to cut the size down.

Dave told me about one of the problems – er, challenges – already uncovered. When the first circuit boards came back from the factory they noticed some funny behaviour. Some diagnostics showed that two pins on the layout had been connected by a mistake in the design. It sounded as if this could be fixed quite easily.

I don’t really understand all the technicalities of Brian’s email but it doesn’t sound like the end of the world to me. I’m sure these glitches can be put right. But as we used to say back in my school days, Tempus Fugit.

It would have been nice to have a perfect prototype first time, but I think we all live in the real world and realise that “right first time” would require a lot of good fortune. It’s not really what Synapse promise (“Fail early and fail often”).

Tactless as ever, I asked Dave who pays for any delays. The answer is Exbiblio.

We’ve hit a few challenges in the hardware project. Here is an e-mail that Brian, the Electrical Engineer on the Falstaff project sent to our internal mailing list yesterday:

Well…The build of 20 units has not gone as cleanly as I had hoped.

There has been pretty low yield on the two PCBs. Less than 50% on the Main board and ~75% on the Button board.

For the Main PCB there are a lot of boards that have processor bus data lines shorted to each other.

For example one of the boards looks to have D8 and D10 shorted together.

If you look at the layout of the board, you’ll see that D8 and D10 are adjacent to each other at the board to board connector and under the SDRAM BGA. See the image below.

If you look at the left side, you’ll see two pins on the connector that are colored yellow. These are D8 and D10.

I suspect that they are shorted either under the J2 connector or under the U7 BGA.

I’m taking 10 boards over to PCA to morrow to have them x-rayed to see if we can locate the shorts, then fix them.

The fallout on the Button board seems to be a bit more random. On one board, the Left Illumination LED doesn’t work, on another the SM Bus data line is shorted to ground.

That being said, I’ve give 7 working board sets to Dave to get assembled into units. We’ll work on getting more working and assembled ASAP…

Here is an animation of the latest layout for “Rosencrantz” which is the next major version of the Exbiblio portable scanner prototype.

Today I came across this archived thread from MacRumors.com. I remember that day back in 2001, I was lurking on this thread… All the Mac geeks (at least the vocal ones) were dissapointed in the iPod. Check it out, it is funny reading it knowing how the iPod actually performed in the market and shaped culture.

One of the things that is facinating about Apple is that they can ignore popular opinion, chart their own course, and end up shaping popular culture. Something to think about as we begin to share early versions of our own products with the public. When should Exbiblio listen to feedback, when should we ignore it, and how do we draw that line?