A GPS adjusted clock

We recently got a new cable box.  The new box has a clock that is a little smaller than the old one, and my wife has a hard time seeing it. We had an LCD clock with huge letters but there just isn't enough light in the place we want it.

So, NE06 GPS modules are getting pretty cheap. Why not get some huge seven segment LEDs and build up a clock based on a GPS?  Turns out large LED displays are fairly hard to come by, and pretty expensive. Plus, all that wiring to all those pins is a pain.

Then it hit me: I have some TFT displays, not huge, but plenty adequate for inch or inch and a half high digits.  If I used the TFT, I wouldn't even have to build the board; I could use my serial graphics terminal board.

First step was to see if I could make huge letters without too much hassle (the largest font I have is only about 3/8" high).  The first whack isn't too bad. It will work, although I might yet do some prettying up of the font.

So, on to the GPS.

I started with my serial terminal code, which may have added more complexity than I needed, but it works.  This code fills a circular buffer with serial interrupts from the GPS and the mainline has to process the contents of the buffer. This makes missing characters less likely but it does mean the mainline is futzing with trying to understand whether there are characters in the buffer and identify the start and end of the GPS data.

Parsing the GPS data is tedious, but not especially difficult.  With the PIC32MX150F128B there is plenty of memory, so I can be pretty aggressive with my code.  Most of the code is the TFT library so the stuff I'm working on is pretty small anyway.

At this point I can get the time and coordinates (which I don't need).  I am displaying all sorts of values which eventually won't be used.

Next up is to get the date, and go through the tedious business of determining whether it is daylight savings or standard time. The correction is trivial but knowing when to apply it is a pain.

Following that I'll get after the PIC's real time clock calendar.  Supposedly the PIC can maintain the time to within a third of a second per month.  I'm not convinced can actually accomplish that, but adjusting it from time to time through the GPS should keep the time always correct.

Since even in the basement with overcast skies I can still see 8 to 11 satellites that might be overkill.  If I have too much trouble with the RTCC I might just skip that, but the next priority is the daylight savings time thing.

The code is currently partial, and pretty rough, but as always I keep everything in git and the current code is in gitlab:
    https://gitlab.com/PIC32MX/gpsTime.X

The board hardware is at
  https://gitlab.com/PIC32MX/tft-board-pcb

And the TFT library code at
   https://gitlab.com/PIC32MX/TFT.X

They will be updated as time goes on.

170807:
OK, so some code cleanup, and slightly larger digits, but still significant work to do:

The digits are actually a tan color, but it doesn't show in the picture.

170824:
And yet another little tweak.  After seeing the clock it occurred to me it would be a nice addition to the shack, too, providing it showed UTC as well as local.

Sooo.....

 Time to get on to making cases, perhaps.

Serial Graphics Terminal

It has been a while since I last posted here, and there have been a number of fun projects under the bridge.

One of the more fun, with more work still planned, is the development of a serial graphics terminal.

Most PIC projects use an LCD for a display. It is cheap and easy, but it has pretty limited real estate, and it uses a bunch of pins.  For quick little test projects, you often spend more time hooking up the LCD than you do on the rest of the project. Serial LCDs are expensive, and don't solve the problem.

More recently there have been some relatively inexpensive TFTs available. Fairly small 320x480 displays have tended to be among the least expensive, but they take even more pins than the LCDs, and quite a bit more code.

Suppose we could connect one of those things up to the serial interface.  That would allow a competent display with only one or two pins.  If we put a lot of smarts into the terminal, the performance might be decent, and we might even end up with a small software footprint on the host project.

Unfortunately, there are relatively few PICs available in 40 pin DIP, and those that are tend to be pretty slow or have limited memory.  I wanted a fast PIC with gobs of memory in a DIP package that I could prototype easily.

By using the MCP23S17 I/O expander, I could get enough I/O to handle a TFT, and selected the PIC32MX250F128B.  Turns out that the PIC32MX150F128B is the same for this purpose, and cheaper, but at the time I could get the 250 quicker.

So I breadboarded up the thing, mounted on my breadboard dsPIC-EL as a test host, and the thing worked.

I developed first text terminal code, then graphics terminal code, and decided that a custom PCB would be worthwhile.

The serial performance, even though limited by the I/O expanders, is quite good.  I developed a graphics library for the PIC32 that the terminal code builds on. The board is capable of the things you would hope such a terminal would do.

One of the things that is a real pain is drawing decent graphs.  All the piddling around in getting the axes and legends straight is a major hassle, so I decided to put a graphing feature into the PIC32 so that a small host application could draw decent graphs.




The TFT library makes it tempting to do projects directly on the TFT board. Unfortunately, there are only a few pins left (which are brought out to a connector), but a simple logic analyzer was irresistible:

Although the performance is quite good, and for most things, even with a serial connection, speed is not an issue, there is one place where the performance falls down, and it is a common one: drawing a continuously varying graph like a strip chart recorder.

A strange thing about this particular TFT controller is that it takes as many commands (and as much time) to fill a rectangle as it does to draw a pixel. When drawing lines at odd angles, like a graph, each pixel must be drawn individually. In this case, the MCP23S17, even though SPI is running at 10 MHz, simply can't keep up.

A large buffer in the PIC32 mitigates this problem for finite lines, if you want to continuously monitor a variable at some point you overflow the buffer.  Even with a huge buffer, at some point it fills.  I have done some experimenting with XON/XOFF, but this requires more complex code in the host.


The next step will be to prototype something with the PIC32MZ1024EFH100 (the 100 pin part is necessary to get all the pins in a single register). If the prototype can substantially improve performance, then I will look at a PCB for that part.

Again, I have no plans in marketing this, but everything needed is in GitLab. PCBs can be cheaply made and all parts, except the TFT, are available from DigiKey. The TFT is a SainSmart 20-011-918.

Project Components (all gitlab projects except document):

•  PC Board
•  PIC32 Graphics Library
  
•  Graphics Terminal
  
•  Description of terminal protocol  (pdf)
•  A host library for the PIC24 

The following is a little video to give an idea of the performance of the serial terminal: