Project
# | Title | Team Members | TA | Documents | Sponsor |
---|---|---|---|---|---|
10 | Plug and Play Modular Keyboard |
Christian Held Daniel Chen Fangqi Han |
Shaoyu Meng | design_document1.pdf design_document2.pdf design_document3.pdf design_document4.pdf design_document5.pdf design_document6.pdf design_document7.pdf design_document8.pdf design_document9.pdf design_document10.pdf final_paper1.pdf proposal9.pdf proposal1.pdf proposal2.pdf |
|
Christian Held ; Fangqi Han ; Daniel Chen Problem – When people think of keyboards, they think of large HP keyboards with a number pad and feet that kick up in the back. Full keyboards are useful for situations where the keyboard does not need to move and for right handed people. On the go, though, they can be bulky and too large for travel. Additionally, the number pad being on the right can be annoying for left handed people. There are keyboards that go smaller (similar to the size of a laptop keyboard, which have their own inconveniences), but then sacrifice the full keyboard functionality that all those extra keys provide. For all these considerations, one should be able to pick and choose the right amount of keys and orientation to maximize their workflow and work situations. Solution Overview - Our solution starts with a relatively portable main keyboard, with the main keys like the letters and numbers called the tenkeyless or 60% keyboard layout, that has a microcontroller and can connect to the computer. Then, there are other modules that can be connected to this main keyboard that will add functionality to the main keyboard. One module would be the number pad, which is necessary for some and needlessly bulky for others. Another would be the function keys (f1, f2…) that have this same tradeoff. Then we can have modules that provide added customization such as a volume knob or other I/O not normally found on a keyboard. The main workflow for this projects starts with the keys. They give a signal to either the microcontroller or I/O expanders (which then feed signals into the microcontroller as well). The microcontroller identifies what key(s) have been pressed and sends serial commands back through the USB to the main computer. The code for the microcontroller should allow for the user to change what each key does so they can have maximum capabilities even in the smallest physical setting. Each module should have a case in order to protect it and the user from one another. Solution Components – Subsystem 1 Key wiring: the mechanical switches of the keyboards, and the wiring/PCB between them that will be connected to the main controller or I/O expander. Examples of switches include cherry switches or gateon switches. Brought up in our comments, these mechanical switches have generally a debouncing period of 5ms, and we think this is short enough that we will not have to deal with this mechanical issue on the software side. Subsystem 2 Microcontroller: interprets key signals from keys or I/O expander into USB signals to be sent to the computer. One microcontroller we are heavily considering is the Teensy 2.0 controller. Subsystem 3 I/O expanders: connects the outer boards to the main “tenkeyless” board. They are connected with 3.5 mm jack plug to communicate. These 3.5 mm plugs need to be TRRS cables, and will send GND, +5, and I2C Serial Data and the Serial Clock between different components with the I/O expanders. (Even though the 3.5 cable can send analog signals, the data will be digital) We are also interested in alternatives for our connection that are more compact, but the 3.5 mm plug seems to provide everything we need to send between components and is hardware that we already understand and can implement straightforward. Subsystem 4 Firmware: code for the microcontroller that will interpret the key signals and also control things like caps lock and the function layer (pressing fn on a laptop, which we plan to implement). Subsystem 5 Programmability: Allows user to modify their keyboard to produce what characters or potentially commands, such as changing the fn layers, having programmable keys, and other features that would help with user productivity and customization, which is one of the main pillars for our design of a modular keyboard. Subsystem 5 Structural components: casing that protects user and keyboard from one another. We plan to use 3D printing and perhaps aluminum plates as simple shells for our pcb and controllers. We would also like to explore alternatives. Criterion for Success - A working main keyboard and one module that can be connected that adds more functionality to the keyboard, as well as disconnecting this module without crashing everything. While a keyboard with a clean case, nice cables, and new keycaps would be nice, the idea of adding more functionality and having an interesting and useful way to connect these separate components are what we want to focus on the most. |