MoPi++: Version 5 and Beyond

   

Hot-swap Mobile Power for the Pi

**** Please don't link or distribute this page ****

Hamish Cunningham, Lubo, Fred, August 2014—...

This page discusses use cases and candidate requirements for MoPi Version 5, which is intended to be a retail version (or versions — we will probably move to several different models at this point).

1. Versions

Let's call the current version MoPi Classic, and upcoming future version(s) MoPi++?

MoPi has been through four versions so far:

1. the initial prototype (with separate regulator and controller boards)
2. the almost-fits-in-a-pibow prototype
3. the pre-production Kickstarter prototype
4. the Kickstarter delivery board (in both stackable and low-profile variants)

Version 4. (MoPi Classic) is a production quality board, and is available via the pre-order page.

MoPi Version 5 (MoPi++) will be a retail version (or versions — we will probably move to several different models at this point).

If there is demand we may maintain availability of MoPi Classic even when MoPi++ variants become available.

2. Use Cases

2.1. Laptop, UPS

Two very common uses to which our backers wish to put MoPi are:

• laptop-style devices (including tablets, portable music players, phones and the like)
• UPS devices (catering for intermittent power disruption)

A UPS and the power subsystem of a laptop actually behave in very similar ways — when there is external power it is used to both power the device and charge the internal batteries; when the power drops the batteries take over. (If there is a difference between the two, it is that for a laptop fast charging is an advantage, whereas for a UPS this doesn't matter too much.)

For laptops in particular a reasonably accurate estimate of remaining battery life is required. Hot swap of batteries is also an advantage.

Implications:

• we can only support these use cases with specific defined battery configurations
• configurations requiring external charging are excluded (which rules out the 8x NiMH holder configuration, for example, unless we manage to build in a specific charger for that configuration)
• we should support several combined battery/board configurations of different weight — a user may want to power a whole laptop rig and have plenty of space for heavy batteries, or just power a Model A+ with a small LCD and a few buttons on it for a music player, for example)

Another common use case is in-car; in which case the ability to track the vehicular power supply is important.

2.2. Solar

The user wants to power a Pi from solar panels. Probably they also want a battery backup for when the sun goes in or down, and then they naturally want to also charge the batteries when there is excess power avaiable.

A variant of this use case is where mains power is also available. Now the user wants to use all the solar power that is available, but if there is insufficient current to supplement it with mains power. Again a battery backup will need to be kept charged.

2.3. Wireless Power

This is a somewhat artificial use case, which is more technology push than user pull, but it seems likely that wireless charging will become widespread (you can already use it in some big restaurant chains in some countries, and IKEA is rumoured to be building slots for charger coils into new furniture designs).

In addition Würth Electronics (under contract from TI) are keen to see development of 3rd-party boards incorporating their coils, and no doubt other big suppliers are working in similar directions.

The main choice for us is between

1. an integrated board that combines both circuitry from MoPi and from the Würth demo boards, or
2. a composite device that includes a MoPi and a 3rd-party receiver-side coil as separate circuits

In the latter case we need to support 5V input; in the former we have quite a difficult integration task due to the sophistication of the components on the Würth example board (which is a 4-layer board with microscopic components!).

Note: this is likely to be mainly a charging technology; i.e. it only really makes sense when we have a specific device with integrated batteries and charging.

2.4. Multiple Boards, Multiple Boxes, Multiple Physical Interfaces

Inevitably people want to use MoPi with other add-on boards and in lots of different types of cases. They also want to put the physical user interface components (the power switch and LEDs) in other places.

2.5. Remote Monitoring, e.g. Kinder Scout

Several backers have described remote monitoring applications, e.g. one whose Pi wakes up every few hours and takes a photo of a building site.

There are also many scientific and environmental applications. Kinder Scout is a hill in the English Penines covered with a large area of peat bog that has suffered erosion due to acid rain degrading the vegetation that normally binds the soil. My brother volunteers as part of a project that began by analysing the conditions causing the erosion, and then reseeded the area with new vegetation. The project uses a set of dip test wells which contain sensors that read and store data about water conditions periodically.

Project staff visit once a week to collect the data from the sensors. We can envisage a Pi-based solution using MoPi, if we can attain e.g. 2-week run-time without a huge battery.

Another requirement here is accurate time keeping — perhaps available if we hook up MoPi's RTC properly?

2.6. The World and Her Dog

We shouldn't forget what is distinctive and attractive about MoPi Classic. Most of our backers didn't buy batteries from us — they use their own, or they plug in solar panels, or an old laptop power supply, or their car cigarette lighter, or etc. MoPi Classic copes with all of these.

We need to continue to support diverse supplies, hot swap, and all the rest. Indeed in some cases we should try and improve on current facilities.

Implication: where we start (in MoPi++) to support use cases which will only work for specific configurations we need to layer these on top of the underlying flexible engine that we have in MoPi Classic.

3. Implementation Notes

1. In some cases we will need to define the battery set. We have a choice of NiMH, Lead Acid (for UPS or solar devices) and LiPo. NiMH wins over LiPo for safety; Lead Acid is only appropriate for static devices.
2. Several use cases will be easier to cater for if we put a micro USB on MoPi and mandate the connection of mains-driven (5V) supplies there. We might even support options like solar and wireless this way (as there are solar rigs available now with 5V regulators built in, or we might sell a simple 5V regulator for the 18V panels).
3. To support the maximum number of boxes and combinations with other boards a separate "bus board" PCB that duplicates the GPIO pins looks like a good solution. This could be arranged in both horizontal and vertical versions, with 2-way and 3-way options.

4. Candidate Requirements

All Pi models. Improve support for the 3 by avoiding resting on C1 (is this still an issue with the latest boards?). Continue to support the Models A, B, B+ and Zero. Support the Compute Module (though this is not yet a major use case, it is likely to increase in future). This means:

• 2.5A max output. (The 3 will supply close to 2A over its USB connections, and also requires power for other components.)
• More flexible / lower cost GPIO connection. We need only 6 pins now, and might use a small low-profile connector coupled with an optional "bus board" to allow stacking of additional boards as required (with versions for both A/B/B+, 3 and Zero). For better ground connectivity we might also go with 10 pins.
• For the compute module we should copy the open developer host board and add MoPi functionality to it.
• Switch and LED's to be side-facing (to support both A/B and B+/3), with enhanced remoting options.
• HAT.

5V input. If we support 5V input then we can support wireless charging, and more battery pack configurations. If we support input voltages down to 3.7V we can support single LiPo sources.

Charging. A common user requirement is charging, usually for applications involving one or more of:

• uninterruptible power
• solar power
• laptop-style operation

In each case there is a mains-derived or solar-derived input (often 5V but also up to e.g. 18V) which comes and goes. When present it should trickle charge the batteries; when absent batteries should be used to power the Pi in the normal way.

Which batteries?! We've worked hard to support many different types of battery and non-battery as viable input supplies. We can't do this for charging though — we should pick whatever configuration makes best sense and support only that. (E.g. multiples of 4 NiMH, or lead acid, or some pre-packaged LiPo.)

Wireless power. See above.

Incremental improvements.

• Remoting pads (with holes) for switch and LEDs.
• When a current-limited input is attached and results in <5V out of the regulator (e.g. solar panels during cloudy spells), the microcontroller should refuse to power the Pi. (Otherwise we can see situations where MoPi tries to supply 5V, fails, and ends up sending an inadequate supply to the Pi.) So the input LEDs (and status sensing) should respond to current, as well as voltage.
• Add a halt script to simbamond to trigger after the filesystems are unmounted (in rc0.d) that will ping MoPi and say "halt now". (The firmware should halt 45 secs after power off requests anyhow, if the ping doesn't come.)
• Add a "boot complete" signal from simbamond to MoPi. The 60 second power-on delay is too conservative. Let's reduce it to 2 seconds like the current version of simbamond.
• [Rejected? Not relevant if we add micro USB 5V input?] The 3.3V feed on the Pi should be used to power the microcontroller to maintain consistent power to MoPi when in UPS-type configurations.
  • Notes from Fred:
    • The main scenario for the 3.3 feed would be so that you could configure/query the MoPi without having to have batteries connected. Then you could have I2C commands to start/stop the regulator, i.e. a software power button.
    • A 5V micro USB on the MoPi itself that supplied the 3.3V to the micro-controller would probably do this as well. However, because of casing issues it still might not always be used. For expert users maybe a solder bridge/jumper on the board that could be used to enable a 3.3 feed from the Pi to the MoPi? I know for example that my Lego cases would probably need to be redesigned heavily to accommodate a 5V feed on the MoPi board.
• It is quite frequent to get a blinking source amber LED when there is no power on a particular source (even with no power connected at all).
• It is quite frequent in development to wish that the power inputs would reset on rising voltage, and not have to power down to cycle this behaviour. This is likey to increase when we support more laptop style, solar and UPS devices.

Nice to have...

• In-situ firmware re-flash. (Probably too expensive.)
• Persistent config data. (Probably too expensive. Also risky when the microcontroller can get into inconsistent states.)
• RTC functionality with Linux driver. (Requires investigation of existing kernel support for particular chips; one may match MoPi...)