5 Simple Ways to Save IO Pins

Sunday, September 28 2014 @ 07:05 PM

It has been far too long since I have put up a new post so I thought I would share some techniques I've discovered while working with low pin count micro-controllers like the ATtiny85, LPC810 and the PIC16F1827. A lack of IO pins can be a limiting factor but there are a number of ways to get more functionality out of what is available. This post covers five useful techniques I have used in various projects.

Please note that the schematics in the post are only meant to give you an idea of how the technique works - you will need to adjust component selection and values to suit your specific application.

Use a Single Pin to Select Two SPI Devices

When you are using SPI based devices the number of pins required can add up very quickly especially if you have more than one in your circuit. You can share the bus lines (MISO, MOSI and SCK) but you will need a separate CE line for each device.

One Pin Select

If you only have two devices on the SPI bus you can use a single pin to switch between them by inverting the selection state to drive a second output, one device will always be selected but you at least have some control over which one it is.

The circuit to the left shows how to achieve this. The SELECT output from the CPU is passed directly to SEL0 and is used to control the select line of the first device. The SEL1 line for the second device is controlled by a NOT gate constructed from a resistor and a transistor. The resister holds SEL1 high while SELECT is low, when SELECT is high the NPN transistor is switched and SEL1 will be pulled to ground selecting the second device.

This simple construction of a NOT gate is very useful and will show up in some other circuits in this post.

Analog and Digital Input on a Single Pin

If you need a single push button in your design you can share a pin with an analog input with one small caveat - that you don't need to measure analog values that are close to 0V.

Shared Input Pin

The circuit to the left shows a good example of this - using a single pin to measure battery voltage as well as a single push button input in a battery powered circuit. In this case the battery voltage is read through a voltage divider that halves the value, giving a range of 0V to 4.5V. Because the battery will never read 0V (the processor would not be running in that case) we can connect a push button between the analog input and ground and use the 0V reading to indicate a button press.

Read Multiple Buttons from One Analog Pin

If you need more than a few buttons in your design you will find that it starts to chew up IO pins very quickly. If you only need to read the state of a single button at a time (no button combinations) you can use a single analog input.

One Pin, Many Buttons

The circuit to the left shows a design to achieve this that I discovered in the Arduino Basic Connections book and covered in detail in a previous post.

Essentially the circuit is a resistor divider, when a button is pressed it selects a different point in the resistor chain to measure which changes the ratio of the divider and the final output voltage. The 1M resistor between ground and the final output ensures the analog pin isn't floating when no buttons are pressed.

As I mentioned earlier, this circuit is only useful if only one of the buttons is pressed at once. This makes it suitable for simple menu navigation or options selection which is often all you need.

Single Pin Serial Port

I have covered this in a lot more detail in Non-existant post but it is worth mentioning again. If your controller does not have a hardware UART available you can still achieve reasonably high speed serial communications by implementing one in software using bit banging.

One Pin Select

Ralph Doncaster took the technique a step further to implement half duplex serial communications on a single IO pin with a handful of discrete components as shown in the circuit to the right.

There are a number of limitations with this circuit:

  • Any bit received on the RX line will be echoed on TX. This means the client will see an echo of everything that it sends.
  • It is half-duplex, you can only be sending or receiving - not both at the same time.
  • The firmware implementation needs to swap the direction of the IO pin to suit the operation being performed.

Once implemented correctly the technique is very reliable - I use it in my serial bootloader implementation for the ATtiny85 and there is support for it in my ATtiny85 template library as well.

Generating a RESET Pulse from SCK

This is another one from Ralph Doncaster and once again relates to SPI. The specific example used by Ralph is to control the CSN pin on a NRF24L01 module from the SCK line but the technique can be adapted to other scenarios.

A number of SPI devices have a RESET input which is used to initialise the device and, in a some cases, this may need to be done under software control rather than through a power on reset circuit. The classic Nokia 5110 LCD module is a good example of this.


The circuit to the left shows how to drive the RESET pin using the SCK. In general the SCK line is oscillating as data is fed to the device, this circuit uses long (more than a few microseconds) pulses to trigger a low level on the REST output.

When SCK goes high for several microseconds, C1 will charge through R1 and switch the transistor, bringing the RESET line low. If SCK is brought low for several microseconds before being used to clock the SPI data, C1 will discharge and the transistor will be switched off allowing RESET to be pulled high by R2. High pulses on SCK of less than a few microseconds during normal SPI operation will not be enough to charge C1 - the transistor will remain switched off and RESET will be pulled high.

If you keep the SCK line low during idle periods you can control the RESET line using a long initial high pulse on SCK.


These techniques are very useful when you are trying to get the most out of the pins available to you and most of them only require a small number of additional components. If you find you are using a large combination of them in a single circuit though you should probably consider using a CPU with a higher pin count.

I would love to hear about additional methods people are using, please post your favourites in the comments.

A CNC Engraver Platform - Part 1

Friday, July 18 2014 @ 10:31 PM

I have been looking for a way to simplify the creation of PCBs with a fairly high degree of accuracy - my series of posts about using a laser diode from a DVD/RW drive was an experiment to see if I could use that to expose copper on a PCB by burning away a layer of paint applied to the board. Unfortunately it turns out they are not powerful enough for the task (although they are still useful for other things).

I started looking at other options including purchasing a CNC router to perform the task by cutting the copper layer away directly. Unfortunately the price of a full CNC router ranges from around $AU 600 to $AU 1500 depending on the size of the work area and if you get it as a kit or not - at this price it is a bit hard to justify given the purpose I want to use it for.

It then occurred to me that I could use a hybrid process - use a layer of paint to protect the copper from etchant and use a simple engraving tool to expose the areas I do want to remove. I did some simple tests using a cheap engraver from Jaycar and proved that you could use it to create relatively fine lines through a coat of spray paint.

The next step is to mount this on a device controllable through G-code commands so I can try it with complete boards. Because the amount of force required is far less than that needed to cut through the copper layer completely and you don't need precise control in the Z direction it should be possible to make the bed at a far cheaper price using easily obtainable materials. This is the first in a series of posts describing my attempt to do just that.

I'm writing these posts as I progress so I have no idea if the end result will be a working device or not. If you spot anything that I'm doing wrong or that I could improve please speak up in the comments. The project is hosted on GitHub so feel free to poke around.

Anticipated Design

The design I'm starting with is fairly simple - a work bed that moves in the X direction and a tool head moving in the Y direction. The tool head only has two states - active and inactive - there is no fine control over movement in the Z direction. There are a few goals I want to achieve with this design:

  1. Wherever possible all the parts should be easily available at a reasonable price from a number of sources - no speciality components or difficult to acquire pieces. I want the project to replicable if I want to build another one at some point or if someone else wants to build one for themselves.
  2. Where custom components are required they should be easy to print on a consumer level 3D printer like a MakerBot or Solidoodle.
  3. Although I'm planning on using the engraver as the tool head I would also like to be able to easily switch it out for a laser and be able to experiment with other tools as well. This means the basic tool head will simply be a mounting frame with a set of control and power lines available that you can attach whatever tool you want to use at the time.

I've settled on using a threaded rod as the drive mechanism for the bed (X axis) rather than a belt driven system - it seems less fiddly and the parts required to put it together are very easy to get as well as being cheap. I will most likely use the same mechanism for the Y axis but I will wait to see how well it works first before finalising that decision.

For the electronics side I'll stick with a standard Arduino or compatible as the main processor and use a motor driver shield to control the stepper motors. The hardware is relatively cheap and definitely readily available - there is also a lot of code available that can be pressed into service to drive the whole thing with minimal modifications. This means I can concentrate on the mechanical side of things without adding additional complexity.

Constructing the Base and Bed

The first step is to build a suitable base and put the mechanical components in place to drive the bed. The threaded rod mechanism requires bearings at either end of the rod and one end to be coupled to a stepper motor. The bed is attached to the rod with nuts and, as the rod is rotated, the nuts slide down the length of it taking the bed with them. We also need some guide rods at the edges so the bed cannot rotate around the drive screw and will remain balanced even if the load placed on it is uneven. The parts I'm using for this are:

  1. 9mm MDF for the base. It's relatively light for it's strength and an easy material to work with.
  2. Xmm MDF for the workbed.
  3. A length of 5/16" threaded rod and matching 5/16" hex nuts.
  4. Two 608 bearings to mount the threaded rod.
  5. Two lengths of aluminium tubing for the guide rods.
  6. A Nyloc nut to help with coupling the threaded rod to the stepper motor.
  7. A stepper motor.
  8. Limit switches for detecting the maximum movement.

All of the parts above came from Bunnings except for the bearings which I bought from a skate shop (they are the same type used in skate boards), the limit switches which came from Jaycar and the stepper motor which I bought from Little Bird Electronics.

Base Layout

I'm aiming for at least a 15cm x 15cm usable work area, it's large enough to be useful but small enough that the final assembly will fit neatly on a workbench. This means the bed will need to be at least the width of the work area and twice the length - so 30cm x 15cm at a minimum. The diagram to the left shows my planned layout for the base and shows the mounts and coupling components that will be required.

Bed Layout

Because the bed and the base are tightly linked they need to be constructed at the same time. The bed is somewhat simpler - it only requires attachments to the guide rods and the threaded rod. The diagram to the right shows how they are laid out.

I apologise for the quality of the diagrams, at this stage it is all very much a work in progress so I'm simply doing a basic layout using the Inkscape tool. The numbers on the components are the arbitrary part numbers I have assigned to the the printed parts - these are described in more detail below.

Coupling and Mounts

All the mounts and the motor coupling are 3D printed and are designed to use M4 bolts to attach them to the base. You can find the OpenSCAD source for them here. At the time of writing these are very much works in progress - I haven't had the chance to put them together yet.

Note: The components in the current design take a long time to print - with my printer (a Solidoodle 2) it takes about 12 hours of printing to make all the parts (4 print runs at an average of 3 hours per run). The largest part just barely fits into the print area I have available (6" x 6"). If you are trying to duplicate this project be prepared for a lot of print time.

At this stage I'm not entirely sure that the plastic components will be strong enough or if they will provide a tight enough grip on the components they are being attached to. I'm trying to avoid the use of non-removable connections so I'm using grub screws instead of glue to fasten the components.

The grub screw concept was introduced to me by a friend. Essentially you need to provide a way to introduce a nut into your print with a bolt hole that will engage with the nut while keeping a slice of plastic between the two. This allows you use the tip of the bolt to apply pressure to the target surface by using the plastic to absorb the force. My friend goes to the extent of dropping the nut in to the print at the opportune time so the print continues around it, my approach is to provide a slot (with a suitable hexagonal shape at the bottom) that you can drop the nut into and insert the screw to the side of it.

In this section of the post I describe the parts that are needed and provide a basic description of their design and requirements. So far I have tested these for sizing and interaction but haven't fully assembled them yet so changes may be required. In the headings for the various components I've included the part numbers I have assigned to them (see the layout diagrams above) so it is a bit easier to match the part type to the purpose it serves.

Guide Rod Mounts (Parts 1, 2 & 6)

Part #2

There are three types of these, the first is used to attach the guide rod to the base and simply consists of a hole for the guide rod to fit in, a slot to hold the nut for the grub screw and bolt holes for attaching to the bed (this is part number 2), the rod is fixed in place with the grub screw. The second type is a simple variation of the first which adds a slot to mount the limit switch (this is part number 1). The arm of the limit switch extends upwards so when the bed has reached its limit of travel the controller knows it cannot move in that direction anymore.

The third and final version is used to attach the bed to the guide rods. This version does away with the grub screw and the hole for the rod passes completely through. The fit on this needs to be relatively tight to avoid wobbles but still loose enough to allow it to slide freely across the guide. I'm planning on using a silicon based lubricant to help with this.

Bed Drive Mount (Part 7)

Part #7

This part (shown to the left) is very simple - it clips on to a hexagonal nut that is screwed on to the threaded rod. My concern with this part is that the orientation of the print means that the force applied to it (and it will be subject to all movement force for the bed) will be in the same orientation of the print layers, although I don't expect a large amount of force to be applied the part may degrade over time.

Bearing Mount (Part 3)

Part #3

The bearing mount (shown to the right) simply needs to hold the 608 bearing in place while allowing it to freely spin. The threaded rod will be mounted in these bearings which will allow it to rotate freely without allowing it to move laterally. There is only a single bearing only mount required, for the other end I merged it with the motor mount to make a single piece.

Motor Mount (Part 4)

Part #4

This is the largest individual piece in the collection - it merges a bearing mount (as described above) with a holder for the stepper motor while allowing space for the motor coupling (described below). The piece, while large, is very straight forward. The only issue to take into account is ensuring the fit for the motor is tight enough that it doesn't wobble when it changes direction. My initial print for this is a little loose (see the image to the left) but I think I can correct for that with some suitable filler material.

Motor Coupling (Part 5)

This part is the most risky - it's job is to couple the shaft of the stepper motor with the threaded rod. To do this I am using a Nyloc nut on the threaded rod and a grub screw to attach the stepper motor shaft.

Part #5

If you are not familiar with Nyloc nuts they are a standard hexagonal nut with a nylon coating on the thread - they require a significant amount of force to screw on to (or screw off) the thread they are put on. This is fairly straight forward and relatively low risk - the hexagonal shape is a lot easier for a 3D printed plastic part to grip on to than a screw thread, by making the part a suitably tight fit you will get a coupling on that end that will transfer the rotational force with very little slippage.

My concern is the coupling to the circular shaft of the stepper motor - some motors provide a shaft with a flat surface on one side, the ones I am using are circular. My coupler design uses a grub screw to attach the motor end so it is purely a pressure based connect - at the moment I'm not sure if the force applied will cause slippage or not (I'm hoping not). This design would certainly not be suitable for applications that would require strong lateral forces (such as cutting through metal, even the thin layer of copper on a PCB). As I'm not planning to do that I'm hoping it will be fine.

Next Steps

I have completed the first design for all the 3D parts and have printed out most of them, the remaining parts are printing now. Over the weekend I will start to put everything together and see how well it all works out. I will be posting updates to my Google+ feed as I go about this and write up the results in a follow up post as soon as I get the chance.

The construction process should be fairly straightforward, how well it works once assembled is something I need to measure fairly carefully. I am hoping for at least an accuracy of 0.3mm - that would allow me to build the type of PCBs I want, if I can get an accuracy of 0.1mm out of the device that would be a great bonus.

Android Wear - A Makers View of the Samsung Gear Live

Sunday, July 13 2014 @ 01:01 PM

This post is a little bit different from the normal content I have here - I recently bought myself a Samsung Gear Live running Android Wear. Now that I've had it for a few days I thought it would be worthwhile doing a review from the point of few of someone who likes to tinker with their devices.

In this review I'm more interested in what I can do with the watch so I'm not going to go into a lot of details about the hardware and software that make it up. If you would like more details about those aspects I recommend the series of reviews at Ars Technica:

In my review I'll give an overview of the device itself and the Android Wear software that runs on it and then show you some ways you can start using it as an accessory for your own projects. I'd like to apologise in advance for the quality of the photos - it turns out to be very difficult to take good quality photos of an LCD screen that wants to turn off very quickly. Where possible I've used images from other sources instead.


Samsung have released a number of smart watches over the past few years, from the original Galaxy Gear (running Android) to the Gear 2 (running Tizen) and the Gear Fit. The Gear Live, despite being one of the first devices running Android Wear at launch seems to be almost a side project for them (it's not mentioned on their wearables site for example).

Unlike the version of Android for phone and tablets Android Wear seems to be far more tightly controlled by Google so the hardware vendor has much less influence on the behaviour of the device - just about everything I describe here (at least in terms of the software) will behave exactly the same way on the LG G Watch (the other launch device) as well as the upcoming Motorola Moto 360. The biggest differences involve form factor, battery life and what embedded sensors are included.

It's worth making clear that Google Wear devices are not standalone devices, they are an accessory for your phone - a bluetooth screen instead of a bluetooth headset if you like. Take away the phone (or even go out of range) and there is very little you can do with them (apart from tell the time of course).

To use the watch you need an Android phone running Android 4.3 or later - there is no support for iOS or Windows Phone and I doubt there ever will be. Choosing a wearable will lock you into the ecosystem - with Android Wear it is Google, the rumoured iWatch will be Apple. Migrating from one to the other will most likely be a difficult process.

Physical Appearance and Performance

Digital vs Real

Neither the Samsung or LG device could be called stylish - they are more solid, functional devices designed for use rather than looks. They are quite large and clunky for a watch, but not overly so (see the image to the right for a comparison). A nice feature of the Samsung over the LG is the curved back - this lets it fit comfortably on the curve of your wrist where a flat back may feel awkward given the size.

The display is nice and large, it's easy to read indoors but can be difficult to see in bright sunlight. The screen on the Samsung has a slightly higher resolution (320 x 320 pixels) and uses an OLED display rather than LCD.

The watch responds quickly and animations are smooth. The CPU embedded in the device is a quad-core ARM processor running at 1.2GHz with 512Mb of RAM so it has plenty of processing power available. Interestingly the LG and the Samsung both use exactly the same chipset in their watches - I'm assuming it's some sort of Google reference design that the manufacturers have then extended slightly.

An aside: I am forever surprised by the amount of computing power that we routinely carry around with us without thinking much about it. In the late 90s I worked with high end (at the time) Unix workstations worth many thousands of dollars that had less processing power and memory than this watch.

The battery life is more than acceptable - you do have to charge it every night much like a mobile phone but you easily get a full day worth of charge out of it. I've been using mine fairly heavily through the day from about 7:00 AM onwards and still have a 65% charge left by 6:00 PM when I get home - you could probably, at a stretch, get a charge to last two full days if needed.

Communications between the watch and the phone is done over Bluetooth and seems to have a range somewhere between 20 and 50 meters. This varies a lot though, it depends on a lot of external factors including radio interference. I can safely go to the next room without losing the connection but further than that is a bit random - at home it seems to work fine from anywhere in the house, at work more than a room away and it will drop out.

I've found the easiest way is to simply carry my phone in my pocket all the time, which a lot of people do anyway so it's not a big change in behaviour. There are a number of apps available already that will cause the watch to notify you when it is out of range (normally you just get a small icon in the top right of the screen). Currently I'm using the Find My Phone application for this and it has the added benefit of helping you to find your misplaced phone with an audio alert.

Overall there are not a lot of behavioural changes to make to start using the device - it simply replaces your existing watch. Rather than adding a new device to your collection you are simply substituting an existing one - unlike Google Glass the watches are far more subtle and quickly feel comfortable.


The setup process is driven through the phone - simply download the Android Wear application and follow the instructions it give you. This will find the device, synchronise it with your phone and then manage the communications for you. Once set up there is very little you need to do in terms of managing the device.

When you set it up out of the box it will download a firmware update (it has done this twice for me now, new features seem to be appearing on a regular basis). Over a Bluetooth connection this is a fairly slow process so be prepared to wait for a while.

One issue I had during setup was that it didn't recognise all the Android Wear compatible apps I already had on my phone - I had to power cycle the phone and use the 'Resync Apps' setting in the Android Wear application to get everything up to date.


The primary purpose of the watch (apart from telling you the time) is to display notifications. Basically any notification that would normally appear on your phone will now appear on the watch as well. Cards from Google Now will be added as well which means you get all those predictive notifications (traffic reports, where you parked your car, etc) that make Google Now so useful. The interface uses the same card metaphor that Google Now and Google Glass use as well which makes it very easy to navigate on a small screen.

Main Screen

Initially notifications are shown on the main screen as small cards, swiping up will allow you to scroll through the current notifications. For each notification you can tap on it to get more information (the full text of an email for example) and then swipe left to display more detail or display the actions available for that notification. Swiping right will discard the notification altogether. It is a very simple set of operations that gives you a lot of flexibility and makes it extremely easy to deal with incoming notifications.

It seems like overkill to have a device that simply shows you notifications but it is really very useful. For a start, Google did a lot of work with the 4.3 version of Android to provide a richer interface to the notification system which means they are no longer limited to simple strings of text - they can be associated with images and linked back to the original application (or a smaller 'Wear' version of the app) so you can do a lot more things with them. The older, plain notifications will still show up as well so you don't have to wait for an upgrade to the application to see events from it on your watch.

You can filter the notifications you see as well - the Android Wear application on the phone has a settings dialog that lets you block notifications from specific apps. They will still appear on your phone but won't be sent to the watch itself.

It is difficult to describe how much of a difference this actually makes. After a few days of using the watch I am so used to it that it has become integral to how I work on a day to day basis. You often hear the term 'information overload' bandied around to describe how we are bombarded with small snippets of information on a daily basis - there is only so much you can do to reduce the amount of incoming information so the obvious next step is to simplify the management of that information, sorting the useful and important bits from the flow in the current context. Google Wear, if not solving the problem, certainly goes a long way in the right direction. The video below gives you a good overview of how you interact with it:

Now that I have the watch on I tend to keep my phone on silent all the time and inspect notifications on the watch to determine if it's something I need to deal with immediately, later or not at all. It's unobtrusive and avoids the 'always playing with his phone' perception (especially good in meetings). Of course you are just swapping 'playing with your phone' to 'playing with your watch' but the process is a lot quicker and far less distracting.

Wearable Applications

Google Wear is more of a reactive device - it's designed to let you quickly react to incoming events. That doesn't mean you can't instigate events on it though - this is where the applications come in.

Unlike the Android interface where you are presented with a collection of applications to chose from to launch most are started through a voice based interface. First you attract the devices attention with the 'OK Google' key phrase and then state what you want to do.

The speech recognition on the device is really well done (still not perfect, but good enough that you can use it every day without getting frustrate) and makes good use of natural sounding phrases such as 'send a text to contact name', 'take a note' and 'remind me to action tomorrow afternoon'.

I had to devote some time to clean up my contact list so the primary name for all contacts was something I would generally call them, instead of 'Tesla, N' for Nikola Telsa I might put 'Nick' or 'Nick Tesla'. This makes it more likely that the voice recognition will match the right contact. Of course I have 'Mum' and 'Dad' in the list :)

One complaint I have is that there is a very small window of opportunity to cancel the action if the voice recognition makes a mistake and it's not really obvious that you can cancel it (a button appears that looks more like a progress indicator than a button - tapping on it will actually cancel the operation). A text message I tried to send to my sister saying 'Are you at Shawns?' got interpreted as 'Are you trans?' and sent before I could cancel it (the response was 'WTF?'). As I said, the voice recognition is good, but not perfect.

Because, of course.

There are custom applications available (as in applications that get installed on the watch itself rather than 'Wear Aware' apps) and the number is growing on a daily basis. You don't really download an Android Wear application though, they are an add-on to a normal Android application - you install the primary application on your phone and (if it has one) the 'sidekick' application will be pushed to your watch. Naturally one of the first games to appear that plays directly on the watch is a Flappy Bird clone.

Like Glassware these apps can attach themselves to their own keyphrase or you can launch them by name by saying 'start application name' or navigating to them by touch. The touch option is a bit annoying - you can either say the 'OK Google' keyphrase or tap the screen to get into action mode, swipe up to get to a menu, scroll all the way to the bottom to see the 'Start ..' option, tap that and then select your application. I get the feeling Google really don't want to see a lot of applications that need to be 'started' - as I said it is more of a 'reactive' device and applications should really just allow you to do things with notifications sent to it by the host application running on the phone.

Your Own Apps

Now, as makers we would really like it to show our own notifications and trigger our own actions. It would be easy enough to simply send text messages or emails (they will show up as notifications) but it would be nice to have a an interface that is a bit less general than that. Here are some of the options that are available to you for that.

The Android SDK

Obviously you could write your own custom application, the Android SDK is available for free, supports Google Wear as well as 'standard' Android, runs on Linux, Windows and OS/X and you can deploy applications to your own device without going through the Play Store. If all you are interested in is sending notifications to the watch you don't even have to write a Google Wear device - just sending a normal phone notification (preferably through the new notification API) will do the trick.

If you already have experience developing Android applications this might be a good solution for you, if not it is a pretty steep learning curve to climb before you get the results that you want. You probably don't want to install a separate application for every device or set of events you want to see either.

If This Then That

If you haven't already played with IFTTT you probably should. Essentially it allows you to set up simple rules with a 'this' (event) side and a 'that' (action) side. Both 'this' and 'that' are selected from a fixed set of 'channels' (as I'm writing this there are 116 available channels) which include some popular hardware device interfaces and web services.

IFTTT has had an 'Android Device' channel for a while and has recently introduced an 'Android Wear' channel as well. On the 'this' side the channel allows you to trigger an event by pushing a button in the custom IFTTT application that gets pushed to your watch, on the 'that' side you can send notifications to your watch (with text and an appropriate image).

Unfortunately IFTTT isn't a very open service, if you want to interact with something that isn't already implemented as a channel you only have a few options available to you:

  1. Use the RSS channel to read an RSS or Atom feed from a server you control and use that to provide detail to IFTTT. You can use filters on the data in the RSS entry to trigger an appropriate action. The delay between you adding a new entry in the RSS file and it being processed by IFTTT can be very long though (measured in hours, or even days).
  2. Implement the WordPress API on a server you control and point the IFTTT 'WordPress' channel at it. The timing is a bit better than RSS (but not much) and it allows you to use it for the 'that' (action) side of the recipe as well.

Another downside is that activating a trigger requires you to either navigate to the IFTTT application by touch using the awkward process I described above or saying the phrase 'start I F T T T' which is not exactly intuitive. Despite this, if the services you want to integrate are already supported by IFTTT and you can accept a delay between the event occurring and the action being triggered this may be all you need.


One of the channels available on IFTTT is Instapush and you can use this directly through a very simple REST API as well as through IFTTT. Basically, this service allows you to send a notification to any iOS or Android device. On Android these notifications will automatically appear on your watch. At the moment in only supports basic text notifications, hopefully support for richer notifications will appear in a future release.

There is a little bit of set up required (read the Instapush Getting Started page for more details) but the API itself is very straight forward. Essentially you need an APPID and an APPSECRET string to identify yourself, an event type to identify the event being sent and a dictionary of trackers which are values to be inserted into the notification text.

Where I work we have a number of build processes that can take a very long time to complete - I wrote a small Python script to notify me when they start, succeed and fail so I don't have to keep checking the output log. The notification I get sent has the text 'Project '{project}' build has {status}' where project and status are variables passed to the event. To invoke it I simply use the command line like the following ...

buildevent.py test-project failed

... which will send a notification to my phone (and to my watch) with the text "Project test-project build has failed". The source for this utility looks like this:

#!/usr/bin/env python
# Send build events via InstaPush (http://instapush.im)
import sys
import json
import requests

#--- Instapush validation
APP_URL    = "http://api.instapush.im/post"
APP_ID     = "enter_appid_here"
APP_SECRET = "enter_app_secret_here"

#--- Usage information
USAGE = """
%s project status

  The 'project' parameter specifies the project name, the status describes
  the build status."

def pushEvent(activity, trackers):
  headers = {"X-INSTAPUSH-APPID": APP_ID, 'X-INSTAPUSH-APPSECRET': APP_SECRET, 'Content-Type': 'application/json'}
  data = {"event": activity, "trackers": trackers}
  return requests.post(APP_URL, headers=headers, data=json.dumps(data))

if __name__ == "__main__":
  # Check command line arguments
  if len(sys.argv) <> 3:
    print (USAGE % sys.argv[0]).strip()
  # Send out the event
  pushEvent('status', { 'project': sys.argv[1], 'status': sys.argv[2] })

The code to send an event is in the 'pushEvent()' function - only a few lines. I do cheat a bit and use the requests module to simplify making the REST request.

It would be very easy to integrate this into your application to send events from any source you like. I'm going to integrate this into the code driving my Bluebell device to send notifications to my phone (and watch) as well.


I certainly don't regret buying the watch - I came very close to getting the original Galaxy Gear when it came out but was put off by the lack of an SDK or any other way to customise what it displayed. The same went for the Pebble, although it did provide an SDK it seemed like a lot of work to get what I wanted displayed on the watch face.

Your mileage may very though, I had an advantage in that I was already deeply invested in the Google ecosystem so everything would integrate well without having to migrate email accounts, cloud services and the rest of my digital life to get the most out of it. For me this device was a natural extension of the services I already use and had the added benefit of being easy to talk to with existing services and some simple code. Given that it is based on an operating system I am already very familiar with means that I can do some more detailed development on it if I need to.

Although I'm hesitant to recommend that you should go out and buy one (everyones requirements are different) I can certainly recommend that you give it a serious look. Wearables are not going to go away anytime soon and replacing existing technology that we wear on our wrist every day with something that has a lot more functionality is not a huge leap.

Fun With Lasers: Part 3 - Burning Things

Sunday, July 06 2014 @ 08:50 PM

The first two parts of this small series concentrated on acquiring and then powering a laser diode from a DVD/RW drive. In this post we get to the fun stuff - using the laser to cut and burn.

I tried the laser jig I described in the previous post on a range of different materials to see what effect it had on them. If you are going to try this for yourself make sure you adhere to the safety guidelines I outlined in the first post. As we are using the lasers heat to burn through materials there is going to smoke and (depending on the material) some of it can be toxic so make sure that any experiments you do are in a well ventilated area.

Foam and Plastic

This type of material is perfect for this laser - plastic has a low melting point and (as long as it's not reflective and doesn't contain any red pigment) the laser goes through it very rapidly. This is the only material I've tried that I could achieve a complete cut at any reasonable depth.

2mm Foam

The image to the left shows the result after applying the laser to 2mm thick craft foam. I had some thin strips of various colours as well as rainbow coloured sheets - perfect for seeing what difference the colour of the material has. With foam the laser has an almost immediate effect and can be moved fairly rapidly (2 or 3 mm/sec) to continue the cut.

The foam does need to be a dark colour though and not reflect a lot of red light. If you look at the bottom of the image you will see that the cut comes to a dead stop at the boundary of the yellow section - this was not done on purpose. I was moving the laser at the same rate past that boundary but it was not providing enough energy to cut through the foam.

Any black plastic is another good candidate for use with the laser. It is easy to scour designs into thicker plastic and thinner plastic (like duct tape) can be cut through directly. I haven't provided any photos of these though - the duct tape is the most interesting but the cuts are very thin and I was unable to capture a good photograph that showed it clearly.

Wood and Paper

I didn't have a lot of samples of paper to test with apart from the normal white photocopier paper - it turns out that matte black paper is very difficult to find. Everything I could find had a glossy finish which simply reflected too much of the laser light to allow enough heat to develop to mark or cut.

White Paper

Although I could not start a cut on plain white paper I found that if I started at an already darkened area (a pencil mark or a printed character) I could initiate a cut and then continue it into the lighter coloured areas. The image to the right shows a cut started on a laser printed character and continued into the main part of the page (again at 2 to 3 mm/sec). Once the cut started the surrounding area becomes dark enough to absorb enough energy to continue the cut as you move the beam.

Balsa Wood

This turned out to be a common theme with lighter coloured materials, my experiments with wood had very similar results. I collected a range of different woods from around the lab - I wound up with some balsa, some pine, paddle pop sticks and MDF. Obviously you will not be able to cut through wood but you can make a deep enough burn to permanently mark it.

With lighter coloured woods it was very difficult (if not impossible) to start the burning process, as with the white paper I had to darken an area of the wood first (I just used a pencil) and, once initiated, the burn would continue without interruption.

Paddle Pops

The denser the wood the slower the laser can advance to continue the burn and the longer it takes to initiate it. Even though MDF is far darker than pine or balsa it still need assistance to get started and the movement rate of the laser was reduced to less than 1mm/sec in order to reliably continue it. This was the rate I used by hand and was just enough to continue a surface mark, if you want to make deep burns the rate would need to be even slower.

PCB Etching

You cannot cut through even the thin layer of copper on a PCB with a 400mW laser, using it to facilitate PCB etching is a multi-step process:

  1. We need to coat the copper side of the PCB with a material that can be burnt away with the the laser.
  2. Burn away the coating to expose the copper that we want to get rid of.
  3. Etch the board as normal and then remove the excess coating.

The results (when using a commercial laser etcher) can be very impressive (as seen in the image to the left). What I wanted to find out was how well I could replicate that with a lower powered laser.

The original post I came across described using a thin layer of spray paint to provide the protective surface that will be burnt away. I tried that with a matte black enamel spray paint and was unable to make any mark in the surface at all.

Sample Paints

On the assumption that a general use paint would contain heat resistant material I decided to experiment with some different types of paint and ink (as shown in the image to the right). Unfortunately I made no progress with any of these either, I was not able to even leave a mark in the coating let alone burn it away to expose the surface beneath. My current working theory is that the heat dissipates too quickly (copper is a good conductor after all) before the covering material can heat up enough to ablate.


Given that my original goal for these experiments was to be able to use the laser to help create PCBs the results are a bit disappointing. It was certainly fun to play with (lasers!) but in terms of utility it is a bit limiting - at the power levels available at least.

As an alternative tool head for a CNC machine or a 3D printer it would be useful, adding the ability to cut foam and paper or permanently mark wood and plastic. There is a reasonable investment of time and effort required to get it working though so you would have to justify that against how often you would use it.

As a tool for preparing PCBs a 300mW or 400mW laser is simply not going to do the job unfortunately.

Fun With Lasers: Part 2 - Powering a DVD/RW Laser Diode

Sunday, July 06 2014 @ 03:35 PM

This is the second post about my experiments with laser diodes, you can read the first one here. In this post I cover adding a lens to focus the beam and protect the diode, building a suitable power supply to drive the laser without destroying it, and finally putting the whole assembly in a safe to use mounting frame.

Adding a Lens

The easiest, and safest way, to mount your diode is to use a pre-made laser diode assembly. These can be purchased on eBay for a reasonable price (just search for "laser diode housing") and include a heatsink, a mount for the TO-18 diode case and an adjustable lens to focus the beam.

I was a little unsure how to assemble everything at first, the image to the left shows how all the various parts fit together. For the most part there are no tools required to assemble everything, you do need to fit the laser diode into the mount provided which does require some force.

Make sure that you solder the power leads to the diode before mounting it. You will need a reasonable length on the cables (about 15cm to 20cm should be fine) so you have a bit of freedom of movement.

To avoid damaging the diode I used a file to enlarge the hole for it but I overdid it a bit and made the hole a bit too large. To compensate for that I used some wax to ensure the diode wouldn't move - it's probably not the best solution but it seems to be working fine.

Normally you would need to apply enough pressure to force the diode into place without damaging. Most advice I have seen on this is to use a small vice to do the task.

Building a Power Supply

If you have extracted a diode from a DVD/RW drive as described in the previous post you should have a 650nm RED laser with a power rating between 300mW and 400mW (a 16X DVD/RW drive should have a 300mW diode, a 32X will generally have a 400mW).

It can be difficult to determine the exact specifications of the laser diode you have (on all the devices I've pulled apart the diodes have no part numbers or any other markings on them) so getting the power supply right requires a little bit of trial and error.

The best place to start is with a 200mA constant current supply. These can be built around an LM317 voltage regulator.

Constant Current

In this case we need a power supply that regulates the current, rather than the voltage. The LM317 is perfect for this task - it can provide an output current of up to 1.5A and requires minimal external circuitry. The schematic to the right shows the design I used.

The output current is controlled by the resistor network between the output and adjust pins on the regulator chip using the formula:

I = 1.25 / R

The network I use has two 10 Ohm resistors in parallel (giving a 5 Ohm total resistance) and a trimpot in series for fine tuning. This allows for a minimum resistance of 5 Ohms and a maximum output current of 250mA. The laser diode has a forward voltage drop of 2.5V so the total power passing through the circuit will be over 500mW - standard 1/2W or 1/4W resistors are not good enough so I used 10W wire-wound resistors instead.

This is jumping ahead a little bit but I found that a 200mA supply is not to generate the full 300mW output the laser is capable of due to the diodes conversion efficiency. We need around 350mA output instead. I added another 10 Ohm resistor to the parallel network reducing the base resistance to 3.3 Ohm and allowing for over 600 mA if needed.

An alternative solution would be to reduce the resistance of the two existing resistors - if you swap the 10 Ohm resistors with 5.6 Ohm ones you will get a similar boost in the output current range.

Tuning the Current

To start with we want the regulator to output a steady 200mA before we attach the laser diode so we need to tune the power supply first. You will need an input power of 9V to 12V, 3 1N4001 diodes and a multimeter capable of measuring up to 500mA of current.

Connect the 3 diodes in series (this will simulate the 2.5V forward voltage drop of the laser diode) and connect this to the output of the power supply with the multimeter in series. Apply the input voltage and adjust the trimpot until you get a steady 200mA reading on the multimeter.

Tuning the Power

I recommend starting with the 200mA current for your initial work. This is not driving the laser at it's full capacity though (the output will actually be about 180mW).

I haven't been able to find detailed datasheets for the laser diodes so ensuring maximum power output mostly done through guesswork and experimentation. The biggest issue is the conversion efficiency of the diode and this is effected by heat as well (you don't want the diode to get much above 60 degrees Celsius).

As a general rule of thumb I've found the output is about 86% of the input current - so at 200mA you are getting around 170mW, at 350mA you are getting around 300mW. If you have a 400mW laser (out of a 32X DVD writer for example) you will need to be driving it at 460mA. Please note that these are guesstimates and have worked with the lasers I have - pushing the current too high (or running the laser for extended periods at high current) will damage it.

Building a Frame

At this stage we have a powered laser with a focusing lens and protective casing and that's probably all that's needed for basic experimentation. I was a bit concerned about the cylindrical lens casing however - I didn't want to have it slip out of my hands and accidentally beam light directly into my (or any other hapless bystanders) eyes. I also wanted to a way to keep the laser a constant distance away from the target surface so I could replicate experiments with some consistency.

To help with this I designed a simple square frame that I could mount the lens assembly in. The design is pretty straight forward (see the image to the right) so I won't cover it in too much detail. You can download the OpenSCAD and STL files for it here.

Once the frame is put together it's a simple matter of inserting the lens assembly and positioning it so the focal point for the laser light is in the centre of the bottom part of the frame. Now I can simply place the frame on the material I want to test against and move it around to test the time it takes to burn or etch that surface.

Next Steps

Now that we have everything in place it's time to find out what a laser of this power can and can't burn. Ideally I would like to be able to burn a thin layer of black paint from a copper surface (and thus expose the copper for later acid etching) but there are other interesting applications as well (cutting stencils out of thin material or slicing up foam for simple constructions for example). In the next post I'll detail the results of those experiments.

Follow me on Google+ to see build images, construction notes and previews of upcoming projects.

Recommended Sites

  • EEWeb

    Electrical Engineering News, Resources, and Community.

  • Sprites Mods

    A collection of projects from a very talented engineer.

  • Blondihacks

    A great collection of hacks and projects by Quinn Dunki.

  • Embedded Projects

    Embedded Projects from Around the Web.

Donate Doge

Like the site? Be kind and send a few Dogecoin my way.