Jonathan Oxer
[Blog]
>> Interview by Marcus Schappi of Little Bird
Thu, Jan 21st 11:11pm 2010 >> Practical Arduino
Right after the Arduino Miniconf ended Marcus Schappi of Little Bird Electronics trapped Hugh and I in a corner and asked us a few questions.
Right after the Arduino Miniconf ended Marcus Schappi of Little Bird Electronics trapped Hugh and I in a corner and asked us a few questions.
>> Arduino Miniconf at LCA2010
Thu, Jan 21st 11:01pm 2010 >> Practical Arduino
Wow, it's all over! The Arduino Miniconf at LCA2010 was a blur of craziness but I had an absolute blast. It was the most fun conference event I've been to in, well, ever.
It started with a hardware assembly session to give all the software geeks a chance to use a soldering iron (some for the very first time) and build their own Pebble shield.

By lunchtime about 30 people had finished assembling their boards, and there were a lot of happy hackers around when they powered up their Arduino and got messages up on the LCD.

Both Vik Olliver and Patrick Herd brought along RepRaps to entertain the crowd. The morning assembly session and the early-afternoon "Introduction to the Pebble" sessions were run by Andy Gelme (seen in the white T-shirt and blue cap with his back to the camera above) who did an awesome job, and he was followed by a great line-up of speakers. A big thankyou to those who spoke at the miniconf:
Truly a 5-star line-up, and with a great range of interesting topics that sparked lively discussion.
Thanks also to all the helpers: the reason the hardware session worked out so well was that we had about 16 experienced people willing and able to give their own time to help out those with less experience. We ended up with a helper:participant ratio of about 1:2 and paired up participants, so every pair had at least one helper and nobody was left floundering around on their own.
Two participants got minor solder burns (not enough to need proper first aid, more of the "ow, that hurt!" variety) so to make it up to them they both received prizes. Speaking of which, we were lucky enough to have Apress provide a few copies of Practical Arduino and Nice Gear provide vouchers for two Duemilanoves and a pair of XBee modules, which we then distributed to participants.
There are a bunch of other people who contributed to the success of the Miniconf including many members of Connected Community Hackerspace in Melbourne who pre-assembled many of the hardware packs. Mitch Davis, in particular, chased down cheap deals on parts so we could make it as cheap as possible for everyone to take part.
Finally, but perhaps most importantly of all, a big thankyou to Luke Weston who put in so much work preparing the Pebble hardware and then didn't even get to attend the Miniconf. The Pebble PCB is his design, and while everyone at the Miniconf in Wellington was having fun assembling his creation he was sitting in Melbourne watching it on a live stream and wishing he was there.
Luke, your efforts are greatly appreciated by a lot of people.
I'll follow up later with links to slides and other resources for the various talks delivered during the Miniconf.
Wow, it's all over! The Arduino Miniconf at LCA2010 was a blur of craziness but I had an absolute blast. It was the most fun conference event I've been to in, well, ever.
It started with a hardware assembly session to give all the software geeks a chance to use a soldering iron (some for the very first time) and build their own Pebble shield.

By lunchtime about 30 people had finished assembling their boards, and there were a lot of happy hackers around when they powered up their Arduino and got messages up on the LCD.

Both Vik Olliver and Patrick Herd brought along RepRaps to entertain the crowd. The morning assembly session and the early-afternoon "Introduction to the Pebble" sessions were run by Andy Gelme (seen in the white T-shirt and blue cap with his back to the camera above) who did an awesome job, and he was followed by a great line-up of speakers. A big thankyou to those who spoke at the miniconf:
- Andy Gelme
- Justin Mclean
- Philip Lindsay
- Peter Chubb
- Nathan Seidle
- Vik Olliver
- Marcus Schappi
Truly a 5-star line-up, and with a great range of interesting topics that sparked lively discussion.
Thanks also to all the helpers: the reason the hardware session worked out so well was that we had about 16 experienced people willing and able to give their own time to help out those with less experience. We ended up with a helper:participant ratio of about 1:2 and paired up participants, so every pair had at least one helper and nobody was left floundering around on their own.
Two participants got minor solder burns (not enough to need proper first aid, more of the "ow, that hurt!" variety) so to make it up to them they both received prizes. Speaking of which, we were lucky enough to have Apress provide a few copies of Practical Arduino and Nice Gear provide vouchers for two Duemilanoves and a pair of XBee modules, which we then distributed to participants.
There are a bunch of other people who contributed to the success of the Miniconf including many members of Connected Community Hackerspace in Melbourne who pre-assembled many of the hardware packs. Mitch Davis, in particular, chased down cheap deals on parts so we could make it as cheap as possible for everyone to take part.
Finally, but perhaps most importantly of all, a big thankyou to Luke Weston who put in so much work preparing the Pebble hardware and then didn't even get to attend the Miniconf. The Pebble PCB is his design, and while everyone at the Miniconf in Wellington was having fun assembling his creation he was sitting in Melbourne watching it on a live stream and wishing he was there.
Luke, your efforts are greatly appreciated by a lot of people.
I'll follow up later with links to slides and other resources for the various talks delivered during the Miniconf.
>> Actual hard copies have arrived!
Thu, Dec 31st 1:59pm 2009 >> Practical Arduino
Originally posted on Practical Arduino
They're here!

Hopefully any day now they'll be arriving on the doorsteps of everyone who placed a pre-order. And if you haven't ordered it yet, here's a subtle hint.
Originally posted on Practical Arduino
They're here!

Hopefully any day now they'll be arriving on the doorsteps of everyone who placed a pre-order. And if you haven't ordered it yet, here's a subtle hint.
>> Practical Arduino: done
Mon, Oct 19th 9:59am 2009 >> Practical Arduino
Originally posted on Practical Arduino
Or at least it's done as far as Hugh and I can influence it, anyway. It's all in Apress' hands now: don't let us down, please!
I don't think I'm emotionally quite ready to do a de-brief post about the experience yet but I can give you a couple of stats about it.
And we now have a shiny looking cover.

Can't wait to see the real thing!
Originally posted on Practical Arduino
Or at least it's done as far as Hugh and I can influence it, anyway. It's all in Apress' hands now: don't let us down, please!
I don't think I'm emotionally quite ready to do a de-brief post about the experience yet but I can give you a couple of stats about it.
- Words: 143,048
- Projects considered: 92
- Projects shortlisted: 45
- Projects commenced: 22
- Projects included: 14
- Total chapters: 16
- Hours: far enough beyond 1,000 that it's scary
- Life lost: 7.5 months
- Prototyping shields used: 47
- Arduinos purchased: 25
- Trips to Jaycar: dunno, but I have a reserved parking space
And we now have a shiny looking cover.

Can't wait to see the real thing!
>> Car engine datalogger project update
Sun, Sep 27th 9:59pm 2009 >> Practical Arduino
Originally posted on Practical Arduino
The final project of the book is turning out to be epic. It's taken me far longer than I expected, and I've hit quite a few snags along the way. I've also had to make quite a few compromises because if I implemented everything I wanted it would take up half the book.
The big problem initially was communications with OBD-II, which was a piece of cake for my previous car datalogger (running on Linux) but turned out to be more tricky on an Arduino. Eventually it got to the point where I just cried and twitched a little bit whenever I thought about working on it, so to save my sanity I ditched my original codebase and switched to working on OBDuino instead.
OBDuino is an offshoot of the MPGuino project, which is primarily intended to be a tool for helping people drive more economically by providing real-time engine performance and fuel consumption information. It's developed collaboratively on the EcoModder website and it's a perfect example of what Arduino is really good at: providing a cheap, simple, flexible platform to allow people to develop something to suit their own requirements. There is now dedicated MPGuino hardware that has grown beyond its Arduino origins, but that's a good thing. It shows Arduino did its job.
Anyway, the point is that in the end it's been easier to take the functional code I had for GPS, flash memory storage, and a serial console, and graft those features onto the existing OBDuino codebase rather than graft OBD support into my codebase. So now I have an OBDuino variant that requires a Mega to run (unlike the original, which will run on a Duemilanove) but adds GPS and datalogging. The datalogging feature is really cool, because it logs GPS plus OBD-II data which can then be correlated and converted to other formats. This afternoon I went for a little drive and when I came back I wrote a script to parse the CSV file stored by OBDuino and generate a KML file to pass into Google Earth, with the result that I can now generate things like this:

(Click the image to see the whole thing full size)
The track is generated from the lat and lon stored from GPS, and the height indicates the speed of the car. By switching the columns selected by the script I can plot position against RPM, load, temperature, or any other value logged from the OBD-II data.
The prototype hardware is still a total mess and the code is only half done, but as long as I don't sleep for about the next 5 days the project should just sneak in within the publishing deadline.
Originally posted on Practical Arduino
The final project of the book is turning out to be epic. It's taken me far longer than I expected, and I've hit quite a few snags along the way. I've also had to make quite a few compromises because if I implemented everything I wanted it would take up half the book.
The big problem initially was communications with OBD-II, which was a piece of cake for my previous car datalogger (running on Linux) but turned out to be more tricky on an Arduino. Eventually it got to the point where I just cried and twitched a little bit whenever I thought about working on it, so to save my sanity I ditched my original codebase and switched to working on OBDuino instead.
OBDuino is an offshoot of the MPGuino project, which is primarily intended to be a tool for helping people drive more economically by providing real-time engine performance and fuel consumption information. It's developed collaboratively on the EcoModder website and it's a perfect example of what Arduino is really good at: providing a cheap, simple, flexible platform to allow people to develop something to suit their own requirements. There is now dedicated MPGuino hardware that has grown beyond its Arduino origins, but that's a good thing. It shows Arduino did its job.
Anyway, the point is that in the end it's been easier to take the functional code I had for GPS, flash memory storage, and a serial console, and graft those features onto the existing OBDuino codebase rather than graft OBD support into my codebase. So now I have an OBDuino variant that requires a Mega to run (unlike the original, which will run on a Duemilanove) but adds GPS and datalogging. The datalogging feature is really cool, because it logs GPS plus OBD-II data which can then be correlated and converted to other formats. This afternoon I went for a little drive and when I came back I wrote a script to parse the CSV file stored by OBDuino and generate a KML file to pass into Google Earth, with the result that I can now generate things like this:

(Click the image to see the whole thing full size)
The track is generated from the lat and lon stored from GPS, and the height indicates the speed of the car. By switching the columns selected by the script I can plot position against RPM, load, temperature, or any other value logged from the OBD-II data.
The prototype hardware is still a total mess and the code is only half done, but as long as I don't sleep for about the next 5 days the project should just sneak in within the publishing deadline.
>> Water flow gauge project update
Sun, Sep 13th 8:57pm 2009 >> Practical Arduino
Originally posted on Practical Arduino
I "finished" the first draft of the water flow gauge project quite a while ago but I was never really satisfied with it. It's quite an important project in the book because it's used to demonstrate some critical concepts such as interrupts, but as a project it wasn't really that useful. It only reported values via the serial port so it needed a host connected to do anything, and it just didn't quite feel like it added enough value to the book.
Over the last two days I've gone back and redone the project almost from scratch, leaving in place the original information about interrupts but expanding the project to include an LCD and buttons to allow it to be used as a stand-alone device.

In its new form it feels much more like a complete project. The LiquidCrystal library was something I really wanted to cover in the book but it hadn't fitted into the other projects that made the final cut, so re-jigging this project gave me the perfect excuse to demonstrate it.
And the final device fitted together so beautifully into the clear-fronted weatherproof case with splashproof pushbuttons that it almost feels like a work of art, even down to the exposed colorful PCB and wiring: something that I can feel proud to show people and tell them I built it.
Originally posted on Practical Arduino
I "finished" the first draft of the water flow gauge project quite a while ago but I was never really satisfied with it. It's quite an important project in the book because it's used to demonstrate some critical concepts such as interrupts, but as a project it wasn't really that useful. It only reported values via the serial port so it needed a host connected to do anything, and it just didn't quite feel like it added enough value to the book.
Over the last two days I've gone back and redone the project almost from scratch, leaving in place the original information about interrupts but expanding the project to include an LCD and buttons to allow it to be used as a stand-alone device.

In its new form it feels much more like a complete project. The LiquidCrystal library was something I really wanted to cover in the book but it hadn't fitted into the other projects that made the final cut, so re-jigging this project gave me the perfect excuse to demonstrate it.
And the final device fitted together so beautifully into the clear-fronted weatherproof case with splashproof pushbuttons that it almost feels like a work of art, even down to the exposed colorful PCB and wiring: something that I can feel proud to show people and tell them I built it.
>> Oscilloscope hardware all done
Sat, Aug 29th 5:57pm 2009 >> Practical Arduino
Originally posted on Practical Arduino
The hardware came together quite nicely, but the software side of this project is giving me a surprising amount of trouble.
The pic below shows it connected to the serial data line on an RFID shield mounted on a Mega:

Hardware works just fine, but the problem is that my computer at home is an original eeeBox with a totally underpowered VIA CPU, and when I have Processing (which is Java based, so ridiculously overweight) on the host trying to process a data stream being thrown at it at 115,200bps it keeps freaking out and becoming unresponsive. Most of the time the serial port won't even come back, which means I've been rebooting the machine about every 10 minutes.
It's driving me nuts so I've just taken some time off to play with a Seeed Studio pan / tilt servo mount which I'm controlling with a Sparkfun analog joystick and breakout board. At least *that* worked first time!
Originally posted on Practical Arduino
The hardware came together quite nicely, but the software side of this project is giving me a surprising amount of trouble.
The pic below shows it connected to the serial data line on an RFID shield mounted on a Mega:

Hardware works just fine, but the problem is that my computer at home is an original eeeBox with a totally underpowered VIA CPU, and when I have Processing (which is Java based, so ridiculously overweight) on the host trying to process a data stream being thrown at it at 115,200bps it keeps freaking out and becoming unresponsive. Most of the time the serial port won't even come back, which means I've been rebooting the machine about every 10 minutes.
It's driving me nuts so I've just taken some time off to play with a Seeed Studio pan / tilt servo mount which I'm controlling with a Sparkfun analog joystick and breakout board. At least *that* worked first time!
>> Crazy multi-processor ARM-based Arduino system
Thu, Aug 20th 8:44am 2009 >> Practical Arduino
Originally posted on Practical Arduino
This is so freaking awesome I don't even know where to start. I want to tell you about ten different things at once and they're all trying to crowd through the door at the same time and getting jammed together!
An email to the Arduino developers mailing list a few hours ago announced that the Arduino development environment had been ported to the ARM processor to support a project under development to create a reconfigurable computer consisting of tiny tiles. Each tile is about 2 square inches and is essentially a micro-sized motherboard: it's a self-contained computer with a CPU, RAM, EEPROM, I/O lines, comms, status LEDs, and an input button. Each edge has reversible connectors that allow them to be plugged together in any direction, even upside down, and each tile automatically detects its neighbors so it can start communicating with them. Power is passed through from one edge to another so to create a parallel array all you have to do is plug a bunch of them together, connect power to one edge of any tile, and it all springs to life.
Pure brilliance.
This is what four of them plugged together look like:

But the genius doesn't end there. They also implemented a crazy custom bootloader that allows software to propagate across a cluster, effectively allowing a programmer to "inject" a new piece of software into one of the edges and it will spread across the system. You can see it demonstrated in this video where they start with two separate clusters and inject a new program into one cluster and let it spread, then link the clusters together and it continues into the second set of tiles:
Right now they have an Arduino fork for the ARM code required to make this work, but hopefully it'll be incorporated into the Arduino mainline before long.
They've made their boards available for purchase through Liquidware so soon anyone will be able to start playing around with them for just US$57 / node.
Lots more information at:
Original blog post
Arduino forum post
Wired coverage
There's lots more to say but for now I'll just point you to those references and let you check it out for yourself.
Originally posted on Practical Arduino
This is so freaking awesome I don't even know where to start. I want to tell you about ten different things at once and they're all trying to crowd through the door at the same time and getting jammed together!
An email to the Arduino developers mailing list a few hours ago announced that the Arduino development environment had been ported to the ARM processor to support a project under development to create a reconfigurable computer consisting of tiny tiles. Each tile is about 2 square inches and is essentially a micro-sized motherboard: it's a self-contained computer with a CPU, RAM, EEPROM, I/O lines, comms, status LEDs, and an input button. Each edge has reversible connectors that allow them to be plugged together in any direction, even upside down, and each tile automatically detects its neighbors so it can start communicating with them. Power is passed through from one edge to another so to create a parallel array all you have to do is plug a bunch of them together, connect power to one edge of any tile, and it all springs to life.
Pure brilliance.
This is what four of them plugged together look like:

But the genius doesn't end there. They also implemented a crazy custom bootloader that allows software to propagate across a cluster, effectively allowing a programmer to "inject" a new piece of software into one of the edges and it will spread across the system. You can see it demonstrated in this video where they start with two separate clusters and inject a new program into one cluster and let it spread, then link the clusters together and it continues into the second set of tiles:
Right now they have an Arduino fork for the ARM code required to make this work, but hopefully it'll be incorporated into the Arduino mainline before long.
They've made their boards available for purchase through Liquidware so soon anyone will be able to start playing around with them for just US$57 / node.
Lots more information at:
Original blog post
Arduino forum post
Wired coverage
There's lots more to say but for now I'll just point you to those references and let you check it out for yourself.
1 of 3 >
[ Back to top ]
