Enduro Computer Project

WAIT!  Before you start reading and get disappointed, this is my research blog.  At this point, there is no enduro computer, it's not finished.  If fact, I'm still roughing out the design.  It may never get finished.  And, it's low priority for me.  I'm starting this now because I'm having to work through some technical issues and maybe somebody else might find my notes useful.  That's all.

Current status: Pre-Alpha, just planning at this point.

The plan: To set up a 2.4" TFT LCD display shield on an Arduino Uno with a Hall Effect sensor and some code and mount it on the handlebar of my Dirtbike for enduro racing.  Total cost should be in the $20 range (and that's probably overestimating).

So, I picked up a 2.4" TFT-LCD touch-screen from Ebay.  Absurdly cheap, in the $5 range.  It's an Arduino shield for an Uno, and it leaves enough pins for me to run a hall effect sensor, which I'll just salvage from a bicycle speedo (another stupid-cheap Ebay purchase).

Problem 1: Drivers for the TFT-LCD.  It appears there are a great many variants of these shields available, and very few come with any kind of documentation or libraries.  Most happen to have "www.mcufriend.com" printed on the PCB, so that means very little.  That website is in Chinese.

Most of the available drivers I tried for this just left a white screen, though the serial output seemed to work.  I did find one, SWTFT, that mostly works.  I can run the tftpaint example, except there is a white bar down the side.  Running the graphicstest example show that it is trying to write under that white bar, and it is trying to write with a backwards font.

Solution 1: The key is to identify which control chip you have and then get matching drivers.  Identify your chip with a utility found here.  Open the Serial Monitor in the Arduino IDE to see the information.

Solution 1a: My TFT-LCD shield uses the '4535' chip.  I found libraries for it at:  Cee'z Blog.  If you use his libraries then buy him a cup of Coffee, I did.  It's worth it.  Everything worked great with Cee'z libraries and example sketches, except the touchscreen was backwards.  No problem though... just run his example calibration sketch and copy the resulting numbers into the config section of the sketch you want to run.  Yes, the "min's" end up being bigger than the "max's" but everything's good after that.

The 'calculator' utility makes for a great example to work from.  Next thing is to figure out how I want the main display to look, and maybe a few sub-displays.

Problem 2:  Using the shield on an Arduino Uno seems to use all the pins.  I've read that A2 is not used, but my shield has a label for that pin (LCD_RS) and not using that pin (bending it out of the way... hey, it's a $5 shield) leaves a white screen.  The Ebay seller states that "you can use digital pins 2, 3 and analog 4 and 5. Pin 12 is available if not using the micro." Some of those pins are labelled. It will not work with D2 and D3 bent out of contact, so the seller's information is not correct either.

Solution 2: The D0/D1 (RX/TX) pins are not labelled on the shield, bending them out of the way left the display still working fine, along with the touch screen, but I've not yet determined if they're needed for the SDcard.  A5 (not labelled) does not seem to be used either.  A4 is labelled as the LCD_RST (reset?) and while it will work bent out of the way, I'm not sure if the library is writing to it or not.  Of course, switching to a MEGA, instead of an Uno, gives a lot of useful pins... but also left a white screen.

Solution 2a:  Using the MEGA is actually fairly simple.  Just edit LGDP4535.cpp (in Cee'z library), commenting out the Uno line and uncommenting the MEGA line.  '//' means this is a comment.
This says to use a MEGA instead:

#include "mega_24_shield.h"

//#include "uno_24_shield.h"

Don't forget to switch back if you want to use an Uno.

Background:  Enduros, for those that don't know, are races where the object is to travel at a set average speed rather than as fast as you can.  The trick to winning them is, however, not just riding at that speed but rather as fast as you can at the start of a section, then guessing how far to the next check, and then calculating what time it should be when you get there.  Parts of the section are typically very difficult to maintain the correct speed while other parts are easy.  Thus, there is a lot of guesswork involved, and math at the same time.  It's pretty easy to figure out how far you should have gone in 15 minutes if the speed is 20km/h:  20km/h * 1/4h = 5km.  Figuring that out for a speed of 17km/h over 10 minutes: 17km * 1/6h... not so easy when you're crashing through the bush and scrabbling over rocks and roots at speed.  Yeah, people actually pay to do that.  Crazy people anyway.  Even crazier ones pay big money for a handlebar mounted computer to do the math for them.  Then, there's cheap and crazy people like me that set out to build their own.

The Interface:  There are a lot of different ways to present the needed information but what I think I want for the main display is simply +/-Minutes, as big as I can make them.  Negative minutes means I'm ahead of where I should be and have some slack.  Positive minutes means I need to run WFO and catch up.  It will have 2 on-screen buttons:  Error and Check.  'Error' means I've missed a turn, happens a lot in enduros, and need to subtract some distance while I get back to the marked trail.  'Check' marks the clock, displays my results, resets the minutes without resetting the seconds, and lets me set the speed for the next section.

More later...