Odd Software for Odd Jobs

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!