RS are good.
Seriously. Their customer service is excellent. I ordered a new display on a whim last night at about 4.30pm. By 10am this morning, DHL were knocking on the door with a parcel. There were no silly delivery charges or anything like that - £9+VAT and the next day, you've got yourself a GLCD display!

This one has just 18-pins, and a load of onboard capacitors, resistors and stuff, so although there are cheaper displays available, they all seem to need a load of capacitors, external negative voltage and so on. This one - according to the datasheet - is nice and easy to interface with.

It's all theoretical at the minute as I've spent most of today trying to get the display connected up to my breadboard. The pads on the left-hand side are arranged in two rows of nine, rather than a nice, easy, single row of 18 pins.
I've added some header pins and the spacing is perfect for attaching a ribbon cable, just like the ones you find on the back of a floppy disk drive, or an old hard drive.
The ribbon cable fits snugly and after testing for continuity between each pin and the end of the cable, it seems that all my dry joints have been fixed and we're ready to go!



Except once again my soldering skills have let me down. I'm really struggling getting the other end of the ribbon cable onto any kind of connector that I can use with my breadboard. So in theory, my lovely new GLCD display is perfect for my ScoreSure Golf Pro device, but in practice, I've no idea!

Latest update on the Game Scoring Device now know as ScoreSure.

After making the decision to create a device for each individual game, here's the latest progress on SureScore Golf Pro:

After spending ages looking for cheap GLCD displays for the device and having spent days trying (and failing) to get the 122x32 displays to work, they were abandoned. They need negative voltages just to get something to appear on the screen and are very fiddly to solder. In the end, although they are cheap, they're just too much hassle to bother with.
Having made this decision, the next big decision was to swallow the extra cost and go for a 128x64 GLCD display. These are pretty common but prices are around £10 each for a ready-to-use easy-to-solder version. At least coding could resume, and the best thing is that the 128x64 GLCD display can be simulated using Oshonsoft PIC18 simulator.
Awesome.

Here are some screenshots of the latest development:



Select the game type (Match Play, Stableford etc.) Golfers know what this is all about - different game types use different rules to decide who has won! Some favour better players (lower handicaps) whereas others - such as Stableford - favour less consistent players and are more forgiving of having a few bad holes in a round. Or so I'm told!
The device supports the following tournament types:

• Match Play
• Stroke Play
• Par Play
• Stableford Rules

The device allows for the following player combinations:

• Single/solo play
• Head-to-head (two players)
• Three individuals
• Foursome (2 x teams of partners)
• Fourball

ScoreSure Golf Pro (as it is now called) allows you to download course details from the internet - this includes information for each hole yardage and the par for the hole. This screen shows which course has been selected and the user can decide to play 9 or a full 18 hole round.



Player details can be downloaded from your PC onto the ScoreSure Golf Pro or entered on-the-fly. Press the up/down arrows to select a pre-loaded players details, or press the edit button to enter their name, handicap and the type of tees that they play off manually.



The course details for each hole are displayed, showing the distance to the flag from each of the tee-off positions and the par for the hole depending on the type of tees you are playing from. If you are playing off red tees, for example, the par for this hole may be different to someone who is playing the same hole but off white tees.



At each hole the user can press the "edit" button to review or enter scores for the hole. This allows the user to scroll through previous holes played and view the score sheet for each hole if required.
ScoreSure Golf Pro automatically calculates how many shots each player is awarded for each hole, based on their handicap, the type of tees they are playing off (which determines the stroke index for the hole) and the game type (for example, Four-ball play usually reduces each players handicap to 3/4).



In edit mode, the user highlights the statistic values that they wish to edit and uses the up/down buttons to increase/decrease the score.
As a score is entered for each hole, ScoreSure Golf Pro calculates the nett score for the hole for each player and updates the electronic score card accordingly. For each player, at each hole, you can record "up/down" and "sand-saver" results. After saving the hole results, the device moves on to the next hole, displaying the distance, par details etc.

Still to do
A summary screen, available at any time, showing the points for each player and who is winning the round. Also, a scrollable version of a digital score card, so that each player's progress at each hole can be seen quickly and easily. For detailed analysis of each hole, simply move the arrow to alongside the hole you wish to view (in the same way the arrow alongside each player is moved to select a player) and press a button to see the "hole results" screen.

Obviously the whole upload/download thing needs coding (although a lot of this has already been done in the early game score device prototype). And a complete website for hosting the results needs building too. But as far as the actual scoring device goes, it's probably about 2/3 of the way there.....

We've just got back from a tiring but thoroughly enjoyable weekend at Prston Park, Brighton where the park played host to the Brighton and Hove TAKEPART Festival.

As well as a weekend of come-and-try-me sports events, there was loads of cool stuff going on as well, including the awesome STOMP who put on some drumming and dance workshops. There was a world-record jive dancing attempt and loads of live music. There was also a brilliant artificial rock climbing wall, just the like the one off Gladiators, and there was even an outdoor icerink! In the middle of summer!

Of course the Brighton and Hove Petanque Club were there with a temporary terrain for people to have a try. On one day alone over 270 people stopped by to throw some boules around, so it was quite a success. It was also really tiring for everyone involved, as it meant we had to shift over 2 tonnes of gravel - not just taking it up to Preston Park the day before and setting up the terrain, but bagging it all up into about 100 sacks and transporting it back to the seafront. It was quite a feat and the task that started at around 6pm was finally finished and we all went home around 9.30pm.
A lovely day - but I personally wouldn't be upset if the next one wasn't for a while yet! ;-)

Despite the lack of news recently, it doesn't means things have gone quiet up here in Nerd Towers. In fact, it's the very opposite - beavering away making clever things means less time to write and tell you about them. But here's something that we're really quite proud of: a servo simulator.

In collaboration with botbuilder.co.uk we're making a USB/serial servo controller which uses EEPROM to store a sequence of commands to control the servo(s). The idea is that you can plug the robot into your USB port, download a "servo script" and sit back as your robot puppet performs it's sequence of tasks.

Using these excellent 360 degree servos the simulator allows you to set the min/max bands for each servo in a list, and to set the centre point. Servo movement over time is defined by plotting points on a graph. The editor also lets you play back (i.e. simulate) your servos movement so you can fine-tune your graph(s).

Here's an early version of the Flash-based online interface (in time it's hoped that users will be able to share servo scripts through the website, hence the online editor):



In this example, servos 1 and 3 have been hacked for continuous 360 degree rotation. Servo 2 is a "traditional" servo, moving through 0-180 degrees.

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.

With all this talk of golf and visits to Whitefields Golf Course it'd be easy to lose sight of why the game scoring device idea came about - to provide a device for keeping score during games played at the Brighton and Hove Petanque Club. When not working on the GLCD interface (details to be posted here soon, when it's finally working properly and not just outputting garbage to the screen) and while waiting for some more etchant to build a breakout board, yet more exciting ideas have been spewing forth - particularly with regards a dedicated Petanque scoring device.

By removing all golf-related code, the microcontroller has enough free program memory to fit a digital distance measuring module. Like most search results for "measure distance microcontroller" on The Big G the most obvious solution is ultrasound.

I've investigated this quite a bit. The problem with using the speed of sound to measure distance is that it's not constant. It changes with temperature. And with Petanque being an outdoor game, this could be quite an issue, as the accuracy of the measurements would drift. The other issue is that the ultrasound receiver is quite bulky and not very accurate because of the wide response angle, so after much umming and ahhing, ultrasound was eventually ruled out.

Laser/radio measuring was quickly ruled out, as I couldn't get a microcontroller to run anywhere near fast enough to measure responses at the speed of light.

So it was back to more traditional methods of measuring distance - namely a tape measure. Now that's not very 21st century is it?
Thanks once again to Robot Steve and some rotary encoders from Farnell, a solution is on the way: a motorised tape measure - using the device interface buttons, a tape measure can extend/retract over a 1m distance, while the rotary encoders measure the distance and display it on the GLCD screen. Pretty cool huh?

And all made possible thanks to a hacked micro servo, similar to the 360 degree continuous rotation servo from botBuilder.co.uk



Simply put, the servo controls the top of a pair of rollers, while the encoder is attached to the bottom roller. As the servo turns, a tape measure is squeezed between the two, and extends/retracts accordingly. The rotary encoder keeps track of how many revolutions (or fractions of a revolution) have taken place, and this can be used to calculate and display the distance travelled on the screen.

It sounds pretty cool in theory. Pictures and videos will be posted here to show it working (or not) in practice....

No, not Gremlins.
Fantastic little graphical LCD displays.
And they are little. Much smaller than the photo from eBay suggested they would be. Perhaps it was just taken at a funny angle. They're longer and slimmer than they appear in photo. But just as cool!

I've been searching for a connector for them with no luck.
Because part of the wires are exposed, it's quite possible to make up a PCB with exposed traces and just solder them straight on. Or perhaps use a through-the-board approach to make a neat, secure connection.

Until then, here's a photo of the LCD with it's backlight lit up (from 2xAAA batteries) - showing the position of pins 17 & 18.

There are loads of graphical LCDs out there - and a whole range of different sizes, prices, functionality and more. Interfacing with each one is different every time, so finding the right display is a fine balancing act between ease-of-use, number-of-pins and cost.

While I'm waiting for my 122x32 GLCD to be delivered (only 99p each from eBay!) I've been working on how to actually display stuff with them! The datasheet(s) are quite vague, but it is possible to glean the basics from them:

The actual display uses TWO driver chips and the data you send to from the microchip is presented to both of them - you need to set a pin to tell the display which driver chip (master or slave) the instruction is intended for. It seems that you do this by making pin E1 high for the master driver (i.e. the top half of the display) or driving E2 high for the slave (the bottom half of the display).

Pin number	Symbol	Level	Description
1	Vdd	3V	Supply voltage
2	Vss	0V	Ground reference
3	Vlcd	varies	Power for LCD display
4	reset	Low-to-High	Reset the system
5	E1	H	Read/write enable (master)
6	E2	H	Read/write enable (slave)
7	R/W	H/L	H=read, L=write
8	A0	H/L	H=data, L=command
9	DB0	0/1	Data bit 0
10	DB1	0/1	Data bit 1
11	DB2	0/1	Data bit 2
12	DB3	0/1	Data bit 3
13	DB4	0/1	Data bit 4
14	DB5	0/1	Data bit 5
15	DB6	0/1	Data bit 6
16	DB7	0/1	Data bit 7
17	BLA	3V	Back light anode
18	BLC	0V	Back light cathode

The SED1520 driver chips do not support built-in characters/fonts, so to write characters on the display, it seems that you must create your own bitmap fonts and send the data across from the microchip, to display each miniature bitmap, one column at a time (since the data is transferred vertically on the data bus).

This means that a complete font set has to be designed and encoded.
I made my own font set using nothing more technical than a sheet of paper, a biro and the side of a CD case for drawing some straight lines! I made each font 8x5 pixels (a pretty standard size) but allowed a pixels space around each letter, so they are slightly smaller than most LCD fonts.

I then transferred these fonts into a custom-built VB application so that each character in the font set could be represented by 5 bytes of data. Now, when a character needs to be sent to the gLCD, the "row" (page) and "column" values can be set, and the data sent as a sequence of 5 bytes, to draw the letter as a bitmap on the display

After feeling really pleased with myself for finally getting somewhere near finished on a project that only came to life a few weeks ago, I've been showing it off to a few people to get some feedback. A few people at Brighton and Hove Petanque club showed some interest, and each had their own suggestions for improving it (for example, a built-in digital measuring device). The general impression was "it's a pretty good idea, but if you could build this into it, it would be brilliant."

I took the same device to the Whitefields Golf Course for some advice from real golfers. My original idea had slowly begun to morph into a "game scoring device with some extra bits for keeping golf scores". The response was similar to the last - "yes, very nice, but if you could make it do x,y and z, then it would be awesome".

So my general feeling is that a single game scoring device may end up being just a little bit too generic - a bit of everything for everyone. So I've decided to concentrate on specific games and build a scoring device that is specifically tailored to each. After all, the bulk of the code can be re-used between projects (selecting and storing player names and interfacing with an LCD/GLCD display for example). I just feel that in trying to be clever and create a device that does everything, I'm in danger of ending up with something that isn't really much use to anyone!

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!

Here's some code showing how to read/write to an eeprom using byte-addressing and Oshonsoft Basic. It was written for an 18f2455 running at 20Mhz and a 24C256 eeprom using I2C communication:

Dim addr As Word
Dim writebyte As Byte

Define I2CCLOCK_STRETCH = 9
Symbol sda = PORTB.3
Symbol scl = PORTB.4

addr=32
writebyte=100
Gosub writeI2C

End

---

writei2c:
  I2CWrite sda, scl, 0xa0, addr, writebyte
  addr = addr + 1
  WaitMs 5
Return

The key thing to note here is the "stretch" command and the 5ms delay after each write instruction. According to the datasheet, a delay of 5ms is needed to allow the chip to finish writing its data to the addressed memory location. In practice, this is a little bit long - you can get away with 4ms and some people have reported delays of 3ms or less. Others have also said it's possible to overclock these eeprom chips and have them running at 1Mhz or more.

I found that 4ms delay works, but to be extra-sure, I've gone for a 5ms delay after writing data. When reading data back from the eeprom, the delay is not necessary.

To use the code above, simply put a 2-byte address into the variable "addr".
Put a value into the variable "writebyte"
Call the sub-routine "writeI2C" using the gosub command.

Equally as important are the connections to your eeprom chip.
Leaving lines floating (ie. not tied to either power or ground) means really erratic behaviour with some read/write operations working and others failing. Here are the pin connections I used:

pin 1-3 (A0-A2): ground
pin 4: Vss : ground
pin 5: Vcc : 5V
pin 6: WP : 0v (write protect)
pin 7: SCL: to PIC pin (RB4)
pin 8: SDA: to PIC pin (RB3)

Ok, so it's been about four days since the last post, but that's because it's been real busy here at Nerd Towers, trying to get the Game Score Keeping Device working. Well, it was already working, but with very limited functionality and a tiny amount of memory (it was squeezed onto a 16F628A microchip after all).
But these last few days haven't been spent idly lounging around in the glorious sunshine we've had lately. Maybe just a bit. And of course there was the small matter of helping out laying the new surface at the Brighton and Hove Petanque Club on Tuesday.

But the good news is that we've very nearly completed another project! Yay!
Here it is on the prototyping breadboard. It's using a beefy 18F series microcontroller and has had loads of new functionality added.


The device is now dual-function. You can use it to record scores for games like petanque/boules, darts, even football! But it also has a special "golf mode" allowing you to download course details (par score for each hole) and to record your progress as you play a round. Golf can be played either against an opponent or in new "solo play" mode. The display changes slightly but the end result is the same: for each hole you record the par score for the hole, your score and your opponents score (if using two-player mode). These scores can then be downloaded to your PC and even uploaded to a web site, to allow you to monitor your progress over a period of time.
There's even a cute message at the end of each hole, telling you whether you've scored a "birdie" or a "bogey" (or one of many other golf terms that only mean something to the initiated).

The most difficult part of the project was introducing an external EEPROM chip.
This uses I2C protocol to talk to the PIC microcontroller. Getting the data read/write signal synchronised was quite tricky, because the micro runs as 20Mhz, whereas the eeprom can't go much beyond 400khz.

A full description of how it was made to work is here on the projects page.