We're missing a GH80. A TKL PCB with full LED, SMD, usb port etc. Phantom is great but not perfect.I agree regarding the Phantom, what we need on it based on priority for me:
I'm going to try and learn how to design a PCB to try and make the above happen (but it ain't easy).
Can't say I'd use a GH100+ but I'm sure loads of people would.
Oh yeah PCB stabs and PCB-mount switch pin holes for sure. PCB stabs are the best :thumb:There is some extension available on the current GH60, but not as much as we want for this case I think. However we can extend the current GH60, to make it as modular, since it is open source, as long as we give due credit to the original GH60 team, we should be fine.
And hold on.. I don't fully understand the modular concept. Are you telling me komar designed the GH60 so that you can simply add all this stuff on?
There is some extension available on the current GH60, but not as much as we want for this case I think. However we can extend the current GH60, to make it as modular, since it is open source, as long as we give due credit to the original GH60 team, we should be fine.Ah I see.
I started working on a 77key layout, but I sort of dropped it when trying to work out some LED arrangements on one of my other projects... then I sort of disappeared into a black hole for about 6 months.Show Image(http://i.imgur.com/2uoTSPk.png)
I'll have to keep an eye on this :D
For this GH100+ what would you guys think of the possibility of an orbweaver type module on the left side. Say 4x3 or 4x4 matrix plus at least a couple thumb buttons IE mini ergo dox to the left of the alphanumerics.
This idea came from my wifes keyboard which is this (http://katz.egloos.com/1865082) but make the left side more cherry matrix friendly. the rest of it seems to be a fairly standard 75% layout.
We're missing a GH80. A TKL PCB with full LED, SMD, usb port etc. Phantom is great but not perfect.I would be more into a GH80 than a GH100+ aswell
I'm going to try and learn how to design a PCB to try and make the above happen (but it ain't easy).
Can't say I'd use a GH100+ but I'm sure loads of people would.
We're missing a GH80. A TKL PCB with full LED, SMD, usb port etc. Phantom is great but not perfect.I would be more into a GH80 than a GH100+ aswell
I'm going to try and learn how to design a PCB to try and make the above happen (but it ain't easy).
Can't say I'd use a GH100+ but I'm sure loads of people would.
i would be interested in this if i could find terminal sets for caps. the only descent set that comes to mind is the R4 SPH SA Terminal set.
plus this community does seem to be obsessed with smaller and smaller boards (guilty as charged) or ergo.
I'm not sure it's so much that the community is that fond of smaller keyboards that a large keyboard wouldn't sell. It's probably more that there is more availability on full size keyboards. Though I do like the idea of having even more keys for some customization. It could come in handy for any number of things.^^^ This
Now all we need is the GH keyboard similar to an MS Ergo and I'm set (ie. tented, single case, no thumb cluster, FX row, and all keys in their regular locations).
How did I miss this thread?
You mean something like this, that I designed a while back?Show Image(http://i.imgur.com/gQ6IhoD.png)
That is all together too many keys :))
That is all together too many keys :))
Super serious gaming macros that you reach with your left elbow, while your feet are on some clicky pedals to make more macro combos. Totally legit! :D
I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.
I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.
Sorry, but you can only have this:Show Image(http://i.imgur.com/fSlOPgR.png)
Bwahahahaha
I want this:+1 for this! except the Function keys are grey too for the AT feel ;D
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.
I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.
I want this:
(Attachment Link)
Plus full support for ISO and JIS, and additional modifiers arrangement like winkeyless and etc.
This with Pure mods would be my dream.
I don't know whether people will "get it" or not. But I love it! So exited that this is finally coming together, MOZ. :D
I don't know whether people will "get it" or not. But I love it! So exited that this is finally coming together, MOZ. :D
By "get it", do you mean:
1. Lack of clear information, if this, I am willing to sort out any doubts
2. This project will reach fruition, I can't comment on this, but I will give it my best shot
3. Buy it, well it will be an open source project and a GB or anything of that sort is the last thing on my mind
4. Understand the concept, which I think is most likely what you meant, the crowd on GH is one of the most intelligent I've seen, so they should. In case they don't, remember, in one way we are working at "unit" level with this project, so once all the blox are done, we can easily combine them onto one PCB, without any problem at all and have that design ready for production; just like computers, those that "get it", assemble their own system as it offers more choice and is generally superior and customised, those that do not, buy preassembled ones.
So your going to make all the different case options to go with all possible combinations :eek:
So your going to make all the different case options to go with all possible combinations :o
Never.
So without cases, whats the point? :(
So without cases, whats the point? :(
and possibly the WS2812: https://www.sparkfun.com/products/11821
for lighting solutions as this would be hugely flexible...
Still a lot to do. The two ideas are:A while ago, I worked a little on a similar idea: a breakaway keyboard that I called the "ErgoHack". "Ergo" because it was split, and "Hack" because you would break or cut away (using a hacksaw) the parts of the PCB that you did not want or wanted to relocate somewhere else. If you wanted to relocate a module, you would solder a ribbon cable from the main board to that module.
1. Separate controller on each module and some way to have them connected to a base module and recognize each module with a unique ID
2. Base module and then using I2C and I/O controller like the Ergodox.
Before you go too far down this road you should evaluate the scan rate you'll be able to achieve over I2C. With the I2C I/O eXpander (IOX) @100kHz in my 5-row switch matrix I'm only able to complete a scan every ~5.2ms. .....I'm planning to maybe use this MCU instead: NXP LPC11U37FBD48/401. The advantage is the FM+ I2C bus. If I do make the switch, I will then also be using the PCA9670/71/74/75 IOX to utilise the 1MHz I2C bus, the added advantage is that the AS1115/17/30 are all 1Mhz compatible. The FM+ allows capacitance of upto 400pF, increased drive current. Since everything is contained in a small area, there isn't much distance so hopefully there isn't too much capacitance that we can't run it at 1Mhz at the allowed 400pF, if in the case there is, we can always use the PCA9601/05/46 buffers/repeaters. A single PCA9601 alone can increase the allowed capacitance by a factor of 10, so 4 nF without introducing too much delay.
If you have 3 IOXs and end up at a 15ms scan rate...well I don't think that's fast enough. You'll have to see if you've added too much capacitance with 6 connectors , 3 cables, and 3 slaves to run at 400kHz - which is the max that the 32U4 supports.
Maybe you'll end up deciding that the 32u4 isn't an option, instead opting for a micro with more I2C busses
or more I/O pins so that you can have one matrix and connect your blox with ribbons rather than I2C...I do no want to use too many ribbon cables for extension as it provides multiple issues such as complexity, large number of solder points, more error prone, more tracks to draw up on PCB.
You should also consider the AS1130: http://www.ams.com/eng/content/view/download/13457That is a very interesting LED controller and one that I am impressed with immensely. Thanks a lot. I also liked the AS1115/17 for driving LED as well as keyscanning for smaller blox upto 16/8 inputs respectively.
A while ago, I worked a little on a similar idea: a breakaway keyboard that I called the "ErgoHack". "Ergo" because it was split, and "Hack" because you would break or cut away (using a hacksaw) the parts of the PCB that you did not want or wanted to relocate somewhere else. If you wanted to relocate a module, you would solder a ribbon cable from the main board to that module.Yeah, everything is a module, the only breakaway is the 6(5)x2 and 6(5)x1, which I may decide to also just go with separate PCBs altogether.
However, taking a hacksaw to a PCB made of fibreglass is something that I learned not to encourage: it is very unhealthy to inhale the dust and I don't want to cause that.
Instead of using I/O expanders, I designed each module to own a part of a single matrix (for each hand, though, because it was split). Each sub-matrix was as tight a square as possible within its larger matrix so as to require as few lines as possible. The smallest unit was 2×2: a 2×2 matrix needs four lines, which are as many as are required for I2C (+V, GND, D+, D-).I sort of maybe get what you are saying and sort of don't as well, so could you elaborate a bit more, maybe a diagram or something, as I am definitely interested in the various options that are out there.
You should know that the MCP23018 does not have general-purpose I/O pins like the AVRs. There are only eight lines for strobing and eight lines for sensing.Yeah, I'm now leaning towards these components:
I think also that for a smaller matrix, you should look into using smaller I/O expanders.
How do you envision the mechanical assembling of the whole keyboard? Custom backplates with all the blox the user want, or some generic assembly system for self-contained blox?I have been pondering on how I can have it so it would be completely generic, so each blok would be self-contained. That is what I would like, now, the ideas I've had thus far, have all been very wild, trying to learn from the most modular thing most of us have been playing with from a very young age, legos and puzzles.
Also to connect your different blox, maybe you should make them smarted, ie. instead of using I²C I/O expanders, you can put a small micro-controller in each blok and only send actual key changes to the main micro-controller over I²C, which should eliminate any bandwidth issue.I do like the idea of a smaller MCU on each board specially if in a similar price range to the expanders, however since I am not an electronics engineer, and have no experience in the field thus far, I can't compare their pros/cons. I would request any electronics gurus, to please chime in and help in the project if possible.
Another alternative would be to put a USB MCU in each blok, and a USB hub chip on the main keyboard. This would make it very flexible (a user could use a 2x6 blok on its own, or just the numpad, without the central unit. It doesn't use more pins than I²C (2 for data, Vcc and GND).This is an idea regack and I have discussed earlier as well; one reason I am not in favour of this is, redundancy, as a separate controller on each blok, means many more components besides just the MCU, higher costs aswell. I'm not sure, but with numerous blox, we might even need a powered source due to the multiple MCU, this might be the case with the non-USB MCU system as well, need someone with more know-how on this.
I do like the idea of a smaller MCU on each board specially if in a similar price range to the expanders, however since I am not an electronics engineer, and have no experience in the field thus far, I can't compare their pros/cons. I would request any electronics gurus, to please chime in and help in the project if possible.
You can find simple MCUs in almost all families (AVR, PIC, ARM, etc.) for a few dollars. For extra reusability you could even have your main keyboard block have two MCUs, a block one directly wired to a hub one that would aggregate all blocks.Yes, I'm aware on the fact that we can get simpler MCU, in the ARM family as well (Which is looking to be the one we might go with), however when I said about pros and cons, I wanted a comparison more along the lines of electrical, ie, power draw as USB supports upto 500mA, capacitance, impedance, other electrical things I have no idea about, etc. :-[
The drawback is that each require programming, but it would at the same time simplify the main MCU code and it's mostly reusable for each block. And if you're in software engineering that shouldn't be a big issue.
hmm.. have you vetted the 23018? i think dox and team tried a bunch of different io serializers and ended up with an atmel chip because the others were just way too slow. otherwise, looking good!I'm not sure how deep the dox team looked into it, they are better than me in this field, however their application was different as they were limited to the AVR, which doesn't have native I2C, and uses something very similar called TWI (Two wire serial interface), which is essentially like I2C, but limited at 400Hz, the 23018, is ended capable of more, however it was limited by the AVR uC, and they only needed to attach a simgle device to the I2C bus, so it wasn't a problem. In our application we need to use many more devices on the I2C bus, and thus require I2C FM+ mode, allowing 1Kz, with all the same allowances as the slower I2C FM, as long as we stay below 400pF.
oh good point on I2C vs TWI.IDEK what FlexRay is :embarrassed:, Google here I come.
question: how about using one of the 8-bit or 16 bit freescale/atmel/Ti/AD/etc micros that has flexray support? flexray is extremely fast, self-configuring, and is emergening as a new standard for on-chip and interchip communication, all while being pretty damned cheap in both pins and cost.
Yes, I'm aware on the fact that we can get simpler MCU, in the ARM family as well (Which is looking to be the one we might go with), however when I said about pros and cons, I wanted a comparison more along the lines of electrical, ie, power draw as USB supports upto 500mA, capacitance, impedance, other electrical things I have no idea about, etc. :-[
When you mention, a secondary MCU for the the hub, do you mean, running it as a USB hub or running the I2C Bus?
There's a whole spectrum of available MCUs, so many that it's probably easier to define a spec you want, filter compatible MCUs, and pick one of the remaining ones. I don't know anything about I²C, but as for power consumption the equation is easy.....To select the right MCU for you, you need to add other filters. Like your familiarity with the manufacturer, your knowledge and the availability of the toolchain, extra features, etc. In particular you might want to look at ones with a USB DFU bootloader pre-programmed by the manufacturer (and eventually in ROM to be unbrickable).Yes, I've spent the last couple of days goign through possibly hundred of pages and datasheets of MCUs and comparing and what not, and thus I'm really keen on using the NXP's line of LCP MCU, and they have an impressive line, even some of the smaller MCU support I2C FM+, ROM with bootloader, I2C drivers, etc. Pricing wise some of them are close to the I/O expanders listed earlier, and thus are also feasibly as they reduce polling by main USB MCU over the I2C bus.
You get 100mA from USB at boot, and then up to 500mA after negotiation. Most USB MCUs are designed to work under that 100mA limit. That leaves you with up to 400mA to distribute between your blocks. I'm pretty sure you can get MCUs in all families with that use less than 50mA, at least if you use them as simple key matrix to I²C controllers (ie. with internal devices like times and ADCs disabled).I don't think current draw is going to be an issue with the MCU(s) and I/O expanders, as the current draw (Max) by the currently shortlisted devices is:
keep in mind that USB3.0 ups that current limit substantially, and that pretty much everyone has USB3 at this point. with a very large device like this that could potentially have very current hungry LED components etc, I would heavily consider targeting USB3 for the extra current.USB3 is definitely popular and something I had already try to rummage through the internet to find a cheap USB 3.0 MCU as it seemed like a feasible solution, given how most new USB host devices do have atleast 1 if not multiple 3.0 ports, however besides cheap, I couldn't find any viable options. We are still not there yet.
why the NXP MCU? imo pretty much everyone else has a better MCU at every price point. why not STM or Ti arm chips?To be honest, I did not study or look too much for better alternatives, as I was going with the I2C interface and NXP/Philips are the pioneers in I2C, so it was more of a natural choice. Once I went into that field, I had some communication with AcidFire (Who has been doing some similar and amazing work on the Nexus modular ergonomic keyboard project) and had been following his thread, the NXP LPC11U37FBD48 was the MCU he chose and seemed like a good choice given the price point and comparison to the ATMEGA32U4. However I have begun the search for a better MCU with I2C FM+ or HS at a similar price point.
NXP is does power fets, afaic. the other guys are better soc designers.
Everyone has USB3? Are you guys serious? :rolleyes:
Everyone has USB3? Are you guys serious? :rolleyes:
I think the NXP MCU line is not that bad, many projects use them. I've only used STM32 recently myself, and it was a bit of a pain to get a free toolchain up and running.LPCExpresso seems to have good reviews, it uses Eclipse, which I have some familiarity with and is straightforward to setup.
As for what you need to implement a keyboard protocol, any MCU with USB can do it. The keyboard protocol is very simple, and even if you want to implement NKRO most if not all will be able to do it (if you stick to a simple NKRO scheme with a single HID interface).I understand requirements can be fairly low for a keyboard system, but when developing a more complex system as this, we need to take into consideration larger systems and various layouts as well, we have to look at both ends of the complexity spectrum. Still, even for the most simple, let's say TKL, what would be the requirements from the MCU (Speed, FLASH or EEPROM or Both and quantity, RAM). These are the parameters I am not sure off.
I had a quick look at your Cypress hub chip, and I believe you misinterpret something regarding downstream ports. It has a 3.3V regulator for its own use (and eventually other chips on the same PCB, with a total limit of 150mA), but it cannot power downstream ports. You still need a separate power switch to route the 5V to each port (the hub chip has a Power-Enable output for each port, but that's just a logic signal to tell the power switch to transmit power or not).I've been an amateur in reading the datasheet and in my approach for large current draw as well, the better option if we do have to use direct power would be to use it directly rather than through a hub, have a connector to connect directly to a wall-wart, and have an auto switching circuit to actively provide 5V to the system, with priority from the wall-wart.
IDK if this is simple question or not, but can someone explain how a keyboard controller works? What the various components, CPU, FLASH, EEPROM, RAM play?
I know that is scans rows or columns for key presses, and then matches the keypress to a scan code and sends it to the host unit. Correct?
However I wanted a more technical and detailed explanation, as in, what role does FLASH/EEPROM play, what does the RAM on the controller do?
Can someone please confirm what the JIS layout looks like.http://en.wikipedia.org/wiki/File:KB_Japanese.svg (http://en.wikipedia.org/wiki/File:KB_Japanese.svg)
Can someone please confirm what the JIS layout looks like.http://en.wikipedia.org/wiki/File:KB_Japanese.svg (http://en.wikipedia.org/wiki/File:KB_Japanese.svg)
http://en.wikipedia.org/wiki/Keyboard_layout (http://en.wikipedia.org/wiki/Keyboard_layout)
no,please symmetric actually from japan as well :))
japan space is small you must smart placing :rolleyes:
Now I am confused, is the one on Wikipedia the correct one or the Filco one.i think same :-X just on filco no win_r key :)
@IvanIvanovich, you mentioned JIS, so I'm guessing you might know.
I started working on a 77key layout, but I sort of dropped it when trying to work out some LED arrangements on one of my other projects... then I sort of disappeared into a black hole for about 6 months.Show Image(http://i.imgur.com/2uoTSPk.png)
I'll have to keep an eye on this :D
moz, ESD or EMI? litster's case doesn't really leave any pcb exposed; are people killing the MCU with that 3.5mm TRS plug they're using to link the halves?
i would just spec a nice star ground through all the connectors that sinks into a plate or USB ground or something. the ESD suppression chips i know of aren't worth the cost when dealing with circuits this simple.