Projects 'n Such

This class essentially instructed us how to use C scripting and programming techniques in general to create and interpret works of art, as well as allow greater control for the artist to guide the user's experience and challenge them in new ways.



Envy from James McMahon on Vimeo.

Screen capture of me using program I made to ideally tell an illustrated story and anthropomorphic parable of envy based on the user's physical position as sensed by the computer's iSight camera. Was able to get basics to work, though transition was choppy and uneven, so I uploaded this version which looks much better, where I was able to figure out how to change and blend image based on horizontal position of mouse. Illustrations are by me, and project was programmed using C and Xcode IDE. For Pixel-by-Pixel class, ITP, NYU, 2008.




X-Ray of Ugly from James McMahon on Vimeo.

Screen capture of me testing a project that requires the user to be in a certain position in front of the computer's iSight camera to line up their face and move the mouse across the captured video to "reveal" the monster beneath. Really, I just wanted a way to make every single person on the planet look ugly and malformed. Created using C, in Xcode IDE. The illustration is cover art for Iron Maiden's "Purgatory" release, created by Derek Riggs. For Pixel-by-Pixel class, ITP, NYU, 2008.

Posted by Jimmy at 10:51 PM | Permalink | Comments (0) | TrackBacks (0)

Hi, I'm Jim, and this is my Massively Multi-User Media blog, full of pictures showcasing the strange, deranged, warped and totally mundane activities of Second Life, along with some embarrassingly simple scripting.

Midterm/Final Concept

My midterm and final concept will be a hybrid obstacle course/king-of-the-hill contest. The game will take place high up in the air, which also allows the opportunity to determine the effects, if any, vertigo has on players as they race, balance and compete against one another (a curiosity of mine). Both physics and normal code statuses will be used to convey the challenges to players.

Essentially, players will make their way through stages of an obstacle course and meet one another at the end, where they will be forced to eliminate one another via means which at this time are still conjectural (push guns, perhaps) to determine a champion. Said shining hero ideally will be rewarded with rather large and copius amounts of billboards surrounding the course, proclaiming their gaming greatness to the virtual world, as well as scorekeeping and anything I can conjure before Finals.

The obstacle course will have three pathways, one for each player. Each course will be identical in the construction and execution of its elements, and each pathway will be split into three sections (or two, if my current scripting progress continues).

The three sections include:

- The "gauntlet" section, where players will face a series of objects attempting to knock them off the platform to a horrible, screaming non-death miles below. The "plank" the players will walk on to move forward will be a slightly elongated sphere, to mess with players' sense of balance, and the plank will be semi-transparent to highlight the faux sense of risky heights. So far, the gauntlet objects are multiple walls with differing movement and avatar-sized holes, which will move horizontally at a right angle to a players' forward progress.

- The "platform" section, where players engage in a bit of platform-jumping reminiscent of the old days of gaming, using 2L's "jump" ability, with different timing and motion attached to each platform object to force caution and timing considerations on players, lest their dreams of death-defying bravado disintegrate horribly at the 2L equivalent of 9.8 m/s.

- The "wall" section, whereby players attempt to "climb" up a wall to get to the top. In this case, "climb" refers to jumping onto precariously placed ledges sticking out from the wall's base, which forces balance and again, a decent command of jump-timing to reach the top and avoid the humiliation of watching one's avatar display the unusually amusing default "fall" animation of 2L.

The king-of-the-hill element comes into play, as mentioned earlier, when players have completed the obstacle course and have met one another at the top. What happens after that is still academic, and will be fleshed out once I finish the obstacle course (concentrating on both at once would most certainly cause great gnashing of teeth, and lead to irredeemable madness on my part).

Some pics of my progress:

Obstacle Course pic 1



Obstacle Course pic 2



Obstacle Course pic 3



Obstacle Course pic 4



Obstacle Course pic 5



Obstacle Course pic 6



Obstacle Course pic 7



Obstacle Course pic 8


Unfortunately, this is where things go askew. My code, which was working fine without any problems, now suddenly has a syntax error at line 35, 4. I don't know how to fix this (or why this occured in the first place), and I feel I should before I can place decent scripts on other platforms, build on previous code, and begin to understand what the hell I'm doing in LSL.

My evil, mischievous code:

integer count;

default
{
state_entry()
{
llSay(0, "Get moving, mofo");
// turn on physics
llSetStatus(STATUS_PHYSICS, TRUE);
llSetTimerEvent(0); //disable timer
count == 0; // zero count
llSetTimerEvent(1); //enable one second timer event
state moveRight;
}
}

state moveRight
{
state_entry()
{
float FORCE_MAGNITUDE = 1; // essentially how fast to fly
vector FORCE_DIRECTION = <0,-1,0>; // which direction to fly in

llSay(0, "moveRight");
llSetBuoyancy(1);
llSetForce(FORCE_DIRECTION * FORCE_MAGNITUDE * llGetMass(), TRUE);
}

touch_start(integer total_number)
{
llSay(0, "Stop all");
llSetTimerEvent(0); //disable timer
// clear the force by setting it to a 0 magnitude vector
llSetForce(<0,0,0>, TRUE);

timer () // run this code every time the timer event is raised
{
count ++; //increment count
if(count > 10) // reset after 10 secs
{
float FORCE_MAGNITUDE = 1; // essentially how fast to fly
vector FORCE_DIRECTION = <0,1,0>;

llSay(0, "Stop moveRight");
llSetForce(FORCE_DIRECTION * FORCE_MAGNITUDE * llGetMass(), TRUE);
state moveLeft;
}
}
}

state moveLeft
{
state_entry()
{
float FORCE_MAGNITUDE = 1; // essentially how fast to fly
vector FORCE_DIRECTION = <0,1,0>; // which direction to fly in

llSay(0, "moveLeft");
llSetBuoyancy(1);
llSetForce(FORCE_DIRECTION * FORCE_MAGNITUDE * llGetMass(), TRUE);
}

touch_start(integer total_number)
{
llSay(0, "Stop all");
llSetTimerEvent(0); //disable timer
// clear the force by setting it to a 0 magnitude vector
llSetForce(<0,0,0>, TRUE);
}

timer () // run this code every time the timer event is raised
{
count ++; //increment count
if(count > 10) // reset after 10 secs
{
float FORCE_MAGNITUDE = 1; // essentially how fast to fly
vector FORCE_DIRECTION = <0,-1,0>;

llSay(0, "Stop moveLeft");
llSetForce(FORCE_DIRECTION * FORCE_MAGNITUDE * llGetMass(), TRUE);
state moveRight;
}
}
}

Next is to work on getting the objects to recognize only avatars and upon contact, do their part to make their lives miserable (after I figure out how to get my walls to move correctly). After I fix the problems and get a little more hang of the code, there should be a snowball effect in terms of constructing the course, as each component will be built from pieces of old physics code and examples, and I will hopefully create and maintain something that doesn't so closely resemble a huge embarrassment failure :)

Class 5

Here is my LSL code for week 5, enabling environment detection and subsequent interaction. Mostly, it's just code example 1 and 3 combined and altered a bit for more interesting conversation, while still performing the basic
requirements of environment detection and interaction. In this case, detecting an avatar, relaying its velocity, and moving 3 paces upon contact/collision with an avatar, with appropriate textual response from object directed to avatar concerning object's displeasure with experiencing contact from anything other than itself. Yes, my object is a bit of a jerk. Enjoy!



Week Five Coding Mod Pic


Code:

//James McMahon
//Massively Multi-User Media - Class 5

integer TELEPORT_RANGE= 3; // this defines the maximum range our object can teleport on the x or y axis

float randomRange(float min, float max) {

float range = max - min; // find the range of numbers that need to be generated
float random_number = llFrand(range); // find the random number in the range we just calculated
return random_number + min; // and return the random number offset by the minimum value

}

default{ //start the script(after declaring variables)

state_entry() { //first "state" code

llOwnerSay("Waiting for something to smack into me");
}

collision_start(integer num_detected) {
//once the object has detected something, run through list of objects detected
integer i = 0;
for(i=0;i //find out and say name of detached object
string object_name = llDetectedName(i);
llOwnerSay("Aw, crap, I just detected an object named "+ object_name);
//find out and say the velocity of the detected object
vector object_velocity = llDetectedVel(i);
llOwnerSay("Its velocity is coming on fast at " + (string) object_velocity);
}

// find out the name of the first person who collided with you so you can complain about being stepped on
llOwnerSay("Damn! "+llDetectedName(0) + ", that hurt, you clumsy-ass bully. I'm outta here before you steal my lunch money and dunk my head in a toilet, too...");

// find out where you currently are
vector my_position = llGetPos();

// figure out a random offset to move the object by. We're not moving in the z direction so we don't end up floating off
vector offset = ;

//note: object can end up swallowed by landscape as it moves; for example, my object will keep
//teleporting until it walks (with the same y position) into a hill, and the only thing peaking out is
//its head. This isn't because there is no Z value, rather, it seems to be that teleporting makes an
//object fall outside parameters that conform on object to the landscape?
//add the offset to your current position position and use vector desired_position = my_position + offset;

// move to the new position
llSetPos(desired_position);
}
}

Class 4

Here are some examples of basic texturing with my models in 2L. First, the double-sword I made (multiple screenshots for a better look at the textures):


Sword Pic 1



Sword Pic 2



Sword Pic 3



Sword Pic 4


The handle is textured with a rug, the white blade is a transparent smoke texture, and the blue blade is a water texture. Secondly, here's my one pic (didn't really need any more) of my Stay Puft Marshmallow Man:


Stay Puft Pic 1


I used a white transparency, messed with the alpha a bit, and ultimately overlayed a blue transparency as the texture.

Tune in next week for more hilarious hijinx when I try my hand at more coding and scripting! Until then, be safe, be sound, and don't rape anyone in cyberspace.

Class 3

Here is the result of my ultra-simple code as I make my first foray into the wonderful and exciting world of LSL scripting. The joy. The excitement. Here is a picture of the result (mainly just an in-game chat conversation example):

Week 3 Example

Behold my programming prowess in action...

Class 2

Here is my first 3D model in Second Life. Having worked with Maya and Blender, I find this system to be irritating, to say the least. Why Linden Labs felt they had to be different and unique from other established 3D-software programs is beyond me, as the interface is not that intuitive. That's just me though, as I enjoy complaining about trivial things (gives me a rush).

Model 1

The Stay Puft Marshmallow Man! Made from...wood. Texturing comes later, dammit.

Class 1/Miscellaneous

What follows are interesting places, views, objects, etc. that I ran across while chilling in Second Life.

"The first interesting place" I came across in 2L...

Silent Hill 2


...followed by my first experience with a griefer! I thought this one was particularly amusing (and surprisingly well-done)...

Jell-Owned!


Here is some scenery I enjoyed...


Whale Riding


As you can now probably tell, my avatar has undergone some cosmetic surgery, from being a humanoid fox-like animal known as a "furrie" (aka generic stock avatar), to something more befitting my admittedly warped and odd sense of humor. In these pics, my virtual alter-ego, drunk off his virtual ass (notice the bottle of Bud), is enjoying various sights around the world...


Chilling On Rustic Missiles



Kitty Riding



Sublime Art Appreciation (Drunk) 1



Sublime Art Appreciation (Drunk) 2



True Artistic Modeling

Posted by Jimmy at 05:23 PM | Permalink | Comments (0) | TrackBacks (0)

Hi, I'm Jim McMahon, and this is my documentation for my The Epiphany Machine physical computing final project. I've broken down this pleasant foray into mechanical madness according to six (6) sections. They are as follows:

1. Concept drawing and controller key
2. Content and general project explanation/description
3. Pseudo-code and general plan-of-attack for completing project
4. Construction and building process pictures
5. Troubleshooting log
6. Conclusion/Sources Cited

Before I begin to lay out for you a tale of tortuous, tenacious technicality, I must inundate you with a brief explanation as to my motives behind the project, and why I wish to see this particular choice through to completion. I graduated from Ohio University with a major in Interactive Multimedia and a minor in English, and while I get plenty of chances to put my multimedia skills to practical use in this program, the constant concocting of correct coding in my classes leaves me yearning for some good 'ol fashioned English and creative writing.

The idea for this came as I was meeting with my physical computing instructor, and attempting to figure out what to do for my final project. As I had no ideas, she simply asked what I liked, and writing being one of them, I decided to see what could come about from the suggestion. My instructor and I chatted about a possible word-changing controller, and I decided to run with the idea as far as my embarrassingly small, bow-legged PComp legs could carry it.

As such, displayed for your viewing pleasure below is an image of the general concept of which I was thinking. Colors in the final incarnation may vary (see also: "I'm using wood, dammit").

1. Concept Drawing and Controller Key

2. Content and General Project Explanation/Description

The main idea behind this thing is to generate, via hands-on manipulation, a creative writing exercise on-the-fly. One exercise I did in college included writing random favorite words from all members of the class onto the blackboard, and subsequently giving the students free reign to write whatever they liked, as long as they forced those words somewhere into their story. Different results followed, from minimalist poetry using only the suggested words and few others, to long, epic (if not bloated) narratives that had no chance of being completed in the 50 minutes of class time we were alotted.

The idea here is a similar one; I'm aiming to allow for options of building sentences input by input, or perhaps having static sentence structure and allowing for variable components of said sentence, much like a mad lib. This will work by serial communication between the Arduino Microcontroller, the Arduino code environment, and the Processing IDE, which will display the results of all that future twisting, turning and pushing in the form of sentences and phrases, or whatever form the user wishes from their choices.

A sample list of words (chosen by me) will respond when variable data is received. For example,

Nouns - brain, turtle, ninja
Verbs - caroom, vomit, fall
Adjectives - contagious, frappish, monomaniacal
Etc...

The construction of unexpected sentences has always helped me hurdle creative dumbfoundery, and a tactile approach will hopefully get the brain thinking in a slightly different way. Ideally this will lead to literary trysts into an imaginitive stratosphere, screaming inky divinity from the end of a ballpoint pen, and enable those modern progeny of Atlas to cast off thy hunched 'n bunched shoulders the soul-crushing weight of writer's block into the briny sea of worthless bombastic bullcrap metaphors.

3. Pseudo-Code and General Plan-of-Attack for Completing Project

I intend to base my initial progress off the Lab 5 - Serial Communication lecture and notes, and to start by making sure all software is correctly installed, as previously I had been missing the drivers in Arduino when I downloaded to my computer.

After this will be a confirmation check to examine if all my equipment is ready by completing the first couple labs, which also will serve to refresh my memory on certain basics.

I will then start the serial communication lab, and attempt to understand how the code works so that I may manipulate certain parameters and areas of the Processing code to better visually illustrate my concept idea.

I will need to revisit how to most effectively use string arrays for my project, so that the words can be displayed on the screen instead of just at "println." I will have to figure out how to map certain physical actions (such as button pushing or pot twisting) to actions in Processing, and to think about how to possibly design such an interface for effective display and usability.

I will then build the prototype for the project, which will definately not look even remotely close to the concept idea, but will instead be an amalgamation of wires, wood, and metal pieces.

Finally, user-testing and cross-platform compatibility will commence, and I hopefully will have the project finished to an acceptable state.

Interface (Processing) pseudo-code

Allow user (for now) to construct his/her own sentence on-the-fly. Basically, whichever potentiometer or pushbutton the user tweaks or presses becomes the next word in the sentence, and while tweaking or pressing the buttons, the screen will show the user cycling through words in a pre-determined (by me) list in real-time, and those words each will be mapped according to a numerical equivalency for accurate mapping.

If any other pot other than the one currently active is activated, move behind last word/string (maybe 10 px from width) and begin cycling through list of verbs, nouns, adjectives, or whatever the user chooses to continue tweaking.

If button is pressed, cycle once through list next word/string. If string is "(this)," change all words/values/strings to matching parameters of the selected.

Design interface should be simple and not very visually cluttered or prominent in any way so as to be distracting for user. Black background will be erasable, by assigning the background command once in setup and once in a key, mouse or serial event. Text will be light gray (#CCCCCC) to mute effect of stark black/white color contrast to eyes constantly fixed on it, and to disallow the "I'm Burning This Damn Text Into My Retinas As Afterimages! The Pain! I Can't Stop Looking At the Words Green Eggs and Ham! Oh Why Did I Peruse Dr. Seuss While Taking a Bathroom Deuce and Then Start Typing Green Eggs and Ham-Related Poetry To My Laptop?!" Effect.

Include "return"-type button which skips to next line and starts at leftmost position on line, which allows for greater freedom with experimentation (e.g. poetry), and enforces left-alignment, which is the common form. Ideally, this project would eventually progress to the point where I could create the option for tabs or spaces or total object alignment, for those who prefer their text centered.

In future, perhaps map A, B, C, etc. on the controller buttons to increase gameplay dynamic, and include suggested "templates" for experimentation with guaranteed somewhat grammatically-feasible results; like in video game codebooks, for example:

"EABDCA," where:

Declarative Article = E, Noun = A, Verb = B, Pronoun = D, Adjective = C, and Noun = A, which could conceivably, as an example, be interpreted on the screen as:

the cheeseburger kicked my voluptuous donkey

*Still curious what effect introducing color to the controller will bring on information-retention methods...

Thoughts on Concious Decisions

The interface for this project's interactivity is relatively simple for many concious decisions, described below:

1. Black background always seems (to me) less intimidating than white space; perhaps because there's an unconcious association to the memory of writer's block or something. Also, it seems more conducive to daydreams and fantasies, which hopefully will speed up "writing epiphany" process.

2. Gray text won't burn itself into your retinas like white, and thus allow for a longer endurance period for your eye to focus correctly on screen.

3. Minimalistic design theme between black background and gray text that seems to work, despite being a bit (purposefully) dull.

4. No punctuation eliminates the distracting tendencies to incessantly tweak grammar, which distracts users from concentrating on the words themselves and their properties. Grammatical structuring should occur later as a secondary result to what they created on the screen with the controller.

5. Limited choice of words prevents the time-consuming, train-of-thought-derailing habit of searching endlessly for the Right Word to perfectly express a feeling or thought. In itself, that's a great thing, but not while in the middle of completing content in a sentence and attempting to awash yourself in your own stream-of-conciousness thinking.

6. Using a tactile approach will hopefully perform a better job of:

a) forcing the user to interpret phrases, sentences, meaning and punctuation,
b) allowing writers of multiple skill sets a method to drop the creative writer's block and rekindle the creative fire, which might seep back into their intended work,
c) engaging the more mechanically-inclined and hands-on learners to allow them to better understand and perhaps appreciate the craft and spark a curiousity to practice themselves,
d) teaching those learning the language, be it young children, handicapped, or international people some basics of communication in English,
e) allowing more concrete mental associations between controller action and screen (basic elements of gameplay),
f) encouraging careful attention to sentence structure, especially if I use "difficulty" choices of words ranging from "common usage" to "hard/unique/complicated/jargon"-type scales.

Below are pics of interface design with the same text content:

[ignoring the RETURN-key option and interacting regularly]

[using RETURN-key option for structural experimentation; in this case, poetry]

4. Construction and Building Process Pictures

Here are some iSight pictures I saved from Processing allowing a visual record of what I've been attempting so far...

These first three pictures are of the layout of my breadboard, currently configured for and awaiting completion of Lab 5 before getting anywhere else.

Here are pics of my tools and tacklebox, with freshly soldered potentiometers and switches all ready to go and awaiting my command.

Here is the computer screen, feebly (in this light) showing my Processing code and Arduino and Terminal windows in the background.

Finally, a true hallmark of any stressful, hair follicle-endangering project:

That's right, Chinese take-out from the 'hood, along with a copy of Firefly to allow confident reassertion of my nerdliness.

These are updated pics of the Epiphany Machine breadboard configuration and layout, while I was trying to figure out what the hell was wrong with the code (again).

Hopefully, I can re-configure this mess of wires for a better looking and "functioning" prototype.

Here is a better looking series of photos about the prototype of the project, though I miscalculated how to include the potentiometer with the buttons, and I just didn't have time to do the necessary arduous and time-consuming task of calculations and measurements that inevitably come from such a "simple" process as poking holes in the foam-core and expecting everything to fall into place (I probably should have laid out a detailed battle plan before engaging in this, but I was too preoccupied trying to figure out why in the name of all that is Holy my code still won't work). This is the final looksie.

Troubleshooting Log

This is the section of my documentation whereby I cry and whine and bitch and moan about why in the hell various parts of my project aren't working. At this point, it's the reason why I'm not further along and anywhere close to where I want to be.

- Had problems with Analog In/Out lab; apparantly PCs are configured wrong in their port setup or whatever. Carlyn helped; looking forward to working on a computer that doesn't annoy the crap out of me, or suck an unnecessary 4 hours out of my life trying to figure out what went wrong.

- Had problems with Serial Communication Lab 5, in the form of not being able to get the Terminal to communicate the way it's supposed to; was advised in class to double-check and make sure I installed correct drivers on my computer. Did so and problem ceased.

- Had problems attempting to figure out what was broadly wrong with Serial Communication Lab 5, as I still cannot get it to work. Sample of e-mail to instructor:

"I know that my breadboard is
wired correctly, because I'm getting values for my two pots and my one
pushbutton in the Terminal, each of which change accordingly when I
twist either of the two pots or push the button. In essence, the
Arduino code seems to be working fine.

The Processing example code, therefore, is the problem. It doesn't work
when I straight copy-and-paste it into the program. It doesn't work
when I change the "port = new Serial(this, Serial.list()[0], 9600);"
command by replacing the "[0]" after "Serial.list()" with any other
number, although 0 and 1 will make the screen black, and 2 and 3 result in:

RXTX uucp_lock() /var/lock/LK.001.009.002 is there
gnu.io.PortInUseException: Unknown Application

java.lang.RuntimeException: Error inside Serial.()
at processing.serial.Serial.errorMessage(Serial.java:575)
at processing.serial.Serial.(Serial.java:148)
at processing.serial.Serial.(Serial.java:102)
at Temporary_7088_1670.setup(Temporary_7088_1670.java:26)
at processing.core.PApplet.handleDisplay(PApplet.java:1237)
at processing.core.PGraphics.requestDisplay(PGraphics.java:568)
at processing.core.PApplet.run(PApplet.java:1406)
at java.lang.Thread.run(Thread.java:613)

These are the listings of my ports:

Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
/dev/tty.modem
/dev/cu.modem
/dev/tty.usbserial-A1000ewV
/dev/cu.usbserial-A1000ewV

Is the port in use by some other program and blocking what I'm trying to
send? This has happened while I had the Terminal up and running, as
well as when the Terminal hadn't been activated after restart. My port
should correspond to number 2, according to the logic of the directions,
but all that happens is a blank applet, not doing or showing anything
but gray. I can force the ball to appear by not linking its color to a
variable, but it won't move at all, despite my sending a capital A to
begin serial commincation; I typed capital A in the terminal, as well as
when the applet is active."

Later, I was able to considerably narrow the problem with help from my housemate, who is a programmer. An example of a revised e-mail:

"we were able to narrow
the problem down to a single line of code in the "setup" area:

port = new Serial(this, Serial.list()[2], 9600);

Most of that line seems to work except the "this" parent Papplet
parameter. The complete code is below (with a bunch of "println"
commands for extra debugging testing), and the result is displayed in
the error log area at the bottom of the Processing window. The applet
generated was of a blank screen, mainly because the program encountered
the error before "draw." Throughout this entire process, Arduino was
running the required code, and the Terminal program was open and running.

//Processing Code

import processing.serial.*;

int bgcolor; // Background color
int fgcolor; // Fill color
Serial port; // The serial port
int[] serialInArray = new int[3]; // Where we'll put what we receive
int serialCount = 0; // A count of how many bytes we receive
int xpos, ypos; // Starting position of the ball
boolean firstContact = false; // Whether we've heard from the
microcontroller

void setup() {
size(256, 256); // Stage size
noStroke(); // No border on the next thing drawn

// Set the starting position of the ball (middle of the stage)
xpos = width/2;
ypos = height/2;

// Print a list of the serial ports, for debugging purposes:
println(Serial.list());
println("port 2 = " + Serial.list()[2]);
println("this=" + this);

// I know that the first port in the serial list on my mac
// is always my Keyspan adaptor, so I open Serial.list()[0].
// On Windows machines, this generally opens COM1.
// Open whatever port is the one you're using.
port = new Serial(this, Serial.list()[2], 9600);
println("1");
port.write(65); // Send a capital A to start the microcontroller
sending
println("2");
}

void draw() {
background(bgcolor);
fill(fgcolor);
// Draw the shape
ellipse(xpos, ypos, 20, 20);
println("xpos=" + xpos + ", ypos=" + ypos);

// If no serial data has beAeen received, send again until we get some.
// (in case you tend to start Processing before you start your
// external device):
if (firstContact == false) {
delay(300);
port.write(65);
}
}

void serialEvent(Serial port) {

println("se: port=" + port);
// if this is the first byte received,
// take note of that fact:
if (firstContact == false) {
firstContact = true;
}
// Add the latest byte from the serial port to array:
serialInArray[serialCount] = port.read();
serialCount++;

// If we have 3 bytes:
if (serialCount > 2 ) {
xpos = serialInArray[0];
ypos = serialInArray[1];
fgcolor = serialInArray[2];

// print the values (for debugging purposes only):
println(xpos + "\t" + ypos + "\t" + fgcolor);

// Send a capital A to request new sensor readings:
port.write(65);
// Reset serialCount:
serialCount = 0;
}
}

//This is what I get in the bottom window after hitting the Play button:

Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version = RXTX-2.1-7
/dev/tty.modem
/dev/cu.modem
/dev/tty.usbserial-A1000ewV
/dev/cu.usbserial-A1000ewV
port 2 = /dev/tty.usbserial-A1000ewV
this=Temporary_1274_4015[panel0,0,22,256x256,layout=java.awt.FlowLayout]//Is
there something here that's causing the problem? -Jim

RXTX Warning: Removing stale lock file. /var/lock/LK.001.009.002
gnu.io.PortInUseException: Unknown Application

java.lang.RuntimeException: Error inside Serial.()
at processing.serial.Serial.errorMessage(Serial.java:575)
at processing.serial.Serial.(Serial.java:148)
at processing.serial.Serial.(Serial.java:102)
at Temporary_1274_4015.setup(Temporary_1274_4015.java:28)
at processing.core.PApplet.handleDisplay(PApplet.java:1237)
at processing.core.PGraphics.requestDisplay(PGraphics.java:568)
at processing.core.PApplet.run(PApplet.java:1406)
at java.lang.Thread.run(Thread.java:613)

My housemate kept asking if there was a source code to look at, which
had something to do with serial initialization. I'm not exactly sure
what he's talking about, but maybe that can explain the problem I'm
having a bit better. In essence, my pot twisting and button pushing is
not being picked up by Processing, and that very basic condition needs
to work before I can go any further."

And this is where I am irredeemingly, irrefutably, incomprehensibly stuck the f*ck in a mucky rut. I can't get anywhere from here, as my basic condition has not been met, despite all attempts to remedy the situation. I'm despondent, and reeling still from the heinous blast of shattered self-confidence and melancholic mourning for a victory that should have been...

Nevermind...

Apparantly the problem was my brain operating on different logic than the directions assumed. I literally did almost everything under the sun to get that damn code to work, and I found out all I had to do was quit Arduino and the Mac Terminal program and just run the Processing code. I had thought it fundamentally important to have at least two programs talking to each other during serial communication, which is technically right, BUT those two programs must be the Arduino Microcontroller itself and some kind of IDE (or Terminal) open and running the required serial recognizable code. Having two programs attempting to control the port is impossible and so I needed to actually kill the other programs. This seems such a basic mistake, but to be perfectly honest, I worked my ass off to figure this out (insert vague, caveman-like grunting sound as emphasis).

12.10.06

After my (ahem) epiphany(!) concerning the need to quit Arduino before uploading code, I ran into another wall, which was basically programming my code in an efficient and generally operable manner with the added features to my breadboard configuration. I met with my instructor, and she rewrote the lab to work with serial communication and send what I needed to get my Processing code to begin working. Unfortunately...

PROBLEM: The Processing code does not work correctly. I came to this conclusion after testing the Arduino code and finding that it sent the correct values for the correct things, as shown below:

In the above example, the first three numbers are the potentiometer values, and the 6 digits that appear after each correspond to one pushbutton (which is wired to the breadboard). The Arduino code works fine. After I upload this and test it, I then will stop the code, quit Arduino, and start up Processing, and to choose the PDE file from "open sketchbook" menu. I run the code, and nothing happens except:

All it does is show a black background and print the serial port list. Nothing else, even when called to println, happens. What you saw is what I got.

As a result of my ineptitude to get this code to work, I've tried all manner of troubleshooting the code, but the problem is that I can't identify specifically what is wrong enough to know what to do or where to look to fix it. I know where the problem resides:

void serialEvent(Serial port) {
// if this is the first byte received,
// take note of that fact:
if (firstContact == false) {
firstContact = true;
}
// Add the latest byte from the serial port to array:
serialInArray[serialCount] = port.read();
serialCount++;

// If we have 7 bytes:
if (serialCount > 6 ) {
int eraVar = serialInArray[0];
println("EraVar:" + eraVar);

for (int i = 1; i < 7; i ++) {

int num = serialInArray[i];

// print the values (for debugging purposes only):
//println(xpos + "\t" + ypos + "\t" + fgcolor);

switch(num) {
case 0:
println("Switch" + i + "Is not pressed"); // Does not execute
break;
case 1:
println("Noun"); // Prints "Noun"
break;
case 2:
println("Verb"); // Prints "Verb"
break;
case 3:
println("Adjective"); // Prints "Adjective"
break;
case 4:
println("Adverb"); // Prints "Adverb"
break;
case 5:
println("Reset"); // Prints "Reset"
break;
case 6:
println("LineBreak"); // Prints "LineBreak"
break;
}
}
}

// Send a capital A to request new sensor readings:
port.write(65);
// Reset serialCount:
serialCount = 0;
}

The serialEvent() seems to be the culprit of what's wrong, but I have no idea where at in the code to figure it out. I've tried moving around placements of nested statements, like moving the " for (int i = 1; i < 7; i ++) {"-command and everything in it to the same level as the preceding "if (serialCount > 6 ) {"-command, which allows the "eraVar" to print repeatedly, and "println("Switch" + i + "Is not pressed");"-command to print as well. The problem with that, though, is my computer freezes everytime I do it (even the CAPS lock light won't go out if it's on), and I have to do a hard restart every time, which I'm loathe to do.

I guess what I need to know is if there's a way to slow down serialEvent() from printing so fast so I can experiment without a crashing computer, and in general to get interaction between the button-pushing and potentiometer twisting. There's a value, "48," which seems to be the default value of the potentiometer that's being transmitted or interpreted when I test for such, which also is a strange problem...Processing doesn't seem to be reading the correct values being sent. What the f*ck is going on?

6. Conclusion/Sources Cited

My conclusion thus far is a somewhat limited one, as I was only able to progress so far without the use of actual serial communication between Processing and Arduino, the point of my project. I believe that given enough time, I could make an interesting little device that might help some people break out of a momentary creative block, which was really all I was hoping for, though my eternal impatience with PComp would probably win out over my desire to see the project through to its fullest. If I've learned anything from this Great Experiment, it would have to be a markedly improved ability to debug Processing, as well as get a sense of what is "probably" going wrong in any given application I tend to run. I've learned a bit about serial, too; pretty much everything I need to know up until the actual communication-with-Processing part.

What follows are my sources and those whom I cite throughout my work...

Notes:

- Physical Computing, ITP 2006 Fall semester, instructed by Carlyn Maw
- Physical Computing, by Dan O'Sullivan and Tom Igoe, Thompson Course Technology, MA. 2004.
- Classmates' online notes and journals, at:
"http://itp.nyu.edu/~cm1002/Fall2006/pComp/index.php?n=Notes.Class" and
"http://itp.nyu.edu/~cm1002/Fall2006/pComp/index.php?n=Notes.Journals"
- Various pages of ITP's Physical Computing web directory:
"http://itp.nyu.edu/physcomp/"
- Arduino and Processing reference libraries, environments, and tools:
"http://www.arduino.cc/" - Arduino homepage
"http://www.processing.org/" - Processing homepage

Consulting/Extra Help:

- Carlyn Maw, my Physical Computing Instructor
- My housemates Ron and Kyle (don't know their last names)
- Felipe Ribeiro, and various other student and teacher input from ITP
- Anyone or anything I forgot (always inevitable)

Thank you for visiting my documentation page. Perhaps someday this device will appear, as if out of the blue, on a newspaper's front page (or page 8) declaring a temporary cure for creative ills, as I am left standing alone in a puddle of questionable liquid in a Subway car, riding off to who knows where and briefly reading over the shoulder of some poor soul who wants nothing but an assurance that I won't rob him this night, if he'll only just let me read a little further the realization of a rough blueprint from long ago.

Thanks again for all those who helped me throughout this semester. I cannot describe how much I appreciate your patience and support.

James (Jim) Franklin McMahon VIII - ITP Fall '06, Class of 2008.

Posted by Jimmy at 03:32 AM | Permalink | Comments (0) | TrackBacks (0)

This is a screen shot of a modified version of the Serial lab from week 5. At the moment, I'm attempting to understand how serial communication works in a more detailed manner, and am trying to complete a few basic steps such as getting specific words to the screen and figuring out what kind of layout and interface would best suit my needs.

Also, just getting the damn code to work every time is a challenge in itself...

Posted by Jimmy at 11:30 AM | Permalink | Comments (0) | TrackBacks (0)

I've taken this project beyond ICM (Introduction to Computational Media) class to a 2-credit programming workshop course. I was interested in getting this to work as well as I could, as it is the first video game I've ever made, and I like the idea of making a decent version of Dots 'n Boxes, of which I haven't found very many.

Programming Help Code Studio page - Below is my section from the Code Studio ITP webpage that includes my objectives and how I plan to complete them:

o Idea: Reasonable closure for my ICM project, "Dots and Boxes," as well as any forward progress that can be made towards my PComp serial communication project, "The Epiphany Machine."

o Week 1 Objective - To refamiliarize myself with both projects, and to document the problems of each which have stifled my forward progress and made me sad, so very sad. Such knowledge will help in communicating the exact nature of the problem for discussion in next week's class and to obtain more efficient and working code, until such time that I slam with a bone-jarring thud straight into the next programming wall, which will be outlined below shortly...

o Week 2 Objective - ...and which is the fact that I cannot figure out what is wrong with my text-entry operation. I want actions to perform once someone submits text, i.e. their name as they typed it, and it actually shows the hell up, which is the precursor to another operation involving typing initials which get recorded and then displayed on boxes whenever a player scores. I want to try to fix this problem so I can move forward with the next phase of my evil operation, which includes...

o Week 3 Objective - ...fixing the same damn problem I had last week. This week, it gets SOLVED (much like getting served, but with a certain intellectual-smackdown quality to it). Basically, I want to allow a rudimentary two-player game, which allows for different mousebutton clicks to lay objects down on a grid by each player, key waiters which allow switching between boxes and connectors for each player, and basic characteristics (different colors, shapes, etc.) which will distinguish UI and gameplay elements between players...

o Week 4 Objective - ...and this week, to do some cleanup work on issues that, last week, invariably were waiting to rear their ugly, pustulating and pox-filled heads. These include actually manipulating text box parameters, adding a second text box for Player Two, and correctly mapping initials to boxes (and getting those initials to appear correctly), which should lead right into...

o Week 5 Objective - ...trying to find the memory hog! Yay! It's like a game for masochists, which slows down my progress and makes me impotently shake my fist at the screen, as if hurling geriatric epithets to those damn kids who just egged my house again. Also, I'd like to figure out how to hide my text boxes and buttons, and to essentially create the interface for the start of the game (i.e. create a darkened screen with on-screen instructions to enter your initials, hit the button, and switch to the regular game-playing mode, to begin the epic battle 'twixt you and your foe)...

o Week 6 Objective - ...which will hopefully free up the chance to get this thing working as a self-contained program able to played and downloaded over the internet. Before all that, I'd like to fix any of the previous problems still relentlessly pouring forth their illogical filth unabated. Concerning the networking, I first would like to figure out where to start on this terrifying venture, and to begin completing the necessary steps to realize this objective...

o Week 7 Objective - ...which, despite jumping the gun here, should continue unabated by previous woes, though I won't rule out constant occurances of figuring out 1) what the hell is wrong with this, 2) why the shit that won't work, and 3) how the f*ck do I do this, seriously, I'm ready to punch myself in the face until I'm pleasantly numb and cannot feel the vertigo of plunging self-esteem because this code won't work AAAARRRRRRGGGGGGGHHHHHHHHH. Or, something to that effect. AN ASIDE: The Epiphany Machine, discussed originally as a possible improvement project, will probably fade into the annals of my deteriorating memory as a useless and one-time foray into Physical Computing, though perhaps, one day in the future, my innate tendency for mental S&M will emerge and I will try to finish the project (out of spite, certainly).

Updated 10/8/2006:

Processing Code:

(Dots and Boxes Tab)

//Dots and Boxes
//By Jim McMahon

PFont regNameFont;
int numX = 15; //how many grid circles across
int numY = 20;

things[] mythings = new things[numX*numY]; /* This is an array of "things" (called "mythings"), which are of class "things" (the class which describes
characteristics these "things" have together*/

int w = 480; //Width of grid area in pixels
int h = 630;

int spacex = w/numX; //spacing between grid circles
int spacey = h/numY;

color lightGray = 150; //One choice of color

int player1NumSquares = 1; //This will increment itself by one (to keep score)
int player2NumSquares = 1;

void setup() // Do all this just once.
{
regNameFont = loadFont("Zapfino-18.vlw");

size(510,750); //size of our battlefield
smooth(); //Anti-alias, mofo'

int gridcx = 0; //Keep in mind that the dependant "class" uses these variables.
int gridcy = 0;
int c = 0;

while(gridcx < numX)
{
while(gridcy < numY)
{
mythings[c] = new things(30+gridcx*spacex,30+gridcy*spacey); //Out of the "mythings" array/basket, pick out "c" number of "things" (which
gridcy++; //have coordinates of "x" and "y," which are defined above and change below).
c++; // Increment "c" by one each time ("c" = itself plus one).
}
gridcy = 0; // Changes y position of background circles.
gridcx++; // Changing this changes spacing between background circles.
}
}

void draw() // Draw this shit repeatedly.
{
background(255); // draws white background
fill(150);
textFont(regNameFont);

textAlign(LEFT);
text("Player One...",30,670);
textAlign(LEFT);
text("Player Two...",30,720);

for (int i = 0; i < mythings.length; i++)
{
/* Apparantly, these conditions above and below (the "for" and "if" loops) are set up as "if myThings isn't a bogus
command, then trip the "if" command, which says "hey bitch, draw whatever's in "void drawThings()" (located
in the class).*/
if (mythings[i] != null)
{
mythings[i].drawThings();
}
}
keyPressed();
mouseOver();
}

void mouseOver()
{

int cindex = 0;
mythings[cindex].con1 = false;
mythings[cindex].con2 = false;

for (int i = 0; i < mythings.length; i++)
{
if (abs(dist(mythings[cindex].gridcx,mythings[cindex].gridcy,mouseX,mouseY)) > abs(dist(mythings[i].gridcx,mythings[i].gridcy,mouseX,mouseY)))
{ /*if the Absolute Value of the Distance between the
*/
cindex = i;
}

}
}

void mousePressed() //Draw shit when mouse is clicked.
{

int cindex = 0;
for (int i = 0; i < mythings.length; i++)
{
if (abs(dist(mythings[cindex].gridcx,mythings[cindex].gridcy,mouseX,mouseY)) > abs(dist(mythings[i].gridcx,mythings[i].gridcy,mouseX,mouseY)))
{
cindex = i;
}
}

if(key == 's' || key == 'S')
{
mythings[cindex].con1 = true; //horizontal connector
}

if(key == 'a' || key == 'A')
{
mythings[cindex].con2 = true; //vertical connector
}

if(key == 'd' || key == 'D')
{
mythings[cindex].con3 = true;
if(mythings[cindex].con3 = true)
{
println("Player 1 score: " + player1NumSquares);
player1NumSquares++;
}
}

if(key == 'k' || key == 'K')
{
mythings[cindex].con1 = true;
}

if(key == 'j' || key == 'J')
{
mythings[cindex].con2 = true;
}

if(key == 'l' || key == 'L')
{
mythings[cindex].con4 = true;
if(mythings[cindex].con4 = true)
{
println("Player 2 score: " + player2NumSquares);
player2NumSquares++;
}
}
}

void keyPressed() // Draw shit when pressing certain keys.
{
/*
//Player 1 Controls

if(key == 'a' || key == 'A')
{ //if you press the "a" key, draw a vertical line that moves with the mouse
stroke(25,25,25,115);
strokeWeight(3);
line(mouseX,mouseY,mouseX,(mouseY+30));
}

if(key == 's' || key == 'S')
{ //if you press the "s" key, draw a vertical line that moves with the mouse
stroke(25,25,25,115);
strokeWeight(3);
line((mouseX),mouseY,(mouseX+30),mouseY);
}
*/
if(key == 'd' || key == 'D')
{ //if you press the "d" key, draw a box that moves with the mouse
noStroke();
fill(lightGray);
rectMode(CORNER);
rect(mouseX,mouseY,spacex-15,spacey-15);
noFill();
}
/*
//Player 2 Controls

if(key == 'j' || key == 'J')
{ //if you press the "a" key, draw a vertical line that moves with the mouse
stroke(25,25,25,115);
strokeWeight(3);
line(mouseX,mouseY,mouseX,(mouseY+30));
}

if(key == 'k' || key == 'K')
{ //if you press the "s" key, draw a vertical line that moves with the mouse
stroke(25,25,25,115);
strokeWeight(3);
line((mouseX),mouseY,(mouseX+30),mouseY);
}
*/
if(key == 'l' || key == 'L')
{ //if you press the "d" key, draw a vertical box that moves with the mouse
noStroke();
fill(lightGray);
rectMode(CORNER);
rect(mouseX,mouseY,spacex-15,spacey-15);
noFill();
}
}

/*
int g = 0;
int h = 0;
int m = 0;
int n = 0;

Here, whenever you click the mouse, you're changing con1 (connector 1) to "true" (which activates con1 code),
and telling the program, through the use of that damn-ass "mythings" array, to draw con1 (connector 1) at the specified
area on the grid.

The area on which the connector is drawn is dependant upon the integer's value it uses, where multiples of 10 are
displayed on top of grid, and anything somewhere below. Instead of counting left to right on the grid, you should
count from top-to-bottom, then move one column left and count top-to-bottom, and so on.*/

//mythings[g].con1 = true;
//mythings[h].con2 = true;
//mythings[m].con3 = true;
//mythings[n].con4 = true;
//g++; //This causes con1 (connector 1) to be drawn at the next array position; g++ or whatever you call it besides "g"
//basically means "draw at a certain place, represented by (array #) 8 (or 9, or wherever the fuck you want the
//position), AND THEN increment the array number by one so it draws at the next position, represented by the
//previous array number plus one."
//h++;

(Class "things" Tab)

class things
{
int gridcx, gridcy; // position of me // seems to be just variables that depend on global definition
boolean con1 = false; // defines if I should draw connector
boolean con2 = false; // defines if I should draw other connector
boolean con3 = false;
boolean con4 = false; //see bottom

things(int _gridcx, int _gridcy)
{
gridcx = _gridcx; // This is passed into a set "class variable" near top of code.
gridcy = _gridcy;
}

void drawThings() { // Drawing number of "connector" (aka con1 and con2)//And setting up the "drawThings"

color lightGray = 150;
//int gridcx = 30; //starting x position of grid circle/point
//int gridcy = 30; //starting y position of grid circle/point
int gridcdiam = 5; //diameter of grid circle
int spacex = w/numX; //spacing between grid circles
int spacey = h/numY;

noStroke();
ellipseMode(CORNER); // function to begin with, as well as drawing those grid circles in the background.
fill(lightGray);
ellipse(gridcx,gridcy,gridcdiam,gridcdiam); // This is a drawing of just one ellipse that appears in the background, starting at (0,0), and which

if (con1) { // gets called a bunch of times by the array things.
// Do the drawing for connector 1.
//(horizontal)
stroke(25,25,25,100);
strokeWeight(3);
line(gridcx+5,gridcy+3,gridcx+35,gridcy+3);
noFill();
noStroke();

}
if (con2)
{
// Do the drawing for connector 2.
//(vertical)
stroke(25,25,25,100);
strokeWeight(3);
line(gridcx+3,gridcy+3,gridcx+3,gridcy+35);
noFill();
noStroke();
}

if (con3)
{ //this is your victory box. Everybody dance now! Everybody dance NOW.
noStroke();
fill(lightGray);
rectMode(CORNER);
rect(gridcx+2,gridcy+2,spacex+2,spacey+2);

smooth();
fill(150);
textFont(regNameFont);
textAlign(RIGHT);
text("..." + abs(player1NumSquares-1),480,670);

noFill();
}

if (con4)
{ //this is your victory box. Everybody dance now! Everybody dance NOW.
noStroke();
fill(lightGray);
rectMode(CORNER);
rect(gridcx+2,gridcy+2,spacex+2,spacey+2);

smooth();
fill(150);
textFont(regNameFont);
textAlign(RIGHT);
text("..." + abs(player2NumSquares-1),480,720);

noFill();
}
}
}




/*if (con3) { old con3 and 4)
//vertical line moved 30 spaces from con2
stroke(25,25,25,100);
strokeWeight(3);
line(gridcx+35,gridcy+3,gridcx+35,(gridcy+3)+30);
noFill();
noStroke();
}
if (con4) { //this is your victory box. Everybody dance now! Everybody dance NOW.

stroke(0,0,0,175);
fill(lightGray);
rectMode(CORNER);
rect(gridcx+2,gridcy+2,spacex-15,spacey-15);
noFill();

}*/

The basic idea for my final is to continue working on the dots and boxes game, fixing and improving different aspects of the project to improve aesthetics, performance, function, and to hopefully enable peer-to-peer communication via server/client relationships across the internet. I want to accomplish a simple two-way communication before I tackle the internet issue. See below:

This is where I am at the moment:

Some examples of changes I intend to implement in the game include:

- Placing text on actual gameboard/grid to keep score and display players' names
- Allow players to type in their initials, which attach to specific players' boxes, and to type in their names instead of being called "Player One/Two," as seen in this example:

- Allow for different-sized gameboard/grids so players can choose how "big" they want their game, as seen below:

- Attempt to allow players the choice of different background/dot/boxes/bar colors, and to possibly incorporate images into it (such as bones instead of bars, or baseballs instead of dots?); see below:

- Provide small sample of sound effects in game (perhaps some satisfying clicking-type noise when bars are laid down on grid, etc.) and have the option to turn said effects on or off
- Get rid of mouse cursor while inside grid
- Perhaps design some sort of logo or decoration for game in lower right corner

MATERIALS: Processing, image-editing programs (Photoshop, Illustrator, etc.), java coding environment, web browsers, freakishly unhealthy amounts of caffeine

Such is my goal, that which you have just read. It seems daunting and scary to me, but hopefully should be accomplished to my satisfaction. In the future, I'd like to provide game mechanic options, such as forcing boxes to close by opposing player if previous player makes a third bar, or to force a player to wait until the other has gone before they can take their turn.

In strange late-night hallucinatory states, I have dreamt of enabling some sort of video capture and playback to allow the background of the game to be an active video capture of the opponent's face, but I think the option of trash-talking your opponent (admittedly what I was thinking of when this epiphany occurred) would be better achieved through the use of some kind of Instant Messaging system complimenting the game. Other thoughts include the option of allowing the computer to randomly slap down a bunch of bars in random areas, to speed up typical slow first halves of games and allow player's to test their skills in random situations.

This, in essence, is my final project for ICM. The board is set. The pieces are moving...

Posted by Jimmy at 10:55 AM | Permalink | Comments (0) | TrackBacks (0)

PComp Lab 1

/home/jfm360/public_html/blog
[Pic of 1st circuit]
[pic of voltimeter]
questions:

1) Is the regulator that we pulled out of Jim’s bag a 5V regulator?

[pic of 5V] Yes

2) We measured the voltage across the switch at 3.37 at the 20V setting. This means that when open (off), the switch had 3.37 volts across. When closed (on), the voltage dropped to 0. If the multimer is in parallel with the switch, then why would the voltage drop? Wouldn’t only the current drop? Our understanding of the circuit is that the voltage stays constant across the circuit - at the point where the led touches ground, there should still be 5V running through, albeit at a near zero current.

3) We get two different readings: from the outside of the switch to ground, we get 5V (as expected). From the outside of the switch to the inside of the switch (ie “across” the switch) we get 3.37. Shouldn’t the full 5V be read across the switch?
[pics 5 v outside, close, 3v across, 3vclose]

4) The math behind the circuit: If the voltage is capped at 5V b/c of the regulator, and we know the resistor is 220 Ohms, then we should be able to calculate the current being pulled across the LED.

Voltage = Current X Resistance
V = IR
5=X220
X = .0227 Amps

22.7mA

Is this correct?

Circuit: LED’s in Series

We got 2.6 V across each LED, which is roughly 50% above their rated capacity. Hmm… makes me wonder at what voltage they would actually stop functioning. Let’s not find out.

3 LED’s in series?

Prediction: will NOT light up, as their cumulative voltage is 5.1, more than the 5V regulator allows.

Test: Yup (pic)

Circuit: LED’s in Parallel

Maybe it’s because we don’t a switch wired into this circuit, and therefore our LED’s have spent a considerable about of time with wll more than 1.7V flowing through them, but the fact is that we are getting a very high reading for milliamps across the LEDs – almost 70! What gives? Are we doing it wrong? We have one needle contacting the leading edge of one LED (connected to the circuit), and the other needle is touching the leading edge of another LED (not connected to the circuit). Both LED’s have their back pin connected to the circuit.

5. Generating a Variable Voltage with a Potentiometer

Just making sure we understand exactly the mechanics behind the potentiometer, we decided to take one apart. It helps to actually see the prongs moving away from the power, looking at the physical distance the electricity has to travel on the graphite (?) disc.
[pic pot deconstruct]

We get an easy to control variable Voltage reading that peaks at 3.36V. Is this because out of 5V available, 1.7 is taken by the LED, leaving 3.3V? Does that mean that the resistor does not affect the voltage, ONLY the current? Hmmm…

Posted by Jimmy at 09:46 PM | Permalink | Comments (0) | TrackBacks (0)