Dull Days - Computational Sculpture Project SY2024 - Particle Argon - Lane Tech PCL

For this year's ever-popular, ever-prestigious, all-important joint PCL-Sculpture Computational Sculpture Project, the theme was "Poison." This was, in large part, because everyone thought it was funny. In this project's case, "Poison" was interpreted as "Media Overexposure," an endeavor I was artistically aided in by one Thom Ruschke. Flashing lights ahead.

Supplies

Breadboard
Particle Argon
Standard Servo
3-long Individually Addressable LED Strip
5V 2A Wall Wart/Connector
Patience

Step 1: Retrieving Data

For this project, I used the polygon finance API to retrieve yesterday's data for Netflix stock. I made a webhook through the particle environment that would only retrieve the open and close prices, then took the difference between them and, through some light arithmetic, turned it into a percentage I used to control the frequency of light and motion in the piece.

Step 2: High School Mathematics and Its Consequences; Or: a Box Full of Trig

All the necessary math is contained within myHandler, which is called once a day (more specifically, on startup and every 24 hours thereafter). Upon calling myHandler, the difference between the open and close values retrieved is calculated. For managing the timings, this number is multiplied by 0.1 then added to 1; This new number (stored as coef) is then multiplied by 400 (the base delay time I chose) the output of which is used in the delay statements in loop(). In terms of basic functionality, that's all you really need to know. If you want a peek inside the black box, though, read on. For managing the light colors, the difference is also multiplied by 0.1 then is put through three trig functions: inverse sine for the red value, inverse cosine for the green value, and inverse tangent for the blue value. Trig functions normally take an angle and return a ratio of sides. Inverse trig functions do the opposite. The concept of sides and angles here is not really relevant: I chose to use the inverse trig functions because they give a wide(r) range of results from small variances in the input value, whereas standard trig functions do not (because angles, on a radian scale, go from 0 to roughly 6.5, while side ratios are oftentimes less than 1 (which diff often is). These inverse trig functions are bounded differently, with their minimum and maximum output values not corresponding to the full range of possible angles (0 to 360 in degrees, 0 to ~6.5 in radians) and not being the same between them. Thus, when the outputs from the inverse trig functions are mapped to the 0 to 255 scale RGB values use, the specified minimum and maximum values vary (and they're nasty approximate decimals because of pi to boot), in order to allow for all possible RGB values (in theory at least). These values are used for one of the three lights, and are flipped (by mapping them on a scale from 255 to 0) and used for the other two lights. What fun.

Step 3: The Normal Part of the Code

After that small but nonetheless frightening quantity of math, all that's left is to actually make the project work. (Un?)Surprisingly, this is not that complicated. We've got a strip of three LEDs (individually addressable) and one servo. The lights blink between the inner one and the outer two based on the delay calculated in the last step, and the servo rotates back and forth every 2 blink cycles (so 4x the delay).

Step 4: Nothing Ever Works

I had this whole thing up and running before I left for spring break. Worked (mostly) fine, but when I came back my servo had mysteriously burnt out. So I had to replace it, and in the process learned that I needed to connect the whole thing to a wall outlet. How annoying. After some stressful near-deadline rewiring, however, the whole thing worked flawlessly.