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.