Then I had to pick up the pieces of me ruining the means of controlling the fan stack. I didn’t want to go back to the car battery solution as it had reacted so violently. I then set about using the back ups Alan had suggested. I plugged in one of the split laptop chargers. To my dismay then knob no longer seemed to work. I then felt like all the work of the last night had been for nought. I was in a bad place at this point and was again losing time unfairly and unnecessarily in my eyes. What fuelled feelings of anger and helplessness was that I didn’t know how Alans car battery circuit worked, and I’d had to take it asunder when moving the stacks the previous day. I had taken a picture on my iphone but it hadn’t saved as can occasionally happen with the camera app I have. I also had no idea what damage I had done when I overloaded the car battery charger

I tried each of the back ups in turn and then found one which did gradually adjust the fan speed. So I now knew I hadn’t fried the fan control. I took apart the car battery to see if a fuse had blown. Nothing there. The more time I had from the earlier shock the more I began to think about the problem logically and systematically. I then measured the voltage going across the working fan power back up and then plucked up the courage to measure the crocodile clips. I found a similar voltage passing through each of them. However clipping the crocodiles to the loose wire accomplished nothing, yet I noted that the full voltage was going through the clips. I then plucked up further courage to return to the circuit, as it was the only part of the system which I hadn’t reintroduced. I found that one capacitor hadn’t blown. Holding the exploded capacitors in my hand and thinking again about what I’d done wrong I realised I’d gotten the polarity wrong on the capacitors. With one left working I was able to bring the car battery and our stacks back into the installation after nearly 3 hours of thinking our tangibilisation method was dead in the water.

My attention then moved to getting things set up appropriately so that I could test my polished scripts from the night before. There was also an interim period where I couldn’t get the arduino working with my laptop. Graham had arrived at this point and I mentioned the debacle of the morning and also that I hadn’t had a chance to do the circuit dropping the voltage of the fan. He again reiterated how easy it would be.

I put some wires into the holes of the fan as per Grahams instruction, and could see that a voltage could be read easily enough. I sat down with Graham, he cautioned that I can’t just stick wires into the fan power like that, that I need to make sure to be careful.

Later as me and Graham sat discussing some element of the stupidly complex project/contraption I’d found myself in charge of, specifically RE the fan and measuring it (with the wires in the fan) the fan stopped working. Dead, no movement. I looked in disbelief, Graham just instructed me to reboot. Then the bigger problems started. The computer would boot on first press of the button, and even when it did the fan wasn’t working. Grahams initial stance at this point was that my recklessness with the wires was the cause (something I do take umbrage with as it was emphasised by both Graham and Alan how easy it would be, a simple matter of inserting wires and neither emphasised this as a possible dangerous outcome [also Grahams later remarks about the sheer bad luck and inexplicability of the fan stopping makes me think that he doesn’t know why it happened at all]). I rushed to lab to get replacement fans, but none worked. I then pulled out the fan to measure the voltage across it (it was necessary to put a fan atop the heatsink as the CPU temp was near 70c on boot alone – prob due to stage lights). The voltage across the fan was non existent, with Grahams aid I deduced that it came to 2.54 volts with fan control running at 0PWM and 0.01 at 254 PWM. This is similar to the inverted voltage on the other fan slot on the motherboard. However no fan could be powered by the pins. Meaning that the conceptual link, and primary means of linking the code to the physical, was gone.

Graham was excellent from here on out, though he admonished me for not having a back up computer (something I even knew was stupid to go without, but it was a necessity of time management – Graham later described this as production values, if you do an installation with tech you have to have a duplicate of everything), and not having it is the only thing I’d say he marks against us. We brought computers from the lab. The first wouldn’t work with the monitor we had. I brought a monitor from the lab and put the hard disk of the non fan computer into this computer. Everything was going well (sensors up and running and everything) and then it transpired that there were no PWM sensors on that motherboard. We went back to the lab and brought all the remaining motherboards and PCs to the theatre. For a brief while our exploded computer installation idea became a reality out of pragmatic need to get the video cards to fit on the motherboard (same bus, different chassis) . But we couldn’t get this computer to boot.

Basically defeat conceded we set about writing arduino communication code into the server client that will take input from one arduino and then drive the motor of the fan control arduino. I’m hoping to trace a conceptual link back in via driving a cpu fan from the stack and still maintaining the link between voice and cpu performance.

Grahams approach to the arduino code was many degrees more elegant than the route I opted for

Good moments to emerge from today: Graham mentioning that he felt that he wished that the course was two years long as he felt he had a lot left to teach me, and suggested that a remedy to that would be to find ways to ensure that we work together in the future.

He thinks our project is conceptually very strong.

Kester and Renees dad talking sense into me when I bemoaned our tutors not telling us that our project was too ambitious. They right pointed out that working with ambition and beyond a comfort zone means you learn more.

Working with Lisa has been detrimental in that respect in that I’ve felt pressured to have an end product as opposed to a research learning project by virtue of her leanings. That I collaborated with her in order to get a handle on how to work to a deadline is the trade off ultimately.

Through trying and failing I’ve learned a lot about production values, the necessity of better time awareness on such projects, and also an acute awareness of where I need to build strength in terms of paring back the complexity of a project to where its essential kernel remains and it is feasible.

Grahams solutions involved acquiring some meccano. This didn’t provide the fix we’d hoped for (we were aiming for the old ridged metal meccano wheels) but it did suggest solutions via more robust rubber bands and a giant rubber wheel which provided a greater resolution of turns for the fan knob.

However all of the day was taken up sorting out this problem which I hoped would be resolved by the afternoon. And a lot of our time in the space was occupied by curatorial trivialities which I regarded as unnecessary distractions (but with retrospect I can appreciate they were necessities which I had neglected to factor into my time management, or appreciation of the amount of time which would have to be devoted to ancillary tasks). Lisa was in a bad way today so it was my turn to hold it together for the pair of us.

Graham offered a solution of a cardboard tube to convey the vibrations of the fan, which I really liked but I knew Lisa wouldn’t be keen and I wished Graham had happened upon this notion earlier rather than us getting enmeshed in Alans solution (plenty of tension between Alan and Graham’s differing methods today)

I worked late into the night getting the calibration as right as possible. I also superglued the wheel which provided a makeshift fix.

The good news is that the relays can fire for very short bursts (10 in arduino seconds).

The bad news is that the rubber band method of turning the gears is inconsistent at best. This is most likely down to the rubber band, but could equally be due to one of the relays firing at a lower voltage. This inexactness basically throws a spanner into all the means we had of relaying one to one voltage to fan noise ratios.

Early days of Fan Control Contraption from Stephen Fortune on Vimeo.

I’m sure interesting observations could be made about the intrusion of noise into the system, but I’m far too tired to give a fuck about that

I may need to file down the switch knob, make it more gear like

I mocked up motor_test in the arduino to get an idea of how well the rubber band was working. The ease of writing the code shows to me that I am finally thinking in the code logic (I know which loops and structures to use automatically now)

Also Alan still has to show me how to measure the voltage across a CPU fan (by phone or text) and I have to re-jig several pieces of server code

A silver lining materialized. Due to the necessity of pushing back to Sunday morning Namjo can’t make it, meaning we can just run through one section of the puja.

Further instances of how we are profaning a religious system can today; angela pointed out that Lisas humming/singing of the chenrezig under her breath was inappropriate as it was in the wrong context.

Alan hadn’t gotten the motor operational, but he advised that I could test the circuit independent of the actual rig up by using potentiometers as surrogate sources of voltage. I dunno why this didn’t occur to me yesterday, especially in light of my propensity and fondness of using potentiometers to test every arduino script to date.

In an example of how far my knowledge of rudimentary circuit board wiring has progressed I got a circuit up and running in a snap.

Actually having the script working on a pseudo voltage generator was very instructive to highlighting potential issues with how the manner in which the server slows down the fan will translate to the tangibilisation for the participants.

With this up and running I tinkered the script, using the map function to translate the 0 – 1023 to 0 117 (map can’t map decimal places so 117 equals 11.7 volts)

Within Lisa’s data the values can oscillate wildly, i.e. its not always low to high to low. Values can jump from 17 to 102 to 81 to 5. This means that having the arduino detect the voltage of the output fans is the only way that the motor can be used in an effective mapping of vocal voltage to fan output.

Also something which I had regarded as a potential irritation in arduino physical output, the fact that the fans spike to 11.8 volts when a transition is executed by my crude script, can actually be used as a trigger for the arduino script to begin adjusting the output fans to match the input fans

<I also uncovered a problem with a fancontrol script occasionally executing as root when bootscript.pl is run>

I got Lisa to do the mantra again with the new server and timings; got an encouraging amount of data back which indicates that the full range of PC fan PWM can be harnessed

Graham went to great pains to automate the fancontrol script and server, this is akin to more good coding practice. He stressed this was necessary to do and get working flawlessly because of the crude and hydra like manner in which I had set up the server and associated parts in communication with one another was prone to unreliability, crashes and therefore unnecessary stress.

Graham went to work on the script, and at the end of it we now have the client relaying info between the two servers: it transpired that it was as straight forward to implement as I had imagined it would be conceptually.

Graham most likely solved the non multiple input issue also, by using a random time inserted into the script. Basically the servers sleep time and the arduinos sleep time had synced with one another, resulting in the beginning of their cycles coinciding and the first port of the arduino loop always assuming predominance. The solution of random seed, an injection of indeterminancy was interesting to me due to the idea of having to insert chaos between two systems to get them working as we wanted them too, and also due to the fact that the history of how random numbers could be generated, as expounded by the science museum was very engaging for me.

The necessity of indeterminancy to logical rational systems of computing is interesting, given the indeterminancy we have had to add to our system in order to make it better. This sparked some surface level googling which pointed outobservations by cryptographers that even thermal noise means of adding random might not be considered random from a different perspective (i.e. string theory); this all suggests interesting theoretical directions

This is the website for expounding the philosophy of whether rand() numbers are genuinely random

http://aplawrence.com/Basics/randomnumbers.html

Overall today drove home the weird and very obvious layers of abstraction our project brings into collision with one another.

Alan is working on the fans – it is evident that there is so much work left to do that this end of the project will be eleventh hour and thus it is as well that the other end of the project is coming together

With some big problems solved I now have a better take on what could have went better: The amount of time spent building the prototype is something that definitely could have went better, even Graham concedes that. However the means in which it became drawn out, i.e. having focus drawn towards areas that would have been best put on back burner until smaller modules were built is indicative of the experience of working with software. Its modular and different pieces need to communicate to one another and it is easy to become snarled in the molasses of abstraction between the abstract layers that compose it. I can chalk this up as both a learning experience and an insight into the way software coding affords certain behaviours to the uninitiated working within its realm.

Today also brought a welcome sliver of reflection:

One – the inexplicable havoc caused by the upgrades necessitated by upgrade manager causing interference to creep in between the numerous bodies of abstraction constitutive of code - There’s no way of knowing everything about the code, even if your a coder - sort of an endophysical statment

Lisa made point that religion could as easily be considered a technology of man also - in reference to stieglers time and technics
My point is - what was our role in appopriating Buddhist relegion, we were not part of the similar technological contract that traditional worshippera would be under
Guilty of surface level engagement - but perhaps not detrimental overall as we approaches meditation/mantra system in a different manner, with deviant intentions to the manner in which it was supposed to act/interact with it’s components
By becoming an interloper in this fashion I appreciate the importance of what graham said about materially engaging with media if trying to explore the links between media and spirituality
Another way of phrasing it would be as a desire to bring two different knowledge systems into collision, and in the end the way we went about it was quite crude – yet potentially effective given that we equal handedly approached neither (PC or religion) with any kind of finesse.