Something that has been bugging me for a little while now is the backlight on our ScoreSure Golf Pro device. It works fine when a 3V3 supply is put to it. But the PIC microcontroller can't provide enough current to drive it directly from one of the output pins. So we've been using a transistor (an NPN BP199 from Farnell if you must know) to switch the backlight on and off via an output pin on the mcu.

It works, but we've never been 100% happy with it.
The backlight comes on, but it's noticeably dimmer when the transistor is used, compared to just connecting power to the LED anodes. But we've got to the bottom of it - it's all to do with using the microcontroller to "sink" or "source" the power to the backlight LEDs.

Here's how to use an mcu and transistor to "source" current for the LED backlight:


When the PIC micro backlight output pin is high, the transistor allows current to flow from the power source into the LCD backlight LED anode (LCD_A+).

Here's how to use an mcu and transistor to "sink" current for the LED backlight:


In this example, the power is always connected to the backlight LED anode (LCD_A+), but the transistor only allows current to flow from the LED cathode (LCD_K-) to ground when the PIC backlight output pin is high. This is known as "sinking" current.
The two switching techniques both work - only "sinking" the current makes the LCD light up nice and brightly, whereas when "sourcing" current through the transistor, the LCD does light up, but more dimly.

We asked for a completed, working schematic, a website, an online golf course editor and a way of getting full-colour images to display on the screen, instead of 16-colour images with their nasty jaggedy edges.

Working late into the night on Xmas Eve, we finally got the full-colour images working, with beautifully drawn, smooth-edged hand-drawn pictures of golf holes on the little LCD screen. (Actually they're not full-colour, but 128-colour-palette images, but you can break a large image up into pieces and get near-photo-quality results with each piece using just 128 colours per image).

But that was all we had time for, for a few days - with family and work commitments (had a brilliant Xmas by-the-way) - development has stalled and will probably remain that way until after the New Year (even nerds get invited to New Years Eve parties you know!)

Now we're getting somewhere - not just photos of LCDs with boring old text and plain old rectangles, or photos of random images (that don't draw properly). Here's an actual real video of the actual, real device doing something actual (and real).
It's showing the golf hole and image data for the first few holes from the Whitefields Golf Course. That's real, actual data, don't you know!

Here's a screenshot that we've all been waiting to see (well, at least those of us involved with the development of the latest version of ScoreSure). It's showing the ScoreSure Golf Pro with details for the first golf hole from the Whitefields Golf Course. Check out the details on the online scorecard. Hole 1 really is called the Flyover and the par for the hole, for blue white and yellow tees really is 4. And the stroke index for hole one, when playing off red tees, really is 15.

All this information has been loaded into Flash/eeprom memory and is pulled out when the device is in "run" mode. But never mind how accurate the information is or isn't (it is, actually!) just take a look at how beautiful it looks.....

...but a mere microsecond when you're working on a technology project with a looming deadline. We've not had much time to update the blog lately, but that's because things have been happening (and changing) at quite a pace over in Nerd Towers.
We're on a mission to get the first ScoreSure Golf Pro prototype developed and working, which has meant lots of late nights and early mornings, and hundreds, nay thousands of lines of code being written and re-written.

The big panic is because our mate Xing from NuElectronics is over in China for Xmas, and we've a fantastic opportunity to actually get some real, working prototypes made up.
Not a bread-board prototype (which is what we use for development) but an actual, final product, in a professionally finished enclosure and a fancy little wallet!

All this, of course, means that we actually have to settle on a final design for the schematics and that in turn has meant ironing out lots of little bugs and issues. For example, making sure that the Flash memory is connected to a consistent port and whether lines we've tied to power/ground may need to be controlled in future developments. It's a balancing act - getting enough done to meet today's demands, but trying to think about what might be needed in future versions of the product so we can re-use the same products and not have to re-develop the entire thing for a minor change.

The biggest obstacle we've had is stream-writing data to the Flash eeprom chip.
We thought we had this nailed, but when drawing bitmaps back to the screen there were missing pixels in the image. We put this down to a dodgy bitmap drawing routine and decided it would be easily fixed. It turns out, that the problem was actually with the Flash/memory writing routines and we had big gaps in our bitmap data!

That in turn has meant rebuilding the device pretty much from the ground up to try to isolate where the problem stemmed from (after all this, there was a bug in the VB app we used to send data to the ScoreSure device, not the actual device itself!). It was a worthwhile exercise, however, because our written design - the electrical schematic we sent for production - has changed quite a bit since we've gone back and had to re-think everything.

But - finally - we have a working ScoreSure device. One that can display menus as well as bitmaps. You can even edit menu entries so we have a mechanism for editing player details.

We're off to fill up on coffee and get back to the grindstone.
In the meantime, here's a screenie showing working bitmaps on the QVGA LCD screen.



And for regular readers of the blog, who may be asking "what about the online Google-maps-based golf course editor"? (all two of you) here's a link to try out latest development: http://www.scoresure.co.uk/googlemaps.htm

...which can only mean plenty of activity up at Nerd Towers.
And you'd be right - we're busy working away on an online golf course editor. Yes, yes, we've already done one of those. But this time, it's different.
This time, not only do you get to drop trees and bunkers onto a pre-made map shape, but you're actually drawing the map that appears on the ScoreSure device itself!

After the partial-success of the bitmap drawing routines we had to decide which would be the best format for saving/displaying bitmaps on the device. RLE (run-length-encoded) bitmaps are nice and quick to draw, use up very little memory - both on the microcontroller and in storage - but lead to very small colour palettes. True-colour images are possible, but take up huge amounts of storage, cannot be buffered or loaded into RAM and are quite slow to draw onto the screen (streaming a single pixel of data from eeprom via two calls to extract two bytes means drawing the screen is quite slow).

So then we got to thinking about RLE bitmaps and how they could be used to draw things like sprites. And then we figured, it would be nice if we could make full use of our colour screen by displaying a little digital map of each hole as they are played. And then we thought "that's a lot of work, creating bitmaps and accurate data for all holes on all golf courses, all over the world!". So what better way to offload some of this workload, than to give the user the tools to create their own golfing maps?

They wouldn't even have to stick to designated golf courses. Got a mini-golf in your back garden? You could create your own online golf course and download it onto your ScoreSure device. Suddenly, there are a world of opportunities - and all because users can create their own maps. What we need is a Flash-based golf-course editor!

Here's how it works:
Find your favourite golf course using the integrated Google Maps editor.
Click the appropriate button(s) to select which "layer" you're going to draw on (there's a separate layer for the fairway, the green, and any bunkers/water)
Draw shapes over the top of the Google Map (changing the transparency to allow other layers to show through as necesasry). In the example, below, you can see we've started drawing the putting green.

When you're happy with your colouring in, hit the "next" button (currently "save") and you get the change to rotate, resize and generally mess about with your map, to get it to fit inside a window that will fit on the ScoreSure screen (at the time of writing, 100x240 pixels).


One of the holes at Whitefields Golf Course, Thurlaston, Rugby in the map editor

With the map in place, facing the right way up and so on, you can then drag and drop the rest of the "furniture" in place - trees, flag, teeing off points and so on.
The idea is that whatever you put together in the Flash editor will be used to recreate the map EXACTLY on your ScoreSure Golf Pro handheld device.

So if anyone has any disagreements with the maps on the device (a range of ready-made maps will be made available for download from the ScoreSure Golf website) they can go off and create their own!

There's a pretty typical pattern emerging here - a few days with no blog posts = flurry of activity "offline" in the real world. And that's exactly what's been going on this time around too. We've been working like a room full of monkeys (not eating bananas and throwing poo around, more like the monkeys that sit with the typewriters banging out the works of Shakespeare) to get some pictures on the LCD screens.
And finally, we think we've cracked it.
Have a look at this - it's the opening screen for the ScoreSure device.



And here it is, actually displayed on the QVGA LCD.



See? Exactly the same.
Well, ok, maybe there's a bit more work to do on this one.
The missing stripes of data could be one of two things:
a) The code drawing the image from Flash to the LCD is screwed up or
b) the more likely option, sending data from the PC to the Flash memory is dodgy

But it's definitely a picture. And it definitely nearly looks like the picture we want to it. So once again, a bit more work and I'm sure we'll have it cracked....