MoPi level 3 is now in testing :-)

[MoPi is mobile, hot-swap and 24/7 power for the Raspberry Pi. How to order.]

This is, we hope, the final pre-production prototype board. It differs quite a lot from the previous prototype (which is the one you may have seen on our Kickstarter page — if you missed it you can sign up for pre-orders here). The success of the crowdfunding campaign allowed us to add a bunch of new features (aka stretch goals). The new board has these new hardware and firmware features:

• screw terminals
• stackable headers
• remoting pads
• self-resetting fuse
• two-way communication using I2C
• remote power-off
• 3.3V supply mod
• timer-based wake-up

This post describes some of our work on testing the new board and on updating the SimBaMon software that manages it from the Pi. Then we look at a possible arrangement for adding battery charging to the picture, and finish up with a revised delivery schedule.

1. The Final Prototype

Here's what the level 3 revision looks like (without the wiring connector or the GPIO connector or the power switch, which were soldered by hand after these pictures were taken):

Top of the board:

Underneath the board:

The stackable headers (for when MoPi is used in tandem with other add-on boards) take up quite a lot of vertical space in order to provide a set of pass-through pins above the MoPi board. Therefore we're offering two versions, one with the stackable header and one with a standard low-profile header. (If you're a backer you'll have had a message about filling in a survey form on which one you prefer.)

This is the stackable header that we're using (from Adafruit):

If you're opting for the low-profile header you can see an example here, on the level 2 board: .

2. A Possible Charging Circuit

One feature that we didn't manage to get sufficient backing for was battery charging. This feature would be a great addition to MoPi, but it turns out to be pretty difficult :-( In fact, dealing with lots of different chemistries may not be possible at all on a tiny device like MoPi. (Most manufacturers of charging ICs only support one chemistry per chip, for example, and some only support charging a single cell per chip! Many chargers also rely on having a temperature sensor in physical proximity to the batteries themselves.)¹ The other challenge is that we've got a really small surface area to work with on the PCB.

Still, a number of our backers want to use MoPi with a charger (e.g. to charge batteries from solar panels during the day and then run on batteries overnight), so we've been working on a configuration with an external charger. For example, here's how we think a UPS configuration with charging could look:

We haven't tested this yet, but it should work ;-)

There are a number of potential gotchas in this type of circuit. For example, when the mains power drops, the Pi must be powered pretty much instantly in order to avoid triggering a reboot. There are no big capacitors on the Pi's PCB to buffer its consumption of 300-500 mA without power. To deal with this requirement we need MoPi to be always on and monitoring the Pi's 5V feed, even when that feed isn't being supplied by MoPi itself. (This doesn't waste much power as our microcontroller is very efficient.) When MoPi sees the 5V rail start to fall the controller immediately enables its 5V stabilizer, taking over supply of power to the Pi.

In the circuit above, when there is mains, the charger is generating e.g. +12V DC and the relay's coil is energized. The contact is switched to the normal open position and is passing +12V to charge the batteries. When mains drops, the relay is switching to the normal closed position and charging will stop. MoPi is powered all the time — and so, we hope, is the Pi. (What does the diode do? When the +12V goes down, accumulated energy in the relay's coil must be dissipated. The diode is shorting the coil to do that. Otherwise the relay's contact will stay closed for a longer time.)

More on this when we get time to test it out in practice.

3. Revised Schedule

I love deadlines. I love the whooshing sound they make as they rush past. [Douglas Adams]

Ok, we're a little behind. We launched a week later than the plan (my fault — I didn't allow enough time for the Kickstarter approval process²), and then we ran for a week longer than planned, and then we met our stretch goals for several things that required additional changes to the level 3 prototype board, not to mention orders from suppliers we haven't used before.

This means that we've only now started testing the level 3 board, approximately a month behind the original schedule. We've also got some significant changes to make to the division of responsibilities between the software running on the Pi and the firmware running on the MoPi microcontroller. The latter is extremely important to get right for the production boards, as flashing a new firmware revision requires special hardware.

Our best guess for the delivery of version 4 (for our Kickstarter backers) and then version 5 (for pre-order subscribers and for retail supply) is now as follows.

(To cut a long story short we now plan to start delivering Kickstarter rewards in May. If we hit issues with component supply or that require hardware revision this might slip to June.)

• Complete prototype board level 3. This is now done for the hardware and we have the boards in testing. Firmware and software changes remain to be done. Supply boards to Pimoroni who are designing the custom PiBow lid.
  • Completion: mid April 2014.
• Finalise the design of the production board. Fix any residual issues arising from testing. Incorporate any feedback from testers. Start ordering components, kit parts and PCBs in bulk. Finalise the pick-and-place manufacturing process and start pre-production testing. Continue work on the firmware and produce the production binary for flashing to the boards. Address any stability issues in the daemon code.
  • Completion: end April 2014.
• Start taking delivery of the production boards. (This is our last opportunity to make firmware changes. Test, test and test again!) The daemon needs to be very stable by now.
  • Completion: late May 2014.
• Fulfill early bird Kickstarter orders for all single item and kit rewards. Solicit additional GitHub committers for the daemon code to help with long-term maintainability.
  • Completion: end May 2014.
• Fulfill any remaining Kickstarter orders.
  • Completion: June 2014.
• Set up sustainable production process and retail board supply and fulfill retail pre-orders.
  • Completion: Summer 2014.
• Collapse in a small pile.³

Read the main article.

Footnotes

1. We like our backers. We'd rather not incinerate them if not completely necessary.
2. I pressed the big green submit button on the Kickstarter 10 days before our planned launch date, which was the last Friday in January — payday! The FAQ said it could take up to a week to get approval, but I should have allowed more time as in the end it took double that and we didn't launch until the following Tuesday. This turned out to be a costly mistake on my part. I'd lined up publicity from a really important site for that Friday, but by the time we were ready the person concerned had gone on holiday for two weeks — and when they came back they had mysteriously changed their minds. From the way the new backer curve played out during the month it was clear that publication on that site would have made a huge difference — perhaps double the number of backers. This would have taken us over the magic 1000 units milestone, where bulk component prices drop sharply, and allowed us to add several really nice features to the board. Hey ho. Life is random!
3. I might bring this one forward a bit depending on whether my partner agrees I'm due for my mid-life crisis yet or not.

comments powered by Disqus