18.12.19 Truffle, Frimaire, 228: A short post on vanishing states, sieges and maths.

Short one this week, thankfully. It’s been a week of slogging it through Christmas events and feeling the extra 10 bpm added to my heart rate in hangovers. Augury got a nice mention in an article in WIRED dot com magazine from Ben Vickers and Hans Ulrich Obrist. I don't know if it's just me and my own filter bubble but the amount of tech and occult work in current circulation seems to have shot up over the last twelve months.

I’ve been reading Vanished Kingdoms which I’ve had sat around for a while. It’s a dense book on the forgotten histories of forgotten states or particularly short ones. I just finished the chapter on Burgundy of which there were 16 different incarnations over a thousand years. The history is list-like, interspersed with quotes from contemporary sources. The whole thing is book-ended with sprawling descriptions of geographic features, or, as is the case with Burgundy, critiques of the way we remember these forgotten states in media. I'm struggling a bit with it because of the density and pacing which I suppose is a hangover of mostly consuming history through Wikipedia and podcasts.

I also bought and started playing This War of Mine which was on sale on Steam. It's a really nicely designed survival platformer focusing on resource management in a war-torn city. I have yet to win a game, it's super difficult and full of curve balls and depressing plot developments.

Things I Learned This Week

• Thanks to This War of Mine I delved into a Wikipedia hole on the Siege of Sarajevo (from which the game takes inspiration.) The Bosnian conflict is one that I know vanishingly little about and is one of those ones that is so complex that it's hard to hold it in your head all at once. The Siege of Sarajevo was the longest-lasting siege of the modern age. 
• A colleague at UAL writes a thing called the 'Digital Transformation Brief' every Monday for staff. It's a really nice thing. This week he posted a link to this story from Brigham Young University about scalable water rendering. There's not a lot there on the process but it's a super interesting development when it comes to artificially simulating 'noisy' physics like water surfaces which normally take a bunch of calculations. 
• Check out the lineup of writers for the latest issue of Continent. Loads of stuff on tech and magic. Talking about tech and magic is cool now.

Channel Recommendation

I recommended maths YouTube channel Three Blue One Brown a while ago which uses really smart python animations to demonstrate complex mathematical ideas, this is another maths one, this one a bit more personality-driven: Standup Maths from Matt Parker. It's very geeky and often quite puzzle-based and involves him talking to other people more often than not. Check out this one on the Frog Problem:



I'll see about doing another post next week. I have a lot of reading and writing that I'm avoiding so this might give me an excuse to do that.

11.12.19 Érable á Sucre, Frimaire, 228: Project PROBE 2, All the Fun of the Fair

I redesigned the blog a little. I'm not super happy with it. Blogger is pretty pernickety but I've never really found a platform that isn't. One of the major issues is it just doens't do responsive design and paradoxically is really reluctant to be just simple. It's all about embedding images, drop shadows and widgets. Also, because it's from another era, it thinks 720px is 'extra wide' so I have to go through and manually resize each image in the HTML for 2019. Think about that as you're reading. A straight column of text with well-placed images is almost impossible.  Also, sorry but most of this is about Project PROBE. If you’re bored by maths and technical processes, turn away or scroll down to the bottom.

Project PROBE Voyager

I was writing this while trying to keep the nature of the project secret and realised that it was basically impossible. So, this is the project I’ve been working on; Voyager. It’s basically a two-axis sign using stepper motors that will point to Voyager I and display its distance.

Last week  I introduced the first bit of this which was testing out the Arduino Rev 2 that the whole thing is going to run off. As I wrote, it needs to be able to connect to the Internet and get its own orientation. So that it can point to where Voyager I relative to where it is. The second part which occupied a lot of the week has been working out the mathematics and geometry that will allow it to work. The process will be:

1. During the setup, when booting, the Arduino will grab its location from the Unwired Labs Geolocation API. It only needs to do this once when turned on. 
2. Then during setup it needs to calibrate the magnetometer and find magnetic north. 
3. Then it's into the loop. First, grab the coordinates (right ascension and declination) and distance of Voyager 1 from here. via a simplified API. Luckily I already set one up for decline.online that I can probably piggy-back on. This only needs to be done every hour or so; the celestial coordinates of Voyager are pretty stable. 
4. Run through the calculations that will use the right ascension and declination of Voyager with longitude, and latitude of the Arduino to work out an azimuth (heading) and altitude for Voyager from where it is.
5. Using the magnetometer’s reading, turn the motors to point the right way.  

Astronomy Maths

This flow reads very simple but I can already see there’s a bunch of things to think about: The Arduino needs to know its datetime in order to work out the heading and altitude of Voyager and Arduinos have no internal clock. Though the speed is obviously consistent, it changes relative to Earth as we move in our orbit (and Earth rotation) towards it, and away. You can see this on the visualisation of decline.online. Anyway, I decided to run the whole thing through Excel to check the maths and inputs before finding a way to implement on Arduino. I’ll share all of these materials this once the project’s all wrapped up but I found this a useful way of checking how the numbers would work:

The two crucial numbers I need are the azimuth (or heading) and altitude of Voyager for the point of view of the Arduino’s longitude and latitude. I found these really useful guide to converting those coordinate systems through what reads as relatively simple trigonometry.

The first thing you need to do is calculate your Local Sidereal Time (LST). This is the time at your location relative to the movement of the celestial sphere rather than the sun. You can check out your sidereal time here but I wanted a way to calculated it on the Arduino without it storing an enormous lookup table. I used a mix of guides to help but this one was the most helpful since it has worked examples and uses a formula that gives accuracy to within 0.001 seconds over 100 years.

The first stage in calculating local sidereal time is to calculate the number of days (including fractions of a day) since a date called ‘J2000’ - this is midday on 1 January 2000 at Greenwich. From this you count the time that’s elapsed and then perform a function on it to get the sidereal time at your coordinates. Once you have Local Sidereal Time, you subtract the right ascension of Voyager to get an hour angle. Hold on to this idea because this is almost entirely where everything went wrong.

sin(altitude) = sin(δ) sin(φ) + cos(δ) cos(φ) cos(H)
cos(azimuth) = { sin(δ) - sin(φ) sin(a) } / cos(φ) cos(a)

You then take these two formula above, one for altitude and one for azimuth. With the hour angle (H), latitude (φ) and declination (δ) you can now calculate the altitude and once you have the altitude you can calculate the azimuth and (in theory), huzzah! (As below):

However, throughout this process I kept checking both the live ‘tracking’ planetarium and this calculator (which also has helpful documentation) using the same formulae and found they were getting totally different results every time.  If you talked to me at the tail end of last week then it would have been the only ting I was talking about. I spent hours tweaking the formulae and getting no closer.

Eventually I clocked that the problem in implementing these formulae all arose in the converting between the different coordinate conventions. Americans tend to use hours, minutes and seconds or degrees, minutes and seconds while Europeans tend to just use degrees. Because Europeans are sensible. Anyway, the whole time I had right ascension down as 17.whatever degrees when in fact it was 17.whatever hours! (eg. roughly around 250 degrees). Once that was multiplied by 15 (34 hours = 360 degrees) everything fell into place. 

A new API

So assuming this all works, the next stage was to build an API that would stream the distance, right ascension and declination to the Arduino. Luckily I can hack together the one I made for decline.online together. This uses Python’s Beautiful Soup to scrape HTML contents from URLs. This was a pretty straightforward presence, made significantly easier by the fact that, unlike decline.online, it doesn’t need continuous data and it’s getting everything from one source. (I'll post it up with the project when done as well.)

Crunching the numbers on Arduino. 

To recap, the idea is: when the Arduino is first turned on it grabs location data from Unwired Labs (you can only do this up to 100 times a day.) Once it has that it enters the loop where every minute or so it is calling time and date and celestial coordinates for Voyager. With these it can constantly calculate an adjusting heading and azimuth as the Earth and Voyager move. 

This is the version I started building here. Here you can see where the Arduino code grabs the time and date data from the API and begins calculating the Sidereal Time. ‘d’ is the total amount of time since J2000 which is the first number you need in the run of calculations. However, immediately, the project quickly ran up against the Arduino’s limited memory and ability to calculate big numbers. The serial monitor shows the numbers are rounded and inaccurate. Arduino does strange things to big numbers that I can’t fully grasp. I spent some time reading around different ways of encoding long numbers in the Arduino's memory but it seemed like it was going to be a lot more work than I really needed. Instead I decided to move the heavier calculations over to the python API on the server which would then give the Arduino a lot of the key components of what it needs to calculate the heading and azimuth.

Once I put the exact same calculations in Python and ran them from the server and found it was delivering results exactly the same as the Excel model with no loss of accuracy. However, the problem here is that the calculations require the longitude quite early on. But these can only be gathered from Unwired Labs 100 times a day and depends on the location. Essentially, there's no simple way of getting both Arduino's location and Voyager's location from the same source. However, playing around with the maths you can actually allow for the longitude and latitude at the very end of the process by adding it on to greenwich sidereal time once it’s been reduced to the range of 0-360 degrees rather than before reducing and get the same outcomes. This means we’re not sending numbers with dozens of digits to the Arduino which is where it struggles.

So in this version, a lot of the harder calculations are done-server side with the final numbers delivered to the Arduino so it’s not crunching the big numbers at the beginning of the process when you have to calculate sidereal time. Now the API sends the current sidereal time at Greenwich to which I simply add the longitude from Unwired Labs. Since in this model the maths the Arduino will be doing occur after the bigger numbers are crunched it means that the results are much more accurate without Arduino's memory issues. 

Then was then quite a lot of fiddling around to get the maths to run properly on the Arduino which actually turned out to be easier than I was expecting and finally I had the Arduino spitting out accurate and updating altitude and azimuth figures for Voyager! As you can see in the screenshot, the altitude and azimuth are not only accurate but adjusting minute-to-minute.

All The Fun of The Fair

Turns out that further down Alice Rawsthorne's Design as an Attitude that the author addresses some of the concerns I had about the way that design is popularly represented and consumed. Addressing the question of 'why make a chair about e-waste?' isn't quite achieved but there's a wonderful quote from Reyner Banham in 1967 writing for New Society: 

The area worst blighted by furniturization lies right under the human arse... Check the area under yours at this moment. That chances are that it is occupied by an object too pompous for the function performed, over-elaborate for the performance actually delivered, and uncomfortable anyhow.

She's quite scathing of the role of the commoditisation of design exemplified by the Salone and the cycnical appropriation of it by 'super-capitalists.' However, there's little work done to re-address the formation of an aesthetic sensibility based on what works at Salone at the cost of critical power. She mentions the role of other up and coming fairs; Eindhoven and Istanbul as counterpoints to the dry commercialism of Milan but it would be useful to see suggestions of how we might push back against Milan's creeping homogeny rather than run away from it.

Things I learned this week

1. I learnt a good joke about a drowning man who asks God for help. (Ask me when you see me and I'll tell you.)
2. I learnt a breathing exercise that reduces flight or fight response. I don't really suffer from this but I found it useful in controlling my body when tired. You have to imagine  cat on your belly and breathe in for four and out for eight. 
3. I'm currently listening to the bit of the podcast about Avicenna. It's funny that I did some training this week where they were saying how in British culture, extolling what you're good at is seen as arrogance and you're expecting to constantly put yourself down. It was normal in the Islamic tradition for philosophers and thinkers to go on about how great, gifted and close to god they were so though in his writings he comes across as very arrogant; for instance, dismissing his learning of medicine as trivial and easy, it was pretty normal to do.

Channel Recommendation. 

An oldie but a goldie. The boys of Prepare to Try reformed about a year ago as RKG (Rory, Krupa, Gavin) As I spent my weekend coding I had their Dark Souls II series on in the background like a sort of deep background sound.

4.12.19 Cédre, Frimaire, 228; Project PROBE, Knowledge Capture in Design Part 3

If I put the titles to what these posts are about, they might be easier to find, though I do tag liberally to help.

Project PROBE

Last week I wrote that I’d started a new little vanity project. I find myself very happy learning new technical stuff and this project gives me the chance to combine some of the things I learnt about servos from Charismatic Megapigment with some of the other projects that have used geolocation maths like Augury. I'm not going to give much away on what it's about, just show process as I go.

I’m trying to get all the inputs to talk to each other this week. Without giving away spoilers; it needs to know exactly where it is in relationship to where something else is. So I need a WiFi module and IMU (inertia measurement unit), ideally with a magnetometer so it can figure out where north is. This way it can use WiFi beacons and the magnetometer to figure it's exact position on the Earth and it's orientation to the poles. Rather than plugging in a bunch of different components, the Rev2 pictured has a WiFi module and IMU built in so that’ll save on space and complexity (although I'm not sure the IMU has a magnetometer built-in.) However, the first challenge was getting it to talk. It wouldn’t talk to any Macs but when I hook it in to a Window’s PC; no problem.

The solution was a creeping reinstall (there's probably a technical name): I had to do a complete manual reinstall of Arduino IDE and all the drivers, starting with oldest to newest until I got one that worked. This meant going through the preferences menu to find Arduino’s cache and wiping it. This is risky if you’re dependent on Arduino projects but I don’t use it everyday so I think I’ll survive.

The second issue was getting it to connect to a WiFi network. Luckily there is a secret one at work that has only WPA encryption (no username, just a password) so I managed to sneak it on. Currently the standard Arduino wifi library – WiFiNINA – has no support for WPA Enterprise without a lot of jiggery-pokery.

The next step is finding a way to get its location in longitude and latitude. Google now charges for its geolocation API which is a pain on a vanity project and not something I wanted to go through the hassle of setting up. Unwired Labs LocationAPI which I found through this helpful tutorial allows you to track up to five devices free for 100 calls every twenty-four hours. I only need to track one device and since it should only need to call the API when it's first turned on this would easily suit my purposes.

The idea here is to ask the Arduino to compile a list of nearby WiFi routers and their signal strength, send them to Unwired Labs and then receive a longitude and latitude, same as the Google Geolocation API. The code in the tutorial is pretty useful but there’s always a bunch of problems to be un-kinked when building a system from different components. The version of the Arduino WiFi scanner library being used in the tutorial had a handy ‘BSSIDstr’ function that converts the byte arrays of BSSID (the mac addresses of nearby routers) to strings so you can feed them into a JSON string. Essentially, the format that the mac addresses are scraped in are in the wrong format to send to the API and you get mangled gobbledy gook if you try. However, BSSIDstr no longer exists so I had to mangle in a ‘sprintf’ bit to do that for me. Sprintf is one of those things I've never properly understood so it was useful to learn how it and byte arrays work. FYI, just for fun, the order of the bytes is backwards so you need to lace the string backwards to get the BSSID in the right order. Then there just some tweaking around with the URL for the API request since it’s all changed since and it was good to go. Et Voila, my Arduino knows exactly where it is on the surface of the world as pictured to a remarkable degree of accuracy.

I already have a magnetometer working from an earlier test so I'm not hugely bothered by the amount of work there so once that's integrated the Arduino will be able to know it's position and orientation when it turns on easily. Most of the stuff that seems to happen in the early stages of these projects is versioning; tutorials use out of date firmware, terms have changed or been removed etc. etc. So most of what you end up doing is chasing around dates and versions to get everything to talk to each other.

If I get any more time I will be looking in to what turns out to be some exceptionally complicated geometry problems which I hitherto had considered child's play. Who knew there are different versions of time?

Knowledge in design part 3; cognitive dissonance and sympathy,

This is more of a short addendum than an entire new line of thinking. A lot of activities last week kept me from reading as much as I’d like but I met up with Yosuke Ushigome of Takram fame on Monday night and we discussed some of this stuff since he at least apparently reads this. We were reflecting briefly on the history and state of speculative and/or critical design with regard to our peers from MA Design Interactions: Why did the canon there struggle to respond to issues that were beyond a limited temporal window and individual scale?

The easiest answer to me is in design’s aesthetic history of tackling human problems on Maslow’s hierarchy; where to live, how to eat and sleep, how to communicate and share information etc. All of these things can be interfaced or encountered within the human sensorium and consequently design’s aesthetic sensibility is drawn from the human body and it’s scale. It’s only in recent years that design has attempted to address ‘systems’ and even these are human-oriented with solutions and products largely being aimed at the interface of the human and the system; different information flows and architectures, levels of access or responsiveness. This is as opposed to the approach of an activist or artist who might address the system in total as an artefact rather than as an inevitability.

Take for example, Suzanne Triester’s work; Hexen 2.0 (left) which examines the history of computation through a quasi-occult, quasi-conspiratorial lens. The goal here is not to improve the system or design it in a different way but to give us a pan-historical reading of it that challenges our comprehensive model and presents alternate narratives.

This is opposed to any number of brilliant design projects on computation that address the way we interface with the very notion of computation through the interface. For example, the amazing work of IF and their catalogue of data patterns almost all of which feature a hand, a phone, a laptop. They address the system at the point of interface where design is most appropriate and comfortable. This is how cognitive understanding is built between the audience of the design and the idea of the design. We all have hands, phones and laptops, we can project ourselves into the alternatives that IF propose for data patterns. To a degree, Triester exploits the same sympathies by drawing on an aesthetic sensibility of diagrams and visualisations with which we might be familiar and so are equipped to interpret the work and put it in a certain frame of reference.

If I was to think about Augury as a project about computation then I’d say it is further abstract than Triester’s work. It draws on some familiar aesthetics; the audience having to look up indicates it’s about something above us, there are flight numbers and names of airline companies to conclude it has something to do with planes. Though it draws on a popular ancient practice of divination, this was less familiar to the audience which was perhaps a failing. Connecting this ancient divination technique with a contemporary technological equivalent – planes’ instead of birds’ flight patterns used to predict the future – was a knowing cognitive leap rather than one meant to create cognitive sympathy. The project exploited the idea that the audience might question why these things are together as way of teasing them towards the absurdity of computational prediction without having to reduce it to human terms (phones, laptops hands) that would make it more comfortable. From the perspective of my practice I find the only way to deal with things maybe beyond the human scale is to exploit cognitive dissonance as it's impossible to make these things sympathetic to human understanding in their entirety.

While a design project might draw on a more familiar aesthetic sensibility to provoke the idea of the absurdity of computational prediction by exploring alternative device interfaces or human interactions, in Augury Wes and I were keen to highlight the supra-human qualities of computation by placing it in the world of the supernatural. It’s hard to then draw on design aesthetics and logics for this kind of framing, there aren’t really (arguably) tenants, principles or methodologies for designing the supernatural. There are certainly designed aesthetics; colours, shapes, styles but not many functional models.

Let’s put this back into the question; ‘Why did Formafantasma design a chair about e-waste?’ which seems to have become the locus for this thinking. Ore Streams draws entirely on a comfortable and sympathetic design aesthetic – the chair – to engage with a bigger-than-human (I’ve been trying out various words here, you may have noticed) idea/issue. But, they draw on elements of sympathy and dissonance; it’s a chair with which we can all connect experientially but it is also provoking a discussion about e-waste with a particular audience. Consequently the audience might ask ‘why is the chair made that way?’  I am going to stop banging on Formafantasma now, I really do love their work and I’m sorry they’ve become a lynch pin that seems to be unduly criticised here. I do think Ore Streams is great, I’m just using it as an exemplar project for design projects that don’t give me a good sense of why did they do it that way? The follow on from which is what is the best way of doing this? Which is basically a PhD right.

Restoring some regular features - things I learned this week. 

A while back I said I liked reflecting on what I've learnt. Obviously it's a bit of a cheat this week because:

1. I learnt a lot more Arduino stuff, particularly what is and how exactly 'sprintf' works and loads of other stuff about using Arduino with online stuff. 
2. I've been listening intently to my Arabic philosophy podcast and have learnt a lot about Al-Razi who spent a lot of time refuting Galen and was mostly known as a heretic so most of his writings are only known by how they're refuted by later Islamic scholars. He dared to suggest that four things preceded God - soul, matter, the universe and time. 
3. The folks at Wikimedia are super cool and have a lot of really interesting stuff going on. (Bit of a cop-out this one, I'll own it.)

And – Channel recommendation

I've loved Girlfriend Reviews since they first started. Witty and irreverent reviews of games which are becoming increasingly more critically engaged in discussion of the industry. The latest one on the new Star Wars game which received lavish praise is brilliant as a piece of media criticism on how games reuse and reconstruct tropes but also now hilarious for my new catch phrase; 'Have y'all lost your minds cos I'll help ya find 'em!'

I've already started notes for next week's blog and it's currently Tuesday so I guess it's going well. I hope you enjoy something and it's not too tiresome.