Saturday, March 1, 2008

Lab 5 - Serial Output/Processing

So the good news is my camera's new, and even without knowing much about it it still takes better shots. Things kind of go downhill from there.

Unlike in the example, I used a photocell and pot as my two analog ins with my digital in switch. I'm starting to understand more fluidly the reason for scaling/ranging, it sometimes outputs a more stable or controllable range of data. My first send through pin 0 (the pot) emitted DEC values of around 227-228, while the 2nd time I tried a BYTE modifier in the code and my values were more รก and "beta".
















I was ready to try sending serial communication using multiple modifiers. My results? In tabbed columns:
Aplha-Beta (BYTE/ASCII) 11100010-11 (BIN) 226-227 (DEC) E2-E3 (HEX) 342-343 (OCT)



Clearly, Arduino and serial i/o are communicating. When I sent BIN values for all 3 sensors, I got my continuous feed of A's until I entered a character, and in the serial monitor I received a 3-ASCII char response. Then I tried it with DEC variables and it spit back 0-255 values in response to the pot, plus values of 100 (off) and 255 (on) when I clicked the digital switch.



So why wouldn't Processing run my program properly when all other communications were verified? I can tell you I checked many factors over and over again, and checked with many people including my professor, students and PhysComp grads on the floor. I could have perhaps used a multimeter to check voltages across the circuit, but other tests ascertained it was not a hardware problem but a code one in nature. Having never seen the Processing environment before (I am not in ITP and haven't taken ICM), I can tell you the code was different enough to make things difficult to debug alone, but I picked up a few tips from others along the way, including writing in println statements at each step to ensure messages were being received. We did deduce that somehow color messages (supposedly controlled by the digital switch) were not being sent - or were sent only as pure black, rendering visibility impossible on a black background - so we changed that part of the code to a constant white value. Good, at least it's on the screen.



And it stayed mostly upper left thereafter, at first with a lot of jostling back and forth which meant control with the pot wasn't smooth and obvious, until some extra tweaks like ridding the code of tabs in the printout, which slowed the ball down considerably. But at least some tangible result was reached. I owe my newest ITP floor buddy Kristen a lot in helping me understand Processing better, so I will take this as a "whatever doesn't kill you makes you stronger" moment. Thanks, Kristen!

No comments: