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.

Low Cost Distributed Battery Management System

Logan Rosenmayer, Daksh Saraf

Low Cost Distributed Battery Management System

Featured Project

Web Board Link: https://courses.engr.illinois.edu/ece445/pace/view-topic.asp?id=27207

Block Diagram: https://imgur.com/GIzjG8R

Members: Logan Rosenmayer (Rosenma2), Anthony Chemaly(chemaly2)

The goal of this project is to design a low cost BMS (Battery Management System) system that is flexible and modular. The BMS must ensure safe operation of lithium ion batteries by protecting the batteries from: Over temperature, overcharge, overdischarge, and overcurrent all at the cell level. Additionally, the should provide cell balancing to maintain overall pack capacity. Last a BMS should be track SOC(state of charge) and SOH (state of health) of the overall pack.

To meet these goals, we plan to integrate a MCU into each module that will handle measurements and report to the module below it. This allows for reconfiguration of battery’s, module replacements. Currently major companies that offer stackable BMSs don’t offer single cell modularity, require software adjustments and require sense wires to be ran back to the centralized IC. Our proposed solution will be able to remain in the same price range as other centralized solutions by utilizing mass produced general purpose microcontrollers and opto-isolators. This project carries a mix of hardware and software challenges. The software side will consist of communication protocol design, interrupt/sleep cycles, and power management. Hardware will consist of communication level shifting, MCU selection, battery voltage and current monitoring circuits, DC/DC converter all with low power draws and cost. (uAs and ~$2.50 without mounting)