ErgoDox - Custom split ergo keyboard.

[alaricljs]

Media keys require special handling.

[ic07]

Media keys require special handling.

Oh grr. Thanks. I'll have to look into it sometime later then.

[sordna]

I'll be using the dvorak-kinesis layout... I already compiled and loaded the firmware on a Teensy 2.0 I already have! Can't really tell if it works, all I can do is stare at the teensy :-)
On my ubuntu machine I first had to do:
sudo apt-get install gcc-avr binutils-avr avr-libc

I neglected avr-libc at first, and got errors about some header files misssing, which was resolved after I installed it.

All the info is of course here:  http://www.pjrc.com/teensy/gcc.html

I also had to install the /etc/udev/rules.d/49-teensy.rules file, which basically has these 2 lines uncommented:
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789]?", MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789]?", MODE:="0666", ENV{ID_MM_DEVICE_IGNORE}="1"

Anyway, I'm going to go to Radio Shack and get a piezo buzzer, and try to get it to click from the teensy. I *really* want to have my ErgoDox click like my Kinesis does, hopefully I can make it happen and then we can add the code to the ergodox firmware.

[sordna]

ic07 / Dox/ bpiphany:
Would the controller/firmware somehow be able to support a piezo speaker to emit a click sound (like the Kinesis Advantage, and a few other keyboards do) when a key registers ?  If anyone has an idea what mod / extra components might be needed, let me know... I like the audible feedback, but if not possible I might go with cherry MX blues I guess.

We have at least 3 pins not being used on the Teensy in the current design, and 2 of them have PWM.  I'd probably try pin PC7 (on TCCR4 for PWM), though PD5 or PD4 might be more convenient if you don't need PWM.  And changing main() a bit to run the code to generate a click when a key is pressed shouldn't be hard at all.  Others are probably much more knowledgable as to the hardware setup, and how easy/hard it might be to drive a piezo speaker using a Teensy.

PS: Also, be sure to explicitly set the state of whatever pins you do use - IIRC, the init code in the controller .c files touches all the pins, so it'd be better not to count on them starting in any default state.

Ok ic07,
I just got a "Piezo Mini Buzzer", RadioShack 273-0074 which produces a 4KHz sound as long as you apply DC voltage to it. It supports anywhere from 3 to 16 volts. I hooked it up to pin C7 of my teensy, and used PJRC's blinky sample program to drive it... I just changed (PORTD |= (1<<6)) to (PORTC |= (1<<7)) to drive the appropriate pin instead of the built-in LED of the teensy.
I'll have to find a 2.4KHz buzzer so it sounds closer in pitch to the Kinesis, but the RadioShack one proves the concept.

So it works, no need for PWM or tone libraries. Basically all we need the firmware to do is turn on the voltage to the assigned pin on every keypress, and turn it off after 10 miliseconds or so. Only caveat is the controller shouldn't be sleeping during that time; it should accept the next keypress even if it comes before the buzzer pin voltage is turned off. Also, even if you hold a key down, the click should last the same amount of time and not longer.
Finally, if you press a key, keep it down, and then press another key (like when shifting) both key presses should click. Basically the click should emulate clicky switches.

Is it doable ic07 ?  I'm sure we can easily turn on a pin upon any keypress, but how do you turn it off after a fixed amount of miliseconds without sleep() ?

[Zalusithix]

ic07 / Dox/ bpiphany:
Would the controller/firmware somehow be able to support a piezo speaker to emit a click sound (like the Kinesis Advantage, and a few other keyboards do) when a key registers ?  If anyone has an idea what mod / extra components might be needed, let me know... I like the audible feedback, but if not possible I might go with cherry MX blues I guess.

We have at least 3 pins not being used on the Teensy in the current design, and 2 of them have PWM.  I'd probably try pin PC7 (on TCCR4 for PWM), though PD5 or PD4 might be more convenient if you don't need PWM.  And changing main() a bit to run the code to generate a click when a key is pressed shouldn't be hard at all.  Others are probably much more knowledgable as to the hardware setup, and how easy/hard it might be to drive a piezo speaker using a Teensy.

PS: Also, be sure to explicitly set the state of whatever pins you do use - IIRC, the init code in the controller .c files touches all the pins, so it'd be better not to count on them starting in any default state.

Ok ic07,
I just got a "Piezo Mini Buzzer", RadioShack 273-0074 which produces a 4KHz sound as long as you apply DC voltage to it. It supports anywhere from 3 to 16 volts. I hooked it up to pin C7 of my teensy, and used PJRC's blinky sample program to drive it... I just changed (PORTD |= (1<<6)) to (PORTC |= (1<<7)) to drive the appropriate pin instead of the built-in LED of the teensy.
I'll have to find a 2.4KHz buzzer so it sounds closer in pitch to the Kinesis, but the RadioShack one proves the concept.

So it works, no need for PWM or tone libraries. Basically all we need the firmware to do is turn on the voltage to the assigned pin on every keypress, and turn it off after 10 miliseconds or so. Only caveat is the controller shouldn't be sleeping during that time; it should accept the next keypress even if it comes before the buzzer pin voltage is turned off. Also, even if you hold a key down, the click should last the same amount of time and not longer.
Finally, if you press a key, keep it down, and then press another key (like when shifting) both key presses should click. Basically the click should emulate clicky switches.

Is it doable ic07 ?  I'm sure we can easily turn on a pin upon any keypress, but how do you turn it off after a fixed amount of miliseconds without sleep() ?

I haven't gone fully into the code and I'm new to doing any coding for the Teensy, but assuming you start the buzzer within the "is pressed" check section of the main loop (https://github.com/benblazak/ergodox-firmware/blob/master/src/main.c line 90):

Code: [Select]

if (is_pressed != was_pressed) {
    if (is_pressed) {
        ...
    } else {
In addition to starting the buzzer (if it hasn't been already started), set an elapsedMillis special variable type to 0 there.  You can then check the elapsedMillis value somewhere within the main scanning for loop. If the value is over target time, stop the buzzer. Throw a check in place to make sure you're not stopping the buzzer every scan cycle and I think you'd be golden. It would only activate on key down, and should only last as long as the target time plus one scan cycle at the greatest. I think he mentioned something like 160Hz scan cycles before, so assuming 10ms, then it could be 10-16ms long. Not perfect, but probably as good as you're going to get without adversely affecting the actual keyboard functions.

[sordna]

Thanks mate! Having the firmware source code is going to be fun. BTW anyone have experience with this Sparkfun pointing device ?
https://www.sparkfun.com/products/10835

[inaneframe]

And I'm in!   

Almost didn't make it, I was thinking about this keyboard so I dropped in to see it only 4 days from completing the buy in, WOW!

Are there going to be more group buys after the initial one?  If I like the first build, I'll be buying two more.

[ic07]

It looks like elapsedMillis is something only available in Teensyduino?  Even in the Arduino reference I can only find mills() and friends.  I'm not using either set of libraries though, which means, if you wish to time things without busy-waiting, you'll need to do something with the Teensy timers directly.

Alternately: If it were me, I'd try reducing the debounce time to 0 (it's currently 5ms), and then just timing the click by busy-waiting with _delay_ms() (in <util/delay.h>).  The downside of this is that, when a key is pressed, it will take 10ms *after each key* to detect the next one (instead of only delaying 5ms after each cycle where a keypress was detected, plus ~5ms between cycles, mostly due to I2C).  The upside is not having to deal with timers (or pull in Arduino dependencies...), and I think it would be bearable under normal usage.

[sordna]

How about I blindly just turn off the buzzer every 2 cycles of the main loop? That should make any clicks last 6 to 12ms without any busy waits? Anyway, no worries, I'll play with it when I get the keyboard, thank you all!

[OrangeJewce]

A UI to remap the keyboard would be great, especially if it could be run locally (not off the Internet). For instance, on my ubuntu machine, I'd love to be able to remap keys or build layouts on a UI (from a locally running webserver, or it could be a TK, or PyQT, or standalone Java application, or whatever), hit a button, and have the UI call the commands to compile as well as call the teensy command-line utility to load the firmware on the keyboard, all in one shot. That would be almost as good as the instant gratification that on-board remapping provides :-)

Sordna,

     I have been torn on this very issue. Unfortunately, I do not feel comfortable and I don't have any confidence in writing a Java UI, because, well, programming a UI in Java is just bad [no seriously, it is]. So, for me, that removes the possibility of easily coding a cross-platform local UI (I'm not familiar enough with python UI programming although I'm aware it's a possibility. Maybe in a secondary release? I'll consult with ic07). Therefore, after talking with ic07, I believed it would be wiser to have a Web based UI. Now, if you'd like to have a local copy, I'm sure it can be arranged that we release the code to you. That being said, my goal would be that the UI will only generate [read: compile and return a download link for the layout file, meaning it's ready to be flashed] the a layout based off of a file you upload to the server (you would be provided a new download link for any modifications), or the ic07 default.

     I'm open to suggestions, but please note that any changes in course from here on out would mean further delays in bringing forth a decent product.

Cheers,

To me this makes the most logical sense and would be a good first step to serving everyone, especially those who are not Windows users or don't have access to a Windows VM to mess with a layout.

[Zalusithix]

It looks like elapsedMillis is something only available in Teensyduino?  Even in the Arduino reference I can only find mills() and friends.  I'm not using either set of libraries though, which means, if you wish to time things without busy-waiting, you'll need to do something with the Teensy timers directly.

Alternately: If it were me, I'd try reducing the debounce time to 0 (it's currently 5ms), and then just timing the click by busy-waiting with _delay_ms() (in <util/delay.h>).  The downside of this is that, when a key is pressed, it will take 10ms *after each key* to detect the next one (instead of only delaying 5ms after each cycle where a keypress was detected, plus ~5ms between cycles, mostly due to I2C).  The upside is not having to deal with timers (or pull in Arduino dependencies...), and I think it would be bearable under normal usage.

Yeah, now that I look at the page carefully, it is for the Teensyduino. I should have checked the page more thoroughly before assuming the feature was native (especially considering my newness to the whole platform). Oh well, Sorry for getting your hopes up for a (mostly) easy solution sordna! Digging deeper (and likely getting ahead of myself), it seems theoretically possible to use interrupts and timers to do it. Set Timer1 for a given length. Create a TIMER1_COMPA_vect ISR that disables the speaker and the mask for the interrupt. Enable the mask immediately after the speaker has been turned on. Profit? lol...

Also, OrangeJewce, I'm not sure if you've missed it, but you have a PM.

[ic07]

How about I blindly just turn off the buzzer every 2 cycles of the main loop? That should make any clicks last 6 to 12ms without any busy waits? Anyway, no worries, I'll play with it when I get the keyboard, thank you all!

Lol that might work too. Awesome :-). Curious to see what you come up with :-).

[AloisiusFauxly]

I'm a developer, and I say go with a web UI for the interface for platform support.

If the js in the UI could generate the contents of the required layout files on its own, then that would be a good start for people who want to compile at home. I edited the layout files by hand and that was the most time-consuming part.

[OrangeJewce]

It looks like elapsedMillis is something only available in Teensyduino?  Even in the Arduino reference I can only find mills() and friends.  I'm not using either set of libraries though, which means, if you wish to time things without busy-waiting, you'll need to do something with the Teensy timers directly.

Alternately: If it were me, I'd try reducing the debounce time to 0 (it's currently 5ms), and then just timing the click by busy-waiting with _delay_ms() (in <util/delay.h>).  The downside of this is that, when a key is pressed, it will take 10ms *after each key* to detect the next one (instead of only delaying 5ms after each cycle where a keypress was detected, plus ~5ms between cycles, mostly due to I2C).  The upside is not having to deal with timers (or pull in Arduino dependencies...), and I think it would be bearable under normal usage.

Yeah, now that I look at the page carefully, it is for the Teensyduino. I should have checked the page more thoroughly before assuming the feature was native (especially considering my newness to the whole platform). Oh well, Sorry for getting your hopes up for a (mostly) easy solution sordna! Digging deeper (and likely getting ahead of myself), it seems theoretically possible to use interrupts and timers to do it. Set Timer1 for a given length. Create a TIMER1_COMPA_vect ISR that disables the speaker and the mask for the interrupt. Enable the mask immediately after the speaker has been turned on. Profit? lol...

Also, OrangeJewce, I'm not sure if you've missed it, but you have a PM.

Hey,

     Sorry, I have a few to sort through. I'm also working 12 hour days right now, so my ability to make big decisions is impacted by the time I actually get home (And I don't really like answering pms whilst at work.) Not to mention the significant other taking up most of it anyhow. I promise to get to everyone this weekend and thank you for the support. I apologize for the delay in reply to pm.

Cheers,

[Zalusithix]

Hey,

     Sorry, I have a few to sort through. I'm also working 12 hour days right now, so my ability to make big decisions is impacted by the time I actually get home (And I don't really like answering pms whilst at work.) Not to mention the significant other taking up most of it anyhow. I promise to get to everyone this weekend and thank you for the support. I apologize for the delay in reply to pm.

Cheers,

No problem on the delay OrangeJewce, I just wanted to make sure there wasn't some issue preventing the message from properly going through / being noticed.

Now, ic07, going back to the millisecond variable type being a teensyduino thing... wouldn't it be possible to emulate the functionality using timer1 and interrupts? If you set the ISR to increment a volatile shared variable every millisecond, it should basically be the same thing. The main code could then reference that variable to find out elapsed time.  Possibly overkill for just a buzzer, but potentially useful for future macro capability? At least assuming (Seriously, I have to work my way around a profanity filter for that? *sigh*) that the macro capability would have programmable delays between key sends. It's really just a matter of how much the interrupt would interfere with performance. I won't have a Teensy to mess around with until the MD group buy starts shipping, so I can't really test anything yet myself. If it were too impacting, a coarser grained interrupt period could be used (say a centisecond instead).

[ic07]

So, you got me reading now... lol :-) .  I'll have to stop soon though, as I have paperwork chores to do, and the firmware rewrite (at least) to finish before I go playing with timers...  But it looks like you're right :-) except that I'm using Timer 1 for PWM on the LEDs, so Timer 3 is probably what we want.

It would be useful for lots of stuff - hold-to-lock / press-to-shift keys, for instance .  And from a design standpoint, the "right" way to do things is probably to base all time sensitive stuff off interrupts (or at least time delay measurements; a constant busy-wait debounce time is a blatant hack, no matter how easily we can get away with it, since it doesn't account for the scanning and processing time)... I just haven't gotten to it yet.

[Zalusithix]

Yeah, I understand that a lot of this was basically hacked together and not exactly "ideal". I can't blame you in the least though, as my pet projects often end up the same way.  Hack together stuff that works until it meets my needs, then go back and redo everything in a more efficient way while taking into account what I've learned on the way. Perhaps not as efficient as doing it the "right way" the first time around, but certainly more interesting (less sitting and planning).

[ic07]

Lol.  In defense of other portions of my hackiness though: I think it could be argued that 8-bit microprocessors themselves are somewhat of a hack... ^^

[Zalusithix]

Nah, they're just retro.

But yeah, I've been working with higher level libraries and stupidly powerful PCs for so many years now that when going to something like the Teensy, everything seems like a bit of a hack. Still, that's fun in it's own right. Heck, I had plenty of fun in the class I had on RISC (MIPS) based assembly - not that would want to do any major / real world project in it.

[TheProfosist]

ic07 are you going to be able to implement everything thats in my layout?

[Zalusithix]

In order to implement the media keys and mouse movement, he'd have to add another couple of HID endpoints / report descriptors. Basically the project stops being just a keyboard. Instead it becomes a keyboard, a mouse, and a kind of generic "consumer control device" that'd support the audio and transport controls. So technically he'd be "able" to, as in there's nothing technically stopping it.  Depending on the amount of time he has to dedicate to the project, and his understanding of the underlying concepts, it might be awhile before you see that functionality though. At this point I think he's focusing more on the actual keyboard aspect.

[ic07]

Zalusithix is quite right.  I'd like to get those things into the firmware at some point, if I can, but it'll likely be quite a while before I'm able to try again.

[TheProfosist]

Zalusithix is quite right.  I'd like to get those things into the firmware at some point, if I can, but it'll likely be quite a while before I'm able to try again.

ok well can you make the rest work until then?

[AloisiusFauxly]

TheProfosist, you're in luck! The rest already works! All you have to do is edit the qwerty-kinesis-mod.c file with your layout, then compile the firmware. Easy peasy, and ic07 doesn't have to do anything else.

[Zalusithix]

Also, while not a native solution, you might be able to use something like AutoHotkey to emulate the functionality. This is running on the assumption that AHK can detect the key codes the system itself is ignoring and then reissue commands the system actually listens to.

Alternatively, when there's macro support, you can have a single key send a sequence (win-alt-somethingoranother etc) that AutoHotkey can most certainly intercept and use.

Neither solution is as nice as having it all baked in at a firmware level, but it should at least allow you to get some semblance of what you want while the firmware continues to mature.

[dorkvader]

I am about to join the Massdrop GB myself, and I am a bit confused about the mounting of the switches:
As I understand it, the design of the keyboard supports both, PCB- and plate-mounted switches. What are we going to get? From the assembly instructions [1] I get that we have to solder the switches to the PCB - i.e. we will get switches with PCB-mounting pins.

However, dorkvader wrote in his mass email:

The PCB supports PCB mounted switches. The mounting plate supports phantom-style easy switch removal.

What exactly does that mean now? Why would I not be able to get the full-hand and classic case and just swap the PCB in between without de-soldering?

EDIT: Also, what color do those LEDs have at the moment? I couldn't find anything on Massdrop's page pertaining to color.

1: https://www.massdrop.com/dox-ergo.php

As the profosist said, Massdrop will have plate mounted switches. Another member (I believe it was rkinze) said that even with the acrylic plate, the switches should be pretty sturdy, as the stabilizing pins on the PCB-mount switches serve to help orient the switch (so it can't twist). I haven't seen anyone make claims to typing feel though.

So the Massdrop switches will not have mounting pins, but that's okay if you plan to use the plate, which is included in the $200 full kit (and required for the case, as it is an integral part)

To explain my quote:
In mist plate mounted keyboards, there is no "room" to unclip the top of the switch housing in the mounting plate. To replace a switch, you need to desolder it. If you want to change springs or stems you need to desolder. This plate supports the removal of the switch tops without desoldering (Room has been made in the mounting plate for the switches to unclip) so should you want to replace a defective switch, or change springs or whatever, you can do that.

I am by no means certain, but I'm fairly sure that you'd need to desolder to swap the PCB into a different case like that, though it might be possible to detach the switch-bottoms from the mounting plate after soldering, it' certainly won't be easy.

About the LED's I haven't checked, but I think I read somewhere (on DT) that they are red.

Please correct me if I'm mistaken about something here, I get a little fuzzy this late at night sometimes.

[TheProfosist]

Wait the leds are red? I need to confirm this so i can offer whit as an option then.

[Matt3o]

would some ergodox guy help me defining the keys needed for this http://geekhack.org/index.php?topic=39603.0 ?

would you prefer blank mods or with legend? if the latter, is there a "default" configuration?

thanks

[Halverson]

would some ergodox guy help me defining the keys needed for this http://geekhack.org/index.php?topic=39603.0 ?

would you prefer blank mods or with legend? if the latter, is there a "default" configuration?

thanks

Perhaps you can use the massdrop mock up to determine what's needed?

[Matt3o]

sorry I thought they were all blank keys. I'll check it out.

[Halverson]

sorry I thought they were all blank keys. I'll check it out.

Oh my, I thought you meant just for sizing, not legends. Sorry bout that.

[Halverson]

sorry I thought they were all blank keys. I'll check it out.

Oh my, I thought you meant just for sizing, not legends. Sorry bout that.

I think it may be hard to choose a default considering how different every board may be. Perhaps just a set with main layer legend, since second layer would probably be different on every board.

[Glod]

no legends is fine for an ergodox add on

[Matt3o]

do you need some letter in 1.5 unit?

[mikelanding]

Below is layout from dox.



But mine is below (talk from a Kinesis user perspective), As close as to Kinesis layout. I think the middle 6 X 1.5 keys can leave blank. For the modifier keys like -, \, ' will be a bit tricky. Someone might not like Kinesis placement of these keys at all. By the way, I dont mind All the 1.5X to be all blank. I think most ergodox user are touch typist right? Or i am wrong :S

[TheProfosist]

hers min v1.1 iim working on v1.2 as we speak but there will only be small tweaks

[Matt3o]

thank you guys, I'll review your layouts and try to make an ergo dox compatible set

[Glod]

hers min v1.1 iim working on v1.2 as we speak but there will only be small tweaks

Show Image

im kind fo digging this but if i am reading correctly you cant do a CTRL+END / CTRL+HOME etc combination with your layout, am i correct?

[TheProfosist]

hers min v1.1 iim working on v1.2 as we speak but there will only be small tweaks

Show Image

im kind fo digging this but if i am reading correctly you cant do a CTRL+END / CTRL+HOME etc combination with your layout, am i correct?

you can

Ctrl+Home or Ctrl+Fn1+Home

I usually carry mods or other important keys to the next layer

[sordna]

The Control location on the Kinesis layout is very good, trust me. So is the backspace. Do yourself a favor and don't put often use keys in your pinkies.

[seferphier]

hers min v1.1 iim working on v1.2 as we speak but there will only be small tweaks

Show Image

the layout looks very cool.

I wonder how difficult it is to program my own set of keys. I am a non-programmer and may find difficulty implementing my own design.

[mikelanding]

The Control location on the Kinesis layout is very good, trust me. So is the backspace. Do yourself a favor and don't put often use keys in your pinkies.

Yes. Save your pinkies!
Even with Kinesis layout and remap shift to thumb keys. My left pinky still sore.

[TheProfosist]

hers min v1.1 iim working on v1.2 as we speak but there will only be small tweaks

Show Image

the layout looks very cool.

I wonder how difficult it is to program my own set of keys. I am a non-programmer and may find difficulty implementing my own design.

same here

[TheProfosist]

The Control location on the Kinesis layout is very good, trust me. So is the backspace. Do yourself a favor and don't put often use keys in your pinkies.

Yes. Save your pinkies!
Even with Kinesis layout and remap shift to thumb keys. My left pinky still sore.

do some pinky exercises? Idk ive never had a problem with my pinky's though im no speed typer.

[sordna]

the layout looks very cool.

I wonder how difficult it is to program my own set of keys. I am a non-programmer and may find difficulty implementing my own design.

same here

Um, let's try to remove large images from quotes of quotes to avoid all the page scrolling :-)

There has been talk of a web service that will allow you to design and generate your layout... however until that happens, I'm sure many folks here will be willing to compile firmwares for you guys. I plan to compile my own firmware since I'll be using switches with integrated diodes, which need a modification in the code.

To help with custom layouts, at minimum we need a GUI program that allows folks to design the layout and generate the .c file. I think OJ has something for windows. Anyway, if we have any kind of program that generates the layout file, even if there is no web service to generate the firmware, any of us that have a development environment set up would be able to easily compile a firmware for you.

[OrangeJewce]

the layout looks very cool.

I wonder how difficult it is to program my own set of keys. I am a non-programmer and may find difficulty implementing my own design.

same here

Um, let's try to remove large images from quotes of quotes to avoid all the page scrolling :-)

There has been talk of a web service that will allow you to design and generate your layout... however until that happens, I'm sure many folks here will be willing to compile firmwares for you guys. I plan to compile my own firmware since I'll be using switches with integrated diodes, which need a modification in the code.

To help with custom layouts, at minimum we need a GUI program that allows folks to design the layout and generate the .c file. I think OJ has something for windows. Anyway, if we have any kind of program that generates the layout file, even if there is no web service to generate the firmware, any of us that have a development environment set up would be able to easily compile a firmware for you.

I have some pms that I intend to reply to today regarding the web service. I have been extremely constrained for free time as I have had to work at least partial weekends now. In fact I'm working on something for my job right now. It has been mentioned that a cross-platform, python based local UI is another option. I think I've decided for now to stick with the web service, and will be contacting you who pmed me regarding hosting today. I need to see where ic07 is at as well so we can get ducks in a row for this.

ic07's rewrite will make compiling your own source much easier than it used to be, given that a UI may not arrive in time for when you all first receive your kits. You won't need a development environment to generate your own layouts, just cygwin with gcc to compile the edited .c to create the .eep and .hex that will be necessary for flashing via the teensy firmware utility, which is linux and windows compatible.

Cheers,

[litster]

Has anyone checked with Mass Drop what legs are used under the case?  I have not seen any picture of the underside of the case.  As far as I am concerned, you are ordering ergodox with case with no legs. 

Also, when I designed the case, I didn't account for conductivity with acrylic :-).  Now the same design is made with metal.  I can't tell from the outside how thick the mounting plate is or how many layers make up the mounting plate layer.  It if it is too thick, it could touch the PCB. 

Be careful with your ergodox if you order a metal case.  I am not responsible for any damage :-)

[wasabah]

Massdrop said they won't include any kind of legs/feet. So we need to take care of that by ourselves.

[sordna]

Hmm, good point about conductivity of the metal case, I guess some duct tape is needed at the points the case meets the PCB.
I'm going with acrylic case for another reason.... to easily drill holes for arcade buttons (palm keys) :-)

[litster]

Careful when drilling acrylic.  It can easily crack.  And the drill bit can bite into the material and spin the whole piece out of control.