Arduino + ESP8266 hacking

This post is quite a deal more technical than my usual fare. I’m doing this as a write-up of some of the learnings, in part to share with participants at the OzBerryPi IoT meetup that occurred last night.

I’ve recently been investing some time into a project using Arduino as a wifi-enabled energy monitor.

I had an hypothesis that open-source hardware such as the Arduino and related chips like the ESP8266 wifi chip were approaching the point where someone like myself, with a reasonable degree of experience in web development, might be able to build a low-cost embedded electronics project (and potentially, down the track, product).


  • Existing libraries are firmware dependent. Few work with the current version of the ESP8266 firmware. Be sure that you can flash your chips with the target/tested/stable firmware.
  • The current version of the ESP8266 firmware seems to have some bugs/quirks (returning mangled responses, or cruft at the beginning of responses, at times). I wouldn’t consider it “reliable”. YMMV on older (or future) firmware versions.
  • There’s tonnes of information snippets out there, but there’s few “definitive” guides to get up and running. There’s a lot of information that is either stale or inaccurate (now) based on current firmware/library versions etc.
  • Arduino quirks and low memory conditions make it challenging to work with strings without understanding C/C++ character arrays and related methods/utilities. The String class is problematic (buggy, poor memory management) and should be avoided if possible.
  • Design to use very short/small strings to be passed between client and server. Don’t try to implement full HTTP requests/response construction/parsing.

Project goals

The basic gist of the project is to have a power-point level energy monitor, similar to the Belkin Wemo but at a reduced build cost, so I could run 6–12 units in a variety of locations/contexts (i.e. potentially 20–30 units).

The parameters of my “experiment”/project:

  • Operate at a power point-level (i.e. for individual power points in a house), not aggregate (i.e. whole of house)
  • Target a USD$10–15 (or less) component cost per unit
  • Built upon common open-source hardware and readily available sensors etc.
  • A hardware architecture/spec that could be scaled up later (i.e. not something as a “one off” hobby approach)
  • Support 5v analog sensors
  • Be wifi-based (not bluetooth)
  • Be self-contained (i.e. not require separate power supplies etc.)
  • Get access to the raw backend data
  • While longer term the vision/idea was to have individual points send messages to a central unit on the same network, with that central unit communicating with an online service, for my first prototype I wanted the device to post directly to the internet (so I didn’t have to write server code just to get a basic prototype working).
  • Ideally, post to an existing online “Internet of Things” server, such as Thingspeak, etc.
  • Had a strong development community/base (incl. documentation)
  • Didn’t require coding/linking to an online service to get basics working (like posting code to the device)

I note the parameters above as there are a number of existing projects (such as the excellent OpenEnergyMonitor that meet some, but not all of the requirements. There are a number of systems/architectures USD$25+, such as NodeMCU-style development boards that have wifi built in. The Particle range, the soon to be released Tessel2, the Arduino Yun, etc. But these wouldn’t meet the price point, nor the longer-term “architecture” goals.

Initial exploration

Doing some preliminary research it seemed that this should be possible using Arduino with the Espressif ESP8266 wifi chip. I also worked out the similarly low-cost Allegro Microsystems ACS712 chip could be used for sensing energy usage. A quick inventory suggested that these two components combined with an Arduino (for example a non-official Nano, that are available on Ebay and Aliexpress at very low cost) would be feasible.

In fact, the single most expensive component, it appeared, would be the switching power supply.

Doing a bit more research, I found were lots of “getting started” tutorials that suggested this would be doable. Most get to the point of sending basic “GET” commands for the ESP8266, and for reading DC current using the ACS712 sensor.

So I got started…

Getting started

Energy monitoring

Current sensor + Arduino Uno + Wifi shield

I got the ACS712 working quite quickly with a DC current and basic sketch. Working with AC current was a bit more challenging, but I was able to find sufficient documentation online to take samples over a period to calculate RMS voltage and derive current from that. A lot of the projects assume a inductive sensor (rather than one that could connect directly to the mains).

While I found it a little frustrating piecing together bits of information from all over the web, overall it was a relatively painless experience (about 1–1.5 days effort I would estimate). With the assistance of a friend who maintains and repairs power supplies for a living, I built up a basic test rig containing the ACS712 sensor, that could plug into the Arduino prototype rig I was developing (see picture above).


On the wifi front, I thought I’d make things easier for myself by using a pre-designed shield that used the ESP8266 chipset as a means of getting up and running, knowing with a view to moving towards connecting directly to an ESP8266 chip (and reducing cost) using the same code/library/architecture.

I picked up the Sparkfun ESP8266 shield, and used the library that was provided by Sparkfun. The board would power up (sometimes) and the blue status light with flicker then disappear. Other times it would remain on all the time. Other times it would be in between. The library consistently returned “Could not communicate with the device errors”. I tried running it using breadboard jumpers, rather than using the header pins as a shield configuration. While this was more stable, it was still very inconsistent. This seems to be a power-related issue. I’ve since been using an independent power supply for other ESP8266 units, but this didn’t fix the issue for the shield (i.e. when sending VCC directly to the shield).

This was the beginning of a very time consuming and frustrating experience with trying to get the Arduino/ESP8266 architecture, using AT commands, working.

After a lot of head scratching, and starting to reverse engineer the SparkFun library to see if I could work out what was going wrong, I switched tact.

I bought an ESP8266-01. I didn’t have a lot of experience with serial comms and using FTDI interfaces etc. it was a bit of a slog to work out how to get it communicating with the Arduino. I also had to buy a logic level converter and an FTDI interface. With a big assist from some folks at the OzBerryPi IoT meetup a few weeks back, I got comms (simple AT commands) working first using CoolTerm (a serial terminal), then the Arduino, via the logic level converter. I also added a more stable power supply, so as not to rely on the Arduino 5v/3v3 VCC outs (see pic below for the updated development rig).

Arduino Uno + logic level converter + power supply + ESP8266-01

Once these comms had been established, I searched for libraries that used AT commands to communicate with the ESP8266 chipset. I found a couple of promising ones (for example, WeeESP8266 and ESP8266_Simple), but these didn’t work consistently. Sometimes this seemed to be a firmware issue (expecting certain responses that had changed). Sometimes this related to memory issues (with Serial.println() statements getting corrupted or not working). Other times it would be a non-responsive chip (not responding to the most basic AT command).

Again, I tried to reverse engineer/trouble-shoot with the existing libraries, but found them a little light on documenting what was going on/expected as a response, and as such it was difficult to decipher and work out what was expected to be received vs. what was received etc.

From what I’d read, I realised that most code examples were very sensitive to the firmware version and AT command set version supported by the device. So I worked out how to update the firmware, but was unable to find the specific versions that the libraries needed that I could install via Mac. (There are a lot of references to as being a “stable” version.)

Eventually, as a “last resort”, I opted to implement a “first principles” approach using the latest firmware (reporting the version number as “0020000903”) from Espressif, which I was able to flash to the device successfully using esptool. This was after losing a few hours working out how to reset the baud rate of the ESP (which was now too high for the Arduino). (“AT+IPR=9600” did the trick—thanks Andrew Rapp.)

I got a basic (albeit what I would consider brittle) version working—despite inconsistent range and formats for AT command responses and weird cruft either at the start of the AT response, or mangling the body of the responses. Then I tried to refactor into my only library for cleanliness. Which of course borked everything (again, seemingly memory-related issues).

I presented my experience to the OzBerryPi IoT Meetup group last night. Details of my experience/experiment with this approach are available at my Bitbucket repo of the resultant code.

Days have passed. Still no stable code.

Strings and low memory

Admittedly, not all of this is the ESP’s fault. While there are definitely some quirks and issues with the AT firmware, a lot of it is to do with the Arduino’s constraints and quirks. Two in particular being low memory, and limited string functionality (which are related).

Arduino code is a weird in between of C and C++. It doesn’t implement the std::string library, nor common string parsing and manipulation tools like regex, apparently due to the memory and storage limitations of the device. The fact that I’m new to C/C++ didn’t help either.

The Arduino environment does provide a String class (not to be confused with std::string) but is very limited, and by all reports is both buggy and causes memory issues. This means that you’re often having to work with raw character arrays to do string manipulation. There are a bunch of functions to support this (like strstr, memcpy, strcat, strcpy etc.), but it’s a long ways away from “easy” and straightforward.

Lastly, there seem to be very limited tools for debugging and monitoring memory etc. on the Arduino. This makes it difficult to know where the problem lay, when things just randomly fail and there’s no clear way to determine if it’s a memory issue. (I’m aware there are some rudimentary memory monitoring tools/libraries around—but when Serial.println is failing, there’s not much you can do to troubleshoot.)

Why spend so much time?

An obvious question arises: wouldn’t I have been better off spending the $25 for the more expensive, but more stable (one would hope, anyway), architectures to get the data and get started on the bigger picture goal I have in mind? A false economy, perhaps…

I’ve asked myself this numerous times along the journey, and decided to continue persevering because of some “bigger picture” motives, and other considerations, that suggested investing further time in trying to get this to work. For example:

  • There was no guarantee these more expensive units would be more stable in practice/reality
  • Often these units required entirely different code bases (e.g. NodeMCU uses Lua, Tessel2 uses io.js etc.) and often these are not as well documented, as the technology and communities around then are still nascent
  • Some development boards didn’t have the ADC (analog to digital) conversion capacity—e.g. the ESP8266 has only one ADC, and it requires a logic level conversion down to 1.8v (from 3v or 5v source, depending on your sensor)
  • I wanted to see if I could get this low-cost architecture working with a view to potentially developing a product to sell in the future, so was trying to stick with components that would have a chance of meeting a target price point
  • I wanted to see if I could get a library working with the current firmware version, to contribute back to community (given there were limited options available)
  • I was using this entire exercise as a learning exercise in developing for devices and hardware, and I was learning a lot of the nuances of C++ (and the Arduino environment, which is not true C/C++) which just takes time (so I’m thinking of this as professional development/training, to some degree)

I think, however, it’s time to let go of my original ideas/approach, and start looking at alternatives.

Possible next steps

I have a couple of ideas about how to get a stable implementation using this kind of architecture:

  • Use a different platform (as noted above) and wear the additional expense/unit to get the basics working, and revisit down the track (or wait for the cost of the other platforms to come down, as has happened recently with the RaspberryPi Zero)
  • Continue to experiment with different libraries (ESP8266wifi looks promising, seemingly developed with low memory situations in mind, but tested on firmware.)
  • Ditch the use of HTTP/POST method and go for a “lighter-weight” protocol. Either to a cloud-based server I control/code for, or on a central device on the local network that then posts to the cloud.
  • Use Arduino on the ESP8266 chip and work out how to deal with sensor input given the limited ADC capabilities. My understanding is some ESP variants have more memory than the Arduino boards, which may make life easier too.
  • Run Arduino code on the chip and use the built-in libraries, implementing a simple, text/serial based interface that is then run on the chip. (Or you could use NodeMCU in a similar capacity.) This would be terribly difficult to debug, and far from desirable.
  • Look into embedded programming practices (e.g. coding for the Atmel out of the Arduino environment, or coding for the ESP8266 using the SDK directly)

I’m very tempted to take option 1, unless someone cracks the nut with a stable firmware/library combination.


I’ve had to invest a lot more time than I intended/wanted to get to this point. So I thought it would be helpful to share some more top-level thoughts based on that experience. I’m hoping this will be useful to someone considering this sort of architecture for their own project. This is what I’d tell my prior self, if I knew what I know now…

Don’t rely on the AT firmware I would seek alternatives to AT command firmware to get a reliable system up and running. The latest version seems to be buggy and, while better documented than previously, the current docs still leave a bit to be desired, with inconsistent response formats and some missing responses for certain states (for example, sometimes the device will return “no ip” as the message, but this is not in the documentation, sometimes it will return a “busy…” message, but I’ve not seen this in the docs either) etc. See Possible next steps above for my thoughts on how you could get around this. YMMV with future (or older) versions of the firmware.

Develop to a specific firmware version If you do find a specific firmware version and you develop code for it, stick with it. Flash all your devices so you’re working with a consistent/known base that you can be confident with. As noted earlier, 0.9.2.X seems to be a popular choice/period, but I couldn’t work out how to flash the chip on a Mac to this version.

Be a hard-ass on the KISS principle Given the constraints of the Arduino environment, it’s difficult to build libraries that handle generic use cases (see next point). I’ve found that refactoring into libraries that are more “generic” in what they try to do is where a lot of issues are introduced, due to bloat, additional memory requirements, passing objects/data around in memory etc. I would recommend a laser-like focus on what you need it to do and keep it as simple as absolutely possible to achieve that objective. i.e. Build only what you need, resist temptation to “library-fi”.

Only use simple text strings for comms Given all the limitations noted above, trying to do anything beyond very basic string manipulation is not advised. For example, the Thingspeak API returns a 700 character plus response to a POST message. This is a big string to handle on an Arduino. Creating a basic POST request is about 256 chars.

The lack of std::string functionality and other string manipulation tools also makes it quite cumbersome. I now understand why a lot of folks throw out the HTTP verbs other than GET! I’m aware there’s some libraries around (like Arduino JSON or the MQTT libraries like pubsubclient or Adafruit’s implementation etc. would probably help with some of this… but given the previous point re: KISS + my experience working with the AT libraries for the ESP8266, you’ll have to forgive me for being nervous about relying on libraries too much.)

So, if you’re communicating with a server you have control over, and you can build very basic API input/output protocol, this would probably be the best way to go. The idea I mentioned earlier of having a central unit receiving the smaller units’ data using a simple text protocol to a server running on a beefier device, that is then relayed up to the cloud using the standard HTTP stack. For example, run a Raspberry Pi or BeagleBone as a central point, running a node.js or python-based server. Keep the individual points doing the absolute bare minimum (getting a basic text string to the local server) and do the “heavy lifting” on a device with more headroom.

“Growing” 3D printed objects

I found this demonstration and talk by Joseph DeSimone of Carbon 3D, explaining a new method of 3D printing where the elements are sort of “grown”, really interesting.

I’ve been fortunate enough in my current role to be able to explore 3D printing—working with great peeps like Mel Fuller from Three Farm and Matthew Connolly from me3D in teaching this technology to young folks.

It’s really piqued my interest—I’m fascinated by the possibilities. I’ve been looking into various approaches to 3D printing bikes (perhaps unsurprisingly!), among other things. But I also see potential in creating parts for things like robotics projects.

One of my “alternate lives” would be an industrial designer. I’ve long had an interest in building things in real life (starting with my love of LEGO, but extending to radio control cars, and dreams of being a robotics engineer at one point). But I’ve never quite had the skills or equipment to pull that off. I thought about heading back into study of industrial design at one point, but wasn’t quite convinced it was the right path for me.

What I’m finding most inspiring/interesting about 3D printing is that it brings into reach many of things that I always dreamt of being able to do. I was very excited recently to be able to 3D print an iPhone stand for a custom application at work. Not knowing how to use the software at the start of the day, we were able to get a first prototype designed and printed within the space of a few hours.

Speed and strength are two key issues with the resulting output for some applications. For example, if I was still actively working on RC cars, I can see countless opportunities for customisations and enhancements using 3D printed parts, but they would need to be quite strong.

The Carbon 3D technology is much faster, supports a wide range of source materials, and is stronger—so seems to address a lot of those issues.

I also think about applying this sort of thing to creating the robot pieces that I envisaged when I was a youngster, attempting (unsuccessfully) to build a robot with an articulated arm out of wood.

Combined with my ongoing interest with robots and technologies like the Raspberry Pi and Arduino, I see the potential to fulfil those childhood/teenage dreams.

Suffice to say I’m finding the whole “digital making” space very inspiring at a personal level (and wishing I had more time in my professional capacity to explore and play with the tech that we’re teaching at IDX!)

Hippy bifday to me…

I’m having a birthday.

One that ends in a “Zero”.

Wanting to do something small to mark the occasion.

Doing two things:

  1. Seeing Death Cab for Cutie on 1 August at the Opera House. 10 years ago, I celebrated my birthday by going to see DCFC at Home in Darling Harbour. Great show. Figured given the timing being not far away from my birthday again, that this show would be a fitting “revisit”. Given the nature of the latest album, being a bit more about “growing up”, also a little poignant. The last show Ang and I saw at the Opera House (heh: from “Home” to the “House”)—Elbow—was amazing. We discovered a little gem near Wynyard serving a tremendous selection of boutique beers on tap called Frankie’s Pizza. Seems like the perfect start to the evening. So kicking off there about 5ish. Dinner. Then the show.

  2. I live in Katoomba now. I love the place. I feel my roots starting to dig in up here. And it’s a long way from Circular Quay 😉 So, I’d really like to do something close to home to mark the occasion as well. I’m away on business on my actual birthday (in Darwin, attending/co-facilitating/participating in the Broadband for the Bush Forum), but figured I might just hole up at Station Bar, one of our favourite joints up this way—and perhaps unsurprisingly one that usually has a great selection of boutique beers on tap (noticing a theme here?). Date: Saturday 18 July. Time: 6pm+.

’twill be low key. But fun… If you’re reading this, there’s a good chance it’d be great to have you there 🙂

So, if you’re up for it let me know which/when/where in the comments so I can book tables and stuff…

Reconnecting with music

I’ve been trying to reconnect with the art of having fun making music.

Anyone that knows me well knows that making and performing music has been a big part of my life for, like, forever.

But since Fuzu called it a day, in part due to my sojourn into Sustainable Practice at uni, I’ve found it hard to reconnect with any particular musical venture.

I had the support of some great musician friends to record an EP last year, but that project feels like it’s stalled. Which is disappointing. If only because I feel like I’m dishonouring the effort and creativity of the folks involved. It don’t treat that lightly.

But, to be honest, I’d forgotten the tremendous amount of energy and headspace required to do justice to a project like that. My previous efforts were all group efforts—with a band, where each member contributed some forward momentum to the process. This project felt different, as it was to record something akin to a “solo” project. And a lot of hard work. To co-ordinate. To write. To rehearse. To arrange. To perform. To mix. To promote. To turn it into “something”. Something of note. Something to carry forward. Something that begins something else.

After many years doing the whole “band thing”, I recognise and acknowledge that if you want to make it in the business, you have to treat it like a business. And after many years of trying to do that, I am at a point where I think I’ve worked out I don’t actually want it to be a business.

I want to reconnect with the feeling that I get when inspiration strikes. A sense that you are a conduit for something more. Something outside yourself.

That sense of flow that you get where you lose an hour evolving and developing a riff. A verse. A lyrical idea. An arrangement.

That sense of camaraderie that emerges from being in a room with other musicians and you create something that feels bigger than yourself.

A synergy.

A spark that begets a spark that is transformed into something to share. And when another human connects with that, to honour that mutual sense of connection. Of a shared experience, emotion, sentiment, imagery.

For the longest time I’d start a song, or a project, and enjoy that creative process. I’d enjoy the opportunity to get in front of an audience (with a bit of marketing and relationship building with venues/bookers etc.). And to experience all that.

Times have changed.

My professional life requires a lot more headspace.

To even get a gig now requires a solid Facebook following. And a guaranteed audience.

I get that. I understand.

But I’ve come to realise that’s not what I connect with music around.

So… letting go of some of that, I decided I need to revisit the sorts of behaviours that got me started. And to let go of some of the baggage around the whole “making music” thing.

A new song doesn’t have to be a launching point for an EP or recording project.

A jam doesn’t have to be the launching point for a band.

A performance doesn’t have to be at a commercial venue.

So, I’ve been attending the Western Fringe songwriting sessions here in Katoomba. Stewart Peters and Snez have been organising these for some time (and until recently they were running at Parramatta at, the now defunct, Mars Hill Cafe).

Watching Stewart and Snez perform at those sessions was inspiring. It reminded me about the “why?” A passion for connecting with the creative spirit. To express oneself. To enjoy the process.

Since I’ve started attending the sessions, two songs have flowed. Not a lot (esp. compared to what I used to produce), but a start. And I’ve enjoyed reconnecting with the art. With that spirit. And having a small audience to share that with—not necessarily having to have it finished, polished, recorded, marketed, rehearsed, socialised via facebook et. al.

To just create. For the sake of it.

I was speaking to one of my besties the other day, and he was advocating the virtues of just woodshedding on your instrument. To find flow running scales, transcribing a favourite line, playing along with someone else’s work. And, importantly, not having to come up with something new.

There’s something very strongly appealing to me about that.

I remember many hours spent working out (and later transcribing) bass lines at home and at uni. ‘Shedding on scales and patterns from instructional videos from John Patitucci and other inspiring players. There was a joy. In the challenge. In the flow. In the developing of one’s own “voice” on the instrument, through understanding what you liked in others’. To find resonance with/in what others’ have got to say. And to pass that forward.

So I think I’ll be setting aside some time in the coming weeks to give it a go.

In the hope I can rekindle that connection to what is important to me about music.

To understand and process the world around me.

To express my emotions. To transform negative energy and experiences into something positive. (And to celebrate the positive stuff too.)

Quieting the inner critic

One thing I keep hearing is that I’m verbose. That I like complexity. That I’m technical.

I’ve decided that here is not about listening to those voices. Here is about me unpacking the world and digging for answers. Or failing that, at least insights. If it’s verbose, complex, boring, convoluted, unclear, lacking a point… that’s ok.

Perhaps in expressing the “unfiltered” version here, I’ll be more succinct, less technical, and express an elegant simplicity in other aspects of my life. We’ll see 😉

Letting go

It’s been forever since I just wrote a blog.

Just about something of interest. Something that makes me mad. Got me inspired. Something that just happened.

Not a series (though I still have hopes to do some of that too). Not “adding value”, other than in a sense of self expression (that someone else might connect with, but that’s not a requirement/intent). Just trying to make sense of the world.

That’s sort of come about as my work has centred more and more around doing what I consider valuable to work in, with and for communities.

A sense that I have to have something important to say. To share completed ideas. To somehow contribute to this (slippery) sense of “thought leadership”.

And a little bit of fear that what I might say might be misconstrued, or somehow impact my ability to do play the role I wish to play in my professional sphere.

Consider this a first attempt to break the pattern of “stop energy”.

To just reconnect with the idea of blogging. The thing that got me excited all those years ago (I started blogging around 2002, my current blog has entries back to 2003).

To have a voice in the wilderness.

To share.

To challenge.

To be challenged.

To learn.

To live true to the tagline that I started with, that inspired the name of this blog: “Thoughts that made it to the page.”

NZ MTB: Prepping for the plane

Man, can’t believe my last post was in January! In the last instalment I talked about the steps to get my bike to NZ. There were a few other little things that I had to work out before getting on the plane.

As you will have spotted in the photos in that previous post, I was traveling pretty light. Bike bag + one travel bag, which meant taking my hydration pack on the plane (and I had one checked bag + the bike bag).

I had to wade through the contents of my bag and remove any dangerous items (matches, lighter, pliers, multi-tool etc.). I left my pump in there with no issues (I have had one query on a plane ride since). Being an international flight I also removed all liquids (didn’t fill the pack, and removed the 200ml sunscreen I had in the bag) and put all that in the checked luggage. I forgot to do this on the return flight, and thus it was confiscated during the security check. Not a biggie, but annoying given how much suncscreen costs nowadays!

Due to weight/size restrictions I wasn’t able to take a floor pump, but my hand-pump had a pressure gauge and this proved sufficient for my needs (and I borrowed the odd floor pump once over there from bike stores and the shuttle operator).

I’d read that I should drop the pressure in my tires, but later found out it wasn’t really necessary. As I changed my tires just before I left, I just left them down, but this had the unfortunate side-effect of not properly seating the tubeless ready tires into the rims (which I discovered when I did a quick test ride around Rotorua on my arrival). On the return trip I didn’t bother dropping the pressure (I was running ~30 psi for the trails there) and didn’t have any issues.

I’d also read (in numerous places) and also been advised that the weather could be a bit unpredictable, so I picked up a long-sleeve merino base layer just in case.

I also booked a small station wagon through Rent a Dent, as they offered the option of a bike rack, and pick up in Rotorua with drop-off in Auckland (albeit with a return fee). And accoms of course (but I’ll list those in future posts). As an Australian citizen with a valid license I was able to drive in NZ without any issue (right hand drive, left side of the road, very similar signage and road rules).

NZ MTB: Getting my bike to NZ

First up, why take the bike at all? NZ is well setup for hire bikes, esp. around Rotorua, and I did consider this as an option. However, I’ve hired bikes twice in the past and have found them to be lacking (low quality and in lower states of repair than I’m comfortable with). I also have a reasonably high spec bike (a Specialized Epic Carbon Comp) and I wanted to take advantage of that. Especially as some good MTB mates, who are a lot fitter than I am, warned me about the climbs in NZ.

My trusty steed—Specialised Epic Carbon Comp

Lastly, I was planning on riding unfamiliar trails, and expecting to do a lot of climbing and spending a lot of time in the saddle (riding at least a couple of hours 7 out of the 10 days of the trip) so wanted something I could be confident on, that climbed well, and that I knew would be comfortable.

Speaking to the folks at PlanetBike while I was over there, they made that point that if you’re travelling to do MTB, take your bike. If you’re travelling to do holidays, and happen to want to do a ride or two while over there, hire. I think this is wise advice. I the end I’m glad I made the decision—having my own ride made the whole experience more enjoyable and I definitely benefited from taking my own ride.

Flight bag

Some time ago, I spotted my good friend Ashley had been using a flight bag for transporting his bike when travelling between Perth and Brisbane (and overseas). He recommended I check out the Evoc bike travel bag and after I’d checked out a few (positive) reviews, I managed to picked up a good deal through Wiggle (unfortunately it seems Wiggle aren’t currently stocking them).

I also estimated the combined weight of bike and bag to work out luggage costs etc. I used the old trick first weighing myself on a set of scales, then weighing myself holding the bike. I added this to the weight noted in the specs for the bike bag. It was close to the 23kg limit for standard luggage, so I was hopeful the specs weren’t out by too much. In the end, all packed the bike+bag came in 500g under the 23kg limit.

The bag was easy to assemble and quite robust. You have to disassemble parts of your bike—taking the wheels and pedals off, and releasing the handlebars from the stem—which took me a little while the first time around. But I was a lot quicker repacking the bike on my return.

My bike and luggage at the train station

This meant I chose to take some grease for screw threads and the like, and also a torque wrench (mine is very similar to this) as I was concerned about cracking the Thomson X4 stem. (I’d read reports/horror stories and wanted to make sure I didn’t make the same mistake).

Even though the airline had indicated a $120 oversize luggage fee would apply, in the end I wasn’t charged that for either outbound or return flights. I’m not sure if that would be the case had I come in over the 23kg mark.

The wheels and well designed handles on the bag made it relatively easy to transport around trains, cabs and the airport.

Taking a bike through customs

Another good friend and regular MTB co-rider, Mark, had travelled with their bike recently and reminded me that you need to clean up any dirt and mud off your bike and shoes before travelling to clear customs.

So after my last ride before leaving I got out my Green Clean bike cleaner and bicycle brush and gave it a really thorough clean up. I took the opportunity also to do a degrease.

The Evoc bag made it really easy to show the wheels of the bike, which is mainly what the customs officers was interested in (these are packed to the side of the bag, and have their own access zips/pockets. (This design also provides additional protection to the frame.) The customs officer also wanted to check my shoes as well—and I realised after I got there I’d packed them at the bottom of my bag… Lesson learnt and on the return trip I made sure they were more accessible.

NZ MTB: Planning (pt 1)

Before jumping into the fun stuff (i.e. the rides themselves) I thought it might be worth just touching on some of the things that helped in getting over to NZ.

As I noted in my introductory post, I was originally booked on the NZ Epic tour with Wild Horizons. I used this as my starting point and began researching different rides and shuttle options.

There’s a tonne of info online about the various trails around NZ, but it can be difficult sometimes to get the nitty gritty details and pull it all together into something more coherent.

I connected via email with Dan from NZ by Bike and he was really helpful. I connected with a number of tour and shuttle organisers, and managed to link up with Ted at Tread Routes to join another group that had booked his shuttle to ride the Great Lake Trail during the period I’d be in NZ.

I was interested in the Moerangi trail and read some reviews of the ride that mentioned the Jailhouse Farmstay who ran a shuttle and accommodation there. Early in my research it had seemed the shuttle had ceased to run, but later I found the site above and discovered that the shuttle still ran.

However, I wasn’t able to link into any pre-booked groups during the period, and it wasn’t cost effective to go solo for rides that required a shuttle.

Once I’d mapped out a few key rides (like the Great Lake Trail) I had enough idea of what I where I needed to be, so I booked my accoms at Rotorua and Lake Taupo (I was planning to stay with a friend in Auckland). Lucky I did, because the weekend I was in Taupo was also the weekend of the Contact Huka Challenge, where thousands of riders descend on Taupo. I managed to find one room left in the city, so I nabbed that and set about filling in the remainder of my itinerary.

After a lot of back and forth, my final plan ended up looking like:

Day 1: Fly in and orientation (Rotorua)
Day 2: Redwoods
Day 3: Redwoods
Day 4: Drive to Taupo, Craters of the Moon MTB park
Day 5: Great Lake Trail (Orakau to Whakaipo)
Day 6: Great Lake Trail (Waihaha to Waihora)
Day 7: Drive to Auckland
Day 8: Woodhill MTB park
Day 9: Woodhill MTB park
Day 10–11: Rest and return flight

I would have liked to have to have done at least one more trail ride (rather than 3 MTB parks), but as a solo rider this was really difficult due to shuttle costs/co-ordination. The only way this would be cost effective is to link in with another group, which I was only able to do for the Great Lake Trail. I wasn’t able to get one for the Timber Trail nor Moerangi on the dates I was there.