Author: carmenda

This week, I worked on finalizing the software for detecting the mouse and key presses. I set up scripts to run on boot, so now the keyboard can just be plugged in and used without any setup. Most of the keys are mapped, all that’s left in terms of the keyboard is to implement the alternate keys and other error-correction features (such as shift or toggle and ignoring double pressed keys).  In terms of the mouse clicks, I am still working on setting up the Raspberry Pi zero to act as a mouse. It doesn’t have wifi, and ssh over USB disables the system we use to send mouse clicks, so it is slow to set up, but should be done by tonight. The reason we decided to use a second Raspberry Pi was due to a delay that occurs when switching gadgets on the fly. It made the mouse clicks interfere with the keyboard to an extent that I considered unusable.

I also worked on designing the mouse housing using CAD. I made a prototype version (shown below) to make sure the mouse internals would fit and still function, and the final version was printed today (but we haven’t picked it up yet.

At this point, I believe we can finish most of the hardware by tomorrow. From there, it will just be getting the software to fully implement the features we planned previously.

This week I had started on working to get mouse clicks to work along with key presses but was facing some issues. Right now it’s on or the other essentially. I was unable to work since Monday due to illness, so progress is behind now.

This week I worked on implementing mouse clicks via a key press. The USB gadget system that Linux uses only allows one device to be simulated at a time. So, for this to work, the keyboard device needs to be “disconnected” and the mouse needs to be “connected” when performing a mouse press. I plan to fully implement this functionality next week. Also, we were able to run the breadboard software of a 2×2 grid on the PCB that was printed (connections shown below).

This week I modified the keyboard software so that it behaved like a standard keyboard. The reason it was sending thousands of key presses very quickly before was due to the way I was implementing the report descriptors. The way they work is that you send a list of keys pressed, and when a key is released, it is removed from the list that you send. So, now it only removed keys from the list if they are no longer pressed. One other thing to note is that the USB standard only allows up to six keys to be pressed simultaneously.

This week, the diodes we ordered arrived. I set up the circuit we had originally planned on to make sure that unique keys can be detected. The script I ran can be seen here. I modified the script to be easier to use different keys, and the only change that will need to be made is adding more IO pins to the row and column lists. I also made a class to keep track of what values correspond to what keys when sending the keyboard reports. These values are based on the documentation from the USB  usage tables. An image of the circuit I set up is shown below. The blue wires correspond to the rows, and the yellow wires correspond to columns. The circuit diagram can be seen in an older team post here.

When all four switches are closed, all four keys are detected, and every combination of on and off for each switch is recognized as distinct. This means the ghosting issues we were seeing before were caused due to the missing diodes, and that the diodes are not optional for functionality.

On another note, CLASS has not responded to my email yet, so I will need to look into following up and potentially using another source of contact.

This week I worked on setting up the keyboard emulation on the Raspberry Pi and helped with the design review paper.

Getting the Raspberry Pi to work as a keyboard was not very complex, but ended up being somewhat time consuming due to some details I was not aware of to start. The link I posted in my last report had all the material needed to figure it out however. The one oversight I had was that I had originally connected to the Raspberry Pi via ssh over USB, so some of the settings to enable that interfered with the settings to enable sending key presses over USB. Once I figured out the issue, running the setup script from the website I linked caused the following window to appear on my Mac:

This means that my computer detected it as a standard keyboard, and sending key presses worked fine after clicking on “Quit”. With this done, writing the code for detecting GPIO pin changes and sending a keystroke to any host computer should be relatively straight forward.

With this done, I am still on schedule. I mentioned in my last report that I would also write the code for preliminary matrix scanning, but setting up emulating key presses was more involved than expected. However, writing the remaining code should be trivial now that the base functions have been shown to work. So, I’ll write the preliminary code that uses matrix scanning to detect and send key presses next week. Once this is done, the hardware will be the only thing left to complete for implementing a custom keyboard.

This week I worked with my teammates to finish the design review presentation. I also started some testing with the Raspberry Pi to learn how to read and write to the GPIO pins. The gpiozero library that comes standard with Raspberry Pi OS provides all the functionality that will be needed for this. The following test script I made using Python was able to detect when pin 2 and ground were connected via a wire:

This means that the code for detecting whether or not a switch is pressed will be relatively simple once we have decided on a layout.

On the other hand, sending key inputs to a computer will be a bit more involved. According to this  link , it appears that there is a gadget system in place on Linux that has the desired functionality.

Since we didn’t schedule the software to be started until after the design report was due, I am technically working ahead of schedule. The meeting we have scheduled with Professor Carrington isn’t until next week, so we are limited in certain areas that we can start working on. The software for communicating signals is independent of the feedback we will receive from that meeting, so I started work on it sooner.

For next week, I plan to write a preliminary script to handle matrix scanning from the GPIO pins. I also hope to nail down exactly what the process of sending key presses to a host computer will look like.