Physical Computing - Week 2 (24-09-10)

Lab Activities

This week's lab covered quite a few subjects:

• How to connect digital inputs and outputs through a microcontroller
• How to utilize code to alter input and output
• Connecting analog sensors with a microcontroller to extract sensor range with code
• Different ways to use sensors and produce interesting output

One yellow LED and one blue LED alternating on and off when switch is closed. Run on an Arduino Nano 33 IoT.

One yellow LED and one blue LED turning on when switch is closed. Run on Arduino Nano 33 IoT.

The first exercise was to wire up two LEDs with a switch and program them to alternate when the switch is on and off (left image above). In effort to understand the code, I changed the LED output to both turn on when the switch is pressed (right image above).

Question: Why does the digital input wire have to go on the ground side of the switch and not the power input side of the switch? If the circuit is effectively a loop, wouldn't the placement of the wire affect the timing of reading rather than the overall functionality of the switch?

There was an optional exercise in the lab to wire a speaker for audible output experience, so I gave that a try. 
At first I simply removed the yellow LED and plugged in the speakers to their respective positive and ground connection points and altered the code, but that did not work. A couple of us got together to troubleshoot by using an example built into the Arduino IDE, during which we established that the speaker works properly and the wiring was not the issue. Next, we turned to troubleshoot the code without removing the LED to have a visual indicator of switch reaction. First we tried turning the speakers on and off with the "noTone()" function when the switch was open and the "tone()" function when the switch was closed. This did not yield any results. We also tried removing "pinMode(8, OUTPUT)" from the setup function, which also did not play the speaker.

It was Nasif who suggested adding a "delay()" function after the "tone()" function, which worked (see video on right when program includes "delay(100);" after the "tone()" functions. This was confusing because another tablemate, Chloe, was able to run the program without the "delay()" function. Our thinking is that perhaps because she is using a 5V Arduino Uno, there is more processing power in the microcontroller, whereas the Ardiuno Nano 33 IoT might need a moment to process the different functions being requested?

Another exercise that I really enjoyed was mapping the force sensitive resistor input readings to the LED's brightness output. There are a lot of interesting things that could be done by manipulating the input value range in relation to the output. This exercise also reminded me a lot of Devan's switch from last week. Beyond pressure and distance based variables, this could extend to the time spent engaging with an interaction (ie, if someone spends more time standing in front of a projection, it becomes clearer, or perhaps output becomes more complex. 

Further Developing the Switch

After Yeseul mentioned last week that my switch was essentially an exposed potentiometer, I decided to leverage this element of my design and make the most out of it. Beyond the LED output, I hoped that the varying input could also produce a ranged audible output.

There were a couple steps that were involved:

1. Solder the wires on the speakers and LED. Last week I struggled a lot to maintain consistent connection with the copper tape, so this had to be done to save a lot of headache down the road.
2. Test out some code to get the speaker and light connected to the switch, which led to a couple discoveries.
   1. The LED does not produce an output as noticeable as the speaker. Although this could be due to the environment, since last week in class, I realized that the light was dimming rather than turning off as the pen reached the end of the labyrinth. 
   2. "Serial.println()" was absolutely pivotal in identifying the viable input range. You can kind of see a little bit of the printed output in the left video below. Also from the video, you'll notice there are some "dead spots" on the copper tape path. The further away from the "origin", or more resistance in the circuit, the less consistent the readings were, and at times there would be no readings at all. So I retapped the labyrinth with new copper tape, which happened to be much more conductive than the last roll of tape, so I reviewed the new readings and updated the input values in the program.
   3. The range of input values in the "map()" function matter. After retapping with new copper tape, my input range was significantly reduced to to 850 - 1024, which caused the program to not print any analog readings. So the "constrain()" function was utilized to limit the sensor value, in hopes to make it more efficient? It worked.

The further you get from the path's "origin" point, the more fluctuation there is in the sound output, which is also reflected in the input value readings. 
Ultimately, this project met the loose project scope definition of "producing a ranged sound output" when there is change in the resistance. The power unclear specifications 🤣 

Self reflection from this week's labs:
It seems that I find inspiration and possibility for a project in the technical information I know, whereas some folks in our cohort start with a potential interaction in mind and seek out the necessary information. I don't think one or the other is necessarily better, but I can't help but wonder if I am limited to the technical knowledge I have? What can I do to think more unconventionally and beyond the scope that I am already within?