Category: Ben’s Status Reports

This week, I first worked on the presentation and practiced presenting the slides at home. I also made sure the keyboard receiver was robust enough both in transmission rate and latency to be able to be used as the presentation tools. During the presentation, I noticed that sometimes when pressing the key extremely quickly, it would take multiple keypresses for a key to be registered. After the presentation, I looked into this issue more, as it did not show up during testing. Eventually, I found out that quick keypresses would often times not register correctly. To remedy this, I added a functionality for tap detection, where the key would be pressed and unpressed more rapidly than the time it took to change the characteristic value. The issue was that if two consecutive keyevents were to happen very close together, only one of them would end up registering and being sent to the receiver.  First, I tried decreasing the debounce time but found that even without debounce, it would still only send a single keyevent. Next, I tried briefly going back to a polling method rather than an interrupt method, but that still did not work. Finally, I added a special case where if a keyrelease was detected without it’s corresponding keypress, it would register as a tap, and send a print character command over the keyboard. This ended up working, and even with rapid taps, would still output the correct number of letters. After doing this, I tested with 10 rapid taps, and found that it was much more consistent than before without any lost keys.

My progress is on schedule.

Next week, I hope to finish the final report, poster, and video on time and have nothing go wrong during the final demo.

This week I worked on getting the forwarding of connection and keypress data from the auxiliary BLE receivers to the main BLE receiver. I also modified the software of the main BLE receiver to be reprogrammable over UART. The first thing I did was consider the possibility of setting up a network where the 2 secondary BLE receivers would then connect to the main BLE receiver and forward the keypress data. However, I decided that this idea would not be feasible since the BLE latency from a direct connection was already over half the use case requirement of 50ms at 37.5ms, so adding a second jump for the connection would not be feasible. My solution to this issue was to physically connect the 3 microcontrollers. Since they all have the same pin footprint, I simply soldered headers that allowed the microcontrollers to stack on top of each other, transmitting the key press data in the form of pin signals. Receiver 1 is tied to pins D2-D6 and receiver 2 is tied to pins A2-A6. Whenever a key event is detected, the pin is set to the corresponding level. This adds a negligible latency, as when testing with the 240 fps slow motion camera on my phone, the latency was still 9 frames even when connecting to the bottommost receiver in the stack. Additionally, I implemented the protocol to receive the programming commands over UART. The main receiver will then parse the received string and determine what the new key assignments should be.

My progress is on schedule, and I have finished pretty much everything needed for the project.

Next week I will be working on the presentation, final report, and preparing everything for the demo.

This week I worked on getting more than 7 devices to connect to one central BLE receiver. However, I was ultimately unsuccessful. The first thing I tried was to modify the values in the MbedOS configuration for the Arduino Nano33 BLE boards that I received this week. However, the issue was that to recompile the MbedOS required installing a certain set of depenedencies that were no longer possible. After failing to modify the MbedOS configuration, I instead looked towards trying to modify the ArduinoBLE library to allow multiple connections. I tried changing the ATT_MAX_CONN value first to 8, but that ultimately ended up not doing anything. Then, I dug deeper and looked into what exactly the library was calling, and where connect was failing. I found that the problematic function was in the HCI class’s leCreateConn function, which had would return the value of a call to sendCommand. sendCommand would return the value of _cmdCompleteOpcode, and after some digging, I found that this value was set by the handleEventPkt function, specifically in the EVT_CMD_COMPLETE case. However, I was unable to locate where exactly the value was being written, since the value is assigned to a value passed in through an array that was read into from HCITransport.read. However, I was unable to determine where this value was being read from and how I could ensure that it would not return a result that would lead to the connection failing to be established.

I am still on schedule as it is not essential to have one device connect to more than 7 keys, as multiple receivers can be used. However, I would like to get the number up to at least 8 since that would mean that only 2 receivers would be needed.

Personally, I will be running the tests involving latency and battery life. I will measure latency by recording the process of pressing a key with my phone slow-motion mode, and then counting the frames until it shows up on the screen. Each frame would be 1/120th of a second, so multiplying the frames by 833uS would give me the latency. Next, for battery life, I will be testing the overall battery drain over a period of 1 hour. By measuring the analogue input from the battery pin, and comparing it with the max and min values of the LIPO battery, I will be able to measure the battery level. Then, simply by using the keys for 1 hour I will be able to tell how much battery has drained, and thus how much battery life the device has.

Next week I plan on acquiring more Nano33 IOT boards and developing the connections further. This way, I will be able to test the receiving of more than 7 keys. Additionally, I will also be helping with the housing design and fabrication, and I will be making a few more keys. I can also begin preliminary testing of the latency through frame counting.

This week I worked on assembling an additional 5 BLE stacks to bring the total to 9. To do this in an efficient way, I devised a method where the boards could be secured by the header pins into a breadboard to ensure they are aligned correctly after soldering. I also updated the KeyPeripheral code such that the keys will now go into a deep sleep mode after either 10 minutes without activity while connected to the central receiver or 1 minute without connecting to anything after being turned on. This reduces the battery consumption significantly, such that the keys can stay unplugged for multiple days and still be able to connect when pressed again to wake them up. However, I encountered an issue with the Arduino Nano 33 IOT, which is that it only seems to be able to connect to 7 peripherals simultaneously. There doesn’t seem to be a lot of documentation online specifically about this board and how to raise the limit, but there does appear to be some in place for the Arduino Nano 33 BLE. I have tinkered with some of the mbedOS files to increase the thread stack size and also some constants but the number of BLE devices that can be connected simultaneously remains hard capped at 7. Additionally, I have modified the receiver code so that it can identify and connect to new keys after the scan period is over. It does this by storing a copy of all the hardware IDs of each of the keys it’s connected to, and it then periodically attempts to connect to the new modules if it finds that they are available. The updated code can be found on bojuns/FP-Key-A_BLE (github.com)

My progress is on schedule this week.

Next week, I hope to unlock the connection cap to allow at least 8 boards to connect simultaneously to a single receiver. This way, it would be possible to connect all 16 switches simultaneously with only 2 receivers. If this does not end up working, then the next solution would be to make a two tiered design, where the switches connect to an intermediary receiver, which then forwards the signal to the central receiver.

This week I soldered another 2 BLE boards together and worked more on the software side of things. First, I added debouncing to the peripheral code to ensure that the interrupt would no longer cause a race condition when it was called multiple times in rapid succession due to switch bounce. This caused issues with key reading so I switched the key reading system such that it would toggle the value upon detecting a state change instead, which would save power from reading the keypin all the time. I also played around with the delay in the main loop such that it would connect to the central device quickly without using up too much power. Next, I set up event handlers for the BLE events of connection and disconnection, having them stop and restart the advertising respectively. This would further save on power as the device would no longer need to advertise constantly even though it was already connected to a central. On the central side of things, I fixed up the reconnection such that instead of taking upwards of 30 seconds to reconnect, reconnection could happen within a second or so. Additionally, other keys can still be used while a key or multiple keys are reconnecting since the reconnection does not spin anymore while waiting for a connection like before. However, to facilitate this, I had to also add BLE event handlers for connection and disconnection that would start and stop the scan for the particular device UUID so as to reduce function call overhead for the reconnection of a device. I also helped fit the key stack onto the first prototype of the 3D printed housing. It ended up being too large and without a cutout for the USB, so adjustments will be made in the future.

I believe my progress is on schedule this week.

Next week I plan on working on the central code such that it will be capable of connecting to new key devices beyond just the scan phase. This will mean that if a user brings in new keys, they can be connected right away without a reset of the central receiver. Additionally, this means that if a key was not detected immediately, it can be connected later still.

This week I worked on implementing the connection between multiple Seeed BLE boards and a central controller. To facilitate this, I modified the peripheral code, having each Seeed board’s characteristic utilize the notify function to allow the central board to subscribe to multiple peripherals at once. Unfortunately, because I only brought 2 Seeed boards home, I had to buy a Arduino Nano 33 IoT to test the multi board connection. Luckily, the BLE library worked fine with the board and I was able to test the central connecting with two peripherals simultaneously. The code has been updated on the github to reflect these changes. I also wrote the Introduction, Use-Case requirements, Architecture, and Design Requirements sections of the design report and helped with the Design studies, Summary, and Glossary of Terms.

This work puts me a bit ahead of schedule since I believe this will allow me to scale up to multiple switch devices without much hassle.

Next week I plan to get multiple keys working and, when the single switch PCBs get here, solder together the switch breakout board with the Seeed boards and test their stability.

Here is a video of the two key receiver working: https://youtu.be/-SggOrEHb1I

This week I rewrote the entirety of the BLE code such that each key peripheral device “daisy chains” off the previous one, forwarding the values of each key to the central controller. However, I was unable to get this fully working as I had to solve a few issues with getting ArduinoBLE to make a device act both as a central and a peripheral. The current code can be found here: bojuns/FP-Key-A_BLE (github.com)

Still, however, I believe my progress is on track since after some more debugging, I believe I should be able to get multiple connections working before the end of next week.

Next week I hope to finish the daisy chaining protocol and test it for latency measurements.

https://youtube.com/shorts/qfVXAoujZhY?feature=share

This week, I got a single key to communicate via BLE to a controller. When the key was pressed, an LED on the switch and receiver will light up. I first started by finding an appropriate BLE library for arduino, which ended up being ArduinoBLE. From here, I defined a ledService for turning on and off the LED with a ByteCharacteristic to send the key press state. Debugging and troubleshooting took a lot of time because sometimes the device would fail to connect, but after a reset or a reflash, would work all of a sudden. This was solved after removing the serial initialization, when I realized that the device would lose power after being unplugged and before switching over to LIPO power, which caused the code to run again, which led it to continuously wait for a serial connection to the computer.

I believe my progress is on schedule, as I am scheduled to have a single key working this week. From what I gathered, I believe implementing multiple keys will not be too difficult.

Next week, I will try to implement multiple keys communicating with the central microcontroller, where each key module will be able to wireless transmit the pressed or unpressed state to the key.

18-220 was a great help to the progress this week, as it introduced me to the Arduino IDE and how to install various packages and program the correct board. Additionally, I applied my 18-349 experience of reading datasheets to determine pinouts and functionality (which is how I determined which pins to hook up the switch and the battery to). Additionally, Embedded taught me how to use minicom, which helped with debugging (since the Arduino IDE only lets you open a single serial terminal at once). Finally, the programming knowledge was learned during the last 2 weeks when I was researching the BLE protocol and how to implement it through arduino.

This week I worked on ordering the parts and reading up on the BLE programming protocol for the Seeed XIAO nRF52840. I placed an order for 16 microcontrollers through the order form, which are on schedule to get here next week. Additionally, I did research on the BLE protocol and the role of devices in communication. I found that the microcontrollers would be best used in peripheral mode, with a specific GATT (Generalized Attribute) and service for each key. Each key should also only have notify and read permissions.

I believe that I am on schedule to begin programming the basic single key interface with the computer next week when the parts hopefully arrive. In the meantime, I will be continuing to work on the starter code so that once the board gets here, I can begin programming and debugging right away.

For next week, I hope to program a single microcontroller with the ability to determine whether or not a key is pressed and send that data over BLE.

This week I helped refine the project proposal and refine the use case. We initially thought about switching to a different project, but after some careful consideration, we decided to more clearly define the use case for our current idea. After careful consideration of multiple ideas, we decided to abandon our original I2C connected board and switch to BLE instead. I researched a variety of BLE capable microcontrollers, comparing factors such as size, ease of programmability, price, and availability to settle on the Seeed XIAO BLE. I also looked up the spec sheets of the switches we were planning to use (Cherry MX) and recorded key dimensions to aid in the search for parts. Finally, I tried to find similar projects online to see how we could improve on what’s already on the market, but there was not really anything similar.

My progress has been on schedule since I have made good progress or finished my tasks for the week. These included refining the project scope, performing an initial survey of possible electronic components we would need, and adding my contributions to the powerpoint.

Next week I hope to read up more on the BLE implementation on the Seeed XIAO BLE so I can be ready to program when the parts come in. Additionally, I hope to have the remainder of the parts decided and ideally ordered so we can begin prototyping as soon as possible.