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.