The Call I Almost Missed
Thursday, March 14, 2024. At 4:37 p.m., I almost sent a call to voicemail. Thirty minutes earlier, my brother had texted me a question he asks every few years: what is the best multimeter for home use? I sent back the short version—CAT III input rating, fused current jacks, and don't buy from a random seller with no calibration story—and put the phone down. Then the work line rang.
The caller was Priya, co-founder of a three-person hardware startup. I will keep the product description broad because the IP is not the point. They made a compact USB-C power device with an internal battery and a USB-PD controller. A contract manufacturer had a production slot reserved, and the design needed to pass charging and USB-PD validation before that slot could move. Priya had contacted a test lab that quoted four to six weeks. Her deadline was Monday morning, and it was Thursday afternoon.
I know this story pattern. I coordinate rush test setups for a living, and over the past six years I have handled more than 200 orders with short deadlines. When a call like this comes in, my first questions tend to be the same: how many hours remain, what is the smallest reliable measurement that will answer the question, and what is the worst case if we get it wrong? For Priya the worst case was concrete: miss the slot and wait another six to eight weeks. For a small startup, that delay can be fatal.
She started by apologizing for the size of the order. I told her it didn't matter. The size of the invoice is not the same as the size of the risk. That rule has saved me from making a lot of bad decisions.
Setting Up an 88-Hour Test
We had roughly 88 hours, not six weeks. Not ideal, but workable if we started immediately.
The setup needed two pieces. The first was a way to make the battery state perfectly repeatable. The phrase Keysight battery test solutions might make you think of a floor-to-ceiling rack of gear. Sometimes it is that big. This time it was one DC power analyzer running battery simulation software. It let us set the cell voltage to any state of charge and watch voltage and current change in real time. Most importantly, it made the low-battery condition reproducible.
The second piece was a USB-PD logger. It watched USB Power Delivery while recording list changes from every Source_Capabilities message. If that phrase is new, a USB-PD source sends a list of power outputs it can supply. That list is called the PDO list. The logger time-stamped each message and kept the full list, so we could compare the advertised profiles against the actual battery state. That detail mattered later.
That same afternoon, I also had a request sitting in my inbox for a Keysight optical spectrum analyzer. I mention it because it makes the setup decision clearer. The optical spectrum analyzer is extremely precise as long as the problem lives in the optical domain. This problem was not optical. Precision only helps when it is aimed at the right question.
Before we connected anything, I did a slow walk around Priya's bench. Under a pile of cables I spotted a spare module with a silver label that read Platinum BP5450. It was not in the bill of materials, not in the test setup, and not in the approval matrix. We moved it to a different table before powering anything on. Unexplained hardware is a liability in a validation run, and that five-minute decision probably saved us from chasing a phantom later.
Run Number 47
Friday afternoon, the first 46 runs looked clean. At 80% state of charge, the device advertised 5V, 9V, and 20V. At 40%, it advertised 5V and 9V and dropped the profile it could no longer support. At run 47, I set the simulator to 15% state of charge. The expected PDO list was simple: just 5V. The logger showed 5V and 20V.
We repeated the test to make sure it wasn't a glitch. It wasn't. We replaced the USB cable, swapped the load, and still got the same list. Then we let the test load negotiate 20V. The output sagged immediately, and the device reset. If you looked at current alone, the event looked like a random power glitch. The recorded PDO list told a different story.
The surprise wasn't a broken component. It was a firmware bug. The USB-PD controller built its Source_Capabilities list before reading the latest battery fuel-gauge result. At low battery voltage, the list was stale. It advertised a 20V profile the battery could not support. Under the USB-PD spec, a source must not advertise a capability it cannot deliver. The firmware update moved the fuel-gauge check earlier in the connection sequence, so the PDO list always matched the real cell condition. Sunday afternoon, we cycled the same test 200 times. No mismatch.
The Lesson I Keep Relearning
Priya submitted the report Monday morning. The contract manufacturer accepted it. The production slot stayed.
The point of this story is not to turn everyone into a protocol logger. It is to say that small orders can contain enormous risks. If I had sent that call to voicemail, a three-person company would have shipped a product with a hidden power-management bug. The validation would have looked fine until someone tried to pull 20V from a nearly empty battery. That is the kind of failure that surprises customers and kills confidence.
So now, when someone apologizes for a small project or asks a simple question like what is the best multimeter for home use, I take it as seriously as I take a large lab order. The question may be simple on the surface, but the safety behind it is not. And if the phone rings at 4:37 on a Thursday, answer it.
