Author Topic: The Living PCB Design Thread  (Read 92170 times)

0 Members and 3 Guests are viewing this topic.

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #400 on: Mon, 12 December 2016, 09:01:35 »
The other pin one the LED goes to ground or VCC, depending on the orientation of the LED. Ie. if the anode is connected to the MCU, the cathode is connected to ground, and if the cathode is connected to MCU, you should connect the anode to VCC.
I was missing this very difference. Thank you very much.

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #401 on: Wed, 14 December 2016, 16:33:18 »
Can I put indicators' LEDs in the switch matrix like this?

Also, this is going to be connected to a teensy 2.0; does it look ok to you?

(click to enlarge)

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #402 on: Thu, 15 December 2016, 00:36:40 »
LEDs and resistors go in series. One end of the resistor connects to one end of the LED. Nothing in between and nothing more connected there.

Other than that it may actually work. You'll have a more interesting firmware to write, and you really should test that out in a breadboard or something. The LEDs won't be on while you're scanning the matrix. That is a very small percentage of the time, so that won't matter much.

Do you intend to use Those BKSP and JIS keys toghether? They are in the same row/col and would be mutually exclusive. If they are two different mounting options for the same key you don't need the extra diode, just put the switches in parallel. (Unless, of course, you are using switches with built in diodes.)


Edit: Actually since you're only using one row for the LEDs anyway. If this works, and I believe it should (test it), you could reuse the Col,4,5,6-pins for the LEDs, and simply connect the cathodes directly to GND. If you were utilizing more parts of the matrix for LEDs you'd need to multiplex them by use of the Row-pins.

The way it would work is you have three states for the Col-pins. When the LED is turned off the pin is tri-stated (removed from the circuit). To turn the LED on you drive the pin high. And when you scan that particular Col-pin you drive it low (which also turns the LED off).

In a matrix like this with more LEDs, using Row-pins for the cathodes, you'd switch the Row-pin from pull-up input to output low to activate the LEDs in that row.
« Last Edit: Thu, 15 December 2016, 01:04:21 by bpiphany »

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #403 on: Thu, 15 December 2016, 03:40:09 »
Do you intend to use Those BKSP and JIS keys toghether? They are in the same row/col and would be mutually exclusive. If they are two different mounting options for the same key you don't need the extra diode, just put the switches in parallel. (Unless, of course, you are using switches with built in diodes.)
Yes, I'm splitting the 2u Backspace into two 1u keys (JIS is one), so I'd better be moving BSKP to Row 0:Col 13 then.

The LEDs won't be on while you're scanning the matrix. That is a very small percentage of the time, so that won't matter much.
So they basically turn off everytime I press a key? That's gonna be weird.

LEDs and resistors go in series. One end of the resistor connects to one end of the LED. Nothing in between and nothing more connected there.

Other than that it may actually work. You'll have a more interesting firmware to write, and you really should test that out in a breadboard or something.

Edit: Actually since you're only using one row for the LEDs anyway. If this works, and I believe it should (test it), you could reuse the Col,4,5,6-pins for the LEDs, and simply connect the cathodes directly to GND. If you were utilizing more parts of the matrix for LEDs you'd need to multiplex them by use of the Row-pins.

The way it would work is you have three states for the Col-pins. When the LED is turned off the pin is tri-stated (removed from the circuit). To turn the LED on you drive the pin high. And when you scan that particular Col-pin you drive it low (which also turns the LED off).

In a matrix like this with more LEDs, using Row-pins for the cathodes, you'd switch the Row-pin from pull-up input to output low to activate the LEDs in that row.
What if I move the LEDs to totally new row? If they are going to, say, Row 6:Col 0, 1 and 2, will I still be experiencing what stated before?
I can wire each LED to a dedicated Teensy pad, I have room, but I'd like to understand how to put indicators in a matrix anyway (if it's even possible).
A breadboard is on its way to me. I'll run some tests as soon as I get my hands on it.

Once again, thank you very much.

Offline vvp

  • Posts: 642
Re: The Living PCB Design Thread
« Reply #404 on: Thu, 15 December 2016, 04:15:46 »
The LEDs won't be on while you're scanning the matrix. That is a very small percentage of the time, so that won't matter much.
So they basically turn off everytime I press a key? That's gonna be weird.
That is not weird. This allows you to share row xor column wires for both key matrix scanning and LED brightness control. The LEDs will be blinking but you are scanning keyboard with frequency of at least 200 Hz (which is on the low side for a matrix scanning). You will not see the blinking no matter how good your eyes are.
Actually, my current keyboard has a light sensor which adjusts LED brightness based on the illuminance. The brightness is controlled using PWM. So my status LEDs are already blinking at about 250 Hz.

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #405 on: Thu, 15 December 2016, 04:20:43 »
The LEDs won't be on while you're scanning the matrix. That is a very small percentage of the time, so that won't matter much.
So they basically turn off everytime I press a key? That's gonna be weird.
That is not weird. This allows you to share row xor column wires for both key matrix scanning and LED brightness control. The LEDs will be blinking but you are scanning keyboard with frequency of at least 200 Hz (which is on the low side for a matrix scanning). You will not see the blinking no matter how good your eyes are.
That makes it much better. Thank you fine sir.

my current keyboard has a light sensor which adjusts LED brightness based on the illuminance.
Witchcraft.

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #406 on: Thu, 15 December 2016, 06:37:10 »
Yeah, move BKSP to Row0.

You have plenty of pins on the Teensy. Personally I would use separate pins for each LED. It just make things easier. If you had a whole matrix of keys it would be a different matter. I don't know where you intend to place the LEDs physically in relation to the Teensy, but wiring them up to the bottom row may just be cumbersome anyhow.

We had some thought experiment way back on how to double purpose the matrix for full individual back lighting. Although probably possible, I don't think that led anywhere...

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #407 on: Thu, 15 December 2016, 07:22:54 »
Yeah, move BKSP to Row0.

I would use separate pins for each LED.
Done.

Is this mess gonna work?

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #408 on: Thu, 15 December 2016, 07:51:13 »
Sure should, but I would move the LEDs to PB5,6,7. Then you will have them on OC1A,B,C which are the compare output pins for timer 1 interrupts. That way you can "effortlessly" PWM them, when you get to that skill level ;)

Offline vvp

  • Posts: 642
Re: The Living PCB Design Thread
« Reply #409 on: Thu, 15 December 2016, 08:03:37 »
We had some thought experiment way back on how to double purpose the matrix for full individual back lighting. Although probably possible, I don't think that led anywhere...
Something like this should work. May be the row selection block needs to be a bit more complicated if common 5V tolerant pins are not also tolerant in output mode. My guess is that they are but I'm not sure.

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #410 on: Thu, 15 December 2016, 08:45:02 »
Sure should, but I would move the LEDs to PB5,6,7. Then you will have them on OC1A,B,C which are the compare output pins for timer 1 interrupts. That way you can "effortlessly" PWM them, when you get to that skill level ;)
Whoa, amazing. I love that you're saying when rather than if ever.
Thanks a bunch.

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #411 on: Thu, 15 December 2016, 08:55:30 »
I would aim to use the same matrix for connecting both switches LEDs if possible. I don't remember which transistors are capable of what and which way around they work... But something like this would perhaps work.

I don't know if the row pins will be pulled low enough with two diode drops. But configured with pull-up resistors they should shut off the transistor and scan the matrix. If they are switched to low outputs they can sink the row of LEDs through the transistor. The diode protects the input pin from the LED current.

The column pins work like before with tri-stating.

I really don't know. I just had the idea =)

155474-0

Offline deadall127

  • Posts: 16
  • Location: France
Re: The Living PCB Design Thread
« Reply #412 on: Fri, 16 December 2016, 00:04:13 »
Where is a good source to get a PCB made in Europe? Like ExpressPCB or EasyEDA.

pcbshopper.com is a price comparator, easyEDA is often the best

Offline deadall127

  • Posts: 16
  • Location: France
Re: The Living PCB Design Thread
« Reply #413 on: Fri, 16 December 2016, 00:16:04 »
I would aim to use the same matrix for connecting both switches LEDs if possible. I don't remember which transistors are capable of what and which way around they work... But something like this would perhaps work.

I don't know if the row pins will be pulled low enough with two diode drops. But configured with pull-up resistors they should shut off the transistor and scan the matrix. If they are switched to low outputs they can sink the row of LEDs through the transistor. The diode protects the input pin from the LED current.

The column pins work like before with tri-stating.

I really don't know. I just had the idea =)

(Attachment Link)

one resistor per switch? heavy...

I'll post my RGB scheme later

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #414 on: Fri, 16 December 2016, 02:49:37 »
one resistor per switch? heavy...

Well, that was quick and dirty =D So just move them to one per column. The switch circuit shouldn't care too much about that.

Offline vvp

  • Posts: 642
Re: The Living PCB Design Thread
« Reply #415 on: Fri, 16 December 2016, 05:12:30 »
It could work if you select low forward voltage diodes for rows (D5,...) and matrix scanning (D3,...) and high forward voltage LEDs. If there is a key pressed then there will be color bleed from a LED which should should be lit to some other LEDs. May be it will not be noticeable. It will be sensitive to part selection.

You should satisfy these inequalities with as good margin as  possible so that it works even with key switches which are not perfect and diodes which forward voltage varies a bit from part to part.
Ufd + Ufk < 0.3*Vcc
Ufd + Ufl  + 2*Ufk > 0.7*Vcc
Ufl + Ut < Vcc
2*Ufl + Ufk + Ut > Vcc

Ufd - forward voltage drop on row diode
Ufk - forward voltage drop on key diode
Ufl - forward voltage drop on LED
Ut - voltage drop on open transistor

Lets consider this as a test:
Ufd = 0.3 V
Ufk = 0.3 V
Ufl = 2.1 V
Ut = 0.2 V
Vcc = 3.3 V

We get:
0.6 < 0.99
3.0 > 2.3
2.3 < 3.3
4.7 > 3.3

Looks like margins are usable. But this would require expensive schottky diodes. Also one must be careful about this inequality: Ufd + Ufl  + 2*Ufk > 0.7*Vcc
Diodes allow forward current even below forward voltage so the pull down resistor on the columns must be small emough to raise the diodes forward voltage to high enough values. E.g. an orange diode can have forward voltage of 2.1V but at 20 mA. Our example inequality for this was 3.0>2.3. If we use lower current of 1 mA  for the orange diode then its forward voltage drops to 1.8 V and our safety margin of 0.7 drops to 0.4 V. Not that bad but internal MCU pull down will not give you 1 mA but only few  A when the dioeds are considered. The LED specification does not even tell what forward voltage will be at this low current. So we need to use external pull downs of about 3.3 kΩ to be really safe. That makes things more complicated.

Well, to tell the truth I would rather simulate this in spice before even trying to built it on a bread board. It looks like it may work but margins are low for my liking. Also the schematic may get more complicated since MCU pull downs may not be good enough. I think I'll rather stay with a separate wires for lines xor cols in the matrix to be on the safe side. That is rather simple solution considering all things overall.

Putting the resistor on the lines is better.

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #416 on: Fri, 16 December 2016, 05:45:37 »
Ok, so. My reasoning went like this:

Forward voltage of diode ≃ 0.6V, times 2 that is 1.2, which is smaller than 0.35V=1.5V, so that's a bit on the margin.

The part that always confuses me is transistors. I would like them to work like this:

1. All row pins are normally inputs with pull-up resistors activated. The ATmegas source current in this mode, and I hope that will close the transistors for all rows.
2. All column pins are normally tri-stated. No current passes either in or out.
3. To scan a column, that one column is pulled low, rows are read and the column tri-stated again.
4. To light up selected LEDs of a row, the corresponding columns are driven high, and the row pin is driven low to open the transistor of that row alone.

I now see how in 4. when the upper LED row is activated, current can pass through L1, S2, D2, L4 even when neither L1 nor L4 should be lit. So, yeah, my idea falls on that =P

Trixy, that ghosting is =)
« Last Edit: Fri, 16 December 2016, 05:48:00 by bpiphany »

Offline vvp

  • Posts: 642
Re: The Living PCB Design Thread
« Reply #417 on: Fri, 16 December 2016, 06:38:44 »
Don't take me wrong. I think it actually may work well. The only problems are that it is sensitive to part selection and it may (or maybe it will not) require external pull ups/downs because the ones in MCU may be too weak. If you are feeling advantageous make a spice simulation. It is not hard. You can use qucs or even kicad allows to export a spice code. The tools are free but the time spent with it will be considerable (if you do not already do this often).

I though you read columns and power rows when scanning the key matrix. But I guess that making it the opposite way will not change the nature of inequalities.

I kind of like the idea of using a simple LED driver(*) and not needing to care about LED forward voltage and resistors. Want a different LED? Maybe a LEDs with different color? Just swap it with any LED which has forward voltage less than 5V. No need to be careful about it. The problem is that I do not have an idea how to share both rows and cols with a LED driver.

(*) especially when the simple LED drivers can cost less than 1

Offline deadall127

  • Posts: 16
  • Location: France
Re: The Living PCB Design Thread
« Reply #418 on: Sun, 18 December 2016, 06:41:41 »
so, here's a 2*2 simplification of my keyboard matrix:



left => led state input
down => column selection
right => output with pull-up res

/!\ works only with 5V controllers (PIC, ATmega etc...) /!\

Offline nonah

  • Posts: 16
  • Location: Sweden
Re: The Living PCB Design Thread
« Reply #419 on: Sun, 18 December 2016, 18:25:32 »
Does anyone know why they have wired PB4 to Vcc on the ergodox? Referencing this diagram:  https://github.com/benblazak/ergodox-firmware/blob/master/src/keyboard/ergodox/circuit-diagram.svg,
 and this schematic: https://github.com/ErgoDox-EZ/docs/blob/master/ErgoDox%20EZ%20Schematic.pdf.

In https://github.com/jackhumbert/qmk_firmware/blob/master/keyboards/ergodox/ez/ez.c, they cite the reason being "hardware convenience", whatever that means.

And this documentation: https://github.com/benblazak/ergodox-firmware/blob/master/src/keyboard/ergodox/controller/teensy-2-0.md, doesn't shed any light on the matter.

I'm quite confused, it seems rather strange. No chance any of you guys know?  ;)

Offline hasu

  • Posts: 2360
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: The Living PCB Design Thread
« Reply #420 on: Sun, 18 December 2016, 20:24:30 »
See KiCad PCB file here, https://github.com/Ergodox-io/ErgoDox
Ergodox shares one PCB desgin for both left and right and one pcb has Teensy and another has MCP23018 IO expander. And footprint of the two chips are overlaped each other to share traces of matrix.


where 11 of MCP23018 is Vdd and  28 of Teensy2.0 is PB4.

This weirdness is needed to feed power to Vdd pin of MCP23018, PB4 is sacrificed just because it shares same position as  the Vdd pin.
⚠ My Engrish is broken.  TMK firmwareHHKB Alt  ⌨ConvertersAlps64FC660C Alt

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #421 on: Mon, 19 December 2016, 03:37:09 »
The deeper reason why there is a track going from pin 11 on the expander to pin 20 of the Teensy is to be able to put a bypass capacitor there. Pin 18 of the Teensy really shouldn't be connected to GND either. That is also why I put those solder jumpers there. To make it possible to connect/disconnect them from the Teensy.

Offline nonah

  • Posts: 16
  • Location: Sweden
Re: The Living PCB Design Thread
« Reply #422 on: Mon, 19 December 2016, 05:17:13 »
Ah, thanks a lot guys, that's a pretty brilliant design.

Edit: why is PB4 set to input with its internal pull up resistor disabled in the firmware?
« Last Edit: Mon, 19 December 2016, 07:32:51 by nonah »

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #423 on: Mon, 19 December 2016, 09:10:09 »
Edit: why is PB4 set to input with its internal pull up resistor disabled in the firmware?

That is how you tri-state a pin. It could have had the pull-up activated, but that would draw some (very small) current for no good reason. The VCC solder jumper is connected per default, and it would be pretty bad to set PB4 as a low output. So staying as far away from that as possible =)

Offline nonah

  • Posts: 16
  • Location: Sweden
Re: The Living PCB Design Thread
« Reply #424 on: Mon, 19 December 2016, 11:20:51 »
Edit: why is PB4 set to input with its internal pull up resistor disabled in the firmware?

That is how you tri-state a pin. It could have had the pull-up activated, but that would draw some (very small) current for no good reason. The VCC solder jumper is connected per default, and it would be pretty bad to set PB4 as a low output. So staying as far away from that as possible =)

Thanks, makes sense :thumb:

Offline kolec94

  • Posts: 98
Re: The Living PCB Design Thread
« Reply #425 on: Mon, 19 December 2016, 15:36:57 »
Anyone have experience with a mbi5042gp led controller?

kbparadise v60 blues

Offline hasu

  • Posts: 2360
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: The Living PCB Design Thread
« Reply #426 on: Mon, 19 December 2016, 17:04:20 »
Thanks for the explanation, bpiphany.
I didn't find the bypass capacitor thing at point of wrting my post. So users have to close on GND solder jumper(default open) to add the capacitor to IO expander. And cutting the VCC solder jumper(closed by default) is optional but safer for Teensy side. Makes sense. I hope users could get good assembly guide :D

⚠ My Engrish is broken.  TMK firmwareHHKB Alt  ⌨ConvertersAlps64FC660C Alt

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #427 on: Wed, 21 December 2016, 08:47:02 »
Wouldn't that be about time ;) But, really, is anyone still using this archaic design?..

It was a bit unclear at the time if a by-pass should be needed. I suppose the more educated answer is that they should always be used. I don't really remember the justifications for keeping one solder jumper open and the other closed. Stuff probably work with the GND open, and certainly not without the VCC closed, I suppose..

Online climbalima

  • Posts: 116
  • Location: Boston MA
  • likes building stuff
Re: The Living PCB Design Thread
« Reply #428 on: Tue, 27 December 2016, 21:45:01 »
Im having trouble with a custom pcb I did. The reset button is not functioning. I was able to get the first flash done, but needed to make changes to the firmware. When I push the reset button the device disconnects, but reconnects as the keyboard without going into bootloader mode. This is not my first board with a 32u4, but the first that I have had this issue with. Here is a picture of the schematic


Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #429 on: Wed, 28 December 2016, 07:55:33 »
More questions for you gentlemen.

First, would you please check if my schematic would work?


Particularly: I've read I need a pull-up resistor on the reset switch and, by looking at the Teensy's schematic, it's placed between ground and PE2 which works as Hardware Bootloader Activator. Will this work or I have to move the resistor to the reset switch directly? The datasheet reads that PE2 (HWB) has an internal pull-up resistor, isn't that enough for the purpose?

Secondly: The AREF pin is, as for the datasheet, the analog reference pin (input) for the A/D Converter. Since I'm very unlikely to do any analog-digital conversion, is it safe to leave it unconnected?

Lastly: the Satan GH60, which is unless I'm wrong a rebrand of the GH60 rev. A, mounts a ME9926 triode transistor that, to my understanding, is used for backlighting. Since I'm not using such feature, am I safe to assume that I can leave it out of the PCB?

Thanks.

Offline monkeyplusplus

  • Posts: 16
Re: The Living PCB Design Thread
« Reply #430 on: Wed, 28 December 2016, 12:35:33 »
To answer just your last question, the first design I did don't have any LEDs, so I left out the transistor (and everything else of course) to control them. It worked fine :)

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #431 on: Wed, 28 December 2016, 12:40:33 »
To answer just your last question, the first design I did don't have any LEDs, so I left out the transistor (and everything else of course) to control them. It worked fine :)
The confirmation I needed. Thank you.

Online climbalima

  • Posts: 116
  • Location: Boston MA
  • likes building stuff
Re: The Living PCB Design Thread
« Reply #432 on: Wed, 28 December 2016, 13:53:56 »
More questions for you gentlemen.

First, would you please check if my schematic would work?
Show Image


Particularly: I've read I need a pull-up resistor on the reset switch and, by looking at the Teensy's schematic, it's placed between ground and PE2 which works as Hardware Bootloader Activator. Will this work or I have to move the resistor to the reset switch directly? The datasheet reads that PE2 (HWB) has an internal pull-up resistor, isn't that enough for the purpose?

Secondly: The AREF pin is, as for the datasheet, the analog reference pin (input) for the A/D Converter. Since I'm very unlikely to do any analog-digital conversion, is it safe to leave it unconnected?

Lastly: the Satan GH60, which is unless I'm wrong a rebrand of the GH60 rev. A, mounts a ME9926 triode transistor that, to my understanding, is used for backlighting. Since I'm not using such feature, am I safe to assume that I can leave it out of the PCB?

Thanks.

Just a note on your decoupling. The VCC pins can all be connected to VCC, but then the caps go to ground. You have all the VCC pins going through a capacitor before going to the voltage rail. Strange stuff may happen with this.

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #433 on: Wed, 28 December 2016, 14:16:32 »
Just a note on your decoupling. The VCC pins can all be connected to VCC, but then the caps go to ground. You have all the VCC pins going through a capacitor before going to the voltage rail. Strange stuff may happen with this.
Thanks sir, does it look any better now?


Online climbalima

  • Posts: 116
  • Location: Boston MA
  • likes building stuff
Re: The Living PCB Design Thread
« Reply #434 on: Wed, 28 December 2016, 15:10:52 »
Thanks sir, does it look any better now?

Show Image


Yup, but I have the UCAP go to ground and UVCC and VBUS go to the voltage rail.

Offline Eszett

  • Posts: 453
  • Supporting the communities Geekhack & Deskthority
Re: The Living PCB Design Thread
« Reply #435 on: Wed, 28 December 2016, 15:22:39 »
Hi guys! I have a question. Here is my ISO-enter footprint. According to all the other sources I inspected so far, the keyswitch footprint is rotated 90 degrees. Why?
156315-0

Would there be any downside (which downside?) if I have it unrotated, as all the other keyswitch footprints, like this? ...
156317-1
« Last Edit: Wed, 28 December 2016, 15:25:05 by Eszett »

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #436 on: Wed, 28 December 2016, 15:26:50 »
the keyswitch footprint is rotated 90 degrees. Why?
To allow the usage of Costar stabilizer. I assume it applies to any vertical key, namely numpad plus and enter.

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #437 on: Wed, 28 December 2016, 15:28:49 »
I have the UCAP go to ground and UVCC and VBUS go to the voltage rail.
Like this?

Offline Eszett

  • Posts: 453
  • Supporting the communities Geekhack & Deskthority
Re: The Living PCB Design Thread
« Reply #438 on: Wed, 28 December 2016, 15:38:09 »
@TalkingTree. Ah... do I understand it right: otherwise, the Costar wire would collide with the keyswitch house? In this area here I marked red...

Offline TalkingTree

  • Posts: 1226
  • Location: Italy
Re: The Living PCB Design Thread
« Reply #439 on: Wed, 28 December 2016, 15:49:19 »
do I understand it right: otherwise, the Costar wire would collide with the keyswitch house? In this area here I marked red... (Attachment Link)
I don't have any evidence but I'm pretty much sure that you described the issue perfectly. Also, I believe one can't use in-switch LEDs with Costar stabilizers or, perhaps, 2x3x4mm ones.

Offline Eszett

  • Posts: 453
  • Supporting the communities Geekhack & Deskthority
Re: The Living PCB Design Thread
« Reply #440 on: Wed, 28 December 2016, 15:50:31 »
Thanks TalkingTree. I'll better leave it rotated then.

Online climbalima

  • Posts: 116
  • Location: Boston MA
  • likes building stuff
Re: The Living PCB Design Thread
« Reply #441 on: Wed, 28 December 2016, 16:38:23 »
I have the UCAP go to ground and UVCC and VBUS go to the voltage rail.
Like this?
Show Image


Yup, but include the decoupling caps for them too.

Offline Eszett

  • Posts: 453
  • Supporting the communities Geekhack & Deskthority
Re: The Living PCB Design Thread
« Reply #442 on: Wed, 28 December 2016, 17:03:29 »
The VBUS pin at the Atmega32u4 is just a monitor pin, not sure if it really needs a decoupling cap? Instead, it might be reasonable to add one bulk capacitor with a larger value, e.g. 2.2F, no? I have it like this: 0.1F decoupling capacitor at Pin_2, Pin_14, Pin_24, Pin_34, and Pin_44. Plus, one 2.2F decoupling capacitor for those pins in common. And, the 1F cap on UCAP is mandatory. On the other hand, the Atmega is pretty robust, I've heard it tends to work even when you're merely using 4 decoupling caps. Depends all on your environment tho..
« Last Edit: Thu, 29 December 2016, 10:01:35 by Eszett »

Offline kolec94

  • Posts: 98
Re: The Living PCB Design Thread
« Reply #443 on: Thu, 29 December 2016, 11:11:53 »
anyone know how to do sdo and sdi with a atmega32u4?

kbparadise v60 blues

Offline vvp

  • Posts: 642
Re: The Living PCB Design Thread
« Reply #444 on: Thu, 29 December 2016, 13:34:51 »
Just connect the pins like this:

Just a direct connection between pins. No pull-ups/downs / capacitors etc are needed. Your MCU is going to be a master. A slave can be e.g. an EEPROM.
Here is an example code which handles SPI EEPROM. Just follow the compilation branches for ARCH_AVR8. EDIT: That is a simple approach using polling. ATmega does not support DMA but it supports IRQ on transfer completion so you can get a bit fancier if you need to save clock cycles for parallel tasks.
« Last Edit: Thu, 29 December 2016, 13:43:37 by vvp »

Offline swill

  • * Elevated Elder
  • Posts: 3296
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The Living PCB Design Thread
« Reply #445 on: Mon, 02 January 2017, 17:44:37 »
Hey all.  I am new to this thread. I have not touched anything on the electrical side of building keyboards, and have only built boards based on PCBs designed by others.

I am the developer behind http://builder.swillkb.com.  Ironically, I started it because I was not confident in my cad skills and thought I should automate the plate layout.  Now it does quite a bit more than I was expecting when I started, but I have always had the pipe dream of being able to produce a PCB that goes with the layout specified.

The biggest hurdle I think I am going to have with this is the auto routing for the pcb.  I am only just starting to look into what I would need to do to even get something primitive built.

So my question is. What algorithms should I be researching, and what auto routing systems are best suited to designing keyboards. I know the following exist, but not much beyond that.

Maze router,
Line probe router,
Channel router,
Area routers,
Switchbox routing

Given my current skill level, I will probably have to spend a couple months just learning stuff. I would not expect to actually have anything written for about 6 months and really, who knows at that point.

If anyone has resources you can share that you think would be required reading for me, please share a link. If you have ideas or suggestions, please let me know as well.

Thanks for the help everyone. Happy new year. If you have not checked out the builder recently, you guys may be interested in the new custom polygon features I finally finished adding to the builder over the holidays.


Offline kolec94

  • Posts: 98
Re: The Living PCB Design Thread
« Reply #446 on: Mon, 02 January 2017, 19:16:02 »
Hey all.  I am new to this thread. I have not touched anything on the electrical side of building keyboards, and have only built boards based on PCBs designed by others.

I am the developer behind http://builder.swillkb.com.  Ironically, I started it because I was not confident in my cad skills and thought I should automate the plate layout.  Now it does quite a bit more than I was expecting when I started, but I have always had the pipe dream of being able to produce a PCB that goes with the layout specified.

The biggest hurdle I think I am going to have with this is the auto routing for the pcb.  I am only just starting to look into what I would need to do to even get something primitive built.

So my question is. What algorithms should I be researching, and what auto routing systems are best suited to designing keyboards. I know the following exist, but not much beyond that.

Maze router,
Line probe router,
Channel router,
Area routers,
Switchbox routing

Given my current skill level, I will probably have to spend a couple months just learning stuff. I would not expect to actually have anything written for about 6 months and really, who knows at that point.

If anyone has resources you can share that you think would be required reading for me, please share a link. If you have ideas or suggestions, please let me know as well.

Thanks for the help everyone. Happy new year. If you have not checked out the builder recently, you guys may be interested in the new custom polygon features I finally finished adding to the builder over the holidays.
ok so what are you going to use as a controller diodes and other components?
do you have pcb models for different switch types?
led holes?

kbparadise v60 blues

Offline swill

  • * Elevated Elder
  • Posts: 3296
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The Living PCB Design Thread
« Reply #447 on: Mon, 02 January 2017, 21:36:18 »
Hey all.  I am new to this thread. I have not touched anything on the electrical side of building keyboards, and have only built boards based on PCBs designed by others.

I am the developer behind http://builder.swillkb.com.  Ironically, I started it because I was not confident in my cad skills and thought I should automate the plate layout.  Now it does quite a bit more than I was expecting when I started, but I have always had the pipe dream of being able to produce a PCB that goes with the layout specified.

The biggest hurdle I think I am going to have with this is the auto routing for the pcb.  I am only just starting to look into what I would need to do to even get something primitive built.

So my question is. What algorithms should I be researching, and what auto routing systems are best suited to designing keyboards. I know the following exist, but not much beyond that.

Maze router,
Line probe router,
Channel router,
Area routers,
Switchbox routing

Given my current skill level, I will probably have to spend a couple months just learning stuff. I would not expect to actually have anything written for about 6 months and really, who knows at that point.

If anyone has resources you can share that you think would be required reading for me, please share a link. If you have ideas or suggestions, please let me know as well.

Thanks for the help everyone. Happy new year. If you have not checked out the builder recently, you guys may be interested in the new custom polygon features I finally finished adding to the builder over the holidays.
ok so what are you going to use as a controller diodes and other components?
do you have pcb models for different switch types?
led holes?

So right now I don't have anything, but I do have an idea of the things I will need.  I don't have modules built yet for switch and led layouts.  I will likely do SMD diodes and resistors (for LEDs, when I support them).  Ideally, I would build a standard footprint I use for every switch and use it everywhere.  That will make things easier from the dev side.  I have not talked to MOZ or Melvang about this yet, but I basically want to use something like a simplified Enabler PCB as the base switch component.  I know through hole is less daunting for builders, but I think most people are capable of soldering SMD (I was without much practice).  I think it is probably important to support SMD because it makes it easier to automate pick and place of components.  If people end up running small group buys based on the output, I think it gets us one step closer to a fully automated process.

The controller is a bit of a different story.  I would ideally like to give people options, but I have to start somewhere.  The ones that are on my radar would be something like; the SMD footprint for an ATMEGA32U4 (or similar), through hole pin set for the teensy (or similar).

My goal is to help enable builders and people with ideas to make it happen, so I am trying to solve the lowest common denominator with the most value to start with.  Then we go from there... 

To me, the auto routing is the biggest blind spot for me.  I know it is possible, but I also know it is non-trivial, so I have to get comfortable with how I am going to solve that before I get to deep into the weeds on some of the other pieces.  With the builder right now, I have the capability to draw vector files (svg+) and I already have the location of all the switches.  It would not be hard for me to start with a drill hole output, or even draw essentially the enabler at every switch location and just not route it.  Obviously not an end game solution, but it is a start.  It gets me to the point of being able to produce something of value.  With that as a starting point, I may be able to output as KiCad and people could manually route the pcb. 

Anyway, this is longer than I was planning to write.  There is a lot of ground I have to cover before I get to an end game solution, but I think there is probably a lot of value in some of the baby steps.  :)

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #448 on: Tue, 03 January 2017, 00:30:57 »
One board to rule them all, routed and ready for any occasion ;)
https://geekhack.org/index.php?topic=38414.msg757373#msg757373
« Last Edit: Tue, 03 January 2017, 00:34:20 by bpiphany »

Offline bpiphany

  • Posts: 994
  • Location: Stockholm, Sweden
  • bpiph is a special type of crazy. //mkawa
Re: The Living PCB Design Thread
« Reply #449 on: Tue, 03 January 2017, 00:31:14 »
double post