There have been no design changes and schedule changes this week. At this point we feel that we are ready for the demos.

Work Update

Last week I worked on creating elements for the web frontend. I also finalized the websocket communication between the frontend and the server that pushes out game updates. Finally, I worked on finishing the communication between the play areas and the central computer using gRPC.

Schedule Update

I believe I’m still on track for my tasks. Next week I will work to finish everything and prepare for our demo.

Work Update

Last week I worked with Chris and Mark to build the dealer component. I also started building various parts of the web frontend, and the socket server that will send game updates to the players and audience.

Schedule Update

I believe I’m still on track for my tasks. Next week I will continue work on the communication layer between the play areas and the central computer, as well as the motor driver.

Work Update

Last week I did some light research and work to prepare to write the motor driver, but other than that was unproductive.

Schedule Update

I believe I’m still on track for my tasks. Next week I will work on the communication layer between the play areas and the central computer, as well as the motor driver.

Work Update

Last week I finished the chip detection driver, and worked on a rough prototype of the e-ink display driver. With the display driver I ran into some difficulty because there are very subtle differences between the models that are not made explicit in the documentation. It was a process of trial and error to get the screen to work, but once it began working it was an easier process to get the rest of the driver figured out.

I ended up using a second library to make generating images for the screen easier. The way an image is sent to the device is as a big two dimensional array of binary values, because each pixel the screen can either be on or off. However to generate text and graphics by hand would be a pain and require a large amount of boilerplate code. Instead I use a two step process. The first step is generating the image using PIL (Python Image Library). It creates a “canvas” that can then be drawn on. It has resources for drawing text, images, shapes, and more. Then the second step is to take that canvas and render it to black and white, and output an array like the one required by the screen. That data is then written to the screen’s memory.

Finally, I wrote some simple code to glue everything together for the demo. It was a simple loop that checks for new cards, checks for new chips, then updates the screen with the results if any are new. While this isn’t the exact approach that will be used for the final game coordinator running in the play area, I hope to be able to reuse a lot of the code.

Schedule Update

I believe I’m still on track for my tasks. Next week I will work on finalizing the game coordinator in the play area and building a simple server to test with on the central computer.

Work Update

Last week I worked on and am almost finished with the chip detection driver. This was something of a departure from the RFID driver because it was a whole new piece of hardware, and it was built on an I2C driver rather than an SPI driver. Luckily, the INA219 did not require nearly as much setup or configuration as the MFRC522 did.

One hiccup I ran into was that the resistor built into the INA219 was too small to measure the current in the circuit directly. I ended up using another resistor in series with the set of chip resistors in parallel and measuring the potential difference across it, which was large enough to not be a problem for the INA219. Another potential problem is that the accuracy of the INA219 is good, but not perfect. However, I think that by looking at the change in chip value rather than the absolute value at any time we can make some assumptions about what the correct set of values is.

Schedule Update

I believe I’m still on track for my tasks. Next week I will work on the driver for the e-ink screen, which will make the play area subsystem more or less complete software-wise.

Work Update

Last week I completed the RFID driver. As mentioned in the design review and a previous blog post, it was built on top of the Raspberry Pi GPIO library for Python, as well as another library that has some basic SPI primitives. Specifically, it exposes an API that allows the user to create a connection to an SPI device, and transfer data.

I began by writing some relatively simple code to set and read registers on the MFRC522 device, as well as using bitmasks to set or clear specific bits of a register without changing the others. I then began to implement some basic functionality of the MFRC522, as well as a subset of the full RFID spec given by the tags we bought. On the device, we need to initialize it, configure it, and have the ability to send commands to select a tag, send commands to it, and read the response back. In this way we can read the ID of each tag without needing to implement the full set of cryptography operations that are required to read and write to the data sectors of each device.

This work was an iterative process of reading the manufacturer documentation, figuring out which registers and settings were needed, and testing. Progress was slow because while the documentation is detailed, the device has a significant number of features, and there is no guidance on how to perform particular tasks. That made the process largely one of trial and error.

Schedule Update

I believe I’m still on track for my tasks. Next week I will work on the driver for the current shunt so that Mark and I can begin to test the chips he’s been working on.