Expansion Bay Developer Program

To enable creating new Expansion Bay Modules for Framework Laptop 16, we’ve published documentation and CAD.

To screw in the interposer cables we use, currently, a custom SMT Nut is needed. 2x are needed per board. We’re working to find an off the shelf solution, but in the meantime, you can request a cut tape section of nuts that you can either hand solder or have machine placed during SMT.

Quantities are limited, so we’ll be prioritizing applications that have electrical design progress. You can make a request through this application form.


What is the current plan for getting any kind of testing hardware to test designs?

1 Like

+1, the custom nuts are good, but an empty shell + fxbeam connector would be great to verify manufactured hardware.

We have a small quantity of riser boards now that adapt the Expansion Bay connector to PCIe. You can use the same form as before to request one.


Do we have a user guide and/or schematic for the riser board?

1 Like

Good question. We kind of missed on providing that. Let me check what we have.


We don’t have a sharable full schematic yet, but here are some of the key parts:


Hm, looked at the pinout a bit, https://github.com/FrameworkComputer/ExpansionBay/tree/main/Electrical, looks like VADP_GPU is needed for providing power back to the system. Haven’t looked at much else yet, but if I’m reading it right, for a Expansion Bay battery pack, you don’t need it specially regulated, between 7.6v and 20v? Or you need it regulated to 7.6v or 20v? Likewise, 6 pins, so maximum of 90W at 20v (0.75a each)?

So if it’s a 4s battery, for example, we can simply connect (through for example a MOSFET to enable/disable) those to the 6 VADP_GPU pins, so 16.8v-12v (charged to discharged) would be just fine? Or do we need to do constant voltage 7.6v or 20v?

And looks like pins 59-61 would be ideally implemented, for the EC to talk to any battery expansion bay. Is there any documentation for the EC of what exact protocol/specs an external battery should talk?

And pin 63 to control if it should discharge, or charge from VSYS_GPU pins, right? So if high, discharge, if low, connect to VSYS_GPU to charge?

Wow! That’s an amazing starting point for an external GPU enclosure that uses old FW16 GPUs!

1 Like

I can fathom how to fit the Graphics Board in there.
But the space needed for the cooling system’s fans looks blocked to me by other connectors.

1 Like

Guess you have to bring your own cooling system.

Yes, I had the same tought. I did some quick measurements, and the heatsink mounting system dimensions for the GPU module is something around 58,46 x 41,85 mm.

This hole layout does not match with anything I found on the internet, if it is full custom we can say goodbye to external coolers.
I was already dreaming about slapping a huge, off the shelf, 4090 cooler on it and having a DIY, semi-passive external GPU enclosure for the 7700S.
EDIT: image is mine, not an official/technical measurement of any kind. If someone over there at Framework wants to provide us with tech specs about the mounting system for the 7700S, we are all ears <3


Even if it is, you can probably easily enough put together a frame with some aluminum bits or what not to create a frame that can be used to hold a standard cooler down on top. Just so long as you can match the type of screw to those posts, which I bet Framework will be happy to share, if they don’t have it in the specs on github somewhere already.

1 Like

The power block diagram looks like this:

LM5143 supports a wide input range and ISL9241 is a buck/boost that can output the end 19V rail.

As you noted, one tricky thing on this is that the Expansion Bay Module would need to communicate with the rest of the PD controllers through the EC to ensure that only one power source is enabled at a time. That is something we haven’t defined yet.


Oh really? Do you mean only 1 battery in use at a time? Or battery vs external power?

On the diagram the main battery is separate, so both batteries could provide power at the same time if the system power draw requires it.
Which makes sense if you consider that the laptop can also use battery and a PD input at the same time during power peaks (and charge the battery otherwise).

1 Like

Is there any update on this yet?
Im working on a project for the expansion bay that would include an additional PD port which should ideally also be able to charge the framework. The PD type C port controller Im going to use has the I2C interface to communicate with the EC, but what I dont know currently is what that communication would need to look like.
Is the EC going to communicate at all on the I2C bus thats on the interposer and if so, is it possible to tell the EC that there is power available on the VADP rail at the moment or not?

Im still designing the hardware atm, but would be good to know if I can expect this to be a possibility at all or not…

1 Like

No update yet, but that is the intent behind this. It will likely require new firmware on the system side as well.