Next GH-brewed KB design - 'The Light' (open for discussion)

[bpiphany]

Wait, 6 rows? I thought we were doing a 7 row 133 key board. And how could you possibly route it to work as a fullsize, tenkeyless, and poker?! That's a lot of extra circuitry you're adding too. Wouldn't that drive up the price too much? How is a filco replacement board "universal"?...

So if I have this straight - Those Transister_NPN would be replaced by FETs. C would be Source (S), B would be Gate (G), and E would be Drain (D).

When in polling mode - the FETs on the LED rows would have their gates closed to prevent the LEDs from lighting up during polling. Each column would take it's turn having it's gate open to be polled through the switch rows.

When in LED lighting mode - The FETs on the LED rows would have their gates opened (when polled) to allow the LEDs to light up when they are polled. Each column would take it's turn having it's gate open to light up the LED rows that were polled.

Is this what you're trying to do?

I'm leaning towards having completely separate matrices for the switches and LEDs after all.

But wiring like that picture it should probably be possible to do both the LED lighting and switch sensing at the same time. If there aren't to much stray capacities/inductances.

I just picked the transistor symbol I had at hand. FETs and BJTs are very different but still the "same" in this application, we only want them maxed out as current switches. N- as well as P-channel could be used depending on what what turns out to be the most suitable.

A universal Filco replacement board have all the important circuitry contained within the alpha-section. This makes it possible to cut away parts not needed. The Filco tenkeyless is the same physical layout as the fullsize (differing only in mounting holes and other under the hood stuff). Simple circuitry doesn't mind being cut away if designed to allow for it. Mounting holes may interfere, but I don't think I have run into any unsolvable problems this far.

I'm redesigning my backup script at the moment (important second to nothing...), but after that I might squeeze in some KiCAD time =)

[bpiphany]

I quite liked the idea of using the polling columns to shift through the LEDs as well, Is the shift registers really necessary?

Also, would it be hard for others to load, since not everyone has a programmer.

I might go head with what I had in mind and design with the teensy as the MCU. I think with the use of some FETs there doesn't need to be shift registers.

Have you documented any measurements for things that I could possibly get off of you? Also maybe components like diodes/resistors designs for the software. That would be handy.

Shift registers frees up a ton of processor cycles, and more cycles allows for generating more advanced lighting patterns. The shift registers are ~<$0.5 a piece, so $9 in total.

I'm unsure of how much current can be put through the VCC and GND pins on the Teensy, but it might be the full USB 500mA, I don't know. Having the USB connector directly on the main board would give a safe 500mA for sure. And implementing the "Teensy" directly on the main board solves some placement difficulties =P

No-one should get sad if we develop two competing products. Competition is good, right? =)

I have some measurements for mounting holes and key locations of the Filco boards if you are interested. They are only as good as I made them though, no universal truths...

I haven't made footprints for anything else than the Teensy and Cherry parts. But there are libraries out there for all sorts of components. And there are hundreds of different footprints for transistors and things like that. So you would still want to make your own based on the datasheet of the actual part you are going to use.

[hazeluff]

Designing two only helps our cause. Since neither of us can work on one design together. By doing two one can be the fallback of the other. Ill do my integrated design and you do your split one (LED). See what turns out better.

I still dont think the shift registers help. Since the wire that is polling for the keyboard can be used for also the LEDs.

[The_Ed]

OK, but was I correct in understanding what you're trying to do hazeluff? If so then I also agree that your design should work, and should be cheaper with those extra keys even.

[bpiphany]

Oh, and I  forgot... 21 columns on a full size board, and 21 for the LEDs, and then 7 rows on top of that. That is a lot of I/O without some external logic components.

Edit: Well make that 11 + 11 cols plus 14 rows and that is less of a problem.

[hazeluff]

Oh, and I  forgot... 21 columns on a full size board, and 21 for the LEDs, and then 7 rows on top of that. That is a lot of I/O without some external logic components.

Edit: Well make that 11 + 11 cols plus 14 rows and that is less of a problem.

The current design is (15 + 3 + 4) 22 Column + 7 Row = 29 pins For the keyboard itself, with 7 more for the LED Rows.
By reusing the same pins of the Column of the keyboard for the LEDs I save a lot of pins.

(= Calm down boys (and girls, what do I know..) Looking for this? I can't swear it'll work out exactly like that, but I have a feeling it should be doable.

Show Image

Thats 36, which can be implemented with the teensy 2 ++.

Yes it's a lot of I/O but it should be fine.

[The_Ed]

22 columns?

1. 13
Extra 13
2. 14
3. 14
4. 13
5. 12
6. 8

Largest is 14. 14 + 3 + 4 = 21...

+ 7 * 2 = 35...

Am I missing something?

[bpiphany]

The current design is (15 + 3 + 4) 22 Column + 7 Row = 29 pins For the keyboard itself, with 7 more for the LED Rows.
By reusing the same pins of the Column of the keyboard for the LEDs I save a lot of pins.

Yeah, so I haven't slept a lot lately... Of course it should be done that way around, but I think you should consider 11+11+14. That still fits the Teensy++ and lowers the required frequency of cycling the matrix. Now I've got some more work to do, no sleeping yet =P

[hazeluff]

22 columns?

1. 13
Extra 13
2. 14
3. 14
4. 13
5. 12
6. 8

Largest is 14. 14 + 3 + 4 = 21...

+ 7 * 2 = 35...

Am I missing something?

Esc + F1-12 + 2 extra = 15?

[hazeluff]

Yeah, so I haven't slept a lot lately... Of course it should be done that way around, but I think you should consider 11+11+14. That still fits the Teensy++ and lowers the required frequency of cycling the matrix. Now I've got some more work to do, no sleeping yet =P

I see what you mean, but Given how much slack we have to compute between cycles to still achieve the 1kHz poll rate, I don't think it's nessesary.

[The_Ed]

There's no way that the 9 holes required for every switch won't interfere with each other if there is a 15 switch spacing laid over a 13 switch spacing on the F and extra rows. We would have to have the F and extra rows be either 13 key or 15 key. Unless there is diagram proof that they both fit we should go with the traditional 13.

The PCB switch mounting pins are the most likely holes to interfere with each other, followed by the diode holes. And even if all the holes fit, the traces may not with so little "land".

The PCB mount cherry G99 stabilizer holes are also a concern for interfering.

I have been referencing these 2 PCBs for my spacing concerns. How sure are you that EVERYTHING will fit?

[The_Ed]

I just thought of a compromise. 14 keys on the F and extra rows. The 14th would be between Esc and F1. That wouldn't interfere with anything. Sound good?

[hazeluff]

I just thought of a compromise. 14 keys on the F and extra rows. The 14th would be between Esc and F1. That wouldn't interfere with anything. Sound good?

I'm working it out right now... Its a very slow process of putting down 100+ switches onto the design ><.

I think it'll work. I'm not ruling it out until my thing doesn't work

[hazeluff]

Progress: Cluster**** time

[ Attachment Invalid Or Does Not Exist ] 41225[/ATTACH]

[The_Ed]

I'm not seeing it... What layout IS that? Or is it just incompletely populated with switches that are in the wrong places?

[hazeluff]

Prin do you have SMD component for diodes (schematics)? Also should i change the grid to fit the different mod switches? The settings now don't quite work for the 1.25 mods (or 1.5) I don't know. It doesn't lay out right. I'm currently using your 0.1875" setting for the grid.

[hazeluff]

I'm not seeing it... What layout IS that? Or is it just incompletely populated with switches that are in the wrong places?

Im laying out all the layouts on there. Was only half done.

[bpiphany]

First of all, turn off the ratsnest...

Second, keys not fitting on the grid needs to be adjusted "manually". Right click the component and set the coordinates by hand. Make yourself a spreadsheet of all the switch coordinates. It will come in handy, I promise =)

I don't have any footprints for SMD diodes. You want to make them yourself anyhow to make sure they are correct. There are a lot of different ones. Different manufacturers mmay even have different recommendations for pad layouts. Check the datasheet for the exact part you will b using. If you are going to have a manufacturer mount the components you might need to specify "good" solder mask clearances and solder paste patterns as well. I haven't looked into those things.

[hazeluff]

First of all, turn off the ratsnest...

Second, keys not fitting on the grid needs to be adjusted "manually". Right click the component and set the coordinates by hand. Make yourself a spreadsheet of all the switch coordinates. It will come in handy, I promise =)

I don't have any footprints for SMD diodes. You want to make them yourself anyhow to make sure they are correct. There are a lot of different ones. Different manufacturers mmay even have different recommendations for pad layouts. Check the datasheet for the exact part you will b using. If you are going to have a manufacturer mount the components you might need to specify "good" solder mask clearances and solder paste patterns as well. I haven't looked into those things.

How handy is the switch coordinates... >.> theres like 160 switches...

Oh well I'll work with the discrete for now and see how that works.

[bpiphany]

There's no way that the 9 holes required for every switch won't interfere with each other if there is a 15 switch spacing laid over a 13 switch spacing on the F and extra rows. We would have to have the F and extra rows be either 13 key or 15 key. Unless there is diagram proof that they both fit we should go with the traditional 13.

The PCB switch mounting pins are the most likely holes to interfere with each other, followed by the diode holes. And even if all the holes fit, the traces may not with so little "land".

The PCB mount cherry G99 stabilizer holes are also a concern for interfering.

I have been referencing these 2 PCBs for my spacing concerns. How sure are you that EVERYTHING will fit?

I'm probably going to drop some of the PCB mount holes, especially for secondary switch locations. Some of them will be completely swallowed by center holes of other switch locations. PCB mounted switches isn't really a absolute requirement even on a mounting plate less board. It just requires some more care to get everything straight.

LED holes will actually not interfere too badly. There are going to be some creative solutions in a couple of places, but nothing really bothersome.

Mounting holes for stabilizers for different layouts might be the biggest concern. They can't really be combined. If any holes are drilled to full size from start it won't be possible to have options, since the holes will overlap extensiely. Stabilizer/center holes for the ANSI and ISO enters really messes things up for eachother already.

I am going to do 1mm holes for all stabilizer mounts. Which holes to drill will be chosen later. It's pretty easy to line the holes up with those pilot holes. And chery stabilizers aren't that extremely sensitive either. (In my opinion plate mounting is the future anyways =D)

[hazeluff]

I'm actually to get lost in all that is the holes for mounting x and y.

[Parak]

Prin do you have SMD component for diodes (schematics)? Also should i change the grid to fit the different mod switches? The settings now don't quite work for the 1.25 mods (or 1.5) I don't know. It doesn't lay out right. I'm currently using your 0.1875" setting for the grid.

Here's a SOD/SOT-123 component that I made for Vishay 1N4148W-V-GS08. I don't recall why, but I didn't like the SOD-123 that came with kicad libraries for some reason.

[hazeluff]

On my design I've scrapped the extra keys above the Numpad. It's extra keys that I don't think are that useful. Also it gives me room for the teensy

[The_Ed]

4 of the 8, or all 8? The 4 directly above the numpad were going to be used for my rotary encoders remember?

[hazeluff]

I threw them all...out...Wire them up to the bit above the arrows?

[The_Ed]

The 5 above the arrows is where "play/pause", "next track", "previous track", "stop", and "mute" will go. I need the 4 directly above the numpad for the 2 rotary encoders for "volume up/down", and "fast forward/reverse". Can't you just throw out the 4 above those 4? Is a 1 x 4 key plot too small? If we truly are using cherry or custom cases you could still have all 8 of those and put everything that doesn't fit in that extra 1.5 inches at the top.

[hazeluff]

The 5 above the arrows is where "play/pause", "next track", "previous track", "stop", and "mute" will go. I need the 4 directly above the numpad for the 2 rotary encoders for "volume up/down", and "fast forward/reverse". Can't you just throw out the 4 above those 4? Is a 1 x 4 key plot too small? If we truly are using cherry or custom cases you could still have all 8 of those and put everything that doesn't fit in that extra 1.5 inches at the top.

But you can easily use wires to connect it elsewhere. I'm going to stick with the being removed and work towards putting them back. Tonight I shall put in the LEDs and FETs...

[The_Ed]

Just use the extra 1.5 inches in the top. You'd have room for the teensy and the FETs there. And you could keep those 8 keys too.

Can those FETs switch open and closed in <4ns like a diode? If they can't then they may not work.

[hazeluff]

I dont want to make the board much bigger than it needs to be.
 Also im taking this one step at a time. Gonna get something working before i add more stuff.
As for the fets. They are smd atm so there tiny as hell. As for switching they should be in the nanosecond range. I dont have the numbers atm but ill check they should switch fast enough.

[bpiphany]

The ns only tell how fast signals they can handle. With the processor running at 16MHz the shortest possible time for anything is 62ns, and I don't know if it is even possible to turn I/O-pins on for a single clock cycle. In any case that's probably not going to be interesting since there will be a lot to do between I/O-signals.

[hazeluff]

The ns only tell how fast signals they can handle. With the processor running at 16MHz the shortest possible time for anything is 62ns, and I don't know if it is even possible to turn I/O-pins on for a single clock cycle. In any case that's probably not going to be interesting since there will be a lot to do between I/O-signals.

Yeah

I mean the absolute is the delay of turning on the pin and the LED lighting up. But that's not near being a problem.

I'm not having much fun putting the components in place... Can't wait to see the routing spaz out.

Prin, do you know the correct orientation for the LEDs. They are slightly differently aligned when I use the user grid and rotate the LED. It's not really a big problem since its quite minimal difference, and the LED legs could always be slightly slated/bent.

[bpiphany]

I am soon going to know this link by heart... The LED pads should be on the same distance from the center. Otherwise there is something wrong with the footprint. There is a little diode symbol on the casing. Getting that orientation is of course prettier, but it doesn't really matter =) The LED fits into the switch any way around. It might be a bit late now but I would recommend integrating the LED pads with the switch footprint.

[hazeluff]

I am soon going to know this link by heart... The LED pads should be on the same distance from the center. Otherwise there is something wrong with the footprint. There is a little diode symbol on the casing. Getting that orientation is of course prettier, but it doesn't really matter =) The LED fits into the switch any way around. It might be a bit late now but I would recommend integrating the LED pads with the switch footprint.

Wait are you telling me, the diode included switch is actually the switch + LED? == FML... Redrawing my whole thing... Dear lord...thats gonna take a while...I've been using a basic switch + LED component...

[bpiphany]

For this project I am going to use a 4-pin schematics switch symbol with the LEDs included. When I did the Phantom I had separate LED symbols, and separate components. But they were only 3 LEDs =) I also made a MX_LED footprint with the same coordinate origin as the switch to line them up easily.

[hazeluff]

For this project I am going to use a 4-pin schematics switch symbol with the LEDs included. When I did the Phantom I had separate LED symbols, and separate components. But they were only 3 LEDs =) I also made a MX_LED footprint with the same coordinate origin as the switch to line them up easily.

I don't want to redraw the schematic I have. The separate LED (I think I'm using MX_LED) is what I want, since I want to be able to rotate the orientation of the LED, without redrawing on the schematic. Should i just play around with the schematic so that it works both ways?

[Parak]

As found by Ripster, it looks someone had the idea of using super bright leds inside of the switches as backlighting for normal keycaps. I have to say that it looks quite nice.

[Parak]

you'll have to help me out here, since I can't read the original post on kbdmania... but from what Google translate did (or didn't) parse, I don't see any evidence from either the post or that picture that the LEDs are outside of the housing. the positioning of the light would actually suggest that the standard LED pass through in the housing was used.

and for what it's worth, the give-away for me is the capslock key.  if you're designing lighting independent from the switch, I don't see why anyone would choose to offset the light on the capslock key.

Yeah, I totally jumped the gun on this one, partially owing to not seeing such T1 LEDs before. Post edited to reflect (oho) that, thanks.

[bpiphany]

Just did my first try at soldering an ATmega controller. It didn't come out excessively bad at all =D Simple $50 40W soldering iron, a lot of flux, and lead free solder. I haven't tested it yet but I don't think I managed to break it... I had to do some cleaning up after the first side of legs. After that I nailed the right amount of solder to cover all pads in one go.




On a separate note, I am considering making a Filco replacement "mother board". 12 rows, every other column belonging to each row, so two physical rows for each keyboard row. And 21 columns with the possibility to connect columns in pairs with jumpers. That way it is possible to choose if you want to use 12 rows x 11 cols or 6rows x 21 cols, by connecting rows or columns in different ways to each other. Then there will simply be perhaps a 36 pin connector of some sort to connect everything to a separate controller board.

And all that x2, once more for the LED matrix as well.

[The_Ed]

I use a Weller WESD51 and either Kester 24-6040-0053 or Kester 24-6337-0010. There is so little flux residue that you don't even have to clean it. Lead-free solder is crap, it will lead to cold/broken joints. Get yourself some good 'ol leaded Kester "44" and you will be quite pleased with it.

[Parak]

Just did my first try at soldering an ATmega controller. It didn't come out excessively bad at all =D Simple $50 40W soldering iron, a lot of flux, and lead free solder. I haven't tested it yet but I don't think I managed to break it... I had to do some cleaning up after the first side of legs. After that I nailed the right amount of solder to cover all pads in one go.

Hey, better than what my first attempt at hand soldering SMDs. You can clean the residue with denatured alcohol and a lot of paper (which will get shredded on the TH parts) if you want.

Prototyping a controller?

[mkawa]

holy **** prin, that's really clean for doing it by hand.

[litster]

Nice PrinsValium.  If you can SMD the controller to the tiny PCB, may as well do it on the keyboard PCB.  That would make the case design a lot simpler because we would not need to make room for the controller that is the size of a Teensy.  Also, we could make many different kind of cases and have the USB connector on the PCB and exposed through the case.

[bpiphany]

Thanks, I think it turned out pretty well =) Drag soldering was pretty simple after all... Yes, I cleaned it up with alcohol afterwards, there was flux left all over the place... There should be some paper fibers showing in that picture. Before soldering switches or other hollow parts the board could probably be really easily cleaned in an ultrasonic alcohol bath. (Trivia: my mom sometimes do ultrasonic baths of glassware in boiling hot concentrated nitric acid at work, that is when they need to be clean)

It would be nice to have everything mounted directly on the PCB. There are two things I haven't figured out yet though. First of all I would like to be able to use the ATmega32u2 instead of the ATmega32u4 (the Teensy controller). The u2 chips are 32 pin instead of 44 pin and take a fair bit less space. The TQFP packages with legs (like the one I soldered) is at least possible to solder by hand, but much larger than the QFN package chips that are on the Teensy boards. QFN chips need to be reflow soldered though, and I don't think I will be doing that at home at least (it's far from impossible though). First thing, I don't know if the usb_keyboard code will compile for the u2 series of chips, or how hard it would be to adjust it. I have very little knowledge onthe hardware part of that code... The other thing is, I still haven't tried programming any ATmega controller other than using the Teensy boot loader.

[The_Ed]

That diabolical 7bit keeps adding switches to the GB. My balance now reads $119.82... 173 switches are quite expensive. Hopefully this PCB will be done soon so I'll have a place to put most of those.

[mkawa]

Hey, better than what my first attempt at hand soldering SMDs. You can clean the residue with denatured alcohol and a lot of paper (which will get shredded on the TH parts) if you want.

Prototyping a controller?

toothbrush and drug store isopropyl works fine and doesn't leave bits of paper everywhere.

prin: what's the status of adapting this design for a 60% board? i was thinking it we don't have enough room on the board for the controller for some reason we could do a board sandwich (which i think you allude to a previous post)

[Parak]

toothbrush and drug store isopropyl works fine and doesn't leave bits of paper everywhere.

I actually never found a toothbrush to work well at all, as it just picks up the rosin and spreads it in a nice thin and sticky layer all over the board. YMMV

[mkawa]

you need to really douse that sucker with solvent

[The_Ed]

All of you talk about cleaning the PCB afterwards, but you wouldn't have to if you used Kester "44" solder. There is only a few yellow pinprick droplets of rosin flux left after you are done. And even though they come off easily, I just leave them. Kester themselves say you don't have to clean "44". Once you try it you can never go back.

[mkawa]

imo no clean solder is totally a crock

[The_Ed]

Kester "44" is RA, NOT no-clean. But since it's non-corrosive and non-conductive you don't have to clean it. Don't knock it 'till you try it.

Kester “44”®
Rosin “44”®
is a high activity RA core flux designed for
excellent instant wetting action, even on Nickel surfaces.
Although “44”®
is a RA-based material, the residues are
non-corrosive if not cleaned.  Per J-STD-004, “44”®
is
classified as ROM1 flux.

Product Description
Kester 44 Rosin Flux is an activated rosin formula
for use in flux-cored solder wire.  Kester 44 Rosin
Flux has virtually dominated the field of   activated
rosin core solders for well over four decades.  An
outstanding performance feature of this flux is the
"instant-action" wetting behavior.  The high mobility
and fast-spreading action of this  flux results in
more reliable production line soldering.
Performance Characteristics:
•   High activity RA formulation
•   Excellent solderability to a wide variety of
metallizations
•   Industry standard RA cored wire for decades
•   Classified as ROM1 per J-STD-004

Cleaning:
Kester 44 possesses excellent fluxing ability, the flux residue is non-corrosive and non-conductive under normal
conditions of use.  When exposed to an elevated temperature and humidity environment (38°C, 94% RH) for
72 hours, there is no evidence of corrosion caused by the flux residue.  Throughout its many years of wide
usage, 44 Rosin Flux has produced many billions of soldered connections.  In all these billions of solder
joints, involving the most delicate and critical of electrical and electronic components, there has never been
an authentic instance of corrosion by the flux residue under normal conditions of use.  This mild property of
the residue permits leaving the flux on the assembly for many applications.