I am revisiting a project I started quite a while ago in preparation to set it aside as a winter project. I have so much to do on the outside of our house that I can't approach this now, but when I take refuge in the house against the winter, I want this project waiting for me.

I'd like to go as far as ordering some parts to start the prototyping straight away. Momentum is important for my brain.

So, here's the deal. This project is designed to produced a supremely useful device while also stretching my knowledge and skills in areas where I currently lack depth or that are effectively absent. To that end part of this project involves designing the PCB(s) and the case—two things I am not an expert in.

So, here's my request to you, AAC pals, join me in brainstorming this thing. For today, budget is not an object. I want to think of the best version of this and see which features turn out to be easier than expected to include, as well as which appeared easy but turn out to be hard. Please join me in trying to rough out a design of something you would like to have in your bag.

Here's the pitch:

The... err... PABS (Portable Agile Battery Supply, not a real name) is a highly compact programmable power supply intended for use wherever DC power up to, say 40V might be needed. This includes simply powering devices, acting as a bench supply, may profiling power consumption, etc. The PABS is a must have tool for technicians and hobbyists who work on the go.

The marketing hype:

The PABS is incredibly advanced and flexible. It is fully computer controlled and fully instrumented:

1. Advanced MCU control provides programmable presets, power cycles, and supervision for unprecedented control over power and protection against OV/OC
   
   
2. Serial-over-Wire, Serial-over-Bluetooth, WiFi (AP and client modes), and Ethernet Connectivity for easy access to the microcontroller via a robust API
   
   
3. Sensors for voltage, current, temperature, and humidity—as well as an IMU that can be read out for data acquisition or used to trigger API calls

The PABS is designed for flexibility:

1. Matrix switching of the 10 cells in the pack allows for complete flexibility in battery configuration from 10P1S to 1P10S and anything in between, providing highly granular voltage vs. current selection for the task at hand.
   
   
2. Output terminals include four shielded 4mm bananas, allowing the switching matrix to be connected to different battery configurations or used in tandem on one battery; XT60 for high current applications; 5.5mm barrel jack, USB A for simple charging, USB Type-C with PD for advanced power and charging applications
   
   
3. Input terminals include USB Type C, XT60, and 5.5mm barrel for charging or supplementary power selectable via the switching matrix.
   
   
4. Data I/O terminals include RJ45 Ethernet and USB Type-C serial, with a built-in USB to UART converter.

The PABS is designed for modularity, offering both power and control bus connections for future additions, as well as a robust docking mechanism on the housing to attach new modules. These could include additional battery, displays, HID, cooling, or any other useful addition.

So, this is the completely blue sky version in a nut shell. Of course, even if it gets to this level, it will be iterative. My goal in thinking so expansively is to understand how to accommodate future expansion of the practical first generation versions. I want to avoid, so far as possible, building in dead ends, and also to explicitly build in pathways to expansion in the architecture and implementation.

I would really love to hear your ideas about this! Either about the possible best options to implement the described feature set, or other features, or both. This is brainstorming, you don't have to be "practical" in the normal way. Just stick to exciting, possible, things and let me know your great ideas!

 

Interesting concept Ya'akov.

You might want to revisit the '10 cells'. 10 gives you 10S1P, 5S2P, 2S5P, 1S10P

There's a reason the ancients went with '12' even though we have 10 digits, 'cos 12 has many more factors, eg 12S1P, 6S2P, 4S3P, 3S4P, 2S6P, 1S12P

 

Irving brings an excellent point.

My two yen: since the “gadget” could be wired to a computer while supplying power somewhere else, whose commons could be at a different potential, I would consider input galvanic isolation. This of course is unnecessary if Bluetooth or Wifi are the only interfaces.

 

Interesting concept Ya'akov.

You might want to revisit the '10 cells'. 10 gives you 10S1P, 5S2P, 2S5P, 1S10P

There's a reason the ancients went with '12' even though we have 10 digits, 'cos 12 has many more factors, eg 12S1P, 6S2P, 4S3P, 3S4P, 2S6P, 1S12P

Good point. I am not year sure of the chemistry though it seems it will have to be something Lithium. Pouches, prismatic, LiMn, LiFe, etc. I am leaning towards 18650s for simplicity but also LiPo for weight and current capacity—while of course LiFePO4 is attractive from a safety perspective.

 

Irving brings an excellent point.

My two yen: since the “gadget” could be wired to a computer while supplying power somewhere else, whose commons could be at a different potential, I would consider input galvanic isolation. This of course is unnecessary if Bluetooth or Wifi are the only interfaces.

Noted. I do want serial and ethernet options, so isolation is a great idea.

 

I should add that although I said “MCU”, I am strongly considering an RPi Zero W or moral equivalent. running full blown Linux has enticing possibilities for on-board data cooking and web interface options. It could also be the nexus for other devices (remote instrumentation for voltage, current, resistance, etc) via BT, WiFi, or even serial as well.

 

I should add that although I said “MCU”, I am strongly considering an RPi Zero W or moral equivalent. running full blown Linux has enticing possibilities for on-board data cooking and web interface options. It could also be the nexus for other devices (remote instrumentation for voltage, current, resistance, etc) via BT, WiFi, or even serial as well.

I think you should split duties into control and application processors. The real-time physical control (configuration and generation of voltage, current, power, etc ...) of the PS IMO should done at the MCU level because it's much simpler to design the near real-time control loops needed to monitor critical conditions of overloads, failures and misuses to the core components using simple, deterministic, static programming and data structures. This core MCU will run and if needed, fail-safe the power supply even if the external applications processor for the interfacing, GUI and data functions completely dies.

 

I think you should split duties into control and application processors.

This makes sense. Since I am seeking good modularity, I might even consider an MCU per function approach so the modules can have an MCU scaled to the job and independent of the others. Most modules would probably work well with a very small MCU.

One way or another, a distributed, async architecture is a good idea. It has me thinking about the bus topology.

 

Noted. I do want serial and ethernet options, so isolation is a great idea.

Ethernet is already isolated. To some extent, it's a shame MIDI (or something like it) didn't make it as an industrial control protocol. There are isolated RS485 and CAN transceivers but they have the disadvantage of needing power supplies on both the instrument and the data sides.

 

Interesting concept Ya'akov.

You might want to revisit the '10 cells'. 10 gives you 10S1P, 5S2P, 2S5P, 1S10P

There's a reason the ancients went with '12' even though we have 10 digits, 'cos 12 has many more factors, eg 12S1P, 6S2P, 4S3P, 3S4P, 2S6P, 1S12P

Reading the initial post, I was going to make the same suggestion for the same reasons.

 

Perhaps I'm missing it, but while you say that this will provide voltage up to 40 V, I didn't see anything about how much current it can deliver. Being able to deliver 100 mA is a lot different than being able to deliver 10 A.

 

Please join me in trying to rough out a design of something you would like to have in your bag.
[...]
The PABS is a must have tool for technicians and hobbyists who work on the go.

I work on the go, and Here's what I have had in my bag for going on 10 years now:

It is a 24VDC plus 0-20V/0-2A CC/CV portable bench power supply that runs off a Dewalt 20V cordless tool battery. The battery voltage passes through a low voltage dropout circuit, into a switch mode boost circuit which steps 16-20V up to 24V (which is available at banana jacks on the back side), and then goes into the China brand CC/CV module embedded in the front side, whose output is available at banana jacks on the front side. I utilized an existing Dewalt battery 20V cordless tool battery charger for its mechanical and electrical docking interface (this was before things like this were available online):




Using the Dewalt charger also lended the benefit of providing an enclosure for my circuitry (inside the charger is mostly empty space) as well as handling the main power interface and charging circuitry. You can plug it in and charge your battery while simultaneously using the CC/CV output.


I realize this is not at all what you are going for (it is a hack job half-measure in comparison) but it is close enough I think to bring up, and it has some aspects to it that you may benefit from considering. namely:

• It uses available COTS cordless tool batteries which I was already carrying around with me (and your target market is likely to as well) - no additional batteries required. This is attractive in terms of cost as well as storage footprint for a mobile tech. I picked Dewalt because that's what I use but you could make the battery interface modular to accommodate any of the major brands of cordless tool batteries.
• Using removable batteries means when my battery goes dead I can just swap in another; I don't have to bring the thing back to a power source, plug it in, charge it up.
• When my battery pack inevitably reaches end of life I can just drive straight to Home Depot to buy another and be back in business within an hour, as opposed to ordering one from Ya'akov industries and waiting for it to ship. From your perspective that may be lost revenue on batteries but it will make your actual product (the power supply) more desirable and will also alleviate concerns on your end regarding warranty and liability surrounding the batteries.*

* There are (should be) liability concerns with a battery-powered device on the power levels we are talking about. A battery this size contains more than enough energy to start a fire that burns someone's service truck to a husk along with $50k worth of other tools, equipment, and parts. When that happens (even if it's because someone tossed the device into a tote full of scribes, awls, nails, screws, and ice picks, then slammed on the brakes at 90mph and "somehow" the battery got punctured) do you want it to be your battery that started the fire? Personally I could live without the lawsuit, even if won.



Ok, I think I am done espousing the virtues of cordless tool batteries so I move on to:

The PABS is incredibly advanced and flexible. It is fully computer controlled and fully instrumented:

1. Advanced MCU control provides programmable presets, power cycles, and supervision for unprecedented control over power and protection against OV/OC
   
   
2. Serial-over-Wire, Serial-over-Bluetooth, WiFi (AP and client modes), and Ethernet Connectivity for easy access to the microcontroller via a robust API
   
   
3. Sensors for voltage, current, temperature, and humidity—as well as an IMU that can be read out for data acquisition or used to trigger API calls

My use case is not universal to your target market but in almost a decade of using the device I showed, never have I ever needed, wished I had, or even encountered a scenario that made me consider the merit of anything quoted above.

Improvements I have desired, include (in order of desire or importance):

• Better LDO circuit, interfaced with charging circuit. My portable supply, when powering a device and also plugged into the wall for charging, if the load draws more current than the charging circuit supplies, will drain the battery to [theoretically 0V] without ever triggering the LDO circuit. When not plugged into the wall the LDO circuit works just fine and prevents the battery from over-discharge.
• Higher current output. 2A is enough for 90% of my needs but the other 10% require me to also carry a separate 120V bench supply which takes up even more room than the Dewalt supply, not to mention the required extension cord. I repeat myself for emphasis, your target market will value small storage footprint.
• A 100W+ USB-C port that could power my laptop when it dies, even just for a few minutes. This comes up quite often actually; my laptop always seems to die on the plant floor 10 minutes from the finish line. This is maybe a job for a separate device but every time it happens I look at my Dewalt supply for the answer and it isn't there, but it could be, and easily done. Actually I think this thread is my prompt to add it.
• Higher voltage output. If I had 40V like you propose, I would be happy with that.
• Cleaner power. The China CC/CV module has no linear regulator so it gives the output of a SMPS which can be noisy. This has never actually been a problem because I don't connect it to anything that I suspect will cause problems, but it would be nice to have some assurance of a ripple spec and be able to connect it to anything/everything.

I hope you find the above helpful. I definitely think you're barking up a tree that needs barking up. I don't know why a battery powered field/bench supply doesn't already exist but there is definitely a place for it in the market. If one existed 10 years ago I would have just bought it instead rolling my own klugey solution. I'll be totally candid and say that I think you're considering way too much "fluff" (bells/whistles) that will represent unnecessary delays in bringing a viable product to market. IMO you would do yourself a favor by just making a simple battery powered CC/CV supply, bring that to market, and then poll your customer base about the other features for the possibility of a "pro" version of what they aleady have.

 

I work on the go, and Here's what I have had in my bag for going on 10 years now:

It is a 24VDC plus 0-20V/0-2A CC/CV portable bench power supply that runs off a Dewalt 20V cordless tool battery. The battery voltage passes through a low voltage dropout circuit, into a switch mode boost circuit which steps 16-20V up to 24V (which is available at banana jacks on the back side), and then goes into the China brand CC/CV module embedded in the front side, whose output is available at banana jacks on the front side. I utilized an existing Dewalt battery 20V cordless tool battery charger for its mechanical and electrical docking interface (this was before things like this were available online):


View attachment 297065

Using the Dewalt charger also lended the benefit of providing an enclosure for my circuitry (inside the charger is mostly empty space) as well as handling the main power interface and charging circuitry. You can plug it in and charge your battery while simultaneously using the CC/CV output.


I realize this is not at all what you are going for (it is a hack job half-measure in comparison) but it is close enough I think to bring up, and it has some aspects to it that you may benefit from considering. namely:

• It uses available COTS cordless tool batteries which I was already carrying around with me (and your target market is likely to as well) - no additional batteries required. This is attractive in terms of cost as well as storage footprint for a mobile tech. I picked Dewalt because that's what I use but you could make the battery interface modular to accommodate any of the major brands of cordless tool batteries.
• Using removable batteries means when my battery goes dead I can just swap in another; I don't have to bring the thing back to a power source, plug it in, charge it up.
• When my battery pack inevitably reaches end of life I can just drive straight to Home Depot to buy another and be back in business within an hour, as opposed to ordering one from Ya'akov industries and waiting for it to ship. From your perspective that may be lost revenue on batteries but it will make your actual product (the power supply) more desirable and will also alleviate concerns on your end regarding warranty and liability surrounding the batteries.*

* There are (should be) liability concerns with a battery-powered device on the power levels we are talking about. A battery this size contains more than enough energy to start a fire that burns someone's service truck to a husk along with $50k worth of other tools, equipment, and parts. When that happens (even if it's because someone tossed the device into a tote full of scribes, awls, nails, screws, and ice picks, then slammed on the brakes at 90mph and "somehow" the battery got punctured) do you want it to be your battery that started the fire? Personally I could live without the lawsuit, even if won.



Ok, I think I am done espousing the virtues of cordless tool batteries so I move on to:



My use case is not universal to your target market but in almost a decade of using the device I showed, never have I ever needed, wished I had, or even encountered a scenario that made me consider the merit of anything quoted above.

Improvements I have desired, include (in order of desire or importance):

• Better LDO circuit, interfaced with charging circuit. My portable supply, when powering a device and also plugged into the wall for charging, if the load draws more current than the charging circuit supplies, will drain the battery to [theoretically 0V] without ever triggering the LDO circuit. When not plugged into the wall the LDO circuit works just fine and prevents the battery from over-discharge.
• Higher current output. 2A is enough for 90% of my needs but the other 10% require me to also carry a separate 120V bench supply which takes up even more room than the Dewalt supply, not to mention the required extension cord. I repeat myself for emphasis, your target market will value small storage footprint.
• A 100W+ USB-C port that could power my laptop when it dies, even just for a few minutes. This comes up quite often actually; my laptop always seems to die on the plant floor 10 minutes from the finish line. This is maybe a job for a separate device but every time it happens I look at my Dewalt supply for the answer and it isn't there, but it could be, and easily done. Actually I think this thread is my prompt to add it.
• Higher voltage output. If I had 40V like you propose, I would be happy with that.
• Cleaner power. The China CC/CV module has no linear regulator so it gives the output of a SMPS which can be noisy. This has never actually been a problem because I don't connect it to anything that I suspect will cause problems, but it would be nice to have some assurance of a ripple spec and be able to connect it to anything/everything.

I hope you find the above helpful. I definitely think you're barking up a tree that needs barking up. I don't know why a battery powered field/bench supply doesn't already exist but there is definitely a place for it in the market. If one existed 10 years ago I would have just bought it instead rolling my own klugey solution. I'll be totally candid and say that I think you're considering way too much "fluff" (bells/whistles) that will represent unnecessary delays in bringing a viable product to market. IMO you would do yourself a favor by just making a simple battery powered CC/CV supply, bring that to market, and then poll your customer base about the other features for the possibility of a "pro" version of what they aleady have.

A lot of great points. Let me say to start that I am primarily building this supply for me. Once it is developed, I have no doubt it it will be an attractive item. I am currently considering strategies for open sourcing it, possibly offering PCBs, and/or kits, and/or assembled units.

Because of the points you raise, I will not be supplying batteries—but, as I said, this is intended to be modular and battery configurations could be variable. However, the matrix switching of the cells is something I very much want to do, so tool batteries are out for my configuration.

On the other hand, there is no reason why they couldn’t be connected without the matrix feature. One of the things I expect to do is provide autoconfiguration by having the modules report capabilities and requirements. If every module has at least a small MCU and a little flash, it can identify itself and its connection requirements upon connection (preferably in a hot swap mode).

I am actually, particularly excited about the idea of a communications bus and variable autonomy of the modules. It’s something I did on a PC network scale with management and some hardware, and I would like to do it for this (and generalize it enough that it can be used elsewhere).

I think my own first prototypes will use 21700 cells because of capacity and price (high and pleasingly low). I can get very high quality, high capacity 21700s for about $5/cell. That would mean a 12 cell pack would only cost about $60 for the raw cells but provide a lot of current and capacity.

I want to design the case in such a way that there can be “layers” that stack and provide different capabilities. The bottom most layer would be the battery. I like the idea that if I wanted to, I could make a top layer with a large display, or just have a smaller one for utility.

I’m still working on this but I feel that it can be a great thing and a model for other sorts of instruments. Steady, incremental progress can make it happen, I just have to stay the course.

 

Perhaps I'm missing it, but while you say that this will provide voltage up to 40 V, I didn't see anything about how much current it can deliver. Being able to deliver 100 mA is a lot different than being able to deliver 10 A.

The current will depend on the choice of cells. Assuming lithium, the 40V is a round number. Based in tool batteries, I expect that it will be able to supply 10s of amps if needed but expect, practically to keep it cruising at a 10A max, similar to a bench supply, and probably defaulting to 3A unless you tell it to produce more.

Obviously cooling becomes a thing when dealing with 10A continuous not to mention when providing 50 or 60A peaks. I need to work out the practicalities of cooling anyway because even 3A is going to get things warm.

 

Let me say to start that I am primarily building this supply for me.

Thanks for clarifying that. I get it, I have projects like that too, and it's a perfectly reasonable approach to a project, but it limits the kind of discourse that can be had about it. On any given point, asking "why" is a waste of time as "because that's how I want to do it" is a perfectly valid response and the most likely response. Designing for ones own amusement is liberating in that you aren't constrained by anyone else's criteria but at the same time you aren't challenged by anyone else's perspective, which seems relevant when polling other people's perspectives.

For example:

However, the matrix switching of the cells is something I very much want to do, so tool batteries are out for my configuration.

I could ask why you are so adamant about this, and I'm sure you have your reasons, but nothing I could say, ask, or suggest would be relevant because in the end, the answer was already given at the start: "[it] is something I very much want to do." So there is little opportunity for discussion and any that happens is a waste of time on both ends.

As I said, I also have projects like this, I get it. In cases where it's just for me and I have no intention of ever making a product out of it, I only ask technical questions about the specific part of the project I need input on. That saves wasted conversation about aspects of the design that I won't budge on "just because." But for things I think have commercial worth (like this, definitely this), I try to design it from the start as a product, which means letting my ideas be challenged and holding myself accountable for having answers and reasons that would satisfy a hypothetical investor.

This is all yours, you do what you want (and I'll follow with positive anticipation of the result, whatever it is) but I am curious what kind of input you are expecting and/or interested in. I am excited that someone else has resolved to work toward a solution to this need and I would like to be a part of it or at least be an observer to the progress of your project but I don't see the opportunity to help.

 

Thanks for clarifying that. I get it, I have projects like that too, and it's a perfectly reasonable approach to a project, but it limits the kind of discourse that can be had about it. On any given point, asking "why" is a waste of time as "because that's how I want to do it" is a perfectly valid response and the most likely response. Designing for ones own amusement is liberating in that you aren't constrained by anyone else's criteria but at the same time you aren't challenged by anyone else's perspective, which seems relevant when polling other people's perspectives.

For example:

I could ask why you are so adamant about this, and I'm sure you have your reasons, but nothing I could say, ask, or suggest would be relevant because in the end, the answer was already given at the start: "[it] is something I very much want to do." So there is little opportunity for discussion and any that happens is a waste of time on both ends.

As I said, I also have projects like this, I get it. In cases where it's just for me and I have no intention of ever making a product out of it, I only ask technical questions about the specific part of the project I need input on. That saves wasted conversation about aspects of the design that I won't budge on "just because." But for things I think have commercial worth (like this, definitely this), I try to design it from the start as a product, which means letting my ideas be challenged and holding myself accountable for having answers and reasons that would satisfy a hypothetical investor.

This is all yours, you do what you want (and I'll follow with positive anticipation of the result, whatever it is) but I am curious what kind of input you are expecting and/or interested in. I am excited that someone else has resolved to work toward a solution to this need and I would like to be a part of it or at least be an observer to the progress of your project but I don't see the opportunity to help.

Well, while it is true that certain aspects of the feature set are fixed, there is a rich opportunity to help in implementing those features. I’ve already gotten some excellent suggestions about architecture in both the cell count and the processors.

There are still constraints to be managed. For example I will have to settle on a size and weight, and a budget. I have to make connector choices, MCU/SBC choices, part choices of all kinds including MOSFETs for switching which I suspect is going to be an area I will need a lot of help in, LDOs, and many other chips and actives.

There is also the bus design which I feel is critical to get right the first time if possible. So I can see a lot of areas where help is not only possible but will be greatly appreciated. Heck, even my own feature set might need to be revised for practical reasons and choosing how to change it could use input.

At this step in design, though, I am trying to incorporate the things that got me excited about the project. If I do the design right (by my lights) I will be able to grow it with minimal basic revision because I will have gotten the fundamentals right. That’s my goal. For example, with the matrix switching, I should be able to add a second power bus that would allow for dual votage output, or even ±V outputs.

Anyway, if you spot something to give input on, please do. I definitely want to do the USB Type-C I/O right and just how it should look hasn’t solidified

 

you may want to look at EZ-PD family of chips from infineon. CY7110 is the part number for the dev board. Its an MCU that handles the power delivery stack internally. I'm just starting to dig into it, but it might be something to look at. I looked at it since making a compliant usb-c power deliver stack is hard.

 

When you mentioned "ethernet connectivity", have you any particular protocol in mind? Modbus, for instance?

 

When you mentioned "ethernet connectivity", have you any particular protocol in mind? Modbus, for instance?

I don't, though supporting something(s) useful is a good idea. My initial intention for the Ethernet is communication with the SBC at the OS level for things like a web UI. I am adding this to the list, though, along with SCPI.

 

you may want to look at EZ-PD family of chips from infineon. CY7110 is the part number for the dev board. Its an MCU that handles the power delivery stack internally. I'm just starting to dig into it, but it might be something to look at. I looked at it since making a compliant usb-c power deliver stack is hard.

Sounds very interesting. Anything that simplifies PD seems worth looking at.