Odd Software for Odd Jobs

Adding DC power output to my "boombox"

So, I added an AUX-IN to my old Sony boombox. I can now connect my MiniDisc recorder or iPhone and play my tunes, as well as listening to tapes and CDs … oh, what a time to be alive!

I had been running my MiniDisc recorder off a single 1.5V AA battery but wondered about adding a DC output also to the boombox.

The radio tuner section that I have commandeered for my AUX-IN receives 6V from the main board. The MiniDisc recorder takes 3V from an external supply.

I started by figuring out what type of plug the Sony takes … the "Sony yellow tip barrel connector".

Turns out it's a 0.7mm (inner diameter) x 2.5mm (outer diameter) plug … Jaycar catalogue PP-0503. Also known as the "Nokia plug" apparently. Never knew that!

I'm going to use a 2.1mm plug & socket on the other end. So I made up a short cable.

2017-05-04 21.13.42

The first step was to see how much current the MiniDisc recorder would be drawing. I hooked it up to my lab power supply and gave it 3V … it drew about 300mA maximum (when first spinning up the disc and reading in the 10s of audio for the buffer).

I did muck around with regulators but gave up (I'm not clever enough). It's possible to get a 3V regulator but it needs at least a 3V headroom … with a supply of 6V that might be okay … in an "ideal" world. I didn't have any of those handy or easily available. I do have 3.3V regulators … a LM2936 and LM3940. The LM2936 would've been nice but it can only supply 50mA - not enough. I did fiddle around with an LM317 as well but I could never get it to work.

Besides, regulators are inefficient and I'm not sure how much current I'll be able to draw using the tuner's power rail.

There is a 3.3V rail available for the CD player, but I assumed that it wouldn't be powered if the radio tuner (i.e. AUX-IN) was selected. Maybe it is, dunno.

So I just used a more efficient DC buck converter instead! Simples!

2017-05-04 20.59.45

Stuck 6V in, tuned the trimpot to 3V out.

2017-05-04 20.59.34

And the MiniDisc record is happy!

2017-05-04 21.12.45

Checking the service manual again, I could see that +6V and GND were available here - there's a 0Ω link (JC1) for the +6V and a spot next to capacitor C58 for the GND … these are probably the easiest spots to tap in.

File 5-5-17, 12 25 42

There's no convenient hole like there was for the R + L channels, so I just drilled my own.

File 5-5-17, 12 26 09

Hacking away … new DC power output added to my earlier AUX-IN addition.

Honestly, it'd probably be easier if I just made my own replacement radio tuner board … bonus points. Need to check if I can get a similar flat flex connector.

2017-05-05 10.41.23

New hole drilled for the 2.1mm DC power socket.

2017-05-05 10.47.52

The AUX-IN and DC power sockets mounted.

2017-05-05 10.52.34

Jamming the 6V-to-3V converter in.

2017-05-05 10.58.28

Power out … and audio in!

2017-05-05 11.11.43

Sony never meant for this to happen, but their CDF-S350 is now powering their MZ-NH600 as well as taking audio in from it.

2017-05-05 11.11.52

Drawback - the audio and DC power share ground … so you hear digital noise when the MiniDisc recorder is starting up and when you change the song. This noise is not evident when playing, however, so I'm happy to live with it.

Adding AUX-IN to my "boombox"

We've got an "old" Sony CFD-S350 portable radio/CD/tape player (i.e. a "boombox"). So it doesn't really get much use any more - but if it had an AUX-IN then we could hook our MiniDisc or iPhone … or anything … and still use it.

2017-04-23 05.07.12

Pulling it apart …

2017-04-23 21.13.10

Disconnecting the flat flex connecting the CD unit and button controls from the main controller board

2017-04-23 21.12.22

2017-04-23 21.09.18

Removing the tape unit and speakers to reveal the radio tuner board …

2017-04-23 21.07.43

I still want to play the occasional tape and CD … but I don't really listen to radio, so let's see if there's something there I can use …

2017-04-23 05.07.12-3

(I've noticed that the Japanese use the Icelandic letter Ð instead of just plain D … makes sense as it prevent confusion with the letter O or digit 0!).

So there is a left & right channel coming into the main controller board (and amplifier I assume) that I could connect my AUX-IN to!

This is the radio tuner board with the flat flex connector on the right.

2017-04-23 05.07.12-2

The IC is a Toshiba TA2149-series … and the data sheet tells me these are the R & L channel outputs:

2017-04-23 14.04.40-1

Following the trace confirms that they run directly to the flat flex connector with nothing else in the way:

2017-04-23 14.03.33-1

I found the service manual for the CFD-S350 and noticed that there are two 0Ω resistors being used as links … so I could simply remove them, disconnecting the decoded audio from the radio tuner chip and hook my AUX-IN socket:

2017-04-23 17.39.18

Careful …

2017-04-23 20.50.14

Now hooking in my AUX-IN socket …

2017-04-24 13.08.44

Drilled a hole in the side of the case for the socket and put everything back together:

2017-04-24 17.11.46

2017-04-24 13.11.22

New life/use given to this still-working-fine piece of equipment!

2017-05-03 09.37.35

Bonus point … there's a 2Kbit CAT24WC02 serial EEPROM on the the underside of the main controller board … IC805, top right … that uses the I2C bus. I wonder what's on it … ? Maybe I could use an Arduino to read the contents?

2017-04-24 12.36.10

Fixing my Dell 2408 monitor

For many years I've had an Apple 24" screen twinned with a Dell 24" screen (both 1920x1200). However when I returned from my trip to Townsville, my Dell screen appeared to be dead … the green power LED was lit but the screen was blank.

Puzzled, I did some searching on the web - the opinion seemed to be either a blown fuse (but the power LED was lit) or an issue with the backlighting. Ahhh, no backlighting means a pitch-black display.

Dismantling the thing was the first hurdle - no screws to be unscrewed. More research showed that you need to prise the bezel off the front of the screen first.

Once inside I was presented with my first look of a flatscreen monitor's innards:

2016-12-03 15.26.36

The power comes into a small board, which is fed to another board with a few capacitors and transformers (where the main voltage conversion occurs?). This is connected to the main logic board (I guess) with all the various input sockets and a pair of heatsinked processors.

An additional daughterboard on the right plugs into the logic board to provide the additional USB hub and card reader functionality (note-to-self … if the screen dies completely, rescue this board):

Dell 2408 USB daughterboard

The power board also connects to the backlight daughterboard:

Dell 2408 backlight daughterboard

So, why wasn't the backlight working? With power connected, I measured the voltage being fed into the backlight board from the power board - I read that it should be 24V DC. Measuring between GND and each VIN showed 0V.

2016-12-04 10.45.50

So that's pretty obviously the problem - no power to the backlights, no backlighting, no display.

I checked all the capacitors - they looked fine. I then reseated all the cables.

I then noticed the backlights came on, through the holes in the board where the screws had been:

2016-12-04 10.53.22

Checking the display, I could now see images (menu, etc.) being displayed on the screen.

Cool. So it was "fixed". I decided to leave the screen out in the workshop, replacing the older 19" screen I had, as it was more versatile (more input options, USB hub). And I'd gotten used to using the Mac Pro with just a single 24" display anyway!

Upgrading my Early 2009 Mac Pro's RAM

After upgrading the CPUs, the RAM was still registered at 1066MHz. After some research, I found that resetting the PRAM (i.e. NVRAM these days) should get them running at the faster 1333MHz speed.

I tried it once … holding down Command () + Option () + P + R … during restart until you hear the startup tone (indicating the HW is okay).

It didn't seem to help. But, re-reading carefully … you need to keep holding it down until you hear the tone a second time (duh!).

Now the RAM is registered and running at 1333MHz!

Running GeekBench 4.0.1 I now get the following scores:

Single-Core Score

Multi-Core Score

Not a massive improvement, but hey … if the memory can do it, you might as well increase their speed!

Upgrading my Early 2009 Mac Pro's CPUs

Now that my old 2009 MacPro4,1 now looks like a slightly-less old 2010 MacPro5,1 I can replace the original 2 x 2.66GHz quad-core Xeons (X5550) with 2 x 3.46GHz hex-core Xeons (X5690):

Original stock CPUs:

Intel Xeon X5550 @ 2.66 GHz
2 Processors, 8 Cores, 16 Threads

Upgraded CPUs:

Intel Xeon X5690 @ 3.46 GHz
2 Processors, 12 Cores, 24 Threads

With the new CPUs it is also possible to use faster memory - I currently have DDR3 1066MHz (PC3-8500) but can now use DDR3 1333MHz (PC3-10600). Unfortunately that'll be another upgrade.

Anyway, I lumped for a complete kit on eBay (user ID: friendlycomputersusa) rather than just the bare CPUs. I didn't want to muck around. The kit I got was perfect - everything that was required including instructions.

As I'd already done the firmware upgrade for the macOS Sierra upgrade, all I needed to do was replace the CPUs.

This took me about 15min in total. Pretty easy.

The first thing to do was remove the massive heatsink/fan units.

2016-11-02 12.41.20

The X5550s were stuck on the bottom of the heatsinks but these came off pretty easily - remember which heatsink was for which CPU!!!

2016-11-02 12.52.24

Here's the CPU daughterboard with the heatsinks and CPUs removed, ready to pop the new CPUs in.

MacPro Motherboard with CPUs removed

First I need to blow out seven years of crud …

2016-11-02 12.51.55

Pop the new CPUs in … and importantly, because they have their 'hats' on still … put three brass washers on each screw post so that they are not crushed when the heatsinks are replaced!

2016-11-02 13.09.10

Put everything back together … aaaaaaand, yes, the start-up sound indicating all is well with the Mac!

The result:

MacPro upgraded

(note - the memory is still 1066MHz)

I tried out GeekBench4, running a benchmark before and after.

With the stock 2.66GHz quad-core CPUs:

Single-Core Score
Multi-Core Score

And with the new 3.46GHz hex-core CPUs:

Single-Core Score
Multi-Core Score

A decent improvement! If I replace the memory with the faster modules I should see a further bump in the scores.

My trusty Mac Pro should have a few more years of life in her now (seven so far) … barring Apple deliberately obsoleting her like they tried to with macOS Sierra …

Upgrading my Early 2009 Mac Pro to macOS Sierra, part 2

Okay, so I didn't bother doing a backup first. I've had terrible problems with OS X upgrades in the past, usually screwing up some how.

But I took the plunge - I'd already upgraded two Mac Minis successfully.

And … it went without a hitch. I don't think I've ever had an OS X upgrade go so smoothly, especially on my Mac Pro.

But I'm now running macOS Sierra on my (obsoleted) Early 2009 Mac Pro!


Next up … swapping the two quad-core CPUs (Intel Xeon W3520 Nehalems running at 2.66GHz) for a pair of hex-cored CPUs?

Upgrading my Early 2009 Mac Pro to macOS Sierra, part 1

So macOS Sierra was released. Went to download it on my trusty Mac Pro that i've tinkered & upgraded over the years … no dice! Apple has deliberately obsoleted my perfectly good Mac! Not such a big deal but it means that I can't install the latest Xcode.

Some searching around the Web and I found it is actually possible with some hackery.

First step was to hack the firmware so it was running the 2010 Mac Pro firmware. My Mac Pro will now report as MacPro5,1 instead of MacPro4,1 which should allow me to run the macOS Sierra installer.

Someone released a tool in 2011 to do this. It didn't work - gave a 5570 error. More searching showed this was solved simply by downloading the EFI firmware update from Apple ("Mac Pro EFI Firmware Update 1.5", DL1321) and then mounting the DMG. Running the firmware hack tool again was successful as it found the files.

However, the firmware wasn't updated - my Mac Pro still reported as MacPro4,1 after rebooting.

Further searching found the answer. As I am running OS X 10.11 El Capitan it has System Integrity Protection (SIP) enabled which restricts the root account and thus was likely preventing the firmware hack tool from working.

I disabled it as per the instructions - restarted my Mac in recovery mode (holding cmd+R during restart), opening Terminal and executing csrutil.

Rebooting my Mac again and trying the firmware hack tool - success!

My Early 2009 Mac Pro is now reporting as MacPro5,1.



In addition to being able to install macOS Sierra, I can also apparently run hex-core CPUs (so she can keep going for a few years yet!).

I haven't tried running the Sierra installer yet - I want to do a full backup first (need to replace a couple of drives in my external back RAID).

In Memoriam DSE

It's a little sad to see Dick Smiths (formerly Dick Smiths Electronics) fail and all the shops closed. I'd only been in a Dick Smiths shop a few months ago to try and purchase a pack of blank CD-Rs (as I wanted to burn some MP3 CDs for my car) - I'd already been in JB HiFi (my normal first port-of-call) and they didn't stock them (am I that old?), so had tried the Dick Smiths store - they also didn't stock them. I never really understood what the purpose of the Dick Smiths stores were - there was nothing compelling.

So I'd not been in one of them since the late 90s (before I left Australia for my stint overseas) - during my uni days I had a few friends who worked at our local DSE store in Underwood. I actually found reference to that store opening when flicking through an old Australian electronics magazine (also long since closed or absorbed by other publications):

File 23-04-2016, 13 49 38

Flicking through other old magazines, it's amazing to see the sheer number of ads that DSE used to place every month. Man, I wish I could've afforded this electronics hobby back then - so many "cool" (i.e. retro) bits of kit … even something I've been hunting for, a hexadecimal keypad. Anyway.

I've also discovered a "mint" kit that I purchased in DSE back in the 90s - the intention was so I could run my Sony DIscMan in the car. For some reason I never got around to building it

File 23-04-2016, 13 52 06

I also still have the Fun Way Into Electronics books …

2016-04-07 17.58.29-1

Average Speed Calculator, part 6

Road test! Drove into work and tested out the averaging functionality (i.e. the whole point of the project). Seems to work as planned! This was point-to-point on the motorway.

Now I'm just working on improving the user interface. It would be cool for the timezone to update automatically based on your location, but this would require too much memory. So I've settled for manually setting your timezone … still, it would be nice that it automatically updated the time as you drove across the NSW/Queensland border during Summer. It will determine DST automatically, though, based on the date obtained from the GPS.

2016-03-22 20.27_800px

Average Speed Calculator, part 5

Got myself a simple mobile phone holder - this one attaches to the air vents.

2016-03-21 14.49_800px

I checked the GPS coordinates it was giving me in Google Maps … pretty accurate.

Here's a shot when I was stationary at the traffic lights - this shows the speed & altitude display. The speed seemed accurate compared with my car's speedo - it was reporting about 10% more than the car's speedo, which I know under-reports by about 10% (a few years of using a TomTom and comparing the speeds).

2016-03-21 14.44_800px

I tried out the average speed calculator - the main purpose for this project - on the drive home from the local shops. I'm planning to take it out onto the motorway over the next few days, with my wife behind the wheel, so I can give it a proper test of the speed averaging, etc. whilst the wife concentrates on the driving.

2016-03-21 14.49-1_800px

As noted earlier, I already have a few ideas for the "Rev. B" prototype - I might make a few of those tweaks (LED blinking for GPS data reception, replacing the LCD contrast pot. with a fixed resistor). Let's see.

Average Speed Calculator, part 4

I finally took the plunge and implemented a hard-wired/veroboard version of my average speed calculator project.

I decided to use a bare Atmel chip rather than a full Arduino - I've got a few chips pre-programmed with the Arduino boot loader so I can simply program it in an Arduino Uno and then insert it into my circuit!

All you need is a 16MHz crystal across the X1 and X2 pins and its two 22pF load capacitors between X1/X2 and ground, and a 10KΩ pull-up resistor on the reset pin.

I've also got a 10µF capacitor across the Vcc and ground lines from USB input. I was originally going to also use a 5V regulator … just to be sure and in case I decide to add an alternative power source … but USB gives me 5V, so I didn't bother.

2016-03-16 23.33_800px

So that I could re-use the parts (like the GPS module and LCD) and to make it easy to construct/pull apart, I've used pins and sockets to connect the main components together - so much easier when installing the switches!

2016-03-17 17.54_800px

This was the result … and it worked!

2016-03-19 21.06_800px

Here is the board fitted into the jiffy box. I used a hot glue gun on the LCD ribbon cable to give it some extra strength (one wire already broke off the board). You can also see the 3.3V regulator on the right as the GPS module requires the lower voltage.

Additionally, I've used nylon screws instead of metal - they're much easier to cut-to-size, but mainly because it's expected that this would be mounted on the dashboard of the car. Having metal screws exposed to the Sun for hours probably would not be such a good thing!

2016-03-20 07.09_800px

I've used D0 to D5 for the LCD, D7 and D8 for the push button controls, and D12 & D13 for the GPS serial data.

This is the front panel construction:

2016-03-20 08.04_800px

Here are all the components mounted together. The GPS module is along the top - I've used some double-sided tape to hold the patch antenna in place.

2016-03-20 08.05_800px

A very tight fit! I probably should've used the next-size-up jiffy box, but I didn't want it to be too big. One issue is the blue potentiometer used for the LCD contrast - it's just in the way of the left-hand LCD plug. I could either replace this 10KΩ potentiometer with a resistor (establish the best contrast and measure the resistance), or move it slightly up so it's not in the way of the plug. For this Rev. A prototype, it'd be simplest to replace it with a discrete resistor.

The GPS module and antenna fit beautifully.

2016-03-20 08.09_800px

The final result! I was pretty happy with the holes I created for the power switch (on right side), USB socket (on bottom) and push buttons (on front). Unfortunately, the LCD cutout was a little off.

2016-03-20 14.36_800px

Now I just need to get one of those suction-cup holders for mobile phones and I can take it for a road test. It's essentially a GPS speedometer, which I've seen for $100 at Jaycar (item LA9025). But it looks pretty basic. I think mine's got more features/information!

I've already got some ideas for a Rev. B prototype:

  • Larger box - but might be solved by re-organising the circuit board a little;
  • An LED on the front panel to blink, indicating GPS data is being received;
  • Add time/date to the display - I had this earlier - due to the different timezones in Australia, I could add some basic timezone handling based on your GPS coordinates;
  • Include a serial-to-USB converter to make it easier to troubleshoot (i.e. debug log printing) - I already have a USB socket that I'm only using for power, so shouldn't be too difficult to get data out using the same plug.

Grotto Time, part 5

Upload to my website is finally working again - it only took my website just over three weeks to tell me what they changed that stopped it working (despite me telling them what I was trying to send and the exact minute it stopped working). Anyway …

So, it's allowed me to start working on it again.

I've added dew point estimation - this uses the temperature and relative humidity to estimate the dew point. It's a good measure of how humid the day feels. Also, when the ambient temperature is within a few degrees of the dew point, fog will form. It's sometimes nice to photograph the sunrise when it's foggy! So this will help warn me when it might be a foggy morning.

This information is now also uploaded to my website.

In addition, I've also added approximate sunrise & sunset times for my location in Sydney. The times are displayed on the LCD and change during the day - if it's after sunrise, then it will display today's sunset and tomorrow's sunrise. If it's after sunset, then it will display both times for tomorrow.

This is also uploaded to my website.

2016-03-06 19.18.44-1

Grotto Time - Arduino sketch

Here's the code for my little Grotto Time project.

I make no claim that it is perfect or written to excellent coding standards. It has accreted over the years as I've experimented and changed my mind.

It's built with three main components:

  • Freetronics EtherMega - needed due to the sketch size)
  • Freetronics ProtoShield Mega - sandwiched between the EtherMega & LCD, where all the sensors are connected
  • Freetronics LCD & Keypad Shield - so I can see the time

Additionally, I'm using a DHT22 sensor for temperature/humidity, BMP085 for pressure, an LDR to measure ambient light, a PIR to automatically control the LCD backlight and a DS1307RTC real-time clock. I might add a UV light sensor later - I need to figure out how to house it as it needs direct sunlight for the best reading.

The code works roughly like this (not necessarily in this order):

  1. Get an IP address
  2. Try to sync time via NTP and store this to the RTC
  3. If it can't sync via NTP, then read the time from the RTC - note, this assumes/requires that the time is synched via NTP the very first time it's powered up, maybe I can change this to get the time from the computer when the sketch is loaded?
  4. Check if max/min readings are stored in EEPROM - it currently keeps track of the max/min weekly, resetting every Sunday midnight, by storing in EEPROM I don't lose them if I restart the Arduino for some reason (updating the code, connecting serial monitor, etc.)
  5. Startup the sensors
  6. Store the startup time so we can track uptime

Now the main loop starts:

  1. Calculate the local Sydney time, including if DST is active
  2. If it's Sunday midnight, reset the max/min readings
  3. Cycle through each display of information every 5s
  4. Check the sensors every 2s
  5. Check the PIR - if there is movement then flick back to the time/date display and activate the LCD backlight for 5s
  6. Try to post the sensor data to a PHP script on my website every minute (customise the PHP_PAGE_LOCATION and SERVER_ADDRESS)
  7. Check buttons on the LCD shield - the select button takes us back to the time/date display, for example

And that's it.

Bike Sonar, part 5

I've been working on a "Mark 2" version of my Bike Sonar project.

I'm trying a MaxBotix ultrasonic sensor:

2016-02-11 17.01.46-1

I've also thought of using a wireless beeper. My original idea was to have it mounted on my helmet, but when I was fiddling around, I added an LED to the receiver circuit. Then I thought, what about mounting it on my handlebars?

After some tinkering, I managed to get the breadboard prototype working. You can see the transmitter (with MaxBotix ultrasonic sensor) on the right (with a yellow wire being used as an antenna):

2016-02-22 08.33.39

It's a pretty simple circuit - the 433MHz receiver will take a max of 5.5V so I'm using a diode to drop the (nominal) 6V from the 4xAA to less than that. This feeds the Vcc on the Rx board. I've got a 1µF electrolytic capacitor across the Vcc and DATA pins on the receiver - without it, the signal was VERY noisy (Instagram video). The DATA pin is connected to the base of an NPN transistor via a 100KΩ resistor. The emitter of the transistor is connect to ground and the collector is connected to the negative pin of a piezo transducer. The positive pin is then connected to the positive side of the battery pack.

Now this is my very-first "own designed" circuit, simple as it may be. I still haven't figured this out yet, but I had to add an LED between the transistor's collector and ground for the piezo buzzer to sound (and the LED lights at the same time).

When I replaced the transducer with a different type, I had to remove the LED. So I'm a bit confused. But this is why I'm doing all this - to learn and figure things out myself.

Anyway, I ended up using a different piezo transducer when I moved to veroboard. This is what I ended up with:

2016-02-25 17.59.34-1

The strange thing (for me) is that the LED/buzzer remain lit/buzzing if the power is on but no signal is being received by the Rx. So I've obviously screwed up somewhere in my simple design. But, it works enough for my purposes!

The next step will be to figure out how to mount this on my handlebars. I need to also implement the MaxBotix sensor on a new prototyping board, with an antenna for the transmitter. Then I'll be able to give my Bike Sonar, Mk. 2 a test run.

Project Idea: stereoscopic/3D in-car dashcam?

Are there 3D dash cams yet?

Had a thought - if you position a camera about the driver's position and then another over the front passenger's position then you would have both better visibility than a camera stuck in the middle and you could also combine the videos to generate a 3D recording with depth-of-field.

I wonder how cool that would look … ?

Foggy Morning!

It was a foggy start to the day here in Sydney. Checking my little clock/weather station it looks like low temperature & high humidity in the early morning might be a good indicator:

2016-02-16 07.28.54-1

Foggy mornings are nice for photography, but I need to get up early in order to make the trip to somewhere interesting before Sunrise … like the Sydney Harbour Bridge:


File 12-07-2015 13 51 07

So another idea for my Particle Photon - my first idea was to hook up a PIR sensor so I'd get a notification if there was movement in my garage.

My second idea is to hook up a temperature/humidity sensor as well. If it detects high humidity early in the morning (say, a few hours before local sunrise) then send a notification to my phone to get my lazy arse out of bed.

As the Photon has several inputs, I can have it monitoring several things at once for me.

Starting to get more excited about the possibilities of this little computer.

Replacement Sony MiniDisc remote, part 2

The RM-MZ3R MiniDisc remotes I ordered on eBay arrived today so I got to work pulling one apart to start figuring out how to emulate one so I could have a nice large control box rather than a fiddly little remote.

MD remote2

It's simply a bunch of resistors (and one capacitor), with the audio L/R channels passed through.

MB remote1

The audio uses three wires - ground (brown), left (white), right (red). The controls use two wires - grey (KEY) and yellow (+B). Two remaining wires were cut short and not terminated on the circuit board - these, I assume, are for the display information (the RM-MZ3R doesn't have a display).

The resistor values are:

  • R1 = 1KΩ
  • R2 = 1.3KΩ
  • R3 = 1.3KΩ
  • R4 = 47Ω
  • R5 = 1.5KΩ
  • R6 = 62Ω
  • R7 = 2KΩ
  • R8 = 1.3KΩ
  • R9 = 1.5KΩ
  • R10 = 2KΩ
  • R11 = 2.4KΩ
  • R12 = 2.4KΩ

There are ten switches:

  • S101 = hold switch
  • S102 = reverse, select left
  • S103 = FF, play, select right
  • S104 = pause, CAPS
  • S105 = stop, ENTER
  • S106 = VOL -
  • S107 = VOL +
  • S108 = TMARK
  • S109 = DELETE
  • S110 = EDIT

Various combinations of the resistors lead to the MD unit understanding what command was sent. This is what I'm working on now (yes, I can just find it on the Internet but I learn more this way).

To make it easier, I've removed the wires from the circuit board and replaced them with headers. I've also soldered the tiny wires onto a breadboard in preparation for tinkering with an Arduino. I used a hot glue gun to try to make the wires a bit more robust - let's see!

You can see the two shorter wires on the right - these are for the display information. Should be interesting to figure out how that works.

2016-02-15 20.32.23

I'm almost ready to start tinkering …

MD remote3

Particle Photon

This little marvel arrived today from SparkFun … a Particle Photon.

For no particular reason, here it is compared with an old Finnish 10 markka, South African 10c, Albanian 20 leke and an Aussie $1 coin.

2016-02-11 19.32.39-1

I'd forgotten I'd ordered it … and first thought it was just a WiFi module for Arduino. Then I realised it was a full micro controller with WiFi built-in. Wha … ?!

Not sure what I'll do with it yet. More for experimenting to see what it can do.

One idea, maybe. A tiny panic/distress alarm you can carry in your pocket when you're somewhere alone. Press a button and, as it's connected to the cellular network via your phone's WiFi, it will send a geo-tagged, pre-determined Tweet, SMS, FaceBook status and/or make a phone call. It can then also start recording audio, uploading every 30s

GameBoy Camera to iPhone, part 2

A very quick 'n' dirty test of the whole concept - the GameBoy Camera 'printing' to an Arduino, and the Arduino passing the output onto an iOS device. In this case I simply used the demo RedPark app on an iPad.

The picture below shows the data being received on the iPad from the GameBoy via the Arduino … the INIT string of 0x88 0x33 0x01 etc.

2016-02-09 07.34.21

So the next step is customising the code on the Arduino and on iOS. Probably I'll get the Arduino to filter out the control sequences and only pass the raw image data on to the iOS device.

One concern I have is that maybe the printer output is lower resolution than the actual image stored on the GameBoy Camera.

If so, I have a backup plan. A clever fellow, Alex/Alejandro at insideGadgets.com has created an Arduino shield for reading GameBoy cartridges.

2016-02-09 07.46.53

If the quality of the 'printed' images isn't as good as I was hoping then plan B is to read the image data from the SRAM of the GameBoy Camera cartridge using the Arduino, and then still pass it to my iOS program via the RedPark serial cable.

Anyway, let's see. It'd be interesting to try Bluetooth instead of the serial cable but I'm not too sure if Apple have imposed some artificial restriction.

GameBoy Camera to iPhone

This is a little project I started on a few years ago.

I thought it might be "cool" to take photos on my GameBoy Camera and upload them to Instagram on my iPhone.

To do this, I'd need an Arduino to emulate a GameBoy Printer. It would capture the image data "printed" by the GameBoy and then upload it to my iPhone's Camera Roll.

2016-02-06 14.34.23

This would give me experience in implementing arbitrary serial protocols, interfacing the Arduino with my iPhone (originally by RedPark serial cable, but maybe using Bluetooth instead?), and writing a simple iOS application.

I got started on it - cutting a GameBoy serial cable in half and creating a little breakout board. I'd done my research and found people had done something similar, but using a GameBoy Printer on the Arduino rather than using the Arduino as the printer. So I had somewhere to start.

Using my oscilloscope, I could confirm the INIT sequence being sent by the GameBoy but I got stuck trying to send the ACK. So I lost interest.

2016-02-07 07.18.42

But after being re-invigorated in my tinkering and inventing (maybe my family won't be forced to emigrate?!?), I'm having another crack at it.

Doing some more research today, I found someone who implemented something similar to what I want … roughly around the time I was working on it!

Of course, the serial protocol is very similar to SPI. That simplifies things!

Let's see how I go …

Project Idea: Car Protector

Another idea I had - re-use an old Nokia phone to send me an SMS if someone knocks or tries to break into my car.

The Nokia phones are perfectly fine and the older ones sip power. They just don't have 'apps'.

Connect an Arduino to the phone either via Bluetooth (for the newer models) or serial (using an Fbus/Pop-Port cable), giving the Arduino access to the wider world.

If there is some movement detected in the car, send an SMS to me via the phone. Additionally, also activate the dash cam I've already installed.

2016-02-05 16.11.22-1

Project Idea: Lost Bushwalker Finder

I had this idea for a project that may be useful (or more likely useless). And it may or may not have already been done.

It requires a Raspberry Pi, a WiFi dongle, and a drone.

The idea assumes that the lost bushwalker has a smartphone with WiFi switched on but are out of mobile coverage (which is why they haven't called for help). I read somewhere that some (all?) smartphones with WiFi switched on are always looking for an Access Point (AP) to connect to.

I wondered if it might be possible to pinpoint, or at least narrow down, the location of the smartphone (and thus lost bushwalker) by flying a drone overhead in a search pattern with a open AP running so that any device can connect. The smartphone may see the AP flying overhead and thus try to connect to it.

The AP, a Raspberry Pi with WiFi, logs the attempt as well as the GPS coordinates and relays this back to the searcher.

It also assumes that, as it's out in the bush, there aren't many smartphones around. It also assumes that the searchers have WiFi on their phones switched off to avoid false-positives.

The WiFi dongle (or whatever) on the Raspberry Pi would need a boosted antenna to help pick up the weak signal from the bushwalker's phone.

Anyway, was just an idea. Might not be practical. But I thought it would be interesting to try out. And I would finally have a good reason to buy a drone!

Unfortunately, my family's been under the threat of forced-emigration for a while now. Makes it hard to concentrate on tinkering and inventing when your Aussie family may be forced to emigrate from Australia.

Grotto Time, part 4

The sensor data upload to this website now seems to be running quite smoothly - the 'clock' uploads its data every minute or so, and the page auto-refreshes every 30s.


I've also revised the shield I made with the sensors - I've removed the DHT22 temperature/humidity sensor as I thought it was probably too close to the WizNet chip on the Arduino board, thereby skewing the readings. I had another one lying around from my very early Arduino experimenting - it was already on a length of wire so was perfect. I could move the sensor away from the board and place it somewhere else.


With the space freed up by removing the sensor from the board, I added a light-dependent resistor. This would both give additional data to upload as well as controlling the LCD backlight. When it's dark in the garage (i.e. lights are off and I've gone to bed) then the backlight will automatically switch off - video testing it. I've also added an additional screen of information showing the RTC's battery level and the LDR/ambient light level.

2016-02-04 16.54.04

So, this project is pretty much complete - two-three days in total, both hardware and software! The Arduino code is a bit messy and not optimised, but it works! Cleaning it up will be the next step. But first, I just need to figure where I'm going to mount it in my workspace. And come winter time, I'll be able to check the temperature outside on my phone whilst still hiding under the covers!

Grotto Time, part 3

There's one small design flaw I can see already.

The AM2302/DHT22 temperature sensor (white one on the right below) is not far from the WizNet chip that handles the Ethernet connectivity on the Arduino.

GrottoTime shield

This chip generates a bit of heat, and so will probably be skewing the temperature measurements.

Not a big deal - I can move the sensor off the shield and place it a short distance away, connected via wires. This should give a more accurate reading. And it will free-up space on the shield for a light-dependent resistor, perhaps, to automatically switch the LCD backlight off when I've switched the lights off and gone to bed … ? At the moment I can toggle the backlight on/off with the keypad select button.

Before I sort that out though, I've incorporated the web upload code again … and it appears to be working … intermittently. Still need to iron the kinks out.

And I'm working on adding some automatic DST handling too - here in NSW, DST starts on the first Sunday in October and finishes on the first Sunday in April. So shouldn't be too hard to come up with a routine to decide whether it's on or not.

But you can check the current-ish weather in my garage, aka Nerd Grotto, by visiting the page here:


Grotto Time, part 2

I started my GrottoTime project a few years ago - I wanted a clock for my "Nerd Grotto" (i.e. workspace in the garage). I figured it would be a good project to learn how to use a real-time clock (RTC) and Ethernet connectivity.

So I came up with something that would initially poll the time from an NTP server and store it to the battery-backed RTC. It would also check the current temperature/humidity/pressure. This would be displayed on the seven segment LED displays. Additionally, it would upload the sensor data to my website … the thinking was I could wake up in the morning during Winter and quickly check the outside temperature on my phone.

Anyway, the breadboard version worked. The harder part was coming up with a hardwired version.

This is what I settled on - I would use a Freetronics EtherTen board (Arduino Uno with Ethernet & SD card). I shaped a vero-strip board to fit around the Ethernet port of the EtherTen. This would be a shield that would have all the components.

Anyway - this was the result:

Grotto Time Mk. 1

Unfortunately, there appears to be a hardware. The DHT22 temperature sensor (the white thing) fails to start up. The connections look good for it look good.

So it looked like I'd have a lot of frustrating hours fault-finding.

But … as I'd recently figured out how to use LCDs (yeah, simple), I decided to start from scratch. The EtherTen had problems with a lack of memory - it just couldn't fit all the code I wanted it to do … polling the time via NTP, uploading the sensor data, etc.

Thus, here is Mark 2. Much better looking, yes?

  • Changed the EtherTen for an EtherMega (more code space),
  • Used a Freetronics LCD + keypad shield,
  • Used a prototyping shield sandwiched between for the sensors - RTC, barometric pressure, temp/humidity

GrottoTime Mk. 2

Here it is working - I've got a few screens of information working that can be scrolled through using the keypad buttons.

2016-02-02 21.56.04

I've been slowly bringing my original code across to a new sketch, replacing the LED code with LCD code.

The time is initially synched via NTP. This is stored to the RTC. Thus it can then run offline or online. Of course, to upload the data to my website it needs to be online. The idea is that it'll be on the wall in the garage connected to a cheap WiFi access point via an Ethernet cable.

The code is a bit of a mess at the moment, but it works. I'm currently working on adding some automatic DST setting.

Project Idea: Replacement Sony MiniDisc remote

A project idea to exercise the brain - replace the RM-MC38EL remote control on my Sony MiniDisc recorder with a larger unit.

2016-02-01 06.47.07

It would use a larger and easier to read 16x2 LCD and buttons controlled by an Arduino. This will make it more like a component unit and make it easier to use in my workshop than the fiddly little controls it has now.

Sony never made a component HiMD.

The hardest bit will be the plug - either cannibalise a remote or somehow simulate it? Two pins are used to send commands to the MD (different resistance for each command) and the other two for sending data to the remote's display (will need to figure that out!). It does appear easy to acquire Sony RM-MZ3R remotes on eBay, giving me access to a source of the plugs. It would be nice to have just the four-pin plug, leaving the headphone socket free.

I did find a similar project that pre-dates Arduino. In this case it was to allow the use of infra-red remote controls.

Might turn out to be another dead-end ... but it is fun to experiment!

DarcyBot, Mk. 2

This is the second iteration of the first 'robot' I ever built with my eldest son Darcy.

The first was a fairly bog-standard robot - it had two bumper-switches at the front. Move forward until one or both are triggered. Back-off, turn a bit, then proceed.

That was fun. We learned how to use H-bridges to control motors and how to make simple decisions.

We figured a new challenge would be to understand how to interface discarded bits of electronics - in this case, we had the transmitter and receiver of a broken remote controlled police car.

You can see the final result below - we even kept the flashing red/blue lights.

2016-01-31 21.16.40

The transmitter/controller was re-housed in a new box. Pretty simple - just wire up new buttons for forward/reverse/left/right to the circuit board and add a new battery holder:

2016-01-31 21.15.17

The robot itself is built upon a tracked chassis (Jaycar KR-3130, seems discontinued). In the picture below you can see the separate parts:

2016-01-31 21.09.58

The brain is a Freetronics Eleven (Arduino Uno compatible). There are then two shields plugged into the Arduino. The first shield, sandwiched in the middle between the Arduino & the top shield, is the H-bridge. We used a pair of L6202 full-bridge drivers, one for each side of the robot.

2016-01-31 21.10.22

On top of this is another shield that is used to interface the Arduino with the receiver from the broken toy car. The receiver is attached with some double-sided tape (high-tech). The black & red wires are for the flashing lights and the yellow wires are the control signals received from the transmitter - backwards, forwards, left, right.

2016-01-31 21.11.04

The control signals are fed into the Arduino via the analogue inputs. These are simply read and the motors controlled appropriately.

So, from this exercise we learned:

  • What are H-bridges and how they're used to control the direction of motors
  • How to program simple intelligence into a robot to allow it to make decisions based on stimuli
  • How to interface discarded bits of electronics to allow wireless control of completely different devices
  • To never throw away remote control stuff - it can be re-used for simple, one-way wireless communication (i.e. a weather station sensor)

The next iteration of the DarcyBot will probably be some sort of line or light follower - this will teach us how to use visual inputs.

Average Speed Calculator, part 3

Took my little average speed calculator for a quick field-test around the local streets. Seems to be doing the job I wanted it to. Need to enlist the wife's help to do a proper test at highway speeds.

Field test

I also added a sixth screen of information - the maximum speed recorded and the timestamp:


I still need to sort out the localisation of the date from the UTC date received. And also tidy up the code - add some more functions instead of just replicating the code (I feel terrible about it!).

Average Speed Calculator, part 2

I have got my prototype ready for field-testing, i.e. driving around in a car.

The final parts list is:

  • Freetronics Eleven (Arduino Uno compatible)
  • GPS module using a u-blox NEO-6M (board is labelled "GY-GPS6MV2")
  • 16x2 LCD display (labelled "JHD162A")
  • Two SPDT microswitches that I've soldered onto the prototyping area of the Eleven (Jaycar SM-1036)
  • 10kΩ potentiometer to control the LCD contrast
  • 1 x 4.7kΩ, 3 x 10kΩ, 1 x 220Ω resistors

The 4.7kΩ & one 10kΩ resistor are used for the GPS module's Tx pin to the Arduino (the GPS module uses 3.3V).
The 220Ω resistor is connected between the LCD display's pin 15 (LED+), the backlight anode, and the Arduino's 5V supply.
The final two 10kΩ resistors are connected between the switches and the Arduino.

One of the buttons is used to switch between five screens of information:

Screen #1 - current speed and altitude


Screen #2 - when speed averaging is activated (i.e. when you pass under the first point-to-point camera), it shows the duration since it started and the current calculated average. The asterisk indicates whether the average is currently being updated (asterisk) or is from the previous activation (no asterisk)


Screen #3 - current latitude and longitude


Screen #4 - number of visible satellites and the current HDOP


Screen #5 - finally, the current date & time - the date/time is received in UTC so I've hardcoded +11 hours to compensate for current Sydney DST


Oh, bugger - I haven't bothered compensating the date either. Okay, still some polishing to do.

Anyway, the Freetronics Eleven can be run off 5V via the micro-USB or 7-12V so I have the option of wiring up a cigarette lighter plug to power it or simply use a cigarette light -> USB plug.

If it seems to be accurate - I'll measure against my TomTom - then I'll move to the next step and create a proper hardwire prototype in a jiffy box.

Here's the current Arduino code if anyone is interested - I used Mikal Hart's 'kitchen-sink' example from his TinyGPS++ library as the basis.

Average Speed Calculator

There are now a few point-to-point speed cameras on the highways in Australia. These apparently calculate your average speed over a fixed distance by snapping your number plate at the start point and then again at the end point. Now I know that my car's speedometer under-reports by about 10% - if it says I'm doing 100km/hr then I'm actually doing about 92km/hr. I've confirmed this from both my TomTom SatNav and by the road-signs they have roadworks that flash your speed up at you.

So I was wondering if I could hack something together to get a rough estimate of what my average speed is in real-time. I got a GPS unit off eBay some time ago but never got around to trying it out - it's a uBlox NEO-6M (marked GY-GPS6MV2).

Anyway, I finally gave it a go using the TinyGPS++ library by Mikal Hart.

And it worked pretty much straight away! Too easy. Thanks Mikal!

I wanted to use an e-ink/e-paper display so it would be nice and clear. I'd also gotten a 2.7" screen with developer board from Adafruit some time ago, but again had put it aside whilst I worked on other things.

So this was my starting point:

2016-01-26 07.15.08-1

The e-paper display was a harder to get going - a lot harder. The instructions on how to put it together were clear enough, but I found a lot of difficulty getting the examples to work. I finally got one of the examples to work using an Arduino Mega. Unfortunately, it seems the available libraries are slanted towards graphics rather than just text. As I'd gotten the largest 2.7" version, it turns out there's not enough memory to really run it properly. I'd have been better off using the 2" model perhaps.

So that was a disappointment. I might re-visit this later. In the meantime, I had a few 16x2 LCD displays lying around, so put one to use pretty quickly & simply. Unfortunately the contrast was all wrong (I'd used a 1kΩ to ground and a 10kΩ to 5V), but you can just make out the latitude and longitude from the GPS unit being output on the LCD:

2016-01-27 18.46.20-1

I sorted the LCD contrast issue pretty quickly by replacing the two resistors with a 10kΩ pot (blue). I've also added a momentary action switch to the small prototyping area on the Freetronics Eleven board to use as a start/stop button. Added some quick de-bouncing code and it was working as desired.

2016-01-27 20.09.36

So the next step will be to figure out how I want to calculate the average speed - so I just average the speed that the GPS unit reports, or do I actually calculate the distance travelled and divide by the time between start & stop button pushes … ? Something to figure out later.

As I'm limited to just a 16x2 display at the moment, figuring out how to display the info I want might be the biggest challenge! But let's see.

Gotto Time

This is my most ambitious project from about three years ago.

I wanted to create a 'wall clock' for my workspace in the garage. It would do the following:

  • Initialise the current local time via NTP,
  • Store the result to a battery-backed real-time clock,
  • Check the current temperature (and humidity),
  • Alternately output the time & date and then the temperature & humidity via two four-digit seven-segment LED displays,
  • And finally, upload the data to my website so I can lazily check the temperature in the garage from anywhere in the world!

I had a breadboard version pretty much working. The hard-wired version was about 80% complete when I got bored (about three years ago).

This is the state it's been in for a while - pretty much done except for the LED display wiring.

It's in two parts - the 'shield' that I'm building sitting on-top a Freetronics EtherTen.

Grotto Time

This is how it will look when assembled:

Grotto Time, assembled

And this is the underside view - you can see the LEDs haven't been soldered in yet:

Grotto Time, underside

I had some issues fitting all the code into the 32kB available - I think I had to exclude the NTP code as I originally developed it on an EtherMega or something.

Anyway, it was working! The webpage were the data was uploaded is still 'working' … just waiting for new data:


Let's see if I can get it working!

Temperature & Humdity

This is one of my very early experiments with Arduino that succeeded in the move from idle breadboard tinkering into a "manufactured product".

I built a thermometer for my son. It comprises:

  • an Arduino Micro,
  • a DHT22 temperature & humidity sensor (labelled "AM2302"),
  • a two-digit, seven-segment LED display (labelled "CA15621BS", common anode),
  • a 10kΩ resistor for the DHT22,
  • seven 680Ω resistors for the LED display,
  • a SPST temporary action pushbutton,
  • a 9V battery,
  • and an iPod touch case

The result can be seen below:

Temperature Gauge 1

Temperature Gauge 2

(Probably could've made the black negative wire from the switch to the circuit board a little longer)

Why a momentary action switch? I didn't trust that my young son would remember to switch it off after quickly checking the temperature - so you need to hold the button down to check the temperature. So far I've never had to replace the 9V battery!

The LED display alternates between temperature and humidity. As I live in Sydney and the display is limited to two digits, there is no expectation that negative temperatures are needed. Actually, checking the code I wrote, it seems that I don't bother checking the temperature result at all - I think I assumed that the temperature returned by the DHT22 will always be above freezing point (0 Celsius)! Maybe I need to do some cold weather testing, or at least add some sanity checking! Anyway, it's safe for Sydney usage at least.

The code is here.

Here's a short video of it in action.

Bike Sonar, 2nd test run

Took it for a quick test run this morning. No traffic around so I couldn't properly test it, so I rode past some parked cars instead!

Here's a screen grab from the Fly6 video.

Fly6 screengrab

An idea for a different implementation - replace the LED display with a Bluetooth module and feed the data to an app on my phone. This would be an opportunity to both figure out how to implement BT in my Arduino projects and also how to write an iOS app.

Anyway, refinement continues. I will probably replace the LeoStick with an Arduino Nano clone so I can run it off a 9V battery and thus enclose the ultrasonic sensor, Arduino and battery in a more-waterproof Jiffy box or similar. I could probably do the Bluetooth version at the same time so the whole sonar would be in a single box - much less fiddly.

I'm having fun regardless of how useful this may turn out to be!

Bike Sonar, Arduino code

Here's the Arduino code of the prototype I've got running on my bike after a bit of cleanup.

// Simple "bike sonar" ... aka rear parking sensor for a bicyle Winking
// Version 1.1, Brett Hallen, 2016
// Uses: HR-SC04 ultrasonic sensor,
// MAX7219 LED driver,
// four-digit LED display,
// and a piezo buzzer (Jaycar AB-3459)
// Implemented on my bike using a Freetronics LeoStick - requires 5V
// so powered with a "USB battery bank"

// http://playground.arduino.cc/Main/LedControl
#include "LedControl.h"

// http://playground.arduino.cc/Code/NewPing
#include "NewPing.h"

/* ---------------> Sonar Stuff <--------------- */
#define triggerPin 7
#define echoPin 6
#define maxDistance 400 // the HR-SC04 has a max range of about 450cm
#define triggerDistance 100 // when to trigger buzzer, in cm
#define pingDelay 50 // pause between sonar pings
NewPing sonar(triggerPin,echoPin,maxDistance);

/* ---------------> LED/MAX7219 Stuff <--------------- */
#define Din 8
#define CS 9
#define CLK 10
LedControl lc = LedControl(Din,CLK,CS,1);

/* ---------------> Speaker Stuff <--------------- */
#define speakerPin 12

void setup()
int i = 0;

// for verification of ping result to serial monitor

// initialise the LEDs
// Intensity between 0 (lowest) and 16 (highest)

// Bit of fancy "I'm powering on, running setup()" indication
// print 0123 on LED
for (i=0;i<=3;i++)
lc.setChar(0,i,' ',false);
// print 3210 on LED
for (i=3;i>=0;i--)
lc.setChar(0,i,' ',false);

// initialise speaker output
pinMode(speakerPin, OUTPUT);

// setup done

void loop()
// pause between sonar pings

// send a ping
int uS = sonar.ping();

// calculate distance in cm
int distance = uS / US_ROUNDTRIP_CM;

// print distance on the LED

// object closer than minimum distance?
if (triggerDistance > distance)
// closer the object, the faster the 'beeps'
int toneDelay = distance * 5;
// turn on LEDs
playTone(toneDelay,500); // beep
delay(toneDelay); // pause
playTone(toneDelay,500); // beep
else if (250 < distance)

void printDistanceOnLED(int distance)
int metres = distance / 100;
distance = distance - metres * 100;
int cms_tens = distance / 10;
int cms_ones = distance % 10;

// only display digits if non-zero
// no need for thousands digit
lc.setChar(0,0,' ',false);

// display hundreds digit?
// yes if it is non-zero
if (metres)
lc.setChar(0,1,' ',false);

// display tens digit?
// yes if it is non-zero or we already have displayed the hundreds digit
if ((cms_tens) || (metres))
lc.setChar(0,2,' ',false);

// display ones digit?
// yes if it is non-zero, or we already have displayed the hundreds or tens digit
if ((cms_ones) || (cms_tens) || (metres))
lc.setChar(0,3,' ',false);

// for verification to serial monitor
Serial.print(metres); Serial.print("."); Serial.print(cms_tens); Serial.print(cms_ones); Serial.println("m");

// duration in milliseconds, frequency in Hertz
// http://michael.thegrebs.com/2009/03/23/playing-a-tone-through-an-arduino-connected-piezo/
void playTone(long duration, int freq)
duration *= 1000;
int period = (1.0 / freq) * 1000000;
long elapsed_time = 0;
while (elapsed_time < duration) {
delayMicroseconds(period / 2);
digitalWrite(speakerPin, LOW);
delayMicroseconds(period / 2);
elapsed_time += (period);

Bike Sonar, part 4

So this is what I've ended up with for mounting on my bike - bit of wood, a lot of cable ties, a bit of galvanised steel and some bolts (that has holes that perfectly lined up with where my red reflector was).

2016-01-16 15.17.33

Bike Sonar

2016-01-16 15.18.05

The display is mounted so that the distance is captured on video by my Cycliq Fly6.

I made the mistake of running the LeoStick from a 9V battery - whoa, that smelt bad when it blew! Silly mistake - I'd earlier used an Arduino Nano clone that happily ran off a 9V and had assumed the LeoStick was the same (when you assume, you make an ass out of u and me … but just me in this case).

So down to Jaycar to grab another LeoStick. But how to power it? There's no 5V batteries - could I used 6V directly? Probably not - I'd have to add a voltage regulator to my circuit to knock it down to 5V - a bit of a re-design after all that fiddly soldering I did!

But then got the idea to use one of those USB battery banks you can recharge your phone with.

Unfortunately, the battery bank I got is too clever … it can tell a phone isn't plugged in and so switches off. As a workaround, I have to plug my phone into the second USB output socket (shaking head).

I took it for a test ride … and it worked! Unfortunately, the cycling infrastructure around where I live is pretty good - lots of bike paths, so I didn't really get a chance to ride on the road. But I simulated by riding up close to parked cars.

First thing I realised … an LED display is not much use in the middle of the day! Not bright enough. Anyway, made some tweaks and did a static test after I got home.

Bike Sonar, part 3

Now, the idea seems to work on a breadboard.

To properly test it, I need to move it to something that can be attached to a bike and powered off a battery.

My original idea was to have the Arduino, ultrasonic sensor, LED display driver mounted on one circuit board at the back of the bike and the LED display mounted remotely on the handlebars.

Bike sonar, original plan

Slept on it, then decided to use a Freetronics LeoStick with the ultrasonic sensor mounted above it on a ProtoStick. The piezo buzzer, LED display and driver IC would then be mounted separately and I'd use my Cycliq Fly6 to record the results.

Bike sonar, new plan

This is what I ended up with - my original breadboard prototype at the top and the bike-ready prototype at the bottom:

2016-01-16 11.53.52

I had an old DSLAM serial-port cable handy with a handy ten-pin connector so I used that to link the two circuit boards.

Moving to the LeoStick required some port changes … note to self … solder the components to the ProtoStick first … and THEN solder in the male header pins (damn amateur).

Anyway, it worked pretty much straight away! Phew.

Next step - somehow mounting it on my bike!

Bike Sonar, part 2

The Arduino is coded up and it seems to be working!

Here's the Arduino code - pretty simple.

(sorry, I don't know how to display code all fancy-like at the moment!)

#include "LedControl.h"
#include "NewPing.h"

/* ---------------> Sonar Stuff <--------------- */
#define triggerPin 12
#define echoPin 10
#define maxDistance 400
NewPing sonar(triggerPin,echoPin,maxDistance);

/* ---------------> LED Stuff <--------------- */
#define Din 7
#define CLK 8
#define CS 9
LedControl lc = LedControl(Din,CLK,CS,1);

/* ---------------> speaker Stuff <--------------- */
#define speakerPin 11

#define triggerDistance 100 // cm
int i = 0;

void setup()

// LEDs
for (i=0;i<=3;i++)
lc.setChar(0,i,' ',false);
for (i=3;i>=0;i--)
lc.setChar(0,i,' ',false);

pinMode(speakerPin, OUTPUT);


void loop()
int uS = sonar.ping();
int distance = 0;
int toneDelay = 0;

distance = uS / US_ROUNDTRIP_CM;
toneDelay = distance * 4;

if (triggerDistance > distance)

void printDistanceOnLED(int distance)
int metres = 0;
int cms = 0;
int cms_tens = 0;
int cms_ones = 0;

metres = distance / 100;
distance = distance - metres * 100;
cms_tens = distance / 10;
cms_ones = distance % 10;

// only display digits if non-zero
if (0 != metres)
{lc.setDigit(0,1,' ',false);}

if ((0 != cms_tens) || (0 != metres))
{lc.setDigit(0,2,' ',false);}

if ((0 != cms_ones) || ((0 != cms_tens) || (0 != metres)))
{lc.setDigit(0,3,' ',false);}

lc.setDigit(0,0,' ',true);

Serial.print(metres); Serial.print("."); Serial.print(cms_tens); Serial.print(cms_ones); Serial.println("m");

// duration in mSecs, frequency in hertz
// http://michael.thegrebs.com/2009/03/23/playing-a-tone-through-an-arduino-connected-piezo/
void playTone(long duration, int freq) {
duration *= 1000;
int period = (1.0 / freq) * 1000000;
long elapsed_time = 0;
while (elapsed_time < duration) {
delayMicroseconds(period / 2);
digitalWrite(speakerPin, LOW);
delayMicroseconds(period / 2);
elapsed_time += (period);

Bike Sonar

Hi! This is my first attempt at a blog, so bear with me!

The easiest way I find of learning something new is to have an idea of something you want to create and then go about implement it, learning the pitfalls and how to solve them. I've never been any good at just reading a book and then creating some software.

So where I live in Australia, the government is introducing new laws this year regarding safe passing distances for cars & bicycles. Simply, allow a 1m gap. It's obviously not something you need to get out a ruler and measure but rather to get the mindset that pedestrians are a lot easier to kill than cyclist, and cyclists are a lot easier to kill than motorists. So just think and be courteous to other road users, regardless of their means of transport … no one person owns the road or has any greater rights.

Anyway, this gave me an idea to implement a simple little sonar for my bike. Essentially it's just a 'rear parking sensor' for a bike! The idea is if a car gets too close then an audible warning can be given to the cyclist. It also has a display so that the actual distance can be captured by a video camera, like the Cycliq Fly6.

Maybe this will be of interest to someone else. Like I said, it's pretty simple. And there's no doubt similar things already out there - this was just something so I could practise going from initial idea to prototype and then refine.

Step one. Get all the parts and put it together on a breadboard for testing to see if it'll actually work.

I used the following:

  • Adafruit USB-Boarduino
  • HR-SC04 ultrasonic sensor
  • four-digit seven-segment LED display (labelled "CPS02841AR", common cathode)
  • Maxim MAX7219 LED display driver (plus 68kΩ resistor, 10μF electrolytic and 100nF ceramic capacitors)
  • Freetronics piezo buzzer

First step was just wiring it all up. Here is the result:

Bike Sonar, prototype 1

Next step is to write the code for the Arduino to run it all and test.