Member Since: March 25, 2009

Country: United Kingdom



Currently doing a post-doc in Computer Science at University College London. I am primarily responsible for developing a framework which makes it (relatively) easy to test cognitive algorithms for coordinating teams of quadrotors in both simulation and reality.


Research Associate in Distributed Control of Robotic Systems


University of Oxford

Spoken Languages


Programming Languages

C++, C and Matlab primarily. Experience with loads of others though.


University College London Oxford University, DPhil University of Cape Town, MSc, BBusSci


IEEE 802.11 networks, localization and positioning, unmanned aerial vehicles,


Programming, computer science, electronics, inventing

  • Time for a little rant, which will likely fall on deaf ears because this product has been retired...

    I've spent a long time working on a project centred around this board. My application is simple: I wanted to trigger the device with a PIR sensor when somebody enters a room, and have a single file play over external speaker. Think, music or scary noises. Whatever tickles your fancy.

    I identified that the board's IO is 3.3v and the UART RX pin was pulled high by default. I modified the firmware to listen for PIR pulldowns on the RX pin. All worked wonderfully in my USB-powered test environment, but when powered by a 5v DC wall adapter everything went pear-shaped.

    Turns out that this chip has a fundamental issue, which is described quite nicely here: http://www.vsdsp-forum.com/phpbb/viewtopic.php?f=9&t=69. In a nutshell, the sparkfun breakout board design assumes that you are using headphones. And, in order to couple this board with an external (low cost) amplifier you need quite a bit of external circuitry between the mini-jack and your amplifier. Argh...

  • So I was poking around the sparkfun.com website source and I noticed this "snegg" javascript. I realised that if you drag the logo in the top left of the site home page, it reveals an egg that allows you to play snake. How long has this been around for, and does getting to some score make one a champion?

  • If you're havin' solder problems I feel bad for you, son; I got 99 problems but a pitch aint one.

  • Is there any difference between your firmware and usbspk.c from here: http://www.vlsi.fi/fileadmin/software/VS1000/usbspk.c?

    I recently flashed my breakout with this firmware, and its behaviour is quite similar to the stock firmware.

    I also have written up how to do this here: https://github.com/asymingt/vs1000d-linux

  • I spent some time putting together a toolchain to program this board in Linux. Right now, if you have a FTDI or other USB-to-serial cable, then you can program this board without Linux. I'm working right now to see if I can put together a FTDI-less solution using wine and vstool.exe. I'll update the README on github if I find a soluion.

    Here's a link to the toolchain code: https://github.com/asymingt/vs1000d-linux

    Cheers Andrew

  • Oooh! Good to see that you're expanding the Fez line. What about the "FEZ Cerbuino Bee" and "Cerb40". I could do with some Cortex-M4 love in my life...

  • Is there any off-the-shelf firmware that provides a simple i2c interface to access position / accuracy information? I'm familiar with UART / NMEA sentences, but the micro I'm using (Zigbit) has a shared UART / SPI which I'd prefer to avoid using...

  • I managed to fix the GPRMC string issue. The problem is that the maximum GPS sentence size is 82 bytes, yet uart1ISR.{c,h} defines the uart1Message character array too small. Thus, it overflows and loses the initial message characters. When used in conjunction with the NMEA C library (http://nmea.sourceforge.net) this works really really well! Note that you neet to modify time.c in the NMEA library to work with the RTC in stead of a _gettimeofday unix system call.

  • Like everything, it's always better built than bought!

  • David took his Chumby modding very seriously.