You spin me right round

One of the projects I have in the pipeline needs a pointer that spins a full 360 degrees. The idea of using modified servos for this offends me and the position needs to be pretty accurate, so I picked up one of these cheap geared stepper motors and drivers you see on eBay.

OK, so this is all very standard stuff but it's the first time I've played with a stepper so it's exciting for me, honest.



Something I'll have to deal with is getting the initial position of the pointer calibrated then keeping track of it. I'm currently thinking that I will make it return to zero before the device switches off. Alternatively I could write the last position to NVRAM occasionally but this isn't rated for a vast number of writes on Arduinos.

Next thing after this is to start on the physical build of the prop as the various electronic modules are coming together. I think my last worry is a power supply and batteries. I want to use two Li-ion batteries salvaged from a laptop pack to give it loads of poke, but they won't be easy to remove because the prop will be all sealed up and this will make charging them troublesome.

It is more complicated than that

It seems that on the RFu328 at least, pins 11 & 12 on the Arduino float high when there is no power to the device. This is with a 1M pull-down resistor to ground. Probably something to do with them being usable for FTDI programming.

Which makes them no use to drive the MOSFET for the soft power switch as it's then 'always on'.

Moving the power connection to pin 2 fixes this. I'm using pin 11 to drive a little vibration motor but if that spins briefly on boot that's no big deal, so I've left that in use.


How to massively overcomplicate things

All this nonsense is an on/off switch.

What started out as a conversation about making something hard to accidentally switch off, without making the on switch fiddly, has turned into me thinking about how to incorporate a software controlled power switch.

A bit of googling suggested this isn't something tons of people are interested in but also a lot of messing around with discrete components to make bistable latching switches.

I'm going to be short on space in the project I want this for, so resolved to try something super simple. Also despite having actually studied electronics back in the 1980s I remember about as much of it as I do my French.

Here I've an N-channel MOSFET in line with the ground supply to an Arduino Nano. Pushing the switch brings the MOSFET gate high, which completes the path to ground and the Arduino starts. As soon as the sketch runs it uses one of the pins to keep the MOSFET gate high.

It seems to work just fine. So am I missing something, is there anything more to it than this?


The solidly lit LED is the Arduino power and the flashing one is controlled by the Nano. After 10s it automatically shuts down, but now that's controlled by software the conditions for this can be pretty much whatever I want. The MOSFET's going to leak <1uA when the gate's low but that pretty much counts as off as far as I'm concerned.

Going back to the reason for this, I'm making something small-ish which includes a mix of 5V and 3.3V tolerant components, all powered by an unprotected LiPo. Which might be nominally 3.7V but is going to have a floating voltage of about 4.2 freshly charged. Which will kill the SRF radio. So it needs a 3.3V regulator which will suck power. Also, flattening the LiPo by forgetting to switch it off will kill the LiPo. So I want a way for it to shut itself down if the voltage gets low. Being able to make it only shut down when you want or shut it down by sending commands over the radio becomes a bit of a bonus.

So this is another little piece of the puzzle worked out.

Live long and prosper

R.I.P. Leonard Nimoy.

I find it kind of odd that on the weekend of his death I have spent a fair chunk of it pottering about with something called LLAP.

One of the things I want to get on top of this year is a set of location aware props. The plan is for Spookytron 2 to be wireless and location aware, plus later on I want to build a 'scanner' that can find things, either by having active 'tags' or waypoints.

To this end I have bought a couple of cheap GPS/magnetometer modules from eBay, the sort intended for fitting to a drone. These have a u-blox Neo-6M GPS and HMC5883L magnetometer combined on one board. They're not really integrated in any way, just two things on the same board. You have to power them separately and it even suffers from the GPS having a regulator so it's 5V tolerant while the magnetometer doesn't from what I can see.

After a little looking around to find the pinouts, which aren't widely mentioned, and a play with the examples for the TinyGPS and HMC5883L libraries it all went together very easily.

LLAP less so.

When I was working with LLAP to trigger sounds on another board it was very simple, send a message and deal with it. However, having to constantly process the NMEA feed from the GPS to get a fix showed things to be more fiddly than I'd like.

The Arduino SoftwareSerial library you have to use because the hardware one is connected to the SRF radio has to do a fair bit of work in the background. So it needs the buffer emptying all the time otherwise it drops characters and sentences of GPS data get corrupted. In fact it seems to struggle a bit even when not much else is going on, I need to investigate why as I don't think this should be the case.

The other difficulty I've had is that the LLAP library issued by Ciseco is not only still quite limited in function, it also seems to play poorly with TinyGPS. They say it's in beta but there's sadly no sign of active development.

The library is implemented using the SerialEvent routine, which is kind of like an interrupt in that it is triggered only if there's serial data to be read. However it happens at the end of the main loop, not when the event occurs.

The standard examples for TinyGPS have you slurping as much NMEA data as you can in one go to avoid missing data in the main loop. Then at the end LLAP slurps however much it feels like and faffs around with it. It should only be 12 characters in each packet but it still seems to faff a bit.

This adds up to LLAP messages getting missed (a lot) and GPS data getting corrupted (a bit) as one thing then the other blocks. I'm going to have to do a bunch of messing around to make it so all this blocks as little as possible.

TinyGPS will play nicely with this, but I can see the LLAP library will need a full makeover. Given none of the functions for two way communication seem to be implemented, you can send messages but won't see acknowledgements or responses, I can see me rewriting the whole thing.

Or ditch LLAP altogether, the 12 byte packet is already shown to be an issue for sending GPS data as you only have 9 characters to play with. Once I start having to code a way for floating point numbers to be fragmented or encoded before being pushed around the yak shaving will be in full swing.

They had to do it eventually

Much as I love them the Pi was starting to get long in the tooth and needed a shot in the arm. When the B+ came out I was surprised it wasn't this, but the Raspberry Pi 2 is here now and the expected extra cores, update to Cortex A7 and speed/memory tweaks are in.

I've just stuck Rasbian on one and it is noticeably quicker. OK so I/O isn't going to be any better but those extra cores really help elsewhere.

Running the motion tracking code I was using on a B the difference is very marked. It's only single threaded so the actual image processing isn't much faster but the other cores get to do other OS tasks like update the display if you're watching the results.

I will definitely be ripping the B out of the motion tracking project and putting a Pi2 in. I reckon the B will get retasked for the peer to peer radio project I have in mind as the radio module is designed for the original 26 pin GPIO connector and it really doesn't need the extra grunt to push radio packets around at 256Kbps.

The good thing they have done is make it the same form factor as the B+ and compatible with the same OS images.

Enigma variations

I've been keeping this one under wraps until now as it was a surprise prop in a game some friends were running and playing. Now the game is over I can post about it.

Back in November I found out my partner was playing a Spy and Bletchley Park codebreaker in a WWII/Film Noir themed freeform game. Thinking it might add to the game I contacted the main GM who I know well and offered to build an Enigma machine prop.

At that point I had no idea what it would be or how functional but she jumped at the idea and started to think of ways to add it into the plot. So that was me committed then. :-)

What we have here is a pastiche of the famous German WWII cipher machine, the Enigma. While it is the same size as the original and keeps the spirit of the thing it is not meant to be an exact replica. It's all done with a microcontroller and LEDs for a start. It has five rotors rather than the original three or four and no plugboard. The five rotors were a plot point so I was glad I didn't start building the three rotor one I had in mind at the start.

It is fully functional and uses the original Enigma algorithm to encode/decode messages.

Setting the encryption key is done by turning the rotors and the rotor positions are displayed on 5x7 LED matrices immediately below them.

The keyboard is pretty faithful, made out of a set of keys salvaged from a vintage typewriter, a bunch of brass tube and 27 momentary switches. I've used the QWERTY layout rather than the original QWERTZ as I'm English and it was for an English game.

A degree of obsession with symmetry lead me to add a 27th key, originally thinking it could be a space bar, before realising the algorithm only works with even numbers of characters. So right now it does nothing.

The 27 lamps which show the encoded message are pretty faithful too, only I've used warm white LEDs.

There are then a few indicators and buttons to make it easy to use. This
is a prop to be used in game by everyday people to send secret messages so it had to be fairly simple. They were there to play a game not learn how to use a device from military history. The buttons allow you to play back the plaintext you've typed to check for typos and also the encoded/decoded output so you can write it down easily.

The original had a kind of wrinkle finish paint on the metal covers. This is all made from plywood but I painted the relevant buts with some textured 'weathered iron' paint, which has quite nicely aped the look.

At the heart of it is an Arduino Mega 2560 microcontroller clone and a whole load of hand soldered loom. The keyboard and lamp matrix were hand done and I use the sea of GPIO pins on the big Arduino to multiplex them directly without extra components. When a Mega clone is only £15 why mess around with a smaller one and add extra components to debug? My coding is better than my soldering and that's not saying much.
The rotor movements are read with 'gray code' rotary encoders so they can move through 360 degrees and the matrices driven by MAX7219 driver chips. As you turn the rotors or they advance while typing the letters displayed on the matrices 'scroll' up and down to provide the illusion of a physical machine. It's not the smartest illusion but it works nicely.

The five MAX7219 drivers are mounted on little boards right below each matrix and daisy-chained together. I had a few problems with interference causing the displays to malfunction until I carefully tidied all the wiring up and shortened the data lines.

There are four AA batteries inside so it's portable and can also be run by connecting a USB PSU the to the Arduino USB port. I left the hole in the side of the box for the USB port as it needs to be there for programming anyway. When the batteries need changing you can get to them by removing a small metal cover in the side, I didn't want it so the whole thing had to be ripped open.

If the machine is left untouched for a 15 minutes all the lights and displays shut down to save the batteries and it needs power-cycling to wake it up again.

I hand-rolled all the code, stealing liberally from the Internet for the rotary encoders and MAX7219 without actually using any pre-made libraries. I even made my own 5x7 font for the matrices.

As a bit of added help in the game I chopped the code right down and made a standalone Arduino in a box that takes input from the serial console and encodes/decodes stuff. This is so the game GMs can code/decode messages to pass to/from the players without having to go and use the main machine. A less lazy soul would have ported the code to another environment and maybe written a small app that would run directly on a phone or PC. However I was literally coding this the night before the game and needed it done in an hour. I had the spare Arduino anyway and it can be re-used after the game.

It went down very well in the game and I'm proud of how it's worked out even if some of the woodwork is a bit shonky. I'm an IT guy not a cabinet maker and I scratch built it from the carcass of some 70s plywood furniture I'd knocked to pieces. You can do wonders with hot glue and filler.

Hanging around

I'm in the midst of a load of electronics based projects but took half an hour out to make these.

OK, they look like clothes hangers but they're actually to hang banners on for a bit of set dressing at a LARP. The brass knobs unscrew so you can slide the banner on.

It's just some dowel, old manky brass knobs polished up and a bit of cheap decorative chain but they've come out quite nicely. I'd be tempted to make a few more to use at games but first we'd need the banners to go on them.

Matched pair

I finished off the pair of holdout Lasertag pistols I've been making last night. They're unlensed with reduced power for use indoors (10m range, little reflec) and have turned out very tidy. There's a Lipo battery inside and I made a compact charging socket from a 0.1" pitch connector.

Trouble is I finished them quite late and then couldn't sleep so I'm totally shattered at work today.

The extra 'plugs' are different resistors to adjust the power of the IR as getting it right for use indoors is a bit of an inexact process.

These are really nice and compact, ruler included for scale.
Bog standard enamel matt spray has given them a decent look, although it is likely to wear off a bit in use. I've made no attempt to remove the Nerf branding because they're for a game and once clasped in somebody's hand just look like a cool little holdout gun.
 I'm quite happy with how tidily the controls fit in the base. The X where the plunger went in is perfect for fitting a recessed on/off switch and the air holes are 3mm, perfect for an indicator LED. Charging socket is a bit improvised but sits nicely where I've put it.
 The IR emitter is in 40mm of brass tube which is inserted in a hole in some acrylic rod. This then has a 3mm white LED drilled into the back of it. This makes for a lovely even diffuse ring of light round the centre when it fires.
The standard tag circuit and Lipo just fit inside the handel of a Nerf Jolt. This is one of Spartan Design's boards rather than an Arduino based one of my own.