In the first week, as the syllabus was introduced, it was suggested that we conceive an initial idea for a final project which might utilise the full scope of the techniques covered in the course. This seemed a little daunting, as some of the processes we'd cover in the later weeks were completely new to me.
Given how much time HTMaA was going to take up, I wanted to come up with something that would cohere with my research in the studio. It would also need to be a construction, ideally involving digital and moving mechanical elements. In my current project, I've been exploring ideas around parasitism: systems which attach themselves to others, or appropriate elements of other bodies or environments for their own proliferation. Parasites are structurally interesting because they are often quite simple things; without their hosts, they are incomplete. I've been interested in questions of metabolism: how does the parasitic relation figure as a social and energetic interaction? After all, feeding is a social interface, especially if it's off of one another.
I arrived at a possible project, more of a one-liner than a piece of work: a tank containing a bitcoin mining rig (essentially a couple of GPUs running intensive calculations) submerged within an oil-based cooling system, which gets warm enough (around 60C) to cook meat in the manner of a sous-vide, titled 'proof of steak'. for some time now I've been interested in blockchain protocols and the amount of energy they consume. bitcoin, for example, is projected to use as much energy as a small nation by the end of this decade, because it runs on a 'proof of work' algorithm which essentially involved brute-forcing a very difficult calculation. it takes a lot of energy to run a decentralised system; perhaps trust is a byproduct of heat. 'proof of stake', meanwhile, is a possible (though yet untested) alternative.
Whether or not I actually end up making this particular project as the weeks wear on, I proceeded with this week's assignment of modelling the thing in a few different kinds of 3D software. The first I tried was Antimony, a simple but quite powerful node-based programme which Neil described using some technical terms I can no longer recall but I am assured that it uses a rather different kind of mathematics to conventional modelling tools. My current design is as simple as can be: the GPU shared the tank with the beef, which is hooked on a small winch which can raise or lower it out of the bath, perhaps according to a timer. In an ideal world, there would be an automated mechanism for vacuum packing and un-packing the meat before and after the cooking process. One for the weeks to come, perhaps.
I also modelled the project in cinema 4D, with which I'm a little familiar. It renders very nicely with but is really more geared towards making animations. My favourite software to use was probably Autodesk's Fusion 360, which seems like a pretty good all round package for CAD work. It's clunky and quite frustrating at times, but it is at least intuitive to learn; plus, apparently the industry is moving towards packages like Fusion. I admit I tried freeCAD but found the interface quite challenging - it might be worth learning if I have more time in future.
Modelling with a standard power supply
layout for CAD
Tapping the 6-32 threads.
Lasercut raster inset for the switch.
Laser settings (GCC): 0.5 speed, max power, 800DPI.
The threads finally match up well!
Marked for changes.
Power supply screws on, just about.
New 2nd hand GPU (R9 290) finally arrived.
Starting to fill it up with oil.
After an initial test run demonstrating that the tank was now quite well-fitted, and heated up nicely, there were still a number of issues to be addressed. I wanted to clean up the fitting for a better finish, add an on/off switch to the motherboard jumper cables, and fix a very minor leak, from which a couple of millilitres of oil seeemd to seep from the tank every hour or so. Since I'd applied three layers of silicon sealant already, I could only conclude that the mineral oil was eating away at and penetrating the seams of the sealant, meaning I'd have to find another sealing solution. After a little searcing around a I got hold of some gasket maker/adhesive/sealant which claimed to be oil resistant as well as capable of withstanding very high temperatures.
The gasket-sealed tank.
With spiral development in mind, I chose to use an ATMega328P for the board, so that I would be able to drive the water 12V pump motor using a digital signal to a MOSFET; read the temperature in from my TMP36 chip using analog readings from ADC; and perhaps output using I2C to a small LCD screen I've got. I based the design fundamentally on the hello.arduino board, which I had working a few weeks ago. The new design of the board is basically the hello.arduino with several more specific headers for pinouts (to ADC, digital etc) onto which smaller, modular boards could be connected. The smaller boards would be the TMP36 and the MOSFET.
TMP36 Daughter Board
The main board, however, would give me no end of trouble. I had been able to quite happily programme a modified version of the hello arduino board back in the embedded programming, so I figured that it would not be too problematic to redesign a similar arduino-ish board based on the ATMega328P with outlets for serial, ADC, digital I/O to the MOSFET and some SDA/SCL connections for I2C to a potential LCD display.
As such, I decide to base it on my old board design and added the additional parts. Suffice to say it did not work -- I was getting the same rc-1 error that was usually down to a hardware fault, but I was using all the same traces as last time. I checked it over a couple of times, using the multimeter to check for shorts. I even drew on the trace diagram to make sure all the lines went to the right places and nothing was getting confused, as far as I could tell. I could not work out what was wrong at all. It wasn't in the software -- arduino IDE's boards.txt, platforms.txt and avrdude.conf could be causing issues but I was struggling to even get the IDE to acknowledge the board. I am pretty certain I wasn't frying the board in the soldering process -- I went through about 4-5 iterations of the first version, gradually simplifying bits I didn't need like extra digital I/O pins that had been left on there. By this point I'd become pretty good at soldering the little ATMega328p chip.
doodling over the failed board to make sure all the traces were going home.
By this point I was close to giving up or starting over, so I did. I decided to do the board over with a fresh trace design, making some extra room so the headers weren't quite so close together nad generally trying to ensure a safe board.
Below you can see all the iterations I went through, annotated as I progressed increasingly late into the night.
Many boards, much solder, so wow
At last my board was working: it was reading ADC and outputting to the arduino IDE, which had a very simple programme telling the MOSFET to switch the motor on if it went over a certain temperature.
The last few things to do were to waterproof the TMP36 daughter board, which was now mounted on a much longer wire. I simple smothered it in silicone sealant since time was getting a little tight by now, but given less rush I'd have liked to make a little probe mould for it.
By now it was time to actually put it all together, as the exam was approaching. Regretfully I didn't have time to factor in the main board as part of the design for the oil-tank-motherboard-enclosure, which would have made things a lot neater and a little less precarious, but I somehow managed to lose a couple of days to the PCB design, so things got a little rushed by the end.
I gathered my vinyl tubes, the second sous-vide tank, 24 litres of oil, about 10 litres of water, the computer tank and chips and headed up to the 6th floor.
In the end, it worked pretty well! The water got up to temperature within about 2 hours, with the long coil of oil-filled tubing transferring the heat. With great regret we had to take down the piece after a 2.5 hours because we had to catch a flight later in the day, and therefore couldn't make it to the open house :/
There was time for a final test, however. As we hurried home to pack out travelling bags, Agnes and I had time to fry up a quick steak for lunch. It was genuinely very tasty, even without being in the sous-vide for as long as it should have been, the meat was noticeably firmer but also tender, meaning it was perfect after just a quick sear.
Proof of steak!