The week 5 lab for Physical Computing was on serial duplex, an expansion of last week’s lab on serial communication. This lab took me a long time to complete, I think because of the amount of code there was to understand and replicate.
In this lab, we set up a circuit with two analog inputs and one digital input. I used a FSR, a photocell, and a button. The first step was to simply send and read the data in the serial monitor. We programmed the Arduino to send the data from one sensor in many different formats — including raw binary, ASCII encoded binary, ASCII encoded decimal, hexadecimal, and octal. Here is a picture of my circuit setup and a screenshot of the serial monitor:
Circuit Setup for Week 5 Lab – Serial Duplex
Data in Many Formats
The next step in the lab was to put together the code to send the values of all three inputs instead of just one and figure out which value corresponds to which sensor. This lab covers both the punctuation method and the call-and-response (handshake) method.
Punctuation Method: The first part uses the punctuation method which means that each set of data (in this case, one reading from each of three sensors) ends with a specific type of punctuation to indicate that’s the end, this data set is now complete. We wrote the Arduino code that reads the value from each sensor, prints the sensor value, then prints a comma after the first two sensor readings. For the final sensor, we use Serial.println instead of Serial.print so that we get a carriage return and a linefeed at the end. The result is three numbers separated by commas on each line and we know that the first value corresponds to the analog sensor in A0 (the photocell), the second value corresponds to the analog sensor in A1 (the FSR), and the third value corresponds to the switch. Next we had to write the Processing code to receive and read the values. (Eventually, we’ll use this information to draw a ball and make it move!)
Similar to the first serial communication lab, we have to import Processing’s serial library at the top of the code and make a global variable which will hold the serial port (in my case this is always 4). We add a new line of code in setup: myPort.bufferUntil(‘\n’); This line says wait to call serialEvent until the ASCII newline byte comes into the serial buffer. ’\n’ means “newline” and the ASCII value for that is 10. We get “newline” after the third sensor value has been read (that’s why we used Serial.println) so what this means is that the bytes will be read into the buffer until a linefeed is sent, then serial.Event will be called.
In serial.Event the sensor readings come in and are put in a string, then the string is split at the commas and the values are converted to integers. Then we use a for loop to print out the sensor number and corresponding value. Here’s a screenshot of Processing receiving the information from the sensors:
Processing Reads the Sensors!
What’s exciting is that now we have a bunch of integers that we can use to make something — like a ball that moves around. To do this, we created some variables (xpos and ypos) and then assigned the sensor values to them. (There’s a video at the end of this post.)
Call-and-Response Method: Next, we modified the code (both Arduino and Processing) so that Processing has to request new data when it’s done reading the data it has. For Arduino, we added a method called establishContact() which sends out a message until it gets a byte of data. Here’s a screenshot of the serial monitor after adjusting the code — it prints out “hello” until you type something into the box and hit “send”, at which point the sensor values are returned:
In Processing, we create a new global variable called firstContact. This determines whether or not Arduino has sent anything. Processing will listen until it gets something from Arduino. Once firstContact becomes true, then Processing will split the string at the commas and convert them to integers (just like in the punctuation method) and then print the sensor numbers and values. After this unit of data has been parsed, we tell processing to write to the serial port which sends a request back to the microcontroller asking for more data. And, again, we can use this information to make a ball and move it around. This is a quicktime video of me controlling the ball with the photocell, FSR, and button. The movement is erratic to say the least. SerialDuplex_Wk5Lab_SensorsControlBall_121026
The results of using the punctuation method and the call-and-response method are the same in this lab — the format of the printed values and the movement of the ball look the same. Although the code is complex, and I can’t say that I completely and fully understand it entirely, conceptually, I like the call-and-response method better. Since the two devices are in communication with each other, it makes sense for this to go in both directions. And it seems cleaner to send data one unit at a time when the receiving program is ready rather than just sending information continually and hoping that the receiving program can keep up.