Howard,

How does the LVB detect an LCD presence ?

In all the LCD programming I have ever done, it has been just logic levels towards the LCD.

Nothing in return ?

Are you talking to the LCD CPU ?

---------------------------------------------------------------------------- Andrew Rich VK4TEC [email protected] mailto:[email protected] http://www.tech-software.net

-----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Howard Long Sent: Sunday, 13 January 2008 7:53 PM To: [email protected]; 'AMSAT' Subject: [SPAM] [amsat-bb] Re: LVB tracker display problem Importance: Low

Hi Fer

I just finish to build an LVB tracker for a friend of mine. All works fine with NOVA but during a satellite pass the display stuck as in the picture:

I am not aware of a similar problem occuring. I wonder if it is possible to temporarily try a different display?

There is a section of code that attempts to detect whether an LCD exists or not, for those who don't use the LCD option. If at any point it takes more than 5ms to get a response from the LCD the software assumes there isn't one there and won't attempt to update the display again, until the tracker is reset.

However, looking at the display, it looks like the LCD may have somehow reset itself. This could make the software think that the LCD has been removed: a special startup sequence is needed to configure these LCDs after a reset.

Again, try a different LCD if possible, then check the power supply to the LCD is nice and stable without any glitches.

Also, if you simply press the reset push button, rather than cycle the power, does the display work correctly then? This initiates the LCD reconfiguration.

73, Howard G6LVB

_______________________________________________ Sent via [email protected]. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb

Hello Andrew,

How does the LVB detect an LCD presence ?

In all the LCD programming I have ever done, it has been just logic levels towards the LCD.

Nothing in return ?

Are you talking to the LCD CPU ?

Oh, it's not clever at all. When you send a command to the LCD, you can subsequently ask the LCD for a READY bit to see if the LCD's done its business. If it takes more than 5ms for the bit to become active, then I shut down all LCD communication until the device is reset. Usually, this failure would happen right at boot when there is an attempt to initialise the LCD. If the LCD for whatever reason throws a wobbler and doesn't respond at any point latterly while we wait for the READY bit, any further attempts are disabled too.

The idea behind this was that I didn't want a different set of code for each of the different options. I could have used the push buttons to do some configuration for this, but without a display, I thought that it would be a bit hit and miss.

Look at the code here http://www.g6lvb.com/Articles/LVBTracker/LVBTrack.c, and do a search on the global variable _bLCDActive. It is initially set to TRUE on a somewhat optimistic start during LCDInit. However you'll see it can be set to FALSE in one place, in LCDWaitReady. Various high level LCD routines won't do anything if _bLCDActive is FALSE.

It is wholely possible to do an optimistic algorithm that merely uses worst case spec sheet timings without ever having to read the LCD at all. That would either have meant plenty of dead time sitting in delay loops (equals slow and sporadic response for other parts of the system) or some complicated state machine. As it is, polling for the ready bit is usually only a few tens of microseconds or so. I guess I also just like the nice warm feeling of actually knowing something's listening. Myself I think it's neater to wait for the ready bit, but I accept it's a personal choice. Ask three software engineers the same question, and you'll get three different answers.

Hope this helps.

73, Howard G6LVB