Who stays in the same job for ten years these days?

Not me. I’m moving on to the Ministry of Primary Industries as senior science adviser.

It’s going to be the same combination of policy for science and science for policy, with a focus on the role of innovation in the primary sector. And being part of government, rather than an independent NGO, I will be keeping my opinions more to myself than usual.

It’s been a fun (just short of) ten years at the Royal Society. I’m proud of the pieces of advice that I’ve written/helped put together/been involved with, particularly:

2020: Energy Opportunities
Emerging Issues – Ocean Acidification
Geoengineering no replacement for reducing greenhouse gas emissions
Emerging Issues – Virtual Water
Emerging Issues – GM Forages
Emerging Issues – Sea Level Rise
Ecosystem Services in Policy workshop
Emerging Issues – Ecosystem Services
Future Marine Resource Use
Evidence from ten years of research contract management
The Sustainable Carrying Capacity of New Zealand

But been there, done that, and now the future’s going to be different.

The failure of the NZ Emissions Trading Scheme, or not

Everyone’s been slagging off the Emissions Trading Scheme for failing to reduce emissions.

PCE: Returned ETS bill a failure
University of Canterbury: Greenhouse gas emissions trading scheme more or less dead
Labour: National’s ETS will mean burning more coal; failure to reduce emissions

And here’s the NZ carbon price collapse:

Market prices from Carbon Commtrade

I think they’re missing a critical point – the ETS is doing exactly what it is supposed to do. People are assuming that the ETS is a tool for reducing emissions. Not quite – it is a tool for matching the incentive for emissions reductions with the desire for emissions reductions. Let’s see how this works

Sigma Mesa writeup

Patrick’s put together a write-up of Sigma Mesa, which I mentioned obscurely a couple of weeks ago. We’ve made it onto Hackaday (Taking pictures of exploding wires) and Petapixel (Capturing High-Speed Photographs of Exploding Wires).

I say “we” with a degree of caution. Patrick did most of the work, with HWMNBN contributing timing and charging expertise. I mostly just had conceptual ideas, did some project management, stood around looking bemused, and worked out how to explain the value of all this engineering to a bunch of art and design people. We were aiming for a system that could image ~10 microsecond events using affordable hardware. To do this properly would require cameras that cost $8000 per day to hire, which means you’re only going to do it if you already know what you are doing. Instead we got useful data out of about a grand’s worth of kit, which means you get to play about and discover what might be possible.

It’s been creatively fun, we achieved what we wanted to achieve, and we impressed the people we wanted to impress. Clearly it’s time for a break.

So instead I found myself putting together a detailed plan for the next project. Oh god, this one is going to be awesome…

Try, learn, try again – Mitochondrion Mark 4.2.4 progress

The Mitochondrion M4.2.3 code was a bit of a mess. It wasn’t bad, but it wasn’t great either that it was put together in a bit of a hurry for last summer’s festivals. And then I tweaked it further over the summer while running out of program memory (Arduino Nano/ATmega328 so only 32 kb). And then I left it alone for a month or so, to get sufficient distance from that code base before thinking about what it could be. The vast majority of the code sat in one big library file, the control logic say in one big function, and inter-object dependencies were bloody everywhere, to the point where I didn’t want to mess with any part of it.

Clearly the solution was to mess with all of it. So it was major refactor time, starting with a clean sheet of paper, then scribbling all over it to come up with a design that was pretty close to the existing approach but without all the knobbles. And then coding and testing and more coding.

*wavy lines*

The Mark 4.2.4 now has co-operative multitasking with flexible time-based scheduling; one task object per sensor, output, or pattern generator; a message queue for asynch inter-object comms; and a nice and tidy state/event table for controlling switching between different modes and smoothly handling those transitions. Objects have much more responsibility to handle their own transitions and modes, leading to fewer cross-object tangles and asynchronous behaviour where a mode change sends a message to every object, those objects can finish doing what they are doing before changing modes and reporting those changes back. Of course, it’s never that simple