Framework 180W adaptor - no USB-PD 15V?

[Earphone5329]

Hey all -

I’m writing this as I have a Zoom F8 and I’ve been looking to set myself up with a power supply capable of powering it through the Hirose connector on the side. The included DC adaptor for the F8 is not really practical for proper on-location recording, for a number of reasons I won’t go into here.

I checked my Framework 180W power adaptor (model FRANCNCH00, I think - a little scratched) and saw that it could supply 15V, so I ordered a 15V USB-PD DC cable that essentially just uses USB-PD to negotiate 15V from the power supply you attach it to and then sends that voltage out to a barrel jack. This is a good quality cable from a well-respected seller - based on the product description, I was pretty sure it’s exactly the same cable being sold here on Adafruit. I knew that both the cable and the Framework 180W adaptor complied with the standard, so I was expecting to just chop the cable and solder on a Hirose connector and I’d be sorted. However, I found that the DC jack only appeared to show roughly 1.2 mV when I did this. By contrast, plugging the cable into a MacBook adaptor (model A2743) that I also had lying around gives me ~15.14V as expected.

So something seems to be wrong between the cable and the adaptor. The adaptor has never given me issues before, and I confirmed that it supplied power normally with a phone connected, so I’m confident that I’ve not just plugged it in in a dodgy way or whatever.

Has anyone else seen something similar, and/or would anyone have any ideas on how I could resolve this? I use the Apple power adaptor for other things and the Framework adaptor would fit in my sound gear bag & workflow much better. The Framework adaptor can supply up to 15V 3A and the cable is rated for 15V 5A, but I can’t see how that would cause problems, particularly when the Apple charger is also rated at 15V 3A.

TIA

[MJ1]

@Earphone5329

so I ordered a 15V USB-PD DC cable that essentially just uses USB-PD to negotiate 15V from the power supply you attach it to and then sends that voltage out to a barrel jack.

I would not put faith into the chip in that cable. Those chips, known a USB PD trigger, dummy, or decoys, are not proper USB PD devices. I don’t if reputable chip manufacturers even make any that are expressly for that purpose. But they certainly are available from China for probably a penny each.

Whether one works or not with any given power supply is just luck. If you want to keep trying, maybe the particular chip in your cable is a little off, you could get a half dozen PD decoys for a couple dollars from AliExpress. Ideally get a few different boards, that have chips which appear physically different, at least on the surface. Chances are one of them will work.

[James3]

Hi.
My guess is maybe the FW16 180W PSU has never been tested at 15V output.
When it powers a FW16 it sits at 36V.
You would probably need a usb pd analyser to debug the problem.
The 60W FW13 PSU sits at 20V.

At 15V, the most you can output is 5A, 75W, so I would suggest you purchase a PSU that works, because I doubt FW will try to fix their PSU as they have a small team, and other things are higher priority at the moment.

[MJ1]

@James3

I would suggest you purchase a PSU that works, because I doubt FW will try to fix their PSU

You can see the FW 180W power supply tested here

FRAMEWORK 180 watt USB-C Power Adapter REVIEW AND TEST

Nothing wrong with it was found. He also tested the FW 60W one.

Not sure why’d you’d first suspect the FW power supply vs a random no-name chineseium PD dummy chip. Sure it could be, but between the two, the cheap dummy chip is the thing to suspect first. ThePiHut does not make any claim as to what chips might be found in their cables that I can see.

[James3]

@MJ1

You appear to be right.
That video, at time 4:51 shows all the volt levels being testing.

FRAMEWORK 180 watt USB-C Power Adapter REVIEW AND TEST

It does not explain why a MacBook A2743 PSU worked, but the FW16 did not work with the DC jack cable though. It was that statement in the original post that made me suspect the FW16 PSU.

I propose another theory why the FW16 PSU does not work with the DC jack adapter.
The FW16 PSU only supports the USB 3 PD protocol, and not some of the other multitude of power delivery protocols. Maybe the DC Jack adapter tries to use a different protocol instead of the PD protocol to ask for the 15V power.
Maybe the MacBook PSU just happens to support one of those other protocols as well.
I think some of the other protocols don’t use any messaging, and they just use a specific resistor value on one of the pins to select the voltage. Something like that would be easy for the DC jack adapter to have, without it doing USB PD protocols.

Although saying that, the write up on that adapter says it supports the PD protocol and has the EMARK chip also.

[MJ1]

@James3

It does not explain why a MacBook A2743 PSU worked, but the FW16 did not work with the DC jack cable though.

No-name chineseium chips just don’t put effort into following protocols properly, and separately from that, they can just be straight up buggy. Look into some of the analysis of Chinese clone chips that have be done. And then they have clone of clones… Seemingly attempting to copy a chip that is already a clone, rather than working off the original. Why they do that, Lord only knows.

The mac A2743 power supply I would guess is just more tolerant of devices which don’t follow protocols correctly. But a device following a protocol more closely or expecting connected devices to do so wouldn’t have anything wrong with it. You could perhaps argue that one should engineer a devices to be as forgiving as reasonably possible to others not following protocols quite right. But there is the counter argument that if you do that too much it encourages others to not bother following the protocols properly & leads to more devices that may or may not work, just depending on your luck.

[Earphone5329]

@MJ1, @James3 - thanks for the responses. All makes sense, and yeah I’d seen that video too. I did make a deliberate effort to buy a good quality cable from a known vendor in the hope that that would ensure standards compliance, but I guess maybe there are no reputable vendors of this kind of cable.

I have now fitted the Hirose connector, and was impressed at least with the construction of the cable. It has nice thick stranded conductors and good-quality insulation and connectors. It’s branded ‘WITRN’ and matches the photos on Adafruit and the Pi Hut exactly.

Anyway, I agree that the most likely scenario is that the implementation of the PD standard by this cable is a bit dodgy. I’ll have a think through my options and figure something out to make it work. I didn’t intend for this to be a ‘hey Framework team your charger is broken’ post, just a sanity check to make sure I haven’t missed anything, and a PSA in case anyone else is considering using the Framework PSU for similar projects, so I appreciate the help.

Have a lovely weekend

[James3]

USB-C compatibility problems is hardly a surprise. The Standard is quite complicated and compliance test equipment costs about $20000, so not something these cheap USB-C devices are likely to test with. Maybe FW don’t even test with that sort of test equipment. My guess is they tested compatibility with the USB-C devices they sell, and left it at that.

If the test equipment was something like $100, I think we would have much better USB-C compatibility in the market.

[MJ1]

Framework contracted a company that specializes in things like power supplies to make it. Most companies use contract manufacturers to make their devices. The company who’s sells it may have either, been very closely involved in the design, just oversaw the design, or did nothing more than pick an already complete design.

Framework Laptop 16 Deep Dive - 180W Power Adapter

Pretty certain they have ridiculously expensive compliance test gear. That’s part of the reason why one uses such contract manufacturers. Exactly what they tested, and how thoroughly, would have been up to what was in the contract with Framework.

[MJ1]

@Earphone5329

was impressed at least with the construction of the cable. It has nice thick stranded conductors and good-quality insulation and connectors. It’s branded ‘WITRN’ and matches the photos on Adafruit and the Pi Hut exactly.

It could be the Framework power supply. It just wouldn’t be the part I’d suspect first. If I tried a few different cheap PD decoys, and none worked, then yep, I’d blame the power supply for being just too picky. Still might not technically be wrong, would need expensive equipment to know, but you can still be unreasonably picky without being technically wrong. If you’re more picky than the vast majority of similar devices on the market, then you’re wrong enough, no matter what the letter of the protocol says.

~edit~
Oh hey, Framework has a 30 day return policy I believe for everything. Whether it’s the part at fault or not, don’t need to know or care. I believe it’s just 30 days for any reason. No longer needing it for your project is valid. It’s not cheap.

[Earphone5329]

Ah thanks for reminding - don’t worry though, I got an FW16 in the initial preorder so it’s the one that came with that. My logic was just that I’m never using my laptop at the same time as the recorder so I can use the same power adaptor for both

[Brian_Gregory]

@Earphone5329

The Framework adaptor can supply up to 15V 3A and the cable is rated for 15V 5A, but I can’t see how that would cause problems, particularly when the Apple charger is also rated at 15V 3A.

Presumably the cable will ask for 15V 5A, the PSU will say No way! That would overload me!

[James3]

The A2743 (70W) advertises 15V 3A and so does the FW16 180W PSU.
In addition, the FW16 advertised a PDO for any voltage between 5V and 36V at 5A so the cable could have asked for that, but maybe does not support the continuous range variable one.
FYI, when the FW16 asks for 36V, it uses the continuous range PDO.
The EC understands the continuous range and requests it, even if the Linux kernel does not understand it, and the Linux kernel “sensors” just reports 5V/5A when the EC is actually in 36V/5A mode.

The F8 only needs 24W, so 15V/3A should be enough.

So, on reflection, it is unlucky that the adapter does not work.

[MJ1]

@Brian_Gregory

Presumably the cable will ask for 15V 5A, the PSU will say No way! That would overload me!

Normally the if a power supply can’t provide what the PD trigger requests you just get the next closest voltage. E.g. if 15v is not available but 12v is, you get 12v. Should be the same with amps.

I don’t believe it’s even the power supplies responsibility to decide what to do if a device wants more than it can provide. Rather, I think they say, “This is what I got, here, take it or leave it”. And it’s the device’s responsibility to limit their current draw to within what the power supply says it can provide. Some power supplies have over current protection & will cut out if a device actually tries to draw much more than it can do. But refusing to even provide any, I don’t believe that’s done. Some power supplies do not have any over current protection, so if you try to draw more than it can do you’ll overheat it and / or the voltage will drop as it struggles.

The power supply is not responsible for having active current monitoring just in order to protect the device from it’s own stupidity.

[James3]

I have found a $60 USB-C analyser.
https://www.st.com/en/solutions-reference-designs/sl-pripm09404v1.html#1

I have not tested it yet, but it might work.
I think that the more USB PD negotiation logs we capture, the more likely a fix might be found.

[Alan_Pearce]

@James3

I have found a $60 USB-C analyser.
https://www.st.com/en/solutions-reference-designs/sl-pripm09404v1.html#1

I have not tested it yet, but it might work.
I think that the more USB PD negotiation logs we capture, the more likely a fix might be found.

You do realise that is not a turnkey kit, but rather software on an MCU development system. As such it is likely to require a reasonable bit of work before you have something useful.

[James3]

@Alan_Pearce
I have received the USB-C analyser.
Summary: It does NOT work.
It can act as an endpoint, but when in “spy/monitoring” mode, it does absolutely nothing at all useful. It happily passes through the USB-C signal, but fails to capture any logs of the messages.
The user interface (an app loaded on a laptop) is very clunky, and no source code is available for it.

1. In “endpoint” mode the GUI recognizes it and gathers the CC message log and VBUS voltages/current.
2. In “spy/monitoring” mode the GUI cannot find it at all, and thus not able to capture anything from it.

I feel I might have to go hacking the firmware so that I can at least capture a log from it.

What I have found:

1. In “spy” mode using a non-FW laptop, I can added an external device at it works.
2. In “spy” mode using a FW16 laptop, I can see it cycling about every 2 seconds connect/disconnect/connect/disconnect etc.

So, if I ever do get this USB-C analyzer working, we would get proof as to what is causing that cycling behavior at the CC message level.

[Brian_Gregory]

@MJ1

Normally the if a power supply can’t provide what the PD trigger requests you just get the next closest voltage. E.g. if 15v is not available but 12v is, you get 12v. Should be the same with amps.

I’m pretty sure the negotiation is more of a two-way conversation than just that. Just look at how long it takes a multi output USB-PD charger to figure out a way to divide the available power if you connect an extra device.

In this case, the trigger cannot truthfully reply with “Okay, I can manage with only 3A”, because it has no way to reconfigure whatever is connected to use only 3A, it doesn’t even know what the power is going to be used for. So you could end up trying to draw 5A from a 3A power supply, which obviously can’t be allowed.

[Brian_Gregory]

@James3

have received the USB-C analyser.
Summary: It does NOT work.

Did you get the discovery kit? (which is all I can actually see on that page that is for sale)
If so, it looks like it is not a complete product, but more of a way for you to learn how to build a product around their chip.

[James3]

I have found out how to make it work in “sky/monitor” mode now.
The “SRC” is the laptop side.
The “SNK” is the usb device attached to the laptop.

FW16 trace that cycles about every 2 seconds:

EVENT	37471	1	EVENT_ATTACHED	0	
DEBUG	37471	1	VBUS:3703, CC:1	1	
SRC	37531	1	SOP	 PD3	s:006	    H:0x11A1    	(id:0, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	2	
SRC	37533	1	SOP	 PD3	s:006	    H:0x11A1    	(id:0, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	3	
SRC	37534	1	SOP	 PD3	s:006	    H:0x11A1    	(id:0, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	4	
SRC	37716	1	SOP	 PD3	s:006	    H:0x13A1    	(id:1, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	5	
SRC	37717	1	SOP	 PD3	s:006	    H:0x13A1    	(id:1, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	6	
SRC	37719	1	SOP	 PD3	s:006	    H:0x13A1    	(id:1, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	7	
SRC	37900	1	SOP	 PD3	s:006	    H:0x15A1    	(id:2, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	8	
SRC	37902	1	SOP	 PD3	s:006	    H:0x15A1    	(id:2, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	9	
SRC	37903	1	SOP	 PD3	s:006	    H:0x15A1    	(id:2, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910127	
Option: 	UNCHUNK	DRD	USB	DRP	
 [1] Fixed : 5V - 3A
	10	
SNK	37904	1	SOP	s:002	    H:0x0481     (id:2, DR:UFP, PR:SNK) 	GOODCRC	11	
SNK	37907	1	SOP	 PD3	REQUEST	s:006	    H:0x1082    	(id:0, DR:UFP, PR:SNK)  DATA: 2CB10412
ObjectPosition:1
GiveBack:0
CapabilityMismatch:0
USBCommunicationCapable:1
NoUSBSuspend:0
UnchunkedExtendedMessagesSupported:0
MaximumOperatingCurrent:3000mA
OperatingCurrent:3000mA	12	
SRC	37907	1	SOP	s:002	    H:0x0161     (id:0, DR:DFP, PR:SRC) 	GOODCRC	13	
SRC	37909	1	SOP	 PD3	ACCEPT	s:002	    H:0x07A3     (id:3, DR:DFP, PR:SRC) 	14	
SRC	37911	1	SOP	 PD3	ACCEPT	s:002	    H:0x07A3     (id:3, DR:DFP, PR:SRC) 	15	
SRC	37912	1	SOP	 PD3	ACCEPT	s:002	    H:0x07A3     (id:3, DR:DFP, PR:SRC) 	16	
SRC	37915	1	SOP	 PD3	SOFT_RESET	s:002	    H:0x01AD     (id:0, DR:DFP, PR:SRC) 	17	
SRC	37916	1	SOP	 PD3	SOFT_RESET	s:002	    H:0x01AD     (id:0, DR:DFP, PR:SRC) 	18	
SRC	37918	1	SOP	 PD3	SOFT_RESET	s:002	    H:0x01AD     (id:0, DR:DFP, PR:SRC) 	19	
DEBUG	37996	1	VBUS:960: CC:1	20	
EVENT	37996	1	EVENT_DETACHED	21

Note: After the SOFT_RESET attempt, the SRC (FW Laptop) also sends a HARD_RESET, but that is not shown here. It only appears on the oscilloscope data recording.

A good trace from a different non-FW laptop:

EVENT	898815	1	EVENT_ATTACHED	0	
DEBUG	898815	1	VBUS:1536, CC:1	1	
SRC	898941	1	SOP	 PD2	s:006	    H:0x1161    	(id:0, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	2	
SRC	898942	1	SOP	 PD2	s:006	    H:0x1161    	(id:0, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	3	
SRC	898944	1	SOP	 PD2	s:006	    H:0x1161    	(id:0, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	4	
SRC	898946	1	SOP	 PD2	s:006	    H:0x1161    	(id:0, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	5	
SRC	899058	1	SOP	 PD2	s:006	    H:0x1361    	(id:1, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	6	
SRC	899060	1	SOP	 PD2	s:006	    H:0x1361    	(id:1, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	7	
SRC	899062	1	SOP	 PD2	s:006	    H:0x1361    	(id:1, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	8	
SRC	899063	1	SOP	 PD2	s:006	    H:0x1361    	(id:1, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	9	
SRC	899175	1	SOP	 PD2	s:006	    H:0x1561    	(id:2, DR:DFP, PR:SRC) 	SRC_CAPABILITIES	DATA: 2C910104	
Option: 	USB	
 [1] Fixed : 5V - 3A
	10	
SNK	899176	1	SOP	s:002	    H:0x0441     (id:2, DR:UFP, PR:SNK) 	GOODCRC	11	
SNK	899178	1	SOP	 PD2	REQUEST	s:006	    H:0x1042    	(id:0, DR:UFP, PR:SNK)  DATA: 2CB10412
ObjectPosition:1
GiveBack:0
CapabilityMismatch:0
USBCommunicationCapable:1
NoUSBSuspend:0
UnchunkedExtendedMessagesSupported:0
MaximumOperatingCurrent:3000mA
OperatingCurrent:3000mA	12	
SRC	899179	1	SOP	s:002	    H:0x0161     (id:0, DR:DFP, PR:SRC) 	GOODCRC	13	
SRC	899180	1	SOP	 PD2	ACCEPT	s:002	    H:0x0763     (id:3, DR:DFP, PR:SRC) 	14	
SNK	899180	1	SOP	s:002	    H:0x0641     (id:3, DR:UFP, PR:SNK) 	GOODCRC	15	
SRC	899211	1	SOP	 PD2	PS_RDY	s:002	    H:0x0966     (id:4, DR:DFP, PR:SRC) 	16	
SNK	899212	1	SOP	s:002	    H:0x0841     (id:4, DR:UFP, PR:SNK) 	GOODCRC	17	
SRC	899215	1	SOP	 PD2	GET_SNK_CAP	s:002	    H:0x0B68     (id:5, DR:DFP, PR:SRC) 	18	
SNK	899216	1	SOP	s:002	    H:0x0A41     (id:5, DR:UFP, PR:SNK) 	GOODCRC	19	
SNK	899216	1	SOP	 PD2	s:006	    H:0x1244    	(id:1, DR:UFP, PR:SNK) 	 [1] Fixed : (5V - 3A)	
SNK_CAPABILITIES	DATA: 2C910104	20	
SRC	899217	1	SOP	s:002	    H:0x0361     (id:1, DR:DFP, PR:SRC) 	GOODCRC	21

It looks like the main problem here is the Laptop(SRC) sends the “ACCEPT” but never received a GOODCRC in return from the device(SNK).
I don’t know what the cause of this is yet, it could be any off (guesses):

1. Signal noise or distortion or wrong levels on the Laptop TX side so that when it arrives at the destination device, it sees CRC errors. Note: There is no reporting of bad CRC, so this will be hard to be sure about.
2. The Laptop TX side does not wait long enough between transmissions for the device to react.
3. The Laptop RX side is not sensitive enough and sees more CRC errors that other non-FW laptops.
   In summary, I need to find a way for the spy/monitor to report bad CRC errors and maybe hook up a digital oscilloscope to look for problems in the signal.
   The TX and the RX is done over the same cable it will be difficult to know which side is sending when on the oscilloscope display.
4. laptop not providing enough power to the device to complete the CC power negotiation process.
5. The SNK (device) is simply not responding to the SRC (laptop) ACCEPT request.
   I have connected a data capture oscilloscope to the CC1 pin and then decoded the resulting CC messages. Checked all their CRCs and they are OK, but (5) is confirmed. the SNK is simply not responding to the SRC ACCEPT request as no pulses for it appear on the oscilloscope.
6. The SNK (device) is not correctly detecting when the CC link is “idle”, and thus not responding when it should. This needs further investigation. The “gap” between messages does appear to be different when comparing FW and non-FW laptops.
7. Observation, but no impact on this problem: Neither the FW or the Non-FW laptop send requests to find out which type of cable is attached.

There are some SOP’ “vendor specific” messages that I see on the oscilloscope data that is not present on the spy/monitor output. The SRC (laptop) is not sending GoodCRC for those, so it keeps trying to repeat send them. This is non-compliant to the USB-PD standard, but the non-FW laptop also does not respond to the SOP’ messages, but works fine, so I think that point is not the cause of the problem.