PD Buddy Sink

Surprise!  I've just made another patch release to the 1.2 series, version 1.2.2.  This adds a new LED blink code (1 7/8 s on, 1/8 s off) which indicates that only default USB power is available (no Power Delivery, no higher Type-C Current).  This often occurs because the Sink is powered via a USB Type-A to Type-C cable.  I've had a few users ask why the Sink can't get power from their charger, and the problem turned out to be that they were powering it in this way.  Just today someone suggested adding another blink code for that case, and I liked that idea, so here it is.

Like all firmware releases, this new version is available from the releases page, and the compiled binary installable with dfu-util can be downloaded here.

As promised in the last log entry, I just released firmware version 1.2.1.  This fixes one of the problems encountered with certain power banks by requesting a lower, more accurate current (30 mA instead of 100 mA) when the Sink's output is turned off.

Like all firmware releases, this new version is available from the releases page, and the compiled binary installable with dfu-util can be downloaded here.

A few users have asked me about a problem that the PD Buddy Sink has with the RAVPower 26800 USB PD power bank.  It's a 99 Wh battery pack with a 30 W USB PD output.  I won't give any link to the power bank because as I'm about to describe, it's not a product I can recommend to anyone.  The symptom discovered is that after about 30 seconds of being connected to this power bank, the PD Buddy Sink starts resetting rapidly, with its LED blinking wildly.

The first user to report this problem found a workaround, which was to keep a load of at least 100 mA connected at all times.  For some applications, this obviously isn't a very nice solution: it's a battery, so power is limited, and keeping a low load when possible would be best.  If the load is naturally intermittent, e.g. a soldering iron with bang-bang temperature control, it would be great to not have to keep a dummy load attached when the heater is turned off.

Now, I've been skeptical about this power bank for a while.  Some reports like this one made me feel uncertain that it would follow the USB PD spec very well.  Once I heard of what was going on with the Sink when connected to this thing, I deduced that the power bank must be sending a bunch of hard resets to the Sink.  To the best of my knowledge, a source isn't allowed by the standard to do this simply because of low power draw.  My skepticism of the power bank grew.

After hearing a couple more reports of this problem, I finally decided to suck it up and buy one so I could see what's going on first-hand.  It arrived a couple days ago, and I just got around to testing it today.  I hooked it up to a PD Buddy Sink with my trusty logic analyzer on one of the CC lines, and what I found was even weirder than I imagined.

This power bank has the most extreme example of the "Split PDO" problem that I've ever seen: it first advertises 5V@3A, 9V@3A, and 12V@2.4A.  After the Sink makes a request, it accepts it and provides the power, giving a PS_RDY message.  It then immediately sends the same source capabilities again, so we have to go through the same negotiation twice for no apparent reason.  About a second later, it sends a third Source_Capabilities message, this time with 5V@3A, 9V@3A, 12V@2.4A, 15V@2.1A, and 20V@1.5A.  This disagrees with the printing on the back of the power bank, which says it provides 5V@3A, 9V@2A, 15V@2A, and 20V@1.5A (which by the way violates the USB PD power rules: there should be 3A available at 9V if there's 2A available at 15V).  The advertised capabilities violate the power rules as well because the pack is sold as having a PD Power of 30 W, but the advertised capabilities go up to 31.5 W.  Eek.

But it gets weirder.  After about 30 seconds of supplying the power the Sink requested, if the Sink isn't drawing much power, the charger decided to send another Source_Capabilities message.  This time, it contains a single PDO offering a paltry 5V@50mA.  Not only is this way lower than the PD Power of the device, it's not even one USB 2.0 unit load of 5V@100mA.  This is actually where I admit some fault, because the PD Buddy Sink blindly requests 5V@100mA when it can't negotiate the configured power.  I expected this to be safe amount of power, but it exceeds what the power bank advertised, which is what caused the hard resets.

So I took an accurate measurement of the Sink's real power consumption, which was just a hair over 20 mA during setup mode.  Since all fixed currents must be in increments of 10 mA, I decided that a value of 30 mA would be most sensible.  So I tried that, and now at least it doesn't get a series of hard resets.  Since this means that the Sink can now remain connected to the power bank while in setup mode, I'll make a firmware bugfix release (version 1.2.1) with this patch shortly.

There's still more to fix here, of course.  The PD Buddy Sink still can't maintain a low power draw from the power bank while an explicit contract for higher power is in place.  I'll keep looking into this issue, but I suspect the solution won't be pretty (if I can find one at all).  Regardless, I can't recommend this power bank to anyone because of the discrepancy between how much power it advertises to the sink and the specified output printed on the device.

Things have come a long way since a year ago.  Back then, this project was just a twinkle in my eye, a bodged prototype circuit board, and a first pass at a firmware that never saw the light of day.  It would be nearly another month before I'd write anything about it online, partially because I still had no idea whether I'd get anywhere near a finished device or not.

Today, I've now sold over $2000 worth of PD Buddy devices on Tindie, and they're continuing to sell faster and faster.  The last batch contained 30 boards, and about two thirds of those have sold in the first week.  I realized that I need to reorder immediately, and that it's time to seriously step things up.

So, this project just reached a new milestone: I ordered a batch of 100 boards today.

I've never seen a hundred of a circuit board I designed before.  The thought is really a bit daunting.

By my best projections, I will have started grad school by the time they've all sold.  Finding time to fulfill orders as a Ph.D. student might be challenging, especially if sales keep growing like they are.

To that end, I plan to spend some time between now and August working on an easier programming and testing setup so that MacroFab can fulfill orders for me.  Then I'll be less involved in future batches, allowing me to spend my free time on support and development instead of making shipping labels.

I'll have to think for a time about what this new testing setup will require.  I know that I'll have to make a new board revision of the PD Buddy Sink, at least so the tester can control the Setup signal without physically pressing the button.

A new board revision.  That will give me an excuse to finally add a logo.  That alone will be another milestone.

After one hundred and sixty five days of development, and more than half the commits to the Git repository, it's finally here!  The latest stable release, firmware version 1.2.0 brings support for Power Delivery 3.0 communication, programmable power supplies, requests from voltage ranges, new methods of specifying the required power level, and jumping to the STM32 DFU bootloader.  There are five, count 'em, five new commands in the configuration interface.  Upgrading to future versions won't require anyone to touch a soldering iron, so I might not be so hesitant to make smaller releases now.

For this release, the firmware was reorganized as a library for USB Power Delivery and an application using that library. The library is released under the Apache License, Version 2.0, and the application is still released under the GNU General Public License, Version 3.0. Both parts of the firmware are still kept in the same repository, but this may change at some point.  This is an important change: since I'm planning on making a development board based on the PD Buddy Sink, this will make it easy for folks to write firmware for it without having to hack the PD Buddy Sink's firmware to pieces.

So, what are you waiting for?  Head over to the releases page, download the compiled binary for 1.2.0, flash it to your PD Buddy Sink, and request some weird voltages from a programmable power supply!

As requested, I just made a development release, 1.2.0-dev.  There are quite a few planned features not yet implemented, and as such I don't consider this release "stable" (that is, boards I sell won't ship with this firmware unless you explicitly ask for it).  What this release does provide is support for USB Power Delivery 3.0, bringing with it support for Programmable Power Supply APDOs (both making requests from them and pretty-printing them with get_source_cap).  Also in this release is basic support for voltage ranges, allowing a fallback to common fixed supply PDOs when the preferred voltage is unavailable.  The HV_Preferred flag does what it's supposed to, but the current is always constant when making requests from a range (no power or resistance modes yet).

So, if you're feeling adventurous, head over to the releases page, download the compiled binary for 1.2.0-dev, and flash it to your PD Buddy Sink!  As always, feedback is encouraged. 🙂

EDIT: added a direct link to the firmware binary

In this post: big firmware news, and a question to the project's followers.

Big News

As of today, the firmware in git master supports PD 3.0, programmable power supplies, and making requests from a voltage range!

The support for PD 3.0 is fairly minimal, not supporting any extended messages longer than one chunk.  That's because the only extended messages that can ever be longer than one chunk are for Type-C authentication (no need), USB PD firmware updates (SWD and DFU cover this quite nicely), and country-specific information (can't imagine what use that would be).  The standard allows this, so I'm not being a bad citizen in the eyes of USB-IF.

Support for programmable power supplies is interesting, because in implementing this I realized very clearly that it's mostly just meant for battery charging.  That's not to say that it can't be used just to get arbitrary constant voltages, but just that for this use case it seems odd that the standard requires the request to be repeated every ten seconds.  This is probably meant to prevent improperly charging Li-ion batteries in case of communication failure, but for a use case like the PD Buddy Sink it's just busy work.

I also just implemented the set_vrange command in the configuration interface, and gave the firmware the ability to request fixed supply PDOs from the configured range.  It only requests a constant current at any voltage for now, but I'll add constant power and resistive load modes soon.  Also, when making requests from the range, it doesn't request voltages advertised as part of a programmable power supply APDO.  This leads me to:

The Question

Should I make the firmware able to request voltages from a programmable power supply APDO when the desired voltage is unavailable and it falls back to requesting something from a range?

It would make the procedure of making a request quite a bit more complicated than it is now, and the main benefit of the range I see is to support non-programmable power supplies when the desired voltage isn't available as a fixed supply PDO.  It does seem philosophically more proper though, but I'm not convinced that it's really worth doing.  I'd like to hear feedback on this, so please leave a comment if you have an opinion.

I think, maybe, but I don't know, but I'm starting to feel like Microsoft's got a brain problem situation on their hands. (or they had one before Windows 10 came out, anyway)

After some discussion about configuring the Sink on Windows, I finally took a close look at the situation.  What I found is not good.  While Windows has included a driver for USB CDC-ACM since Vista, for some inane reason, versions older than 10 don't load it without an INF file listing each specific USB VID/PID pair that needs the driver.  Also, Windows 8 requires this file to be signed.  As of now, there's no way I'm going to pay for a code signing certificate just to tell an operating system to load a driver for a standard protocol that it provides itself.  This project just isn't profitable enough for that to be worth it.  If I was shipping a hundred units a month I'd probably do it, but somehow I doubt that will happen any time soon.

So, if you run Windows and want to configure a PD Buddy Sink, either make a live USB Linux system to configure the Sink with, or get Windows 10.

With support for programmable power supplies planned in firmware version 1.2.0, I realize that new configuration will be required.  First of all, this is because USB PD programmable power supplies allow voltages to be requested at 20 mV increments, while fixed PDOs can only be at 50 mV increments.  To support both of these, I'll have to change the configuration to hold voltages at some common denominator: probably either 10 mV or 1 mV.  This means upgrading to firmware 1.2.0 will break your configuration, and there's not a lot I can do about that short of an extra backwards-compatibility code path that in the long term won't see much use.  I'm not crazy about that idea, and the documentation never said the configuration would persist through firmware updates, so I'll probably just warn users about the change when I make the release.

Next, something will have to be done to allow the Sink to get power at less-desired voltages.  For instance, maybe you'd really like to run your project at 13.8 V, but anything from 11-16 V would work as well.  It would suck if setting the Sink for 13.8 V meant it absolutely can't work with older supplies that only offer the standard fixed voltages.  My idea then is to let users set a preferred voltage, and an optional range of acceptable voltages.  If the preferred voltage is not available, the Sink will try to make a request for some arbitrary acceptable voltage instead.

EDIT: The arbitrary selection would almost certainly either favor lower or higher voltages, and I can imagine situations where either of these would be preferred.  Accordingly, I should probably let the user choose between the two.

This raises the question of how much current to request.  It's easy to just set a single current when only a single voltage can be requested, but with a whole range available I can think of several modes that would make sense.  One would just be to request a constant current at all voltages in the range.  Another would be to request a constant power, so that higher voltages come with lower current.  A third would be resistive load mode, where the user sets a resistance and the Sink requests the current required at whatever voltage, so that higher voltages come with higher current.

That about sums up my plans for the new configuration for programmable supplies.  I'd like to hear feedback on this, so if you have any comments please let me know.  In particular, I want to make sure there aren't any use cases I've missed, e.g. modes other than constant current/power/resistance, or maybe something to do with voltages.  Once I feel confident the ideas are all in place, I'll design the new configuration API.

Yes, the latest batch of PD Buddy Sinks just arrived from @MacroFab!  There are twenty in this batch, and they've all been listed on Tindie.  Will this be a repeat of last time?  The STM32F072C8U6 still has shaky availability (what the heck, ST?), so part of me hopes it won't be.  The rest of me hopes it will be, because that might mean I have a hit product on my hands.