Following a discussion on the RobotBrighton Forum, Robot Steve suggested that li-ions are better/safer than li-po batteries. Despite a recent post here extolling the virtues of li-pos, I think he might be onto something: but perhaps not for the reasons he outlined...

After much reading up on li-ion batteries and their variants, it seems that such batteries have a limited shelf-life. Not just a "hanging-around-waiting-to-be-sold" shelf-life (remember, if the battery discharges too much it can become damaged so they need to be used/charged every few months) but also a "use-by" date: typically 18 months - 5 years.
In fact, due to the heavy charge/discharge cycle that laptop batteries go through, many suppliers treat them as consumables now, and I'm thinking along similar lines for the ScoreSure range of devices. So the batteries need to be removeable at some point, not soldered to the PCB via short wires (as was the idea using li-pos).
Because mobile phones are so commonplace, it shouldn't be difficult to get hold of stocks of 3.7v batteries, quite cheaply, in future - and most of these are li-ion, hard-cased batteries, not the lightweight flexible li-pos discussed in recent posts.

When it comes to recharging li-on batteries, eBay is awash with USB phone chargers, for a couple of quid each (less if you buy in bulk) similar to this one.

So while it's going to be interesting to see what turns up in the post over the next few days, there is still plenty of research ongoing, into li-ions as an alternative.

Watch this space....

Well actually, back to the more generic type of game scoring device. While RobotSteve gets on with making some rather smashing looking servo controller boards I've been coding yet more for the golf device.

To date we've got

• eeprom driven menus
• up to 4 player support
• Edit player names
• Edit player parameters (handicap and golf tees)
• eeprom driven bitmaps
• Nokia-type joystick support

.
Something to look out for with these Nokia breakout boards is running them at under-voltage.
I left my PP3 (9v) battery connected to the display all night and in the morning the battery was only giving out 7v. This meant - and I've yet to work out why - that only 4.3v was coming out of the voltage regulator, instead of the full 5v (not very regulated then!).
At this voltage, the Nokia screen (which usually requires 5v to drive it) would reset intermittently. This would sometimes also cause the pic micro to reset too. So behaviour was very unpredictable. Also, because of the lower supply voltage, the joystick values did not read true, and the logic to decide which button was pressed did not always work either (with the effect that the menu selector would appear to pick random entries from the list, instead of the one immediately above/below the highlighted entry).

Below is a video showing Nokia development so far.
It shows how eeprom-driven menus can move control onto a new screen (screen refreshing is slow because we're reading bitmap bytes from eeprom at just 400khz, not a the full 20Mhz that the chip can run at) and also how to edit player details.

Once perfected, these techniques can be used as the basis for other game scoring devices - after all, most games involve picking one or more players, entering their names, and providing some extra information (such as handicap/tee preference in golf, maybe boule weight or team position - pointer, shooter, middle - for petanque and so on).

But it's ok to judge a device by its enclosure.
Thanks to Robot Steve it's already time to think about packaging and how to house what could very well become a commercial product. Already a couple of domains have been bought, and the game scoring device has a spanky new name: ScoreSure.

The domain www.scoreresults.co.uk has been reserved as a place for displaying results and league tables once they've been uploaded. Results will be arranged according to the game type - e.g. http://golf.scoreresults.co.uk and so on.

Never satisfied until the best. Or something like that. When you've grown up with a die-hard blue-nosed Everton fan, stuff like that tends to stick in your head and pop out at the most inappropriate moments. Perhaps today it's not quite so inappropriate.

After all, the ScoreStore Game Keeping Device (see, it has a name now, thanks to Robot Steve over at BotBuilder.co.uk) is done, finished, working, tested, working, done, finished. But somehow, I feel it's not quite there...

For a start, the LCD display is big and clumsy. Secondly, it needs more than 2xAAA batteries to power it. Thinking about the enclosure - which has yet to be designed - this is going to make the device quite a big heavy thing to carry around in your pocket! A big display I can live with, but having to pump 4 x AAA batteries into something like this seems a bit overkill - a portable CD player or a torch, maybe, but an LCD display with a couple of buttons?
My game score keeping device will end up the size of a C90 cassette tape! It'd be easier to carry an A5 notebook in your pocket - there has to be some way of making the whole thing smaller, lighter, and altogether more "professional" looking.

As it turns out, this little thing appeared on eBay. It's a GLCD (graphical LCD). Look at it - it's tiny. No thicker than an After Eight mint. And, best of all, it runs at 3v (as low as 2.5v, so it still works even after a bit of battery drain!). Brilliant.


Low profile, low voltage, and 4 times bigger than a 16x2 character display.
What's not to love about this GLCD?

Luckily the Oshonsoft PIC18 simulator/compiler supports graphical LCD displays - so the commands currently used for writing data out to the 16x2 LCD can be quickly and easily upgraded to use the GLCD. And, to put the cherry on the cake, we can have some nice icons and monochrome bitmaps, just to show off how clever it all is!

It's been a busy week at Nerd Towers, but only because we found ourselves in the strange position of having quite a few events in the social diary! While this does mean that we've managed to get out and see the sun for a few hours at at time it also means fewer hours in front of the computer/etching tank/soldering iron.

Wednesday was the Brighton and Hove Petanque Club Quiz Night at the Iron Duke. Luckily we teamed up with a couple of other members so that our ignorance of all things cool and cultured didn't become too apparent. In fact, we hid our ignorance so well that we won the quiz and each took home a bottle of bubbly!

A lot of the week has been spent in preparation for the Brighton Robot talk "introduction to microcontollers". Lots of kits had to be made up, containing breadboards, wire jumpers, microchips, resistors, leds - all the kind of junk you'd normally find attached to a microchip in fact. In a talk spanning a massive three hours (include beer and fag breaks) everyone managed to get an LED flashing in response to an input signal/button press. We're not quite ready to build a robot army to take over the world, but it's a step in the right direction!

Speaking of RobotBrighton, Robot Steve of BotBuilder fame, spent some time using MS Messenger and a webcam to demonstrate his exciting new Etch-a-Bot.
He's already using an LCD display for his project (pre-built from SparkFun) which allows the user to draw a path on the screen, using a small joystick. The bot can then be put into "playback mode" and it will rove about, following the path drawn on the screen. Pretty impressive stuff!

...you wait for ages for one, then three come along at once.
Just a quick note to say that, despite there being no blog updates for a while, it's not all ground to a halt here at Nerd Towers.

After the success (mostly) of the USB relay switching device I've been inspired to help out with a project for Steve at www.botbuilder.co.uk, which is a USB-driven multiple-servo controller.

Simply put, to drive a servo, you need to send a signal pulse to the servo every 20ms or so (50hz) the duration of which must be between 1ms and 2ms.
A 1ms signal means "0 degrees" (or -90 if your zero position is half way between the two extremes). To move the servo to 90 degrees (or its mid-point) a signal of exactly 1.5ms must be sent, and a signal of 2ms represents "fully extended" or "180 degrees" (or 90 degrees if you're working from -90 to 0 to 90).

Many PICs have a PWM (pulse-wave-mode) module built into them, and some even have two or more. But very few (if any) can support up to 16 servos.
Allowing for errors, and a signal pulse time of 2.5ms per servo - remembering that each servo must have a signal sent to it every 20ms at most - the maximum number of servos that a PIC can control, serially, is 8.
(servo 1 takes 2.5ms, followed by servo 2, another 2.5ms, followed by servo 3 etc...)

8 x 2.5 = 20m/s.

And on top of all this, your PIC is running at 100% capacity - there's no room in there for receiving data requests to update the position of the servos.
So I'm trying to recreate PWM using an 18F series PIC, but using timer1 to create interrupts to drive all servo pins high at the same time, then use some form of offsetting to drive them low again after a period of time between 1ms and 2ms.

Look out for some Oshonsoft PICBasic code shortly (if I get it working!)

After attending the Robot Brighton Shadow Robot Company Talk I had just a few minutes from getting home to retiring to bed (it was gone midnight after all!).
I'd asked around and managed to blag a 470nF capacitor from Kind Steve (and borrowed a PIC programmer from him, just in case mine was playing up: I still didn't know if it was burning hex files onto the 18F series of chips properly) and thought I'd shove it into my breadboard and see what happened.

As I pulled it from it's little plastic bag, I realised he'd given me a 470uF not a 470nF capacitor. It was a big black cylindrical thing, not the little round disk I'd been expecting.

I was about to call it all off and go to bed, when I decided that there'd be no harm in giving it a try anyway, what with him having taken the time to dig one out and bring it with him. So I did. And then plugged in the USB cable.

Nothing happened.
And then this came up:



Wahoo! I finally had a native USB device working!
And just to make sure, I ran the test app that came with the PIC 18 simlulator called hidterminal.
What is does is generate a random 8-byte string and send it to the device.
If you read through the sample code, you'll see that it decreases each value in each byte of the feature code by one, just before the data is sent back to the host (and increases the i/o report by one). From the screenshot below, you can actually see this in action:

The vendor ID was changed to 1221 just to see that a USB device with
any VID/PID combination would be recognised

And all this without having to use a different programmer.
It seems that mine does work with 18F chips, using DonkeyProg after all.
Here's the final schematic for anyone trying to get a native USB device working from a PIC18F2455 controller - don't skimp on any of the parts: they're all critical!



How exciting!
Tomorrow I might just lay out a PCB for it....