Tag in a box

The other day I was making my first lasertag lens unit. Trying to get it focused I quickly decided naffing about with a battery and button wired straight to the emitter wasn't good enough. Plus I burned out one emitter keeping it on too long.

So I built the essence of a lasertag gun in a box, with screw terminals to make it easy to connect up to things for testing. It's also got a low power unlensed emitter run in parallel, in case you want to test sensors.

I've left the USB connector of the Arduino Nano accessible at one end so it can be reprogrammed easily as for now it's just sending WoW hits.

I may open it up again and put screw contacts for the trigger so it can be used as a general purpose thing to tag up bigger props on an ad-hoc basis. It's got 4 AAA NiMH batteries in so with a decent lens unit will have a passable range.

If there's space, which I doubt, I may stick in an IR sensor so it could also be a thing that registers hits, making it a multi-use device for props.

Cellar Dweller

I want to turn my cellar into a decent workspace but it's currently too damp. If you leave things down there the cardboard goes limp and metal slowly corrodes.

It may be that I have to resort to professional tanking of some kind, but as an opening gambit I'm going to try drying it out with a dehumdifier.


Emptying the condensate tank regularly is dull, but there's a connection for an external drain, so I've built a bigger tank out of an old 'Really Useful Box'. This complete with float switches to sense the level and a pump to push the water up out of the cellar into my garden.

This could have been managed with a very simple latching circuit, so it switched on once full and didn't switch off until empty. However I've got all the bits to do this with an Arduino. An added bonus is I can put it on the Internet, so it's now got Ethernet and a temperature/humidity sensor so you can look at a web page showing the current readings and how often it has emptied the tank.



It'll be riveting stuff.

Once I run a network cable down there.

Marginal gains

I built two cheap and cheeful MP5 'tag guns earlier this year and left them unlensed. Having done the quickest, dirtiest thing I could when building I left the original muzzle flash bulb in place and stuck the emitter where they originally had cheapo laser pointers fitted.

Sadly the range was predictably awful and they've not got much use as a result.

This afternoon I opened them both up, swapped this round putting the emitter in the 'barrel' section and the muzzle flash where the emitter used to be. I also swapped the muzzle flash bulb for an LED.

These gun bodies both came with faux suppressors that slide on the end of the barrel and now all I need to do is put a lens a suitable distance down these and it'll make for a basic lens unit. I'll probably leave it removable for easy transport.

I'm not alone

My Spartan Design Predator tag gun has stopped working (it's gone silent) and I've taken it apart to troubleshoot. It seems I'm not the only one who loves using hot glue to gunge a project together.

I fear the sound board has died, but I'll have to dig the board out of its gluey embrace to really know. Which is the downside, it makes later repair or modification a bit of a pain.

Back to basics

While I love making 'technical' props this weekend I'm off to try out a new LARP system that uses NERF guns for combat and fancied painting some up. So I bought a Rapidstrike which was on special offer, dug a Maverick I had kicking around out and painted them both up with Poundland spray paint. The paint is cheap but it's cellulose rather than acrylic which I prefer for adhesion and toughness. It also comes in small cans which you end up finishing. I hate buying expensive paint and only using half of it because the nozzle gums up.

I stripped the guns right down, masked off some of the original painted areas and left some of the original orange on the moving components as they get scuffed up easily. The Rapidstrike was slightly fiddly inside but not terrible and it seems to work afterwords.

In the end these have come out really nicely. The different shades mean they're not just matt black lumps and stripping them down first really helps with definition and coverage.

The orange parts are quite nice highlights and leave a little visual clue they're still toys. Although I wouldn't want to test that by waving the Rapidstrike around anywhere public.

Refreshing some flaky props

 Last year I made a pair of slightly phallic Lasertag stun batons for the UKLTA's indoor LARP "Zero Light Thirty". Sadly they've always been a bit unreliable and irritating.

In an attempt to make using them more immersive I fitted tilt switches so they automatically 'powered up' when you raised them. However these have proved kind of unreliable and they'll turn off/on a bit randomly.

The actual on/off switch and charging socket is buried inside the tube, forcing you to unscrew the handle at the start/end of the game. Which also means disconnecting the cable for the trigger and that's kind of fiddly.

I've made something that doesn't come to pieces very easily despite that being necessary all the damn time.

Then for some reason I thought adjustable power levels would be good so the power switch doubles as a 'power level' switch and even I can't remember which way round the 'indoors' and 'outdoors' settings are.

At the time I didn't have the 'data over tag' signalling code that would allow me to build everything from scratch. I've got an Arduino piggybacking over a Spartan Designs Lasertag board, which was set up for stun shots. The Arduino reads the outputs on the board normally used for a status LED to see if it's ready to fire, then pulses the trigger of the Spartan Designs board when you push the trigger.

All in all they're a bit of a dog's breakfast.

There's a refresh of the game content coming up and I've been asked to fix up these props. If I can make it look tidy I'll ditch the tilt mechanism and just put all the switches & sockets on the outside.

If it bleeds we can kill it

You know how the Internet is. One minute you're looking at one thing and the next you're thinking "wouldn't it be cool to make a thermal camera". You know like Predator vision.

Also a bullshit conversation about making one at a recent LARP didn't help with the whole "doing the sensible thing" thing.

Unlike so many bits of tech we take for granted as easy in the world of supercomputer smartphones and big data this is still the stuff of movies and expensive law enforcement hardware.

When it comes down to it, far infra-red is a lot harder to deal with than visible light or near infra-red, as used for 'night vision' CCTV.

Far infra-red doesn't pass through glass for a start and lenses that can focus it have to be made of things like silicon or germanium.

Then it doesn't work with the usual CCD/CMOS sensors found in digital cameras. There are similar solid state devices using different tech around but they haven't had the development work that devices for visible light have.

A bit of a read around the subject shows that Omron do a very affordable thermal sensor, the D6T-44L. This is quite easy to talk to over I2C and comes in at about £37 by the time you've bought the tiny connectors it uses. Great stuff, but sadly it only has a resolution of 16 pixels. Not 16 megapixels, 16 pixels. It also only does about 4FPS. Still it seemed worth a punt as a first go with this kind of tech as it's quite manageable.

Here I've taken the readings from the sensor and used them to make a pretty responsive display using ye olde MAX7219 and an 8x8 LED matrix. As it already involves some upscaling I've used each block of four pixels to do very basic dithering that represents different temperature readings and made it auto-range.

This doesn't result in desperately sophisticated imagery but I'm happy with how it's come out for an afternoon's faffing around.

Once I connect the sensor up to something more powerful (probably an RPi) I'll try combining it with some conventional video to do a pansharpened image. If this works OK I may end up buying a more expensive sensor like a FLIR Lepton, as I suspect this won't really be usable for much beyond a curiosity.

Dastardly Demon Detecting Devices

I've not been blogging recently as I've been working on a complicated multipart prop for a UKLTA Lasertag game which uses the TV show Supernatural as its background.

Some months back I had discussed the game with my friend Mik who said it would involve a demon possessing different people in turn. To which I said, "if I started soon I could probably build something that will track it".

Here's what it ended up as some months later. This is a 'magic compass' made from a cheap eBay purchase which tracks the demon. Who carries around the blue box you can see. Getting this to happen involved a whole load of making and coding.

There are GPS units in the compass, the small box the demon carries and the EMF meter I later decided to build. Then packet radio to share location data. Then relays to relay the data, increasing range.

It all escalated quite quickly and I plan to write each component up properly, but at least I can share the final result.

As alluded to previously I've ended up writing my own simple mesh networking protocol to make it happen. Which is quite a task, but now I've done it it'll get re-used, oh yes.

The Internet of Props

I have a general pattern of escalation in the complexity of the props I'm making. The exception to this was that during April I was making a ton of stuff for the Fallout game but it was mostly set dressing.

So I've ended up with things like a Fallout Vault door, some crates, a Sheriff's  noticeboard, odd looking ID badges and a fake external hard drive. All of which are essentially static, physical props even though a some of this has blinkenlights.

To make up for this, my current project is a multi-part set of props that need to communicate across a LARP site. Which is a large hilly wood where it can take a good walk to get anywhere.

This is challenging. Just think of the difficulties of getting good mobile phone signal in some places and that's a decades old industry with billions of pounds in development spent on it. Or perhaps more relevantly, using walkie talkies on a LARP site and being able to contact each other reliably.

My current approach is to use the ISF band serial radios released by Ciseco and I've posted here about using them before with their 'Internet of Things' protocol LLAP. The first stab at this was a failure. I made a 'GPS tag' to attach to an object so it can be found but it simply didn't have the range in a wood to be of any use.

So I escalated matters.

Now I've got a higher power radio in the tag, which necessitates a separate microcontroller, bigger batteries and a chunky voltage regulator which has made the device grow a bit, but not terribly.

Also I've now made some 'relays' which are similar sets of components in anonymous boxes with better aerials that can relay data packets for other things. When it comes down to it, fitting a radio powerful enough to go from one end to the site to the other in small props is going to be problematic. Hence, relays. I've built two so far for testing, but plan to have four in the end.

There are other bits to the set but I can't post them yet because, well spoilers sweetie.

The introduction of relays made me abandon LLAP for communication, it simply doesn't facilitate this relaying of data and being ASCII based isn't good at passing floating point numbers around without losing precision, which is essential for what I'm building.

So I've written my own vaguely self-organising mesh communication protocol that pushes data around in binary and implemented it as an Arduino library.

It appears to work.

We're testing this on Wednesday in a wood. No pressure then.

Sworn to secrecy

One of the problems with making props for LARP is that very often I can't talk about them outside of the circle of game organisers in case of plot spoilers and generally ruining the surprise.

We recently did a Fallout themed game and this little bunch here were part of it but I couldn't really say anything for just this reason.

Look, this one has a laser!

Not for long though. I've done an exact copy of the first gun body I did this week and tagged it up. So I now have a matched pair of unlensed MP5K-esque machine pistols to use for the upcoming long weekend of Lasertag games. It may involve shouting "Die motherfucka" a lot.

They're very much a cheap and cheerful conversion, but well that was the whole point.

Soon I'm going to have to bite the bullet and make a 'proper' Lasertag gun in the form of a rifle that's got a decent range. Which means bigger lens units mounted very seriously to the body and getting the sights dialled in.

Before this happens I have a Mossberg-esque pump action shotgun to build. Which will be a 'proper' build, but an unlensed one again.

Before they get used I need to do that 'instant start' code I was thinking about. It really shouldn't take long, so I'll tackle it over the weekend while I'm waiting for some paint to dry on something else.

I have the self control of a toddler

I've recently been gifted a pair of identical cheap plastic gun bodies which others bought and decided weren't worth converting to Lasertag. Being super cheap I decided I would anyway. With a ton of projects already behind this was definitely going to be something to tackle once I'd caught up.

Except I couldn't control myself and did one of them this evening.

Once opened up there's a basic spring metal trigger switch and nasty looking but quite decent sounding loud sound/light board with fair sized speaker. It's so cheap and nasty it uses a little incandescent bulb instead of an LED for the muzzle flash.

A little look at the wiring confirmed the sound board has a power supply and separate connection that you take high to trigger it. Perfect for driving from a microcontroller.  When you pull the trigger it also drives a motor with offset weight on the spindle to cause vibration but I decided to junk this.

The battery holder is easily accessible and takes three AA batteries. With alkaline batteries in this gets you 4.5V or more and connected up to the 5V side of an Arduino Nano, rather than the Vin this drives one just fine. Adding a recharge socket and rechargeable batteries is faff I can't be bothered with in a cheap fun gun.

There's also a button on the side, which in one of the guns activates a crummy laser pointer so you can do the red dot thing beloved of 80s action movies. The switch is still there in this gun despite it not having the laser and it makes a perfect reload button.

I couldn't be bothered to make up a lens assembly for these so I stuck an IR emitter in a metal holder and hot-glued it where the laser was supposed to emerge. I've put a plug/socket arrangement in case I decide to go back and fit a proper emitter. Unlensed the range is going to be poor, but I want them for a bit of fun in the Judge Dredd and Fallout based games that are being run at Dropzone next month.

With these post-Apocalyptic themes I want to have one in each hand firing wildly, shouting obscenities in a kind of cinematic manner. Bothering about being seriously effective in Lasertag games is for other people, I mostly want to have fun. Sometimes that means being effective, sometimes that means dying in a silly way and I want some silly at Dropzone.

The only real mod I had to make to the case was to Dremel out a hole for an on/off switch in the side. Then it was wire it up to the Nano, hack some code around and it worked straight away. With no sound board to send serial commands to or different fire modes it's massively simpler than my Skorpion pistol, which being my first Tag gun took me days on end to build.

OK, right now this is single shot with no ammo count but that'll take no time to sort out. Once I've completed the code I'll convert the second body. This has a snapped off foregrip so it'll need some kind of bodgy repair. This may just be a case of filing down the sharp edges and smothering it in gaffa tape.

Something I may try in this code is to make it an 'instant on' gun. Most guns have a start up delay to stop you just turning them off/on to reload or reset the number of magazines available, which would be a bit cheaty as both have an enforced delay. This startup delay seems to take forever and can be very annoying if you've forgotten to switch it on or just want to test a sensor.

As the Arduino has EEPROM built in, it should be trivial to make it record the current shot and magazine count every time it changes. So you can turn it off/on and then it'll just carry on where you left off. It'll then need some kind of button combo to tell it to reset, this could be as simple as holding down reload while switching it on, at which point you get the long startup sequence. Or something like that. Really, the long startup sounds trivial but it is a pain in the arse and it's one of the things tagger moan about, so experimenting with alternatives seems like something to do. If it works well I'll add it to the Skorpion.

I'm sure they're smaller in the movies

Having sussed my software stability problems with the LLAP serial library I polished off the GPS tracking tag I've been making and took it out for a range/accuracy test in the sort of environment it'll get used in, ie. a large hilly wood.

This weekend was our first Lasertag event of the year and the site is a good example of the sort of thing you see in LARP. I wasn't expecting a massive range but in the end was a bit disappointed with only about 50m.

For this I did a slightly unscientific test using a USB stick radio and wandering off with a laptop until I stopped seeing packets from the tag. The USB stick only has an integral chip antenna so I'd expect a bit more with a wire fitted, but this is nothing like the 150m I'd hoped for.

Still, my plan was for this stuff to work in a mesh as even 150m isn't very far in a large wood, so making some high power transmitters with decent aerials to act as relays was kind of always on the cards.

This particular box is just a proof of concept so I can test range/meshing but it'll serve as an anonymous tag that could be taped to a prop that can be 'tracked' or left in a location for people to find their way to.

The good thing is that under the trees the GPS module gets accuracy 100% of spec or occasionally better, so that's down to a 2m area. Which is great, 5m or so would be good enough.

I already have a couple of high power radios and sticking them in boxes to act as relays should be fairly easy. The sticky bit will be the software, so I mustn't underestimate how long that will take. It always takes me 2-3 times longer than I leave time for and I end up pulling some late nights before I need it.

Is this a stand up fight...

I may have found my first bug in a major open source project for years. This has made me unexpectedly excited.

My current project revolves around using Ciseco's RFu328 microcontroller/radio combo and a GPS. This is to do some communication between devices using mesh radio so that they all know where they are relative to each other.

I've built one piece of this system into a small project box and had nothing but trouble with it. Over Easter I was in Brussels and had a few spare days so I took what I needed to work on it with me.

The failure condition was that the microcontroller, which is Arduino compatible, would hang after a while of running. Sometimes there were problems even programming it. As my sketch had got bigger and more complicated the issue became more pronounced.

Thinking I might have a hardware problem I put the code on a genuine Uno R3 and got much the same behaviour, although slightly less flaky.

I put in a watchdog timer to reboot the device if it hung and even this didn't work. It would restart then almost immediately hang.

Messing around wading through my code, chopping piece by piece from it, I narrowed it down to the LLAP serial library I'd been using. So I swapped to a different one. Which behaved the same way despite being a massive refactor and almost complete rewrite of the original.

Hours of head scratching later, I had the culprit. It is almost certainly the Arduino flush() function. Comment it out from the library and the problem evaporates. The library is using this in a justifiable, sensible fashion to ensure that radio output gets done ASAP in a single packet.

Looking online suggests there was a race condition seen in older versions of the Arduino IDE that caused this. Now I've got to get this boiled down to its bare bones and submit a decent bug report with reproducible examples.

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.