Even if the tech is patented, could I still make my own and share the process without getting sued?
It would be pretty easy to make a magsafe 3 receptacle, but I don’t know what else you need with it. The two outer pins are ground, the next two inward are +V, but that middle one does some talking, I think.
You could also buy a used magsafe 3 port on eBay for $20-$30 and it might work perfectly. I’ve been throwing these ideas around in my mind for a while.
That can’t be real. In that same logic you could get sued for reselling your apple product. Wouldn’t people that sell stuff like shadow boxes of electronics or resellers for components on eBay get sued for distributing? I hope that’s not the case.
Regardless, I think a magnetic expansion card would be sweet. I already have one I 3d printed, but if framework ever made one that doesn’t look nearly as janky as mine, I would be super interested.
So theoretically Apple could indeed spend upwards of a few hundred grand in legal fees seeking a reasonable royalty for your free or low cost small batch production’s use of their patented invention.
Realistically, why would they do that? Patents are about making money in my opinion. A massive number of people assert patents against Apple compared to when Apple rarely, if ever, asserts its patents. This is because if Apple’s found to infringe, the damages are probably huge.
i know i’m a bit late to the thread, but this is a topic i’ve dealt with (and been frustrated by) for a while.
Even if the tech is patented, could I still make my own and share the process without getting sued?
not entirely safely, if you’re replicating any of the components apple makes that’s covered by the patent. if all you’ve done is figure out how to do it and publish tech specs, the odds are low of apple harassing you, but not zero. you have to evaluate that yourself (but i’d be willing to bet any lawyer knowledgable in the field would tell you not to).
You could also buy a used magsafe 3 port on eBay for $20-$30 and it might work perfectly. I’ve been throwing these ideas around in my mind for a while.
this you can do, and publish documents for. (see below)
That can’t be real. In that same logic you could get sued for reselling your apple product. Wouldn’t people that sell stuff like shadow boxes of electronics or resellers for components on eBay get sued for distributing? I hope that’s not the case.
apple HAS been known to go after people replicating the patented components of peripherals, sometimes even small companies or individuals. the products you can find on the market are generally made by buying actual-apple-originated peripherals, salvaging the components, and reusing them in a new product.
basically, as long as the patent holder (apple in this case) actually made and sold it, then you can resell it (even integrated as part of another product) provided you don’t infringe on another patent in the process. the offending process is making your own version of a patented technology
Yes, I’d love having that! Especially since Apple sells USB-C cables, (I assume) I can use any charger with it.
DISCLAIMER: I am not a lawyer, this is not a legal advice.
Looking at the patent, it seems to concern only the physical coupling of electrical contacts, with a few specifics. So manufacturing a compatible port would infringe the patent, but just buying one made by Apple and incorporating it - probably okay.
The old case where Apple went after Sanho for making MagSafe cables out of actual Apple chargers was settled, so no ruling was made and we don’t know what Apple had on them. (e.g., I’ve seen speculation that they were actually making connectors and lied about harvesting them from chargers)
In case of MagSafe expansion card, Apple might have less interest in going after anyone making them, since it actually would make them more money (in cable sales).
As for the rest of the required bits that would sit between the MagSafe port and USB-C - I didn’t find any patents for that. But in case of the previous two implementations, there seems to be only a very basic negotiation protocol and a separate controller for lighting the LEDs in the plug: Teardown and exploration of Apple's Magsafe connector. I guess at that point their concern was fake chargers, and not someone using the original ones for something else
This would be amazing if progress were made. But I’d also be happy if Framework came up a magsafe alternative that fits into the expansion slot; Framework is in a unique position to offer a low-risk option, I think.
The MagSafe 3 connector just uses a normal CC pin with (I hope) normal PD messages. I think in theory it really is as simple as wiring it up to a USB-C connector.
It doesn’t. At the magnetic end MagSafe does not use USB PD at all. The MagSafe signal pin uses the 1-Wire protocol, not related to USB PD at all. And of course no USB data is carried over MagSafe, so there isn’t any USB whatsoever at the magnetic end.
It’s actually not that far off. According to MacBook schematics, middle pin is wired to a USB-PD IC. (There’s active circuitry on both ends of the cable, so it’s not just a dumb pass-through to the power brick).
It’s not exactly USB-PD though, but the signaling seems to be compatible: connecting it to CC pin on the receiving side switches on the cable, but it only outputs the usual 5V. Don’t do this at home, I’m not responsible if you fry something.
My current hypothesis is that Apple uses proprietary messages to do roughly what USB-PD does.
I’ve got microcontrollers with USB PHY some time ago, but still slacking off on hooking them up and checking the communications with the cable.
It’s expected that the same chip would handle the USB-PD end, and Apple’s proprietary signaling for the MagSafe end. Simplifies the cable / lowers cost to not have two custom chips when one will do. Apple has fully custom ICs made as standard practice, since they have more than enough money to do so & it nets a savings for them, I’m sure.
But having the same chip would handle both ends does not mean the signaling is related in any way.
The active part at the MagSafe end with the signal pin, I presume, is done in order to 1) try to prevent non-Apple sold cables / clones, 2) confirm that the connection has been fully made and solid before switching to higher voltage & current. Higher voltages cause arcing issues, so you want initial connection to be done at a lower voltage.
Not sure exactly what you mean “connecting it to CC pin on the receiving side”, can you elaborate?
Pinouts of MagSafe3 list the signal pin as 1-Wire protocol. I presume people have tested it and / or Apple’s patents show it uses 1-Wire as a starting point, then Apple adds their proprietary protocol within that. Not sure if anyone has found how to spoof one or both ends.
Also not sure if USB-IF’s CC signaling is built on top of Dallas Semiconductor’s 1-Wire protocol. If it is, that could explain what I think you mean by the receiving side switching on when CC pin is connected. If you’re connecting CC to Apple’s MagSafe signal pin, and if both USB-IF’s CC signaling & Apple proprietary protocol is built on top of Dallas Semiconductor’s 1-Wire protocol, then that could cause it to pass the first step of Apple’s MagSafe connection checks, i.e. valid 1-Wire is seen, so clearly connection is made, and it’s ok to enable low voltage. But without Apple proprietary protocol under that, the cable isn’t “authorized” so full voltage & current doesn’t happen.
Soldering it to a CC pin on a Type-C plug and inserting the plug into the USB port.
I suspect those pinouts assume that it didn’t change much since MagSafe2. Poking it with 1-Wire protocol was the first thing I tried (using this post as a guide), and it didn’t work. 1-Wire uses transitions between 0V and 5V, so a logic analyzer would have no trouble picking it up - but it didn’t.
Of course, I’m taking it with a huge grain of salt. But in the board schematics I’ve seen that pin is literally called USBC5_CC1, and CC pin signaling (300kHz with logical high being ~1.2-1.5V) is consistent with me not seeing anything useful from both my logic analyzer (signals don’t reach the threshold) and Arduino ADC (way too slow for obtaining enough samples).
As for cost reduction, I’m betting on them just making a few tweaks to PD protocol, rather than making an entirely new thing.
Okay, I take it back. It does indeed seem to talk standard USB-PD, and the reason it didn’t work in my early attempts was just signal corruption due to the wire being too long.
Now I’ve got it to the point where I can reliably receive PDOs upon attaching the cable. In the next few days I’ll also check that it does supply specified voltage when requested, and if it does - start drawing a PCB.
Oh nice.
Good thing you didn’t listen to me, saying that it’s listed as 1-wire protocol. I had got that from the pinouts here https://apple.fandom.com/wiki/MagSafe#MagSafe_3. But I failed to check the citation. It’s from Magsafe 2, not 3.
Made a working prototype and, unless I’m still having issues with signal integrity (which is totally possible), the cable expects some extra handshake from the laptop: it does switch on, but then quickly shuts off. And it goes on like this forever, with one cycle taking roughly two seconds.
Made a brief detour to write a Wireshark dissector for I2C comms with FUSB302 controller: from what I see, message exchange goes the same way as with a regular Type-C cable:
Source_Capabilities →
← Request
Accept →
PS_RDY →
But then, unlike a regular cable, about 2.8 seconds after PS_RDY, MagSafe cable cuts the power and the whole process restarts from scratch.
One of the suspects I have is the lack of normal ongoing message exchange between Sink and Source, but the timing doesn’t line up. (Still possible that Apple has hardcoded a shorter timeout, so I still want to try sending them with 1s intervals and see what happens)
I think at this stage I’ll try to make a USB PD sniffer out of FUSB302 and find someone with a macbook and obtain a dump of communications between MagSafe cable and the IC that Apple is using in their laptops. (Until now I’ve used Pinecil breakout board attached to a logic analyzer to dump the I2C bus Pinecil’s internal FUSB302 is connected to)
If it indeed turns out that the cable requires slightly modified protocol, then we’d have two options:
modify EC firmware to support these modifications (at least on my AMD Framework 13 it seems that EC is handling PD negotiation and the main system knows nothing about it)
have a microcontroller inside the expansion card to take care of that, presenting a normal PD interface to the laptop
Can confirm that re-sending Request every second works and the cable doesn’t restart.
I see two violations of USB PD spec here:
ongoing communication is only required when Augmented PDO is selected by the Sink (and Source also needs to supply at least one of them in the initial Source_Capabilities)
the interval is a lot shorter than tPPSRequest from USB PD spec
It should be fairly easy to patch EC firmware to keep sending Request every second unconditionally. But EC firmware likely requires separate build for each mainboard mode, and I’m not yet sure that the source code on Github is up to date.
The option to have the adapter being completely passive is very attractive, but with how janky and under-documented EC firmware build process is (at least outside of Framework’s dev&qa processes) - it wouldn’t work well.
So, any recommendations on which IC would be the best to use here?
It would need to sit as a man-in-the-middle between MagSafe and laptop’s Type-C port and handle the non-standard bits that the cable is expecting.
FUSB302 I have at hand won’t really cut it, since it supports only one port and must be controlled externally (so it would be 2x FUSB302 + a microcontroller with custom firmware). There are probably some ICs out there that can handle all this in one package.
EDIT: FUSB15200 might’ve been a good fit, except that, despite touting “open-source” on the overview page, reference firmware is provided under a license which roughly boils down to “no, you absolutely, not in a million years, cannot make any of this or any derived work available under an open-source license. We will sue the shit out of you even if you simply ship your code to customers without having them sign an explicit license agreement”