User:Dmoreno1899/ENES100/The Tin Can Band

Link to The Tin Can Band Team page

Give instructor top 3 project choice list
I chose to either continue working on the music project, or:
 * Water Jet Project
 * Illuminate Clothing Project

Write problem statement
Over this period of time, I plan to play a note based on the passing of a magnet through the Hall Effect Probe - in essence, the most basic idea necessary to make an instrument out of the tin can.

Assign Task1
For this next week, I plan to get a single note playing on the keyboard based on the analogRead function, working with the code I worked on with the previous team.

Compare actual work done to Task1
I worked towards getting anything working - in this case, a light to turn on - based on the analogRead. I was met with varying levels of success until a wire on my potentiometer snapped off, and I feel as though my results from testing a code became skewed.

Week1 Narrative
I updated code from my last project to make it a bit easier to adjust. This way I only have to adjust the int sensorThreshold to test different voltage values.

It's obvious just holding an arduino board to my temple isn't nearly an accurate enough way deliver an input for analogRead to interpret. The next logical step before tackling the Hall Effect Probe was to instead use a potentiometer to control the values read by the pin - and instead of having it control a note being played, just turn on the LED in pin 13. My reasoning for this was because of a potential problem that was discussed with the last group: Using certain analog devices require a baud rate of 9600 bits per second (bps), whereas MIDI Protocol requires 31250 bps. I'm only trying to deal with one problem at a time, so I tried to get consistent results with this code first. I went on to study potentiometers.

What I learned about potentiometers and voltage:
 * With the Wikipedia page on Ohms I researched voltage. I found that:
 * P = (V^2)/R
 * Where P is power in Watts, V is voltage, and R is resistance.
 * The potentiometer is used to adjust the resistance, and therefore, the amount of voltage read by the analog pin. Resistance is changed by turning the rod clockwise or counterclockwise.
 * There are three wires on the potentiometer. As far as working them with the arduino is concerned, one wire goes to power supply, another ground, and the third to where you wish power to be supplied to.

The potentiometer I used was actually broken - the wire snapped off the first time I tried to put a wire into an arduino pin. It was soldered back on. In order to solder it back on, one must have a soldering gun/iron, wet sponge, and soldering wire - more detail into the necessary items can be found here. The process of soldering can be fairly complex or simple, depending on the devices used in the process. A detailed explanation for soldering in general can be found here. Once the wire was re-attached, the potentiometer was tested with a multimeter, where it was determined that what I had on hand was a 1 mega-ohm potentiometer.

While looking for the best way to test my potentiometer on the arduino site, I came across a code specifically meant to be used in conjunction with the potentiometer. The code is as follows:

Essentially, what this code does, is it causes the LED on pin 13 to stay lit up, and then turned off, for the value found by the analog pin reading the voltage. It is a very simple way to see how resistance effects the interpreted voltage. My code is similar in this ultimate objective, but goes about it in a different manner; rather, it simply causes the light to turn on once a certain voltage is reached. Initial testing with this code made me realize my potentiometer, as it currently stood, needed one more wire. I found an old broken one, cut off the wire on that, and soldered it on to my potentiometer. I then hooked it up to the arduino and ran this code. My results were as follows:


 * My first time testing different resistances, I noticed a kind of electronic burning smell I've only experienced when trying to put together an old computer. Both the board and potentiometer were fine. The smell disappeared after my first attempt.
 * Turning the pot fully counterclockwise resulted in a dimly lit LED light that was always on, never blinking.
 * Turning the pot fully clockwise resulted in the LED light just being off altogether. Additionally, the power LED would dim and then turn off as well.
 * When turning the potentiometer from fully clockwise to counterclockwise, the light still (generally) blinks at a seemingly constant rate, until a certain threshold is reached approximately 1/3rd of the way to fully counterclockwise, at which point the LED light just remains dim, never blinking, like when it's turned fully counterclockwise.



From this test I have drawn the conclusion that when turned, when turned fully clockwise, all power is being diverted from the arduino into the 5v pin, through the unrestricted potentiometer, and into the analog pin, leaving insufficient power for the power LED pin to be used, meaning that resistance is at its lowest when the potentiometer is rotated fully clockwise. Additionally, after the potentiometer is turned counterclockwise past a certain point, the arduino has difficulty reading the voltage in the analog pin because of how little voltage is getting through the potentiometer, and as a result, the light just dims.

I then tried using my Potentiometer Light Code with the arduino, expecting it to stay off when turned fully counterclockwise. As it was turned clockwise, the LED pin should have turned on, and stayed on. Instead, it just remained off at any given position. When fully clockwise, the power LED turned off again, and when it was turned counterclockwise from this position even just a hair, it would come back on. Additionally, the LED pin would blink rapidly for a short length of time, before remaining off. That blink was consistent, and was for a length of time after the potentiometer was moved - how much it was moved, or where it was moved to, had absolutely no discernible effect on the blinking.

To try and get results more similar to what I expected, I tested several solutions:

'''Note: one wire snapped off while I was trying different combinations. As a result, from here on out, I was only able to test solutions with one wire in the 5v, and one in analog pin 0, and none in grounding.''' The light just continued to stay on, no matter what I did. Fully clockwise and fully counterclockwise did not dim the LED pin, nor did the power LED turn off when turned fully clockwise.
 * Wiring the potentiometer into the arduino differently. I tried several different combinations, but they had no effect.
 * I analyzed my code. I found no reason it would be the problem myself, but a second opinion is something I'm still searching for. Just to try something, I added a delay of 200 milliseconds after the "if" parameters to give the code enough time to reasonable display that the LED is in fact on. This had no effect, so I removed it in all future iterations of testing.


 * I checked that my code was reading the right pin number, and that the wires were in the correct pins - they were.
 * I experimented with different threshold values. I saw no change in the LED pin.
 * 512 - the "halfway" point, or 2.5V
 * 1023 - the "maximum" point, or 5v
 * 1 - the "minimum" point that could still be interpreted with this code, or 0v
 * 736 - an arbitrary value
 * 316 - an arbitrary value
 * 493 - an arbitrary value
 * I tried setting the LED pin to "off" using "digitalWrite(13, LOW);" before any of the if parameters in the void loop. I saw no change in the LED pin, which is strange, because if the analog pin just weren't reading anything, the light should have just been off.

The conclusion I drew was that I would need to re-sodder the wire on that potentiometer before I could continue to test solutions (I do not have the tools necessary at home). What throws me off, however, is the fact that apparently some kind of voltage is being read that causes the LED to turn on, or else the bit of code I threw in to make the default status of the LED pin be "off" would have just kept it off.

Week1 Peer Review
(I have no partners listed on the team page. I am unable to locate the other person in my group)

Assign Task2
Re-solder this wire back on to the potentiometer, and re-test all solutions. From there, work on getting the LED light to work more consistently with the potentiometer, and from there, try to get a note playing based on different voltages.

Compare actual work done to Task2
I didn't re-test the same solutions I came up with previously - new information about the way my potentiometer was constructed revealed why the blinking light code wasn't working. Once fixed, I began examining voltages, resistance, and the way they interact with the arduino while testing example code. Once I found success with that, and was able to predict its behavior, I uploaded my code for arduino interaction with a potentiometer. This was also met with success, so I tried a code that was similar in the way it works (using "if" tests), but instead of causing a light to turn on/off, it plays a note. After working out the problems with that, I then had the code play 3 different notes with the potentiometer - this was met with moderate success.

Week2 Narrative
After speaking with the instructor, I realized my potentiometer, as it was when I received it, had a connection between the middle and top node (red and blue wires). As a result, they essentially acted as one node, and thus skewed the results of my testing last week in a way I hadn't accounted for. I cut this connection with a pair of wire cutters. Additionally, I decided to just cut off the remaining two wires on my potentiometer - one wire was like the one that had snapped off (brittle), and I wasn't sure how much longer it would last, while the other one was fraying and relatively difficult to manage. I snapped these off with wire cutters as well.

I found a "thing" that appeared to be some kind of computer component. The wires were relatively long (~4 in), and the ends were crimped with some kind of metal holding. The ends of them fit perfectly into the arduino pins. I cut a red, green, and blue wire off that, stripped the opposite end of them, and twisted the frayed ends tightly so none were loose. I soldered these three wires to the potentiometer (much better than I did the first time), and they became securely fastened.

The next step was to hook up a digital multimeter to the poteniometer, and analyze the way it would interact with voltage. By hooking up the alligator clips (the multimeter) to two nodes that were not connected yielded a maximum resistance of 1,000,000 ohms - or 1 mega-ohm, which confirmed what was previously found when I first received the potentiometer. By switching the multimeter to read volts, and attaching the alligator clips to the crimped ends of the wires, I found I was able to read the level of voltage going through the potentiometer and into the arduino - essentially being able to see what the voltage reading should be read by the arduino.

I attached the red wire to ground, blue wire to analog input pin #0, and the green wire to 5v, one alligator clip to the green wire, the other to blue. Additionally, I uploaded the "Reading a Potentiometer Sample" code from last week into the arduino. The multimeter read ~5.0v while the light blinked incredibly quickly. This is the opposite of what I expected - when the arduino recognizes a higher voltage, it should have a value close to 1023 from analogRead, which was used in the delay timer, and as such should have a slower blinking rate. Despite this, I found these results to be quite consistent. As I adjusted the resistance with the potentiometer, I found that as voltage increased (up to ~5.0v), so did the rate at which the LED pin blinked. The opposite was true as well, ~0.0v had a (relatively) incredibly slow blinking rate whereas i predicted it would have a fast one. I switched which alligator clip was on which wire to see if I somehow gave the wires an inverse relationship with my apparatus, but the multimeter instead read the same values as they originally did, only they were negative. Because the magnitude of the values were not changed, and I wasn't sure if voltage was even a scalar quantity, I put it back the way I originally had it.



This table displays the general trend of voltage vs blinking rate. When the voltage was 2.0, the resistance wasn't being read properly by the multimeter.

Despite the fact that this wasn't what I originally predicted, this was, generally, what I expected to happen - by using the potentiometer to alter resistances (and therefore the voltage read by the analog pin), I was able to change the rate at which the light blinked. The next step for me was to use a code that I had written instead of being given. I uploaded the "Potentiometer Light" code from last week into the arduino. I had the sensorThreshold at 1023. Only voltage values interpreted as 1023 should turn the light on; originally I thought that would have been 5.0v, but in light of recent events, I changed my prediction to having the light turn on at ~0.0v. I was right, and went on to test this with a different sensor Threshold value (511).

I loaded this into the arduino, and it loaded fine. At ~3.0v the light was off, however, seemingly arbitrarily, the arduino board just powered off as I was writing in my notebook. The multimeter read ~0.0v, and the power LED was off as well as the LED pin. No matter how I changed resistance with the potentiometer, none of the lights would come on, and the multimeter continued to read ~0.0v. I started taking parts off the arduino (the clips and potentiometer) to load just the blinking light code to see if I broke the board, but the moment I took one alligator clip off, the board powered back on. It then behaved accordingly, the LED pin turning off at approximately where I predicted, and turning on in a similar manner (I was unable to look at the voltage, as I decided to leave the multimeter disconnected for a little while). After playing with turning the light on/off for a time, I put the alligator clips back on, and everything resumed working as normal. My theory is that the multimeter was somehow sapping a reserve power from the arduino, but I really have no idea, and no way to test this theory, as I was unable to reproduce this anomaly; the board worked fine from here on out.

From here I decided that, now that I can effectively use the analogRead to alter an output with the arduino, I went to try and use my code from two weeks ago (the original Potentiometer Tone Code). I decided to streamline it a bit, and came up with:

I just tidied up this code by replacing the pin numbers and delay values with integers. Additionally, I changed the delay in both "if" tests to a constant 100 milliseconds. I tried uploading this, and attaching everything together to play notes on the keyboard. I was met by a constant thumping at ~0.1 seconds. The light, however, continued to work the way I expected it to, turning on/off after turning the potentiometer approximately halfway (at this point I didn't have access to a digital multimeter).

Solutions I tested that contributed towards playing proper notes:
 * I just wanted to see if the board and midi shield were working correctly at all - I tried uploading a code that I knew worked with the keyboard (my "Mary Had a Little Lamb" code), and went to see if that still played properly - it did, so I knew the problem was one with my code, and not the hardware
 * I knew that I had the right kind of format for "if" tests in my code because the blinking light test I had just been working on worked fine. However, I wasn't sure if keeping the part of the code that effected the LED pin was creating a problem with the note playing, so I just removed that - it didn't do anything noticeable to the code.
 * I tried changing the timeDelay in the second "if" test, just to see if I could at least augment the rate at which the keyboard was thumping - and I was succesful. After turning the potentiometer ~halfway, I found a difference in the timing of the thumping. However, it did not play a note.
 * I tried removing the "silent" note (the one after the delay with a velocity of 0x00), to no effect.
 * I tried implementing a default "else" block instead of the second "if" test, and removing the note in that else block, instead replacing it with turning the LED light on. After initial testing, I realized I needed to have the light actually turn off in case the "if" test were successful so I could appropriately interpret results. The code appeared as such:


 * It worked as I predicted, the thumping would continue until I turned the potentiometer a certain amount, at which point it would stop and the light would come on. This lead me to believe the problem was in the way the note was being played in the first place.
 * I looked at the values I had inside the noteOn function. Command and pitch were fine, however, I looked at velocity - 0x100 is equal to 256 decimal. The range of midi protocol values is [0, 127] (decimal). 256 is way above that, and never would have worked at all. I tried using a hexadecimal value inside this range - 0x40 (64 decimal) - instead of the 0x100 I had just used in my previous code. It worked wonderfully, the note playing at the rate of the timeDelay value I had set until I turned the potentiometer ~halfway, at which point the note would stop, and the light would turn on.

From this point on I kind of just built my code back up, adding new components that I had either stripped it of in trying to get it to function properly, and adding new ones to try and test how far I could take this.

I tried breaking the analogRead value range [0, 1023] into 3 different segments along the intervals: [0, 341), [341, 682), [682, 1023]. Each interval corresponds to its own different note, and which note is chosen is dependent upon the value that analogRead returns from interpreting the voltage. My end result was this:

This code was met with a moderate amount of success. 3 different notes would in fact play throughout the entire [0, 1023] interval, however they would overlap seemingly random. Further testing into why this occurred is necessary.

Week2 Peer Review
[I still have no listed teammates]

Assign Task3
Resolve the overlapping notes issue. Some ideas to get the ball rolling:
 * Multiple "if" tests are true. Change the intervals to different intervals, and see what happens.
 * Change the notes being played in each interval - they're all the same note on a different octave, so it's difficult to tell which note exactly is playing when. Make it more cacophonous so that it's easier to interpret.
 * Test the three intervals - replace 1 or 2 with a blinking light instead of a note playing.

Compare actual work done to Task3
I took steps towards resolving the overlapping note issue with actual data - I was informed of serial monitor associated with the arduino environment that let's you print values from the arduino to it. I learned the proper way to do this by looking at an example code, and then writing my own test code. From there, I implemented my test code with a compatible version of the potentiometer tone code I wrote in week 2.

Week3 Narrative
After giving a presentation, I was informed of what is called a "serial monitor". It's a way to, with proper coding, look at the actual values specified in the arduino (like the sensorValue I've been using so often). It was my belief that, if I could actually see those values in real time, I'd be able to look at what the arduino was actually producing, and what it should be producing (say it's playing note A when I think it should be playing note B), and would be able to more precisely view any problems.

I looked through the example codes provided for the arduino, and came across the one for use in conjunction with an accelerometer. It used within it, something called "Serial.print", and I was told this had something to do with printing values to the serial monitor. This made sense, so I searched for the function on the arduino site, and found this code:

What this code does is it just has a loop of values, ascending from 0 to 63, and prints those values in decimal, hexadecimal, octal, binary, and as a raw byte value. Essentially all of these are useless for my purposes except for decimal, but it's handy information to know that I can print them as things other than decimal.

The way it works is it prints the "titles" ("No Format", "Dec", "Hex", "Oct", "Byte") in a single row, spacing them with a tab ("\t"). The last line for "Byte" uses "Serial.printin", which essentially does the exact same thing as "Serial.print", except, among other things (which are useless for my purposes), creates a new row, ensuring that all values that follow are now on the second row. It then creates a conditional loop with the "for" statement, which just causes the values go from 0 to 63 in ascending order, and the code lists the values in their respective formats (decimal, hexadecimal, etc), creating a new line after the byte value is displayed. Once all 64 values have been displayed, the conditional loop ends, the void loop ends, and the process repeats.

Note: viewing the serial monitor requires setting a baud rate of 9600, meaning it can't be used in conjunction with the MIDI protocol with any of the arduino boards I currently have access to. However, an arduino mega board would sidestep this issue by allowing me to set multiple baud rates.

Wanting to better learn the format, I wrote my own code to be used in conjunction with a potentiometer:



I used "Serial.print("\n")" instead of "Serial.printin" simply because everything else that comes with Serial.printin is unnecessary. What this code does is it reads the analog pin 0 for a voltage with analogRead, assigns it a value in the range of [0, 1023], and then prints that value in the serial monitor at a rate of two values printed every second. This means that I can see the analog read values in what is essentially real time. I wanted to test this, so I hooked the potentiometer up to the arduino and loaded the code.

It worked as intended initially - values would change as I changed the resistance with the potentiometer, though I came across some complications. They, along with some basic properties, are listed below:
 * Fully clockwise yields a value of 1023, consistently
 * Fully counterclockwise yields a value of 0, consistently
 * Turning the potentiometer clockwise from fully counterclockwise will still result in values of 0 for a time; at approximately 1/3 of the way turned, it starts returning positive integers that ascend proportionally as it's turned clockwise. I refer to this point as the resistance threshold. A multimeter should be used to analyze why this occurs, but it is consistent, and therefore easy to account for.
 * Initial testing of these values resulted in a seemingly random spike as I turned it counterclockwise from fully clockwise. As it descended from 1023, it would randomly spike up to 1023 and stay there as I turned the pot (when I would otherwise expect a value of, for example, 780 that is descending). My ability to reproduce this was inconsistent, though it was more likely to happen when I turned the potentiometer counterclockwise rapidly.
 * Occasionally turning the pot fully counterclockwise resulted in values no longer being returned in the serial monitor (it would just stop), and an error code from the arduino environment. It wouldn't un-"freeze" itself unless I re-uploaded the code altogether. Just closing and then re-opening the serial monitor was insufficient. This error was generally inconsistent, but was more likely to happen when I turned the potentiometer to fully counterclockwise rapidly.

My method of finding solutions to these problems were, originally, just trying to reproduce the errors, both the one that caused the random spike to 1023, and the "freezing" error. My results were sporadic and inconsistent, and googling the error yielded nothing useful. However, I was writing in my notebook while the potentiometer was fully counterclockwise, consistently producing a value of 0. I accidentally knocked it and the arduino off the desk, and I saw that I got the freezing error had occured. This led me to believe perhaps the error was a hardware one, and when I went to pick it up, I noticed the green and blue wires (which go to the 5v and ground pin in the arduino, respectively), where exposed, were touching. I knew from my understanding that this wouldn't lead to anything good, and that due to the way they were soldered, it would be all too easy for them to touch without me noticing.

I turned the potentiometer fully clockwise (where it should yield a value of 1023), and reset the code. I turned it counterclockwise (very slowly), and the values began to descend, I touched the two wires together, and suddenly they would read only 1023, no matter how I turned the potentiometer. The moment I let go they returned to whatever value they should have been. I tried this below the resistance threshold, and it would still read 1023 when the wires touched. However, most importantly, I turned the potentiometer fully counterclockwise and touched the wires - immediately I was given the "freezing" error. I tested this a few times with the same exact result, but I was afraid of somehow doing damage to the arduino board if I kept it up.

So most importantly I learned to make sure that the ground and 5v wires don't touch where they're exposed, and it'll be fine. Additionally, my sensorValues will return 0 for multiple resistances with this potentiometer.

With this new information, I wanted to test my code for playing a note with the potentiometer. This was however impossible with an arduino duemilanove, and will be until I can get an arduino mega, but I could write a code that is similar, and essentially does the same thing with a blinking light instead of playing a note. So what I wrote was:

This code behaves similar to the code I wrote last week, the only difference is that instead of playing a note, it causes the LED light to blink at different rates. Additionally, it accounts for the fact that sensorValue will be equal to 0 for a relatively large section of values, and lets me see the actual values for it in the serial monitor.

Week3 Peer Review
[I still have no teammates listed on the Tin Can Band team page]

Assign Task4
There are several small tasks that must be done before being able to proceed:
 * Test the Potentiometer Interval Code
 * Analyze the Potentiometer Interval Code with a digital multimeter
 * If I have an arduino mega board by next week, replace a blinking light with playing a note in the Potentiometer Interval Code, and analyze those sensorValues
 * Begin research on the Hall Effect Probe