Finishing the Sphere

After a busy final week, my project has very quickly taken form. I left off last week with the bottom half functionally complete, but aesthetically lacking due to a missing top half. This week, I had to get the top half printed, glue in all the LEDs, solder all the additional wiring in place, and update the code to accommodate it. While I had already done each step for the bottom half, the top half did involve more LEDs. This especially complicated the wiring, and made the code more interesting as well. Whereas last week’s wiring had plenty of extra space left over on the protoboard, this week’s wiring took up an entire additional board with no room to spare. If I had made any mistakes while soldering, they would have been difficult to find and even more difficult to fix. However, by some miracle, it was correct on the first try!

(I’m not super proud of the soldering job, but at least it’s covered up!)

I also replaced the USB cable with a wall power supply, which was able to fit through the small hole I put in the stand. In addition to making the model more presentable, this holds the Arduino in place to make everything more secure. One final step I could have taken was to glue the top half on. However, at this point I’d be too worried about something breaking inside and forcing me to pull the top off by force. The lip I created in the bottom half is sufficient to keep the top in place for now.

Software Challenges

Updating the code was fairly straightforward, since I already had a system in place to support an arbitrary number of LEDs and connections. One challenge here was creating a logical mapping between nodes in the software and the actual pins on the shift register. I hadn’t maintained a fully consistent ordering of LEDs when soldering, and some pins on the shift registers aren’t connected to an LED at all.

Another problem was defining which LEDs would be connected by a virtual synapse. Previously, I defined this manually. However, with 33 LEDs in the final version and a goal of four connections per LED, this would be far too tedious. Luckly, after addressing the problem of logical ordering, I could determine which LEDs were adjacent to a given LED, and create the connections automatically.

Fixing the Shutoff Bug

This week I also had to solve a major issue from last week. While the model worked well for a short time, it would suddenly shut off after a while. I had several theories about the cause of this, which we discussed in class. One theory was that the signal simply died off after becoming too week. I didn’t think this was the case, since all the nodes would shut off at the same time. I believed that it was likely a power issue, since I am using the 5V pin on the Arduino to power all of the LEDs. I was worried that the problem would become even more severe when I added more LEDs.

However, the issue seemed to be unaffected by increasing the LED count from 14 to 33. After a suggestion from Will, I tried printing the actual values I was writing to the LEDs over the serial connection. Sure enough, after about 30 seconds, they would all become zero. Since I’m primarily a programmer, this was a major relief to me, since it meant the problem was in the software, not the wiring. I tried decreasing the activation thresholds and messing with the decay rate, but none of these things made any difference. Eventually I came to the realization that 30 seconds (30,000 milliseconds) is approximately the maximum value of a 16-bit signed integer (2^15 = 32768). It turned out that I was storing the time, in milliseconds, that each node was last activated as a 16 bit signed integer, causing it to reset to a negative value after 30 seconds. I hadn’t caught this because I am used to working in languages such as Java where the type ‘int’ refers to a 32-bit integer, not 16-bit.