Add support for Franklin ACE 1000 replacement keyboard

[ryucats]

Hello,

This pull request adds support for a Franklin ACE 1000 replacement keyboard.

The capacitive keyboard on my Franklin failed, so I designed a replacement using Cherry MX keyswitches and your ASCII controller. As the row/column definitions didn't match any of the existing keymaps, I created a new keyboard profile ("ace1000") to match the replacement keyboard.

Cheers.

[dfnr2]

This looks great, nice work! It should pull right in. Ideally, we should have a copy of the keyboard design files for the PCB in the repo as well.

Would it be possible to add your PCB files into a subdirectory of the "hardware" directory in the repo? The GPL can stay intact. The following changes would be nice:

1) Add stabilizers for the spacebar. You could start with the 8U spacebar footprint, and move the stabilizers out 0.375" in either direction to make a 9U spacebar footprint.

2) Consider: Once in the repository, add the hardware/common/unikbd libraries, and substitute the unikbd combined CherryMX/futaba footprints, so that futaba keys can be used. If this complicates routing, then this could be left for later.

3) Consider: If the 40-pin header is on the bottom of the keyboard, then the ribbon cable connection will be at the top, which might make cabling cleaner. If this is too much trouble, it could be left for later

4) Make sure mounting holes and PCB outline match the franklin case.

Thanks!

Dave

[ryucats]

Hello Dave,

Thanks for the encouragement.

I wasn't prepared to submit the keyboard design files just yet, as there are a few minor tweaks I need to do after assembling the prototype board -- and I'm going to be away from my lab for a couple of weeks, so I won't be able to make changes until the beginning of April.

Replies to comments, in order

1. stabilizers are needed on the spacebar, yes. There are holes in the board that should allow mounting, but I'm still waiting for a stabilizer to be delivered.

2. no problem switching from the CherryMX footprint to the combined CherryMX/futaba footprint. Routing should not be impacted that much.

3. I believe that I designed it with the ribbon cable on the top -- the footprint on the silkscreen is on the bottom due to an error, but the header is on the top. Photos are attached.

4. the keyboard is a 1:1 physical replacement for the original keyboard. That was the original design goal, to have a drop-in replacement. I spent serious time with a micrometer measuring gaps, and was gratified to discover that the original capacitative keys had the exact same footprint as CherryMX.

There are issues that I want to resolve before declaring the keyboard finished:

• the power LED should be wired into the keyboard.
• I'm not sure if the caps lock key should have the switch stem in the center (per the keycaps commonly available) or 1/3 to the left (as in the original keyboard, to accomodate the caps lock LED).
• the keyboard sags in the middle due to the PCB not being made out of steel like the original keyboard assembly. I need to go to the hardware store and look for suitable horizontal stiffeners.

I also need to figure out how to get the caps lock to be set on at powerup (#define ACE1000_CAPS_LED_INIT_VALUE 1 doesn't change the behavior), but that's a very minor cosmetic issue.

If you're okay with importing the keyboard design file as it is at this moment, I can add it into the hardware subdirectory and add it to this pull request.

Cheers :)

Edit: I just noticed that the keyboard design file that I committed to the repo was not the final version with the mounting cutouts. Sorry about that -- fixed.

[dfnr2]

Hi Chris, this is a really fantastic addition. The photos look great. The PCB is very nice. Some points:

1) Adding an aligner plate, like the other keyboards in this repo, will eliminate the sag. The aligner plate forms a torsion box with the PCB and screws/spacers that adds a great deal of stability. The Sol-20 keyboard is similar width, and is very stiff. As a bonus, the aligner plate will allow using the 3-pin (plate mount) switches in addition to the 5-pin PCB-mount switches, and sometimes it's easier to find a deal on those. For using futaba keys, which are a closer height to the originals, an aligner is necessary for the keys to end up straight.

2) If you put the connector on the bottom, then it might be possible to mount the encoder to the keyboard with the encoder connector on top. Of course this would require that there is no interference with the motherboard. If the motherboard interferes with the encoder, then best leave the arrangement as is. it looks like you found a good spot for the encoder in the case, so maybe best not to fiddle with it.

3) The encoder already has footprints for per-row diodes, so no need to add them in the keyboard. On the other hand, there are benefits for adding a diode per key. If you use the footprints in the unikbd library, either through-hole or surface mount diodes are supported. Having JLCPCB assemble on the surface mount diodes costs literally a couple of bucks per keyboard and saves a lot of time. And you get better N-key rollover without artifacts.

3) The Caps lock and shift lock functionality are provided by the keyboard firmware, since these functions are common to several layouts. To set the caps lock on initialization, add:

#include "asdf_modifiers.h"
...
void setup_ace1000_keymap(void)
{
...
asdf_modifiers_capslock_activate();
}

The reason setting the CAPS_LED_INIT_VALUE didn't work is that the LED is just a virtual LED--any LED can be designated as the capslock LED via the virtual LED mechanism. Once an LED is assigned to CAPSLOCK, then the capslock functionality provided by the modifier module takes over, and by default sets capslock to off on powerup, regardless of it's init value.

Some other thoughts:

I think it would be well worth putting together a custom keycap set to flesh out the layout without leaving any gaps. The "L"-style tab and return keys will be hard to reproduce, but can be handled by widening or adding keys above the tab and return keys. I custom set from signature plastics would be about $120 in quantities of 10, and could be made very close to the original, including a red lens in the shift lock key. The main downside is the lead time, which is about 9-12 months. There are also other services like Krome and MaxKeyboard which can turn keys faster, albeit not the same color selection and double-shot quality as Signature Plastics. In either case, there should also be a strategy for the 9u spacebar. I suggest using an 8u spacebar and an extra 1u key to fill the space.

It may even be worth figuring out two PCB layouts and keymaps: one for a replica as close as possible to the original, using custom keycaps, and one using standard PC-104 keycaps.

Regarding the Shift Lock with integrated LED, the stem should be in the middle of the key, and the LED can be angled in from the side, as with the Sol-20 layout.

Nice work! If you include the current version into the repo, then I will pull it all in. No hurry on all of the changes. I can also help out once it's in the repo. Would you mind if I add the unified keyboard project to the labeling, in addition to your credit and copyright?

Thanks,

Dave

[ryucats]

Hello Dave,

Thanks (again!) for the kind words. Since fixing the caps lock LED was an easy one (actually three, as I needed to swap the caps and plain matrices), I went ahead and added it to the pull request. The keyboard KiCAD files were also added.

Answers in order:

1. I'll look into putting together an aligner plate when I get back to the lab.

2. space is pretty tight underneath the keyboard, so mounting the encoder directly to the keyboard is problematic -- that color board piggybacked onto the motherboard makes things complicated. Moving the speaker to the PSU fan grille and putting the encoder in its place seemed the simplest solution.

3. I have no strong opinions regarding the diodes. I added footprints for them as I figured it was better to do it on the keyboard rather than on the encoder -- but I had already populated the diodes on the encoder, so the footprints are just jumpered on the keyboard prototype. Having them per-row allowed me to save a couple of vias up near the header, though.

4. ah, thank you very much for the clue-by-four. Caps lock behavior now works the same way as the original keyboard. Fixed, committed, added to request :)

I do want to commission a set of custom keycaps; although the original keyboard does resemble current PC keycaps in most respects, there are a few differences (square and curly braces are separate keys, the tab and enter key shapes that you noted, etc). I was initially looking at Signature Plastics, but hadn't gotten as far as requesting a quote yet. The months-long lead time is a tad unfortunate; while I'm out I'll start a conversation with Krome and/or MaxKeyboard for Franklin keycap reproduction.

I like the idea of doing a straight PC keycap variant as well.

Feel free to modify the keyboard labeling as appropriate.

Thanks again for the encouragement. It is much appreciated.

Cheers :)

[dfnr2]

Nice work Chris! This is a great base to start with. Keep an eye on the repo, as I may also do some simple updates to harmonize the PCB with other keyboards in the repo. I'll be adding some tasks to the issues list, including:

1) Add aligner plate 2) Add the option for a diode per key 3) Futaba / Cherry MX dual footprints 4) 9x spacebar solution (8x + 1x, or 7x + 2 1x, or maybe 2 4.5x) 5) Specs for keycaps

[ryucats]

Wonderful, thank you.