Bit of self-promotion: I spent the last year or so designing an open-source USB-PD protocol analyzer[1], and the complexity of the protocol can be mind-boggling. Most of the time, the communication between source and sink is really straightforward, but it can get amazingly complicated when both devices are dual-role or come from the same vendor[2].
As messy as it is, however, it's also a very useful protocol that allows even small players to take advantage of the same economies of scale that large companies can take advantage of. Pity that the communication often requires dedicated chips, though thankfully those are relatively inexpensive. I was able to get an RP2350 (the same MCU that's in the Raspberry Pi Pico 2) to interface directly with USB-PD, but they could have made it easier and more accessible.
Not only that, but EPR contracts must be actively maintained in order to remain in effect. The sink needs to send a ping to the source every ~500ms, or the source pops out of EPR mode and forces a renegotiation. This ensures that, if the sink crashes, the source doesn't keep pumping power into a device that can't take it anymore.
Can I offer a counterpoint? Much like OG USB put a 5V supply within everyone's reach, USB-PD has made programmable, higher power supplies available to everyone. That's a big deal, because PSUs are an expensive portion of a product, especially for small manufacturers and hobbyists. Having a dedicated standard that supports multiple voltages and currents allows small players to take advantage of the same economies of scale as the largest electronics manufacturers.
Case in point, IKEA will happily sell you a very well built 20W power supply that provides 5, 9, 12, or 15V for less than $5 here in Canada, and you can get a similar price from legitimate Asian distributors, even when buying in limited quantities. If you're working on a small-batch electronic product, that's a boon to your BOM; if you had to go out and source a dedicated barrel-jack PSU with the same capabilities, it'd cost much more, and you don't know what kind of quality you'd be getting.
Where the standard really falls on its face, IMO, is in its opacity. You can get a chip that does the PD negotiation for pennies, but there is no way to inspect the protocol without shelling out thousands for a dedicated analyzer, so when things don't work, it's really hard to troubleshoot the reason.
(Disclaimer: I'm working on an open-source protocol analyzer, so this probably colours my view on the matter a little.)
USB-PD 3.1 provides both a Get_Battery_Cap message, which asks the sink to tell the source the capacity of its battery) and a Get_Battery_Status message, which asks the sink to inform the source about the current charge of its battery.
And then the MBP will send a Get_Battery_Status again, and so on. (Example capture here: https://imgur.com/a/TI5maV0
What's really cool is that this exchange happens both ways—the iPad also sends a Get_Battery_Cap message to the MBP, because it is also capable of acting as a source, and, if the laptop's battery drops sufficiently low, the source/sink roles may swap (using a DR_Swap message) so that the iPad ends up charging the MBP!
Dr. PD is an open-source USB-C Power Delivery analyzer and programmable sink. It can sit inline between a USB-PD source and sink to show you the communication between them, or connect directly to a source and emulate a sink so you can characterize chargers and power supplies.
The goal of the project is to make serious USB-PD analysis more accessible. The hardware, firmware, and host software are all open source. The control software runs locally in Chrome or Edge with no drivers or installation required, and the platform also provides Python, JavaScript, SCPI, and USBTMC interfaces for automation.
(Sorry that I don't have a link to the GH repo yet, but you can follow the project on https://hackaday.io/project/205495-dr-pd. Also, if you read this far, I'm looking for a few beta testers. Reach out if you're interested!)
Noom | Senior Data Science/Full Stack/Backend/Android/iOS/QA positions | REMOTE or HQ | FULL-TIME | https://noom.com
At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.
Our engineering team is expanding, and we have openings for a number of positions that include backend and mobile engineering. Our offices are in NYC, but we are a remote-first organization (some 90% of our team is remote) and are happy to consider candidates anywhere.
Noom | Senior Data Science/Full Stack/Backend/Android/iOS/QA positions | NYC or REMOTE | FULLTIME | https://noom.com
At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.
Our engineering team is expanding, and we have openings for a number of positions that include backend and mobile engineering. Our offices are in NYC, but we are a remote-first organization (some 90% of our team is remote) and are happy to consider candidates anywhere.
Noom | Data/Backend/Android/iOS/Staff positions from Jr. to Director | NYC or REMOTE | FULLTIME | https://noom.com
At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.
Our engineering team is expanding, and we have openings for a number of positions that include backend and mobile engineering. Our offices are in NYC, but we are a remote-first organization (some 90% of our team is remote) and are happy to consider candidates anywhere.
Noom | Data Engineer, Staff Engineer, Sr. Android Engineer | NYC or REMOTE | FULLTIME | https://noom.com
At Noom, we use scientifically-proven methods to help users get a handle on chronic medical conditions like obesity, diabetes, and heart disease. We use a variety of technologies, and get to work on hard problems that range from data warehousing to running experiments on mobile devices.
Our engineering team is expanding, and we have openings for a number of positions that include backend and mobile engineering. Our offices are in NYC, but we are a remote-first organization (some 90% of our team is remote) and are happy to consider candidates anywhere.
1. Listen before you speak. The people you manage are prone to giving your opinion more weight than it deserves.
2. Give your subordinates problems, not solutions. People like to own a task, not to be told what to do; treating them like adults and professionals empowers them and brings out their potential. Besides, if one person only ever makes all the decisions, no decision can be better than that one person's knowledge. If you're afraid of delegation, institute a tight review loop to ensure that people don't go off-track.
3. You're a facilitator, not a doer. People will come to you with their problems, and you must be available at all times to help them through it. As someone else has pointed out, your productivity is secondary to that of the team. It's your job, among other things, to ensure that your team has a good working environment, including good tools, practices, and access to uninterrupted “flow” time.
4. Be aware of politics. The moment you manage a team, politics become a part of your daily job. This is not a bad thing—“politics” just means managing interpersonal relations; it becomes a bad thing when you ignore it.
5. Never be in a position to take. Success belongs to your teammates; failure is all yours.
6. Face problems head-on. People don't like confrontation, and let problems fester until it's too late to fix them. Instead, provide frequent one-on-one time with all your teammates, exhort them to confide in you, and show them that you're trustworthy. Also see #1.
7. Offer clarity. Explain what you expect others to do in a measurable way to make it possible for both you and your team to understand how well everyone is doing. You can use a method like OKR[0] to track your goals internally.
As messy as it is, however, it's also a very useful protocol that allows even small players to take advantage of the same economies of scale that large companies can take advantage of. Pity that the communication often requires dedicated chips, though thankfully those are relatively inexpensive. I was able to get an RP2350 (the same MCU that's in the Raspberry Pi Pico 2) to interface directly with USB-PD, but they could have made it easier and more accessible.
[1] https://github.com/T76-org/drpd or https://www.crowdsupply.com/t76-org/dr-pd [2] https://hackaday.io/page/399885-a-mac-and-an-ipad-walk-into-...