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.