Sonar for the visually impaired - Power supply design

Projects / Project Swiftlet 

I looked into the possibility of lowering the supply voltage for the microcontroller, but there don't seem to be much savings anyway as the power consumption for the VLPR (Very-low-power run mode) is below 1mA and stop mode is below 1uA. In VLPR, the internal LDO for the core voltage is reduced to bare minimal for 4MHz. For this application, that's plenty of speed.

The dual buck converter PAM2306D I used previously on my FPGA board is quiet good for light loads.

Input voltages from 2.5V to 5.5V

Only 40μA (Typ per Channel) Quiescent Current

Output Current: Up to 1A per Channel

Shutdown current is less than 0.1µA

The 80% efficiency for loads below 10mA is roughly the same ballpark as a decent 3.3V LDO and doesn't offer saving. The microcontroller is going to run off the battery directly with an ultra low quiescent current LDO. A PMOS can be used to control the power to the 6-axis sensor from the LDO.

The haptic motors will be controlled by a pair of NMOS. I will be driving the MOSFET directly from PWM pins. Even at low frequency, it is still a good idea to keep the input gate capacitance low. A low capacitance keeps the transition of On/Off short to minimize the losses in the MOSFET. I have not decided whether it should be powered from the battery directly or via a buck converter.

Diodes Inc DMG1023UV-7 and DMG1024UV-7 are dual PMOS and NMOS that have 60pF capacitance at $0.59 (CAD).

The Chinese Ultrasonic modules are for 5V. Looks like I'll need to do some extensive modifications or reverse engineering.

As for battery charging, it'll need to be wireless charging (weight/size issues) or by some self aligned electrical contacts.

Power Supply Design

The power supply in this design is a bit complicated as I have tried to accommodate the use for AA Alkaline battery for emergency usage as well as for international shipping due to postal safety regulations.

Aggressive power management is used to maximize battery life. The power supply is partitioned in segments so that the inactive peripherals can be powered off via P-type MOSFET (DMG1023UV-7).

I found this NLAS4157 from ON Semiconductor. It is a low resistance high current SPDT analog Mux designed for speaker for cell phone for $0.59 (CAD). The crosstalk specs isn't that great outside of audio frequency. It can also be used as a SPDT power switch as it is more power/space/cost effective vs discrete components.

• Continuous current +/- 300mA (absolute max) and about 2 ohms or lower switch on resistance.

Power management firmware

Here is the dependency graph of the component blocks. I like to draw these things out before coding.

• Each of the lower blocks depends on power from its upstream source. e.g. to turn on RAM, requires blocks: SPI Mem, Periph.
• A block can be turned off when there are no more dependence for power from its lower block.

I am going to try coding it in a table and an iterative loop inside a function to resolve the dependency, turn on/off the component etc. That layer of abstraction would be useful for porting/organizing my code.

I think this is what I am going to do:

• For each of the nodes in the graph, the following are stored

1. I/O port address, bit number and polarity
2. a bitmap of its dependants
3. a bitmap representing itself
4. a link to its parent

• There is a global bitmap variable to holds the current device that are on.
• Each time a node is enabled, it adds its bitmap to the global bitmap. It then iterates up the graph by following the parent link.
• Each time a node is disabled, it looks at its dependants bitmap. If it is set (shouldn't happens), it ignores the request. If it is cleared, it removes itself from the global bitmap. It then iterates up the graph.

Now the power management routes handles the power on/off and keep tracks of dependency. e.g. If I want to turn on Audio L, it know to also turn on Amplifier/DAC, Peripheral Supply and all the way up to 3.3V. If I turn on and off other devices using Peripheral Supply, it knows not to turn that off until all the devices on the rail are off. This simplifies the coding as the devices do not need to know the power dependency.

The following is captured current consumption using Mooshimeter. This is for using NiMH battery at around 1.3V. This is without putting the ARM into sleep mode etc. Power profile plots like this is useful for debugging and optimizing the design. Energy consumption can be reduce by only powering the peripherals or branches of power rails when needed.

The current consumption went up in discrete steps because at each stage ARM peripherals and power for external circuits are turned on. It managed to capture 2 of the 3 pings as spikes.

The following shows the debug shell commands during this test.

The decoupling caps on the power rail charges up as MOSFET turns on and this causes an inrush current that shows up as a bigh spike on the rising edge of the current step. I can try using the slew rate control and play around with the drive strength on the ARM I/O pin. There is also the pull down resistors that could be used instead of the output driver. This should slow down the rise time and reduces the inrush current.

Li-ion

A 14500 (AA form factor) protected Li-ion battery is used to power this device. A Li-ion charger (AAT3693) is used to charge the battery. For the prototype, I'll use a micro USB connector. I'll look into additional charger connector/contacts that doesn't involve lining up tiny connector after prototyping stage.

Freescale MCU

In VLPR mode, Freescale MKL16 core consumes 255uA (typ) while executing code in this mode.

Power saving can be achieved by putting the core in LLS during idling. This is the lowest power mode that the core can still recover via interrupts.

Note: Active peripheral also consumes additional power.

In deep sleep, the power can be restored by power cycling the switch and I'll probably use a momentary button and/or touch input for powering it up. The selector switch also has a 3rd position for turning it off during storage/shipping

A micropower LDO (MCP1700) is used to generate 3.0V for the MCU in run mode as well as sleep mode. The low quiescent current (1.6µA typ 4uA max) makes this part ideal for battery operation.

6-axis MEMS

The 6-axis MEMS (FXOS8700CQ) is also powered from the same LDO 3.0 supply. The device can run in low power mode (~8uA) and can be used to interrupt and wake up the MCU when it detects movements. It can be shut off to save power in deep sleep via a PMOS switch.

Peripheral Supply

A buck converter (AAT2120) is used to step down the Li-ion to 1.5V or 3.0V for the more power hungry peripherals. The converter can be shutdown by de-asserting the enable input. It can goes from off to full regulation within 100µs. This allows for very aggressive power management. By changing the voltage divider under program control, the converter can also output the 1.5V for the haptic motors.

AA Cell Mode

While this mode is intended as an emergency back, I'll still try to optimize the power consumption.

A high efficiency boost converter (MCP1640) is used to generate 3.3V supply from an alkaline/NiMH battery. During low load, the MCP1640 automatically switches to PFM (Pulse Frequency Modulation) mode to maintain good efficiency.

The PFM quiescent current is 19µA (typ) 30µA (max). While this might sound high, the amount of battery capacity for 2 weeks, 16 hours days is only 4.25mAHr out of ~2700mA*Hr of an Energizer E91 Alkaline AA. 19µA x 16 hours/day x 7 day/week x 2 weeks = 4.256mA*Hr

The 3.3V is regulated down to 3.0V in this mode. Since the LDO is there might as well use it to protect the MCU in case of an incorrect battery switch setting. The motor in this mode is powered from the AA battery directly to improve efficiency.

Editorial note: It turns out that PFM does not play well with analog circuits as the switch frequency dips low enough to affect the low frequency band.  They do have a version of the chip with same pinout  without PFM at slightly lower efficiency for low load.