Between the mobile clinic trips and World Cup games and Festa Junina celebrations, I have been working on my personal project for Dr. Wilson and the Nuclear Medicine department. The device will draw the correct amount of a given nuclear material based on the user inputs. My design is made up of two parts: calculations and dose draw. On an LED screen, the user is prompted with questions, such as, “When will the sample be used?” and “What is the current radioactivity?”. On a keypad, the user will then enter their numerical responses. Based on these values, the device calculates how much volume needs to be in the syringe and directs to motor to rotate a certain amount of revolutions. As the motor rotates, a clip holding the syringe is drawn back and will stop when the volume in the syringe matches the needed volume.

Before parts arrived, I wrote code for the process and specific parts, but I couldn’t check if it actually worked. The flow of the code felt logical and verifying on Arduino told me there were no syntax errors. I tried to anticipate where the problems would arise, hoping to get ahead of the issue. I was most concerned about the confirmation pushbuttons, spending 30 minutes on FaceTime with a friend talking through possible solutions. I also wrote small files to perform simple tasks, trying to see if the accessories could walk before I made them run. But when parts arrived, and I eagerly hooked everything up, these small files caused big issues and I also realized I didn’t need pushbuttons. C’est la vie!

So far, I’ve spent the most time in troubleshooting teaching the program how to recognize inputted numbers as having numerical value. When a key is pressed on the keypad, the system knows what character is pressed, but it doesn’t know how to treat the character as anything more than a symbol. Online forums and manufacturer spec sheets offered a lot of insight. Reading through other code and user comments, I would be inspired for a line in my own code. Now each character is assigned a value, the value goes into a bin, and then the values are strung together to make a multi-digit number.

Once the accessories actually worked, I asked for feedback on user-flow and added in some control options. Do the questions make sense? Did I miss a confirmation prompt? After the user inputs a number, they have to confirm the inputted value by pressing “A” on the keypad before the next prompt appears. Pressing “*” lets them reject the value and the screen will then tell them to re-input the value. At any point, the user can press “#” to restart the entire system and return to the first prompt.

All of the work up until this point has been at my desk, connecting wires and adjusting code. The next step is to move towards the more physical parts of the design. I still have to define the relationship between turns of the motor and mL drawn, but to do this I need to have the system set up. This design lives in my notebook as a drawing, but soon I will go down to the Clinical Engineering office to materialize it. I learned from the coding part of the project that complications can present themselves in places where you least expect it. So, I am giving myself as much time as possible for the construction part of the project to meet the approaching deadline: three more weeks!