Introduction
Sometimes it is interesting to make test equipment, even if it can’t replace commercial products. Through making it, I learn about my limitations too, but it is also an opportunity to explore and make things that commercially may never make sense due to limited appeal or functionality.
This project is exactly that - a unusual and fairly restrictive project today, but with some uses, and there is potential to modify and adapt it : )
The 3-minute video here explains the project briefly, and shows a demo of it all.
It’s main limitation today is the small output range: 5V DC max, at up to 1.5A. Due to the limitation it cannot replace a general-purpose main bench supply.
Anyway, enough negativity about my own project in the introduction: ) On the more positive side, this project can still offer a few handy capabilities for some projects I hope. The functionality it provides is a mix of a power supply, an ammeter and voltmeter and a data logger with dynamic display, all mashed together basically. Unlike other power supplies, this one continuously charts current consumption, so you can visually see even quite slight fluctuations in the circuit-under-test, at all times. This photo is showing the brief spikes in current every second, from a desk clock.
It is a surface-mount project, but it’s achievable with a normal soldering iron.
The solution overview diagram is shown below. Apart from the main board, all other parts are off-the-shelf low-cost modules.
Background to the Project
The very first project at uni that we had to work on was a bench power supply : ) It taught us how to wire mains plugs, what things to do for basic safety such as strain relief for cables, and how to heat-sink the voltage regulator so that things don’t overheat : ) Nowadays there are more tighter rules concerning mains operated projects, so it probably wouldn’t be constructed in the same way today.
Fast-forward into the IoT age, and I was focused a couple of years ago on testing portable low-power devices that would occasionally draw a lot of current, but for very brief periods.
Many devices sleep for long periods and then occasionally chew up a burst of power to process or transmit data. It’s quite difficult to catch the bursts but also capture information about how frequent the burst occur. If this information were available, it would be possible to see how long batteries may last for, or to discover if the device is transmitting unnecessarily frequently. There are many scenarios where it could be handy.
As a result of this need, I started Project Morpheus which was a battery simulator. It was to be used to on-the-fly simulate a battery under dynamic conditions, and predict battery charge usage. It’s still a work in progress. However, enough of it works that it can already function as a basic power supply with logging capability. When/if the code is complete, lots of functionality is opened up. Currently it can be used for powering and monitoring circuits, and logging data at several thousand samples per second, i.e. good enough to see sub-millisecond bursts of current demand, but it is possible to increase that with some more effort in the software. The code is just prototype quality currently.
The Project Morpheus main board detail can be found in some earlier blog posts (See Building a Battery Simulator - Part 1 and Building a Battery Simulator - Part 2 and Building a Battery Simulator (Project Morpheus) - Part 3 ). The circuit diagram and the PCB files are attached to this blog post. I still need to generate a bill of materials (BoM), that will be complete in a few days.
Hardware Overview
The earlier diagram shows the Morpheus board connected to a NXP FRDM boardNXP FRDM board. The FRDM board is a bit like an Arduino – it can be coded using near-identical commands.
Any controller board can be hooked up, provided a serial peripheral interface (SPI) is available. Eventually I will swap to a Linux board such as the BeagleBone Black.
The diagram below shows the Morpheus board functionality.
The entire left side of the board contains an adjustable voltage regulator and some heatsinking for it. Power is applied to the board at the bottom. The microcontroller board is attached to the I/O connector at the bottom-right of the board. The SPI bus is used to configure the digital-to-analog converter (DAC) that controls the adjustable voltage regulator. At the output of the voltage regulator, there is a sense resistor and amplifier circuit to create a voltage that varies as the current changes. There is a small connector that can be attached to an oscilloscope to capture this. The right side of the board contains an analog-to-digital converter to pass the measured current value to the controller board. For voltage readback (to confirm the DAC and voltage regulator are behaving correctly and for auto-calibration), a voltage proportional to the output voltage is available to the microcontroller (so that the microcontroller’s ADC can be used to monitor it). However things are still reasonably accurate (typically within 10mV) even without such calibration, for an unloaded supply. Once the supply is loaded, I see about 27mV drop at the board output terminals, at 5V 500mA load. A lot of this (15mV) is due to the sense resistor, and so power calculations can be quite accurate if this is taken into consideration in the software.
There are a couple of other bits of minor functionality, but the key areas have been covered.
For the user interface, the TFT display was an afterthought but it works quite well. But, generally so far the user interface is crude. The USB connector on the FRDM board exposes a serial connection (at 115200 baud) to a connected PC, and there is a basic menu system to select the desired output voltage. This of course is inadequate, and eventually some isolated interface (e.g. Ethernet) will be used, as well as a keypad or touchscreen control (for example). I’ve not given that much thought so far either.
This project is restricted to 5V output maximum, because I’d originally intended it to simulate a single LiPo cell. This is very restrictive for a general bench supply, but still lots can be done because many portable projects operate from 5V or lower voltages.
The maximum current is 1.5A, but the maximum measurable current can be optionally lower, depending on an on-board current sense resistor value. A future implementation of this project could have switched sense resistors. Currently I’ve soldered a 30 mOhm sense resistor to the board, which allows me to measure up to 700mA. If I need to measure up to 1.5A then I’d need to change the sense resistor.
Anyway, 1.5A or 700mA, at up to 5V, should hopefully be sufficient for many IoT projects. This project is really just a prototype, and it could be redone one day with higher voltage and current ranges.
The Morpheus board requires 5-5.5V for operation. With a 5.5V supply, the output can reach the full 5V DC, however the maximum possible output is slightly lower if a more commonly available 5V supply is connected. But for most circuits, the difference is negligible. If fitting in an enclosure, an enclosed chassis AC to DC PSU could be used, as they often have a trim adjustment for setting non-standard voltages provided it is close to the stated voltage.
What Functionality is Implemented?
The hardware functions, but the code needs a lot of work.
From the USB serial menu system, it is possible to set a value for the desired output voltage (in millivolts) and switch the output on or off. With a bit of software effort, extra features like current limiting or electronic fuse could be implemented.
By default the system displays on the screen a chart of current consumption, at 10Hz. This is fast enough for casual observation of current consumption perhaps. From the menu it is possible to capture at a faster rate (a few thousand samples per second today, but it could be improved), and it displays a snapshot of about two seconds of capture. There is no permanent log today (the plan is to log to a micro SD card because the FRDM board has a socket for this) but once it has filled its buffer (hard-coded currently to 10,000 samples) it does dump the measurements to the USB serial console. PC serial terminal software can be configured to capture to disk, and then the file can be imported into MATLAB / GNU Octave. It is hardly convenient, but this will be improved later.
Also, as mentioned earlier, there is an analog amplified output suitable for directly attaching to an oscilloscope too.
Using It
Here is an example of how it can be used currently. I set up Project Morpheus to supply 4V to an external device, and monitored the oscilloscope output, to see the current consumption.
The oscilloscope trace below shows the current consumption. It is clear that the connected load is of low power but is occasionally demanding short bursts of current (circled in red because they are hard to see). These bursts occur every second, but they could be more rare, and you may want to capture for many minutes or hours. This ‘scope has 8-bit resolution so the noisy looking stuff at the bottom isn’t very clear. Oscilloscopes aren’t intended for logging for such long periods.
Here is the output captured via the USB serial dump and then imported into MATLAB; it looks similar to the ‘scope capture:
But, it is possible to zoom into this. In the chart below, the vertical axis has been changed to logarithmic, so the low-level detail is clear as well as capturing the short bursts. Now it can be seen that as well as the short 10 msec bursts of heavy current, there is some small fluctuation in current consumption at other times, in a repetitive pattern.
Based on the sample rate, it is now possible to deduce that the tiny stuff at the bottom is remnants from a 50Hz source (UK mains).
Here’s another example; I attached a Raspberry Pi 2B+ onto the output, set it to 5V and turned on the output. This photo shows the chart on the TFT screen during Pi boot-up for the first 50 seconds – this is from the slower (10Hz) logging that occurs continuously, it doesn’t need any configuration. I figured that way, one is more likely to catch interesting behaviour, by having the system continuously charting always, whenever the supply is used.
I really liked having this continuous view, because I could see the slight changes in current (the vertical resolution is 2mA per pixel on this chart) whenever I typed commands or executed anything. It would be possible to optimise software for portable battery operation with this power supply.
As another example, I set the y-axis to 1mA per division (currently it is hard-coded so I had to edit the code to do this) and the horizontal setting to 2 seconds per division, and then attached a small analog table clock to the output. It uses a single AA cell, so the output voltage was set to 1.5V.
It was possible to see each spike as the clock moved its seconds hand. This is quite an extreme test for the continuous charting feature though, because each spike is very brief. Apologies for the poor photos – the resistive touchpad on the TFT screen is very glossy : (
From the menu system the high-speed capture was started, and it logged to a buffer for a brief period of time. Here is the output:
Currently the x-axis doesn’t update for the high speed capture. Also, it just plots data points (with no attempt to join the dots) in the high-speed logging mode.
Anyway, it can be seen from the circled content in the photo above that the burst seems to have two mini spikes. To see more detail, the analog output connector on the board can be attached to an oscilloscope:
What Performance does it have?
Performance has not been measured. Things seem reasonably accurate for the use-case. For resolution below 100uA, it would be worth using a different sense resistor. Most home battery-powered IoT devices demand bursts of current nowhere near 700mA or 1.5A, so changing the sense resistor value could be a reasonable compromise.
For more accurate measurement of standby current, an ammeter should be used. But for seeing trends such as bursty increases of current consumption, Project Morpheus could be handy hopefully.
How to make it?
There are just a few steps. The Morpheus board needs to be constructed of course, but it is a straightforward exercise. The board files are attached to this blog post, for sending to a PCB factory. The parts values can be found from the schematic, but the bill of materials will be supplied shortly too.
Then, it needs to be attached to the FRDM board (using jumper wires). Next, the FRDM board software needs compiling and downloading into the board. That should be sufficient to test the solution, using the USB serial menu capability! Finally, the TFT screen can be attached. All the steps are detailed below.
Morpheus Main Board
The Morpheus board is nearly all surface-mount, but most of the parts are very easy to solder on although a few take a bit more care (but feasible with a normal soldering iron). There is a DC jack for supplying 5-5.5V DC to the board.
A load of jumper wires can be used to patch out to the FRDM board. Eventually I may make an ‘interconnect PCB’ to simplify this, for either the FRDM board or BeagleBone Black.
FRDM Board Software
Next, the software for the separate microcontroller board needs compiling and programming into the board. There are two main ways to do all this. One way is to get a free account at mbed.com and use the online text editor and compiler. Once you click on ‘Compile’ in the browser, the binary output file will be downloaded to your PC and you can drag-and-drop it to the microcontroller board (it has a USB connection that looks like a USB memory stick). The other method is to download an environment to your PC, called mbed-cli. It allows for the software to be coded and compiled on the PC instead. For this project, I took the latter approach and it is discussed below.
Setting up and using mbed-cli
Follow the instructions here: ARM mbed-cli
As part of that, download and extract gcc-arm in a folder.
Then notify mbed-cli about its location, using this command (change the path to suit where you extracted gcc-arm):
mbed config -G GCC_ARM_PATH "/home/shabaz/development/mbed/gcc-arm-none-eabi-7-2018-q2-update/bin"
Create a new project using:
cd development/mbed mbed new K64F-battsim cd K64F-battsim/mbed-os
Then as root user:
pip install -r requirements.txt apt-get install gtkterm
Now go back to the development/mbed/K64-battsim project folder, become a normal user (i.e. not super-user) and type the following to install the TFT library code:
mbed add http://os.mbed.com/users/WiredHome/code/RA8875/
Download the code attached to the bottom of this blog post, and dump everything into the K64F-battsim folder.
Edit the Makefile. The line to modify has my username in it. Change it to your username. The FRDM board looks like a USB memory stick to the OS, so the line containing /media/shabaz/DAPLINK needs changing to whatever path your machine chooses. If you're not sure, just plug in the board and then have a look what file system path gets mounted.
After you've saved the Makefile, you're ready to compile the code!
make
Next, to install the code into the FRDM board (assuming it is plugged in) type:
make install
You should see a green LED close to the USB socket on the FRDM board flash briefly as the code is transferred into the FRDM board.
To connect to the USB console to see the menu system, as root user type:
make console
It should automatically open up a window and connect to the USB serial connection. If it doesn't work, you'll need to edit the Makefile and change the line containing /dev/tty/ACM0.
TFT Screen
The screen is available from many vendors on aliexpress and likely ebay too. There are several variants. The one to get should operate from 3.3V and configured for 4-wire SPI operation. There are versions with resistive or capacitive touch capability, but that has not been implemented in the code yet, so this is optional. The model number of the display is ER-TFTM050-3 and when configuring it to purchase, make sure 4-Wire SPI, and 3.3V operation (not 5V) is specified.
To operate the screen from the same 5-5.5V source as the rest of the project, a DC-DC converter is needed to convert to 3.3V. This could be an off-the-shelf module, or it could be constructed using an IC. I used a ST1S10 chip and followed the datasheet to construct this.
Summary
Although a lot more work needs to be done, the basics of a 5V 1.5A logging power supply were presented. It is quite a straightforward project, and I think is worth the effort to assemble, even though it will never replace a general purpose supply for the lab.
The next step is to get it all assembled into an enclosure and work on implementing more features!
Appendix:
PCB Renders
Most parts are installed on just one side, but a few passives and a serial Flash memory device are installed on the underside. The memory isn't used currently, but will eventually be used to store board-specific calibration data if desired.
To construct the project, the voltage regulator and DAC portion could be assembled first, and checked that the output is as expected by (say) running a test program on the microcontroller board. Next, the current sense amplifier and analog current measurement portion could be assembled and tested. Finally, the ADC part could be assembled to complete the functionality.
Issues Tracking
Revision 1 PCB
There are no known electrical faults with the PCB, however the following tweaks could be made in a future rev 2 board:
- C6 pad needs to be increased from 0603 to 0805
- Replace OUTPUT LED with a red LED instead of green
- T2 and R13 text is touching each other
- Move text J1 slightly right
- Perhaps better silkscreen for the 20way connector (J4)
- Move text J4 slightly right
- Electrolytic silkscreen needs marking with semi-circles to indicate polarity
- U4 silkscreen needs a dot, not an asterisk
- Change MOSFET names T1/T2/T3 to Q1/Q2/Q3
- Change R14 from 1M to 10k, to protect the MOSFET better
- Consider replacing the DAC with a more coding-friendly one
- Consider Welwyn OARS (OARS1) series current sense resistor, it has lower temp coeff. for the same price (but is physically larger)
Attachments
These are the attached files, linked below:
export-battsim... : PCB Files
K64F-battsim-export.. : Source Code
main.pdf : Schematic
 | main.pdf |
Top Comments