Are You Doing Anything Worthwhile If You Don't Fail?
Some Success and Some Failure
We received the board Friday April 22, and we did some preliminary testing. To test, we plugged the arduino into the PCB and ran the multiplexer switching code (which we had already tested). The inputs looked wonderful, when tested one by one on the oscilloscope, so we went on with high fives and high hopes (see Failure for more information on this).
After sitting in the RPL for 6.5hr on Thursday, we finally have a back of our container! It was a glorious moment when it finished until we went to test it (see Failure for more info).
Also under software failures is the implementation of the LCD library. We tried and failed many times over trying to incorporate the LCD library code into our project. Lesson Learned: When working with c and makefiles there are many subtleties. (We also learned a lot about makefiles). Success Post Failure: The LCD code now works and compiles YAY! Note that this happened after an entire day of weeping, gnashing of teeth, and sleeping on the code--almost literally.
We moved to the Leonardo, as I spoke about in the last post. However, after 8 hr of drowning in makefiles and compiler errors on Wednesday April 20, we realized that the UNO had enough pins to suit our needs. Turns out it is not as easy as you might think to write custom compiling code for a new micro controller, and it's even more time consuming trying to figure out I/O. Lesson Learned: It is unwise to move to a more complicated system for the sake of change. If it works, don't try to fix it!
After the six and a half hours of sitting, waiting in the Rapid Prototyping Lab for our child to be fashioned into the world, we tested the back with the board, and it didn't fit. IT DIDN'T FIT. DID NOT. We cried a little before getting some coffee, picking ourselves back up, and delving back into the land of SolidWorks. After Sahithya re-CADed the entire back, she sent me the .dwg file, and I went to the RPL early Saturday morning (April 23rd) to start waiting. This time, I decided to rotate the back 90 degrees to see if it would speed up the laser cutting time at all. TWENTY EIGHT MINUTES later, it was finished. We waiting 6.5 hours for the same piece as took 28 minutes when rotated. Lessons Learned: Always rotate the object being cut to rasterize along the longest axis, and make sure to make the laser cutter cut 1:1 ratio with the .dwg file. Success Post Failure: The back of the container fits on the PCB perfectly now. Yay!
Today, while we were waterproofing the container with the back, we decided to do some more rigorous testing of the code with the board attached. What we found were some very disturbing issues that are completely my fault (sorry Sahithya). Long story short, the schematic that I sent to the board manufacturer was electrically incorrect (see long story long below if you want the details). To fix it, we are having to intervene between the column power pin and the power of the container.
Long Story Long
I got a little too happy with the pull-down resistors in the schematic, and I pulled down the column power pins when they weren't high. Effectively, I am currently sending a 1 through the column when I want it to conduct and a 0 through the column when I don't. Because each row is connected, all columns that are conducting are sending both a 1 and 0 to the arduino at the same time. I'm sending mixed signals if you will. To fix it, I decided to intervene between the power input pin and the column. I need all columns to be in the high Z state when they are not conducting (instead of pulled down to 0) so that whatever signal is going through a row at a given time can go through the entire row without being muddied by the pull down to 0. To achieve this end, I decided to put a tri-state buffer between the power pin and the column, using the previous power pin as the enable for the buffer, so that when it's zero, instead of pulling the entire column to ground, it will place the column in high-Z.