JellyfishOPP (Open Power Profiler)
is will be an affordable open-hardware measurement device
designed to provide advanced, bidirectional power measurements, power optimizations, and battery
profiling/simulation. It primarily targets developers of ultra-low power devices such as IoT sensors
and wearable electronics, while also serving engineers and hobbyists. OPP will be a portable USB
device that can be controlled through a host computer or smartphone app. Additionally, it will
feature a simple on-device user interface for basic functionalities, eliminating the need for a host
device in certain scenarios.
This will be the main page regarding the development of the device with all of the links to future followup posts and details.
- 2023-11-06, Update #1: detailed project description / specification
- 2023/11: research, evaluation, simulation, detailed specification - DONE
- 2023/12: schematic design for the first prototype
- 2024/01: PCB design for the first prototype, PCBA order
- 2024/03: initial testing, basic firmware elements, PCB/schematic fixes, ...
- 2024/??: second prototype, firmware development, ...
- 2024/08-09: production ready hardware, basic firmware, basic host software (EEZ Studio integration, standalone app, ...)
Why "Jellyfish"? The jellyfish (at least according to some random web site) are one of the most "low power" and efficient animals in the world. Also "Jellyfish" sounds much more recognizable and cool name for a device than just generic "open power profiler".
Few years ago when I started working on low power devices I needed a way to (relatively) precisely measure the current consumption of a device. I even wrote a post about it here with an approach of using SiLabs development board for measurement and had an idea of developing a specialized device for this purpose. As I've been in the low power development since then, I've also seen other available tools.
Other than professional source measurement units (SMUs), in the somewhat lower cost range (at least compared to SMUs) there are Otii Arc/Ace and Joulescope and in the really low cost range there is, among some others, Nordic PPK2 which definitely takes the first place and I've used it the most (there are also current measurement amplifiers such as µCurrent and similar). Otii devices and Joulescope are amazing tools with really high end performance and some nice additional features (battery simulation/profiling on Otii devices for example), but their cost (with additional software packs) are out of the reach for most hobbyists or solo engineers.
On the other hand, Nordic's PPK2, while covering a lot of use cases, still has some pretty significant limitations, namely:
- output voltage limited to 5V
- limited current
- no proper filtering/bandwidth limits making it easy to take wrong measurements in cases of really short pulses
So I got the idea – I should design some sort of crossover between PPK2 and Otii Ace: low(er) cost, good performance (without going into rarely used features that complicate things a lot, like a precise nanoampere measurement range) some nice additional features (battery simulation, flexible routing) and, quite important, to make it open source hardware so others can learn from it and make further improvements. Plus, due to the portability, flexible power routing and onboard display+encoder, a set of additional features can be added for using the device without the host computer (low bandwidth oscilloscope, power supply, signal gnerator, multimeter) making it a perfect (multi)tool for using as a part of the field kit.
I still haven't decided on all of the details (that will happen in the next few months after some evaluations) but the initial proposal specified the 100-200khz sample rate, automatic range switching, 1uA to 3A bidirectional measurement range (both source and sink), 0-15V output, battery profiling/simulation, general purpose inputs synced with measurement, portable size. After giving it some additional thought I'm thinking about adding a cheap FPGA to handle all of the sampling needs and increasing the sampling rate to 2-3MS/s (with about 200-300khz of measurement bandwidth) and to let the main processor just handle the data transfer and UI.
I just started working on it and expect to finish it over the next 7-12 months. All of the updates related to the development will be published here.