bpiphany wrote:For the 5000001st time, it's programmable... Set it up whatever way you want. The similarities with the standard qwerty layout are pretty dim, asking about "the iso key" makes absolutely no sense =P
My impression right now is that what you'll get through this purchase, when it happens, is a PCB and a case, i.e. explicitly not the switches or keycaps. I believe this is because of the extremely varied range of tastes in switch feel and actuation force, as well as creativity in keycap.gilsoriano wrote: - There's one thing that I love of my laptop keyboard and it is the backlit effect.
bisl wrote:My impression right now is that what you'll get through this purchase, when it happens, is a PCB and a case, i.e. explicitly not the switches or keycaps. I believe this is because of the extremely varied range of tastes in switch feel and actuation force, as well as creativity in keycap.gilsoriano wrote: - There's one thing that I love of my laptop keyboard and it is the backlit effect.
Finally, backlighting as I understand it (again correct me if I'm wrong) is part of the switch, and the transparency part of the keycap--so I think you should be able to just buy LED switches and transparent caps?
Correct me if I'm wrong.
The iso key is a physical key. So im not really following...bpiphany wrote:For the 5000001st time, it's programmable... Set it up whatever way you want. The similarities with the standard qwerty layout are pretty dim, asking about "the iso key" makes absolutely no sense =P
yep depending of windows keys etc...the Topre tenkeyless uk edition has 88 keys because it adds the iso key next to the left shift.bpiphany wrote:Still doesn't make much sense.. A standard ISO board is what 105 keys, 88 keys, something else close to 88 keys? The ergodox is 76 keys, or 80 keys with split thumb keys. ...2nd time, it's programmable do whatever you feel like =D
You're losing more than that key. You're losing several (12). In exchange you get the ergonomic format that Dox designed, and full programmibility. You can have any layout you want, across several layers.maxrunner wrote:Ok lolol, i'm just confused with the possibility of losing that key physically...obviously i understand you can map any key but the point was mapping it without losing another. But yeah i understand i can map it because i have ansi keyboards and i map that key to another two, its just a preference.
Again, the design of this board is FINAL. No changes will be made. No wireless, etc. Sorry but we want the board as much as everyone else! And it's been almost a year already.gilsoriano wrote:Hi all,
new to the forum, hi to everyone and remarks for such a good job. Seriously, I was looking for a new keyboard and this free project is truly awesome! Count me in for purchasing a whole keyboard.
Apart from that, I've taking a look to the Kicad files and I think that they are outdated from the final design you have send to PCB guys. Can you upload a newer version of them?
Then, some extra thoughts:
- There's one thing that I love of my laptop keyboard and it is the backlit effect. Can we add it (dimming upon last keystroke would be great, btw)?
- Wireless: I've seen that you're thinking about a wireless extension of the keyboard. It would be pretty awesome having it!
In any case, I can offer some help with both issues, just PM if you want me to put some effort in it
Cheers and congrats for such an impressive good job!
Hi bisi,bisl wrote:My impression right now is that what you'll get through this purchase, when it happens, is a PCB and a case, i.e. explicitly not the switches or keycaps. I believe this is because of the extremely varied range of tastes in switch feel and actuation force, as well as creativity in keycap.gilsoriano wrote: - There's one thing that I love of my laptop keyboard and it is the backlit effect.
Finally, backlighting as I understand it (again correct me if I'm wrong) is part of the switch, and the transparency part of the keycap--so I think you should be able to just buy LED switches and transparent caps?
Correct me if I'm wrong.
:) . The problem I see with supporting all those key switch LEDs on the board though is not the extra holes, but the extra traces and the lack of pins (and PWM on those pins) to control them. You can take a look at our pinouts (for the Teensy and the I/O expander) if you like. And Dox has been adamant in the past about using at most 1 Teensy and 1 I/O expander. About wireless, I think Dox has specifically said no to that, since he doesn't want batteries. So, especially given how close we seem to shipping, I'd consider either mod unlikely (sorry). If you end up hand wiring a mod after the group buy though, please post pictures :) I'd be excited to see them. And I'm really glad you like the project! I found it in about the same way, and got involved in the firmware coz Dox said that if someone implemented I2C then we wouldn't have to live with an (ugly) 16 pin (or something) connector.. lol :) . Welcome to deskthority :) .gilsoriano wrote:Hi bisi,
hehehe, yes, you're wrong ;-)
I'm just giving some ideas for another design, because right know it is imposible to put the LEDs in the design. Indeed, I think the most complex part of the design is already achieved and the result is IMPRESSIVE. The layout is beautiful and the configuration is awesome.
The idea for the backlit is basically the same as it is done for the keys of a keyboard, add some control lines that multiplex some LEDs in the board. For instance, we can group by rows, so in the MCU we have the chance to produce vertical fading.
Then, the case of the dimming is different. Typically is easily achievable by flickering the control lines of the LEDs. When you're flickering the ligths it has different effects such as a reduction in current consumption, attenuation of the lighting an generating delta-I noise (take care in very sensitive mixed designs).
About the wireless... There is one thing I haven't thought about it. There are two seperate keyboards connected each other by a cable. So that means another trx... In any case, I'm still thinking the same: it is not that complicated and, at least for me, I see a big advantage of having a wireless device. When I'm at work I usually have to deal with a lot of cables, papers and more things on my desktop. I much prefer having everything tidy and the wireless functionality is a winner. Does it make a more expensive device? Yes. Is it that expensive? It is, but not that expensive (equivalent to add 10 to 15 swithces with their keycaps, I guess..)
Anyway, that were my two cents! ;-)
I2C is a bus protocol, so we could have 2 I/O expanders going. It's kind of slow though (beside space considerations), so having 1 for each side would bring down the scan rate to below 100Hz (which would be fine, but too much slower might be undesirable). Really I think we're using the Teensy because 1) they're soooo common, and 2) the tiny little SMT components we'd have to be soldering if we used the chip directly (or the space things would take up if we didn't) would be beyond most people's capabilities (including mine).gilsoriano wrote:hey, ho!
Well, I've taken another look to the design and it seems that whereas the left parts uses a GPIO expander (I do like MCP23018) the right one is not using it. This is due to the fact that the atmega32u (MCU in Teensy) has only 1 I2C port. I think that it could have been good having expanders at both sides and instead of using Teensy(paying twice for USB connector and pins), just layouting an AT32UC3L064, for instance. It would have probably been cheaper, and your code would work with not mayor changes in that other MCU from the mega32 family.
By the way, I read that you had one doubt with the 2K2 resistors of the I2C. The way of correctly setting up the pullup is as follows:
- First, you select the target speed you require in your I2C interface.
- Second, take a look to the I2C specifications from Philips (NXP) for the rise-time. The value of the rise-time will be the target for your RC.
- Third, calculate the capacitance of your interface or just measure with a given resistance. Reduce the pullups (a.k.a. have a stronger pullup) if you're out of spec.
- TIP: if your RC is out of spec or in the limit, you can have undesired effects (as clock stretching because of weak pulling up) that will make your communication even slower. In any case, this won't a problem for keyboard because pressing a key is a really slow event.
So, yeah, I will probably do a hack whenever I receive the keyboard. Just replace the Teensy for a custom-made board with a different ATmega, two extra I2C expanders, a SPI wireless thingy, a flash-camera Li-rechargeable battery and the trickle for it. So that would be all. I think that all your code will be easilly portable, maybe the worst issue is adjusting the remaps in the MCU for being 100% compatible towards the GUI for custom layouts and, obviously, the battery saving schema. Bad memories of duty-cycling atmegas 128!! :o
The LEDs would be trickier but nothing is impossible ;-)
P.S.: help is welcome in the SPI interface :-D
But the issue of the resistor is something commom I've seen in designs. It works, but slower. . I thought of putting some SMD bicolour LEDs for cool fadding, but do not really know because wiring both pins would be an impossible chore. They should be low power (2mA), otherwise I will go for white ones, in which it will be quite straightforward.
maxrunner wrote:Will there be an option for assembling? i don't have soldering experience, although i intend to change this.
dorkvader wrote: Here is a list of people interested in receiving an assembled keyboard.
*LIST*
I am considering a soldering service: if someone else wants to do this, I'll add their info, but if no-one else wants to, I might do it. Anything to help the project!
List of people offering some sort of soldering/assembly service(I am sure there will be others when the time comes)Code: Select all
Dork Vader (USA) Geekabit (EU)
gilsoriano wrote:hey, ho!
Well, I've taken another look to the design and it seems that whereas the left parts uses a GPIO expander (I do like MCP23018) the right one is not using it. This is due to the fact that the atmega32u (MCU in Teensy) has only 1 I2C port. I think that it could have been good having expanders at both sides and instead of using Teensy(paying twice for USB connector and pins), just layouting an AT32UC3L064, for instance. It would have probably been cheaper, and your code would work with not mayor changes in that other MCU from the mega32 family.
By the way, I read that you had one doubt with the 2K2 resistors of the I2C. The way of correctly setting up the pullup is as follows:
- First, you select the target speed you require in your I2C interface.
- Second, take a look to the I2C specifications from Philips (NXP) for the rise-time. The value of the rise-time will be the target for your RC.
- Third, calculate the capacitance of your interface or just measure with a given resistance. Reduce the pullups (a.k.a. have a stronger pullup) if you're out of spec.
- TIP: if your RC is out of spec or in the limit, you can have undesired effects (as clock stretching because of weak pulling up) that will make your communication even slower. In any case, this won't a problem for keyboard because pressing a key is a really slow event.
So, yeah, I will probably do a hack whenever I receive the keyboard. Just replace the Teensy for a custom-made board with a different ATmega, two extra I2C expanders, a SPI wireless thingy, a flash-camera Li-rechargeable battery and the trickle for it. So that would be all. I think that all your code will be easilly portable, maybe the worst issue is adjusting the remaps in the MCU for being 100% compatible towards the GUI for custom layouts and, obviously, the battery saving schema. Bad memories of duty-cycling atmegas 128!! :o
The LEDs would be trickier but nothing is impossible ;-)
P.S.: help is welcome in the SPI interface :-D
I can help with UK soldering if people are patient. Takes me ages to do anything.... Or if your in the Newcastle area pop over.damorgue wrote: List of people offering some sort of soldering/assembly service(I am sure there will be others when the time comes)Code: Select all
Dork Vader (USA) Geekabit (EU)
TA-DA! Application note from AVR. AN311:http://www.atmel.com/Images/doc2565.pdfbpiphany wrote:gilsoriano wrote:hey, ho!
Well, I've taken another look to the design and it seems that whereas the left parts uses a GPIO expander (I do like MCP23018) the right one is not using it. This is due to the fact that the atmega32u (MCU in Teensy) has only 1 I2C port. I think that it could have been good having expanders at both sides and instead of using Teensy(paying twice for USB connector and pins), just layouting an AT32UC3L064, for instance. It would have probably been cheaper, and your code would work with not mayor changes in that other MCU from the mega32 family.
By the way, I read that you had one doubt with the 2K2 resistors of the I2C. The way of correctly setting up the pullup is as follows:
- First, you select the target speed you require in your I2C interface.
- Second, take a look to the I2C specifications from Philips (NXP) for the rise-time. The value of the rise-time will be the target for your RC.
- Third, calculate the capacitance of your interface or just measure with a given resistance. Reduce the pullups (a.k.a. have a stronger pullup) if you're out of spec.
- TIP: if your RC is out of spec or in the limit, you can have undesired effects (as clock stretching because of weak pulling up) that will make your communication even slower. In any case, this won't a problem for keyboard because pressing a key is a really slow event.
So, yeah, I will probably do a hack whenever I receive the keyboard. Just replace the Teensy for a custom-made board with a different ATmega, two extra I2C expanders, a SPI wireless thingy, a flash-camera Li-rechargeable battery and the trickle for it. So that would be all. I think that all your code will be easilly portable, maybe the worst issue is adjusting the remaps in the MCU for being 100% compatible towards the GUI for custom layouts and, obviously, the battery saving schema. Bad memories of duty-cycling atmegas 128!!
The LEDs would be trickier but nothing is impossible
P.S.: help is welcome in the SPI interface
If I know what to look for I can probably measure the rise time of those signals tomorrow when I'm at my oscilloscope's.
Perhaps you also are the one to ask if you know if the controllers (eg atmega32u?) can be used as I2C slaves. They are not that expensive and it would be easier layout wise to use the same chip on both sides. If there will be a next generation ergodox drawn by me it will for sure have the controller mounted directly at the main board, and the top empty part of the PCB rationalized away, there is plenty of space elsewhere to fit a controller (even using a different chip for the expander).
Don't worry about the GUI, I don't think it will be too hard for people editing the source files and compiling themselves.
! No switches are included here I believe, you will need to get them elsewhere. 7bit currently has a group buy running for switches.maxrunner wrote:also i assume we can choose the switch type/combo?
Ez! If you get the keyboard, attach it to your computer, and replace Emacs with Vim, it will work flawlessly!richie wrote:Aggh cant wait for this keyboard!!!
Thinking of how to set it up for Emacs
Brilliant!mSSM wrote:Ez! If you get the keyboard, attach it to your computer, and replace Emacs with Vim, it will work flawlessly!richie wrote:Aggh cant wait for this keyboard!!!
Thinking of how to set it up for Emacs