Posted on

Ji status report March 26th

Due to the ethics seminar, we could not do much on Wednesday. We did discuss briefly how our project would potentially cause harm. On one hand, it is a ‘better’ keyboard and keyboards already exist. On the other, Social Media is just a better messaging board. We concluded that by giving some people easier access to services that already exist, we could not cause much harm. We also discussed how a cheaper accessibility keyboard may reduce the job opportunities for stenographers, but there are plenty of other jobs other than typing for the impaired.

We also discussed biases. As a team of able-bodied designers, we need to learn from people with cerebral palsy and what they want in a keyboard/mouse set, and not just what we think they want. We reached out to find people with cerebral palsy and are currently awaiting a response.

On Monday, we were still awaiting the shipment of diodes. I searched for key switches for keyboards (the things you press). We went with linear key switches, the simplest and most common type of key switch.

This is the link to the keys we plan on purchasing. We chose Gateron Ink Black switches because they are relatively inexpensive and have consistently been rated as having a ‘smooth’ feel. I was concerned about the mention of lubricating the keys, but apparently it does not particularly matter for people who do not already construct mechanical keyboards. I had considered the silent version of the keys, but they are more expensive and seem to require more force to operate.

https://divinikey.com/products/gateron-ink-v2-switches?variant=32067927048257

Posted on

Team Status Report March. 26

This week we received our diodes and were able to set up a 2×2 prototype of our board. Ee will order the PCB from whichever board-house is most convenient and fast. Besides that, there didn’t seem to be any immediate issues with the PCB so ordering it after this point shouldn’t be too big of an issue.

We reached out to CLASS about finding someone with Cerebral Palsy but have yet to receive a response.

Progress was slow this week since we only really met on Monday because Tuesday was our Ethics Meeting. Progress should be back on track next week.

Posted on

Jorge’s Status Report March 26

This week we did not get that much done, we met on Monday and then Wednesday had our Ethics meeting.

I largely looked at possible revisions for our PCB and looked for potential boardhouses to order from, but it would be best to have a fully working breadboard prototype before we order the PCB. Our Diodes arrived on Friday so that should be done some time next week.

Besides that, Carlo’s wrote an email and we reached out to CLASS, the organization that could potentially put us in contact with someone with Cerebral Palsy, but they have not responded.

We should get back on track next week, but we shouldn’t imagine that we have too much time and get over-confident. In truth we only have a few weeks to integrate and it may be tight due to delays.

Posted on

Team Status Report March 19th

Before spring break, we tried making a better prototype. We did not fully understand how matrix scanning worked, so we assembled a new prototype. This did not work, and upon closer inspection we learned that our diodes were not the right type.

The scanning matrix works by quickly cycling through each column, such that the selected column is pulled to digital low and all other columns are at digital high. It then checks which rows have been pulled low from the switches.

Here is a smaller scale version of the switch.

When we tried making the circuit, we failed because on closer inspection, we had the wrong kind of diode. We used LEDs, which on average drops 1.7 to 2 volts, which would mean that a row with a closed circuit would drop from 3.3 volts to 1.7 volts, which is still a digital high. We are now trying to find diodes with a lower voltage drop, around .3 volts, so that row can be pulled down to a voltage low. We have just ordered a new set of these diodes and are awaiting supplies.

We then moved on to testing the software without the diodes, which helped, but we had the expected ghosting issue. But since the ghosting only happened when multiple columns were on at a time, the circuit and software seems to work and should still work when we add the right diodes.

When it comes to making the PCB, we ran into issues because our board went over the maximum dimensions that Eagle free would allow, so we needed a proper Eagle education license. This was an annoying delay but I (Jorge) submitted my enrollment documentation and the license was supplied the next day. It was a minimal delay, and instead of getting the PCB design finished on Wednesday I got it done Friday. Next steps would be to revise it a little and then decide on a board manufacturer and order it some time next week.

Here below is the board PCB layout

[Note: More specifics on the design in Jorge’s personal status report]

Carlos is also going to reach out to CLASS this week. An organization which the professor in HCI recommended to put us in contact with someone with Spastic Hemiplegia.

Posted on

Jorge’s Status Report for March 18

  • Jorge’s Status Report for 3/18/22

This week we tested the software and made sure it worked well enough with a prototype of the board. We put in an order for the Diode’s we will need and with those we will know finally whether absolutely everything is working as intended. But as mentioned in the group report, the behavior is about what we expected. (The software works fine but once we do inputs from separate columns ghosting becomes an issue.)

Besides that it was my time to start work on the PCB layout. We ran into a slight delay which I made up by working on the layout on Friday. The Eagle license we had was only the free one and our Board dimensions were beyond the allowed limit. I had to submit some enrollment documentation, transcripts, and an ID but we ended up getting the Eagle education (through Fusion 360) license approved the next day.

 

Here below is the PCB:

Notes about the board:

  • It has no ground plane, this is unnecessary because we would only need a ground plane for the LEDs in the switches, which we are not using
  • I am slightly worried about the space the Diodes (not the LEDs) take up, but if they take up space for our switches we can just solder them on the back of the board so I don’t see that as being a big problem.
  •  The pin headers that interface the Pi are organized as rows and columns, it keeps the board neat and orderly. Rows flow through the bottom of the board, columns through the top. Both eventually rout to the top to their respective Pi interfaces
  • LED pins are left disconnected for now, if we decide to use them for some reason I can add some wires and resistors to make use of them, but it isn’t high priority.
  • Spacing is made with 20mm keycaps in mind, and a key-guard. Hopefully the dimensions wont be too ridiculous but there is room to make changes next week before we order the board.

My main worry right now is the time frame, we may need to pay for express shipping so we can get the board on schedule.

 

Posted on

Ji’s Status Report, March 20th

As stated on the team report, we made the prototype board, only to run into a wall when we didn’t have the right diodes. We then moved on to the assigned ethics writeup, which we did during class.

I also proposed a way to make the board more durable: wrap the bottom and sides in adhesive rubber strips, and weigh down the bottom so that it would fall down on the rubber instead of the top. We plan to use an extra board to test durability.

Posted on

Ji’s Status Report, Feb 27th

This week we were doing the design report, both writing the report and slides, so not a lot got done on the design front. We’re still on track.

I contributed by writing the introduction and editing the use case. I also started on the Architecture and Trade-off sections.

Posted on

Team Status Report for 2/26/22

This week, Jorge presented the design review for our team. Also, we started writing the report that goes along with it.

Jorge worked on modifications to our keyboard schematic.

Carlos managed to get the Pi to communicate keyboard inputs for the first time, which is a big step in our software implementation. We should follow this up by prototyping our keyboard on a breadboard and seeing if we can integrate our inputs with our outputs.

Our meeting with Professor Carrington was originally supposed to be on Friday, but was postponed to Monday.

Schedule:

In terms of schedule, we have made progress on all fronts, so we are on good pace. It would have been nice to have the meeting on Friday as originally planned but we have done well to compensate for any delays so far.

Posted on

Jorge’s Status Report for Feb. 26

  • Jorge’s Status Report for 2/26/22

This week I worked on the design review Report with the team, I presented our design review slides on Monday, and made modifications to the schematic. The changes to the schematic are the following:

I added new header pins which we plan to solder some male connectors to, this is for the interface we are making from the keyboard to the pi

Included a Frame for the schematic, mainly aesthetic

Rerouted some wires in consideration of the software. By including four new rows for the specific combination keys, it will help make our software simpler to implement.

These are the final steps before getting started with the actual pcb layout. This part shouldn’t be too hard but I expect changes to be made based on the feedback from the professor in HCI. I am very familiar with the PCB layout portion of Eagle and don’t feel its necessary to layout an entire board ill probably have to change, so I will wait until after our meeting and then proceed making the PCB.

In the mean time, I can get started on designing a little layout for our planned de-activating toggle switches and make a schematic, but that part should be easier to do than the main Keyboard PCB.

Posted on

Carlos’s Status Report for Feb. 26

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.