The design files are here but there are some errata, e.g. SPI pinout is wrong on the flex PCB:
In short: We sneak a flex PCB below the macro pad to connect to the 2nd set of pogo pins. The flex PCB has pads for an RP2040-tiny board and it has the important parts of Waveshare’s adapter board for their 3.7’’ ePaper. We add a resistive touch screen and maybe an APDS-9960 gesture sensor.
On the software side, my hope is that we can add a headless output to Sway and mirror that to the ePaper.
Current issues:
The flex PCB works quite well but it is a bit cumbersome to install because you have to align it before installing the macro pad module. I’m not sure that this can be improved. The challenging parts are (a) we have to align to the pogo pins and (b) distance to the pogo pins changes when we move the module into place.
There isn’t much space in the vertical direction. The current module is 1mm higher than the normal palm rest and we also need a few mm more towards the keys. We will have to find a better touchscreen module to improve this.
I would like to add some security functions to the module (FIDO2 with UI, password manager) but that doesn’t make much sense with RP2040, which omits trusted boot to be unbrickable.
The PCB design has a few errata: SPI pinout, pitch of touchscreen connector, length of connector to the pogo pins.
Just to share more in formation in hopes it may help in some way, it seems Framework made a mock for one which would be in place of the macro/ num pad instead of below it. (Video posted March 25th, 2023)
I am not sure if anything more has been shared outside of it in this video or designs for it shared;
Now if it has a resistive screen and can be used with pen to input letters and numbers via the good ol’ Palm input method “Graffiti” as well as general purpose display… woohoo!
Because of the way you are having to connect I presume this can only go on the left of the touchpad as illustrated, or are you thinking there could be another version that could go to the right?
@BulletzQS Yeah, I’ve seen it in this thread. I’m taking the complicated route because I want to keep the macro pad
@Axel_Hartmann Hehe. I like that idea. Not so useful next to a full keyboard but I might add it anyway. Do you know of any FOSS software that already implements the Palm input method?
You will need a free set of pogo pins with USB. In practice, this means that it is best placed below a double-width module like the macro pad or numpad. I think all of them have must use the USB pads on the left because of how the config resistors are defined, so the right ones are likely free.
@Alan_Pearce Yes, this means that it can be on the right side.
There are additional pogo pins that are covered by the touchpad module. The three in the middle have I2C and are not useful for this module but I think you could swap epaper and touchpad while keeping the macropad to the left. You could also try more creative ways and 3D print a smaller touchpad module.
@TheLPeink@Iron_Raptor I don’t think that this will ever be viable as a product to be sold. The original Framework modules are easy to install and hard to misuse. Their spec isn’t meant to allow this kind of module (which is exactly why I wanted to try it anyway ). It will never be as robust and you can certainly break things if you misalign the flex cable. Thus, customer support would be a nightmare.
Nonetheless, I’m publishing all the design files as usual so anyone can build it and modify to suit their needs. I suggest that you ask at hackerspace/makerspace/Fablab in your area if you need help with soldering and 3D printing the parts. I expect that the cost will be 30-80€ — depending on whether you find someone to pool orders (e.g. you cannot order fewer than five flex PCBs).
The size is not really right and I would like to find a thinner one. Do you have any suggestions on where to buy them? My search on Ali and Ebay was mostly like “open a lot of tabs, hope that they have dimensions somewhere (many don’t), repeat until too frustrated and then buy one that maybe, sort-of works”.
(Edit: And I haven’t found any that specify the pitch of the connector, so I had to guess.)
I just found another small issue: My plan was to also have this working outside of Framework (if only for debugging) but 3.3V for the epaper is not connected when using the RP2040-tiny to USB adapter.
We can close JP4 to fix this but then it shouldn’t be used with the laptop anymore because then two source would be driving that power supply. D’oh!
I just re-printed the outer part of the module, so that’s a good moment to take more photos. This is how it looks from behind:
You can see that the flex PCB is bent when installing the module. This probably won’t survive hundreds of times but so far it is holding up great.
Installing the module becomes easier if we apply a piece of tape. I should have thought of this earlier (It is transparent tape so not so easy to see here.)
No, not really. Only 16’’ has this module system. You can add this to any laptop, in theory, but it will be more work. Framework 13 might be slightly easier than others because of good documentation, easy access to replacement parts and you could use a dongle hider extension card to connect it to USB.
Status update: We can add it as an additional output to Sway:
We are using dithering to simulate additional levels of gray beyond the four that are supported by the display. You can probably not at all in the photo but it is clearly visible in the debug images:
There are some downsides: First, mako may decide to show notifications on the epaper if we position it to the right of the main display (workaround: move it to the left):
This might be exactly what you want, e.g. if you use it as a 2nd screen and there could be private information. My plan is to use this as a status display and it should remain available when the main screen is locked.
swaylock used to support transparency, which would solve this rather nicely, but not anymore (for very valid security reasons - not supporting transparency anymore is just an unintended consequence).
We do have a rather hacky workaround: Run a nested Sway session with X11 backend. The downside is that we cannot move a running application to the epaper without restarting it.
would it help for locating the position of the pogo pins if you do through hole for the pogo pins with contacts touching the sides of the pins? or use the line up pegs that the keyboard uses by making a bigger contact end with holes for the pegs but leave the pads for the pogos the same?
My prototype has through holes and you are correct: It does help. They are smaller than the pogo pins because I wanted the contact area on top of the pogo pins, so the spring will still do its job. The holes could be a bit larger but I was a bit too cautious in the first design (I’d rather make it a bit harder to align and not risk a bad contact).
The holes help because you can feel whether the alignment is correct and they will remain in place while a bit of pressure is applied. However, they won’t remain when you remove your finger. Therefore, you still need a bit of tape to hold it in place.
About the pegs: Yeah, that might work. I was trying to keep the area around the contacts small and not overlay the magnets but maybe I should make it larger and use the pegs.
On a different note: RP2350 is great! I hope that Waveshare will eventually make an RP2350-Tiny. The RP2350 has some security functions, so we could turn the E-Paper module into an actual security key.
An idea to ease the installation would be to install just a flex pcb extending the pogo pins first by sticking it to the mid plate and having it present a horizontal line of CAMM2-like connectors to connect to by sliding the module in.
That’d require a redesign though and I’m not familiar with kicad yet.
Still, I’d like to give it a try, so please let me know how you obtained / manufactured the flat flex pcb connecting to the the pogo pins.
Those are polyimide (brand name: kapton) PCBs. Some PCB fabs might just label them flex PCB. They are an option from jlcpcb.com listed as just “Flex” in the base material selector. oshpark.com has them, but makes them a little different than normal. They use a soldermask like traditional FR4 PCBs use, whereas normally polyimide PCBs use a “coverlay”, an outer layer of polyimide that serves as the soldermask. Their reason is mentioned in the FAQ on that page.
(It is transparent tape so not so easy to see here.)
