HamHUD I

First of the HamHUDs - 1997 & 1998

Steve Bragg KA9MVA's

 NAV MENU


-> HamHUD Home

-> HamHUD II Kits
-> Homebrew HamHUDs
-> SmartBeaconing
The HamHUD I was the first experiment in the HamHUD line.  It is now obselete, but I am going to leave this material online, so others can see how HamHUD got its start.

Features

Here are the main features of the HamHUD I
  • Connects to serial port (TXD,RXD, and RTS) of Kantronics TNC configuredfor tracker mode.
  • Does not modifiy the configuration of the tracker in any way (see Compatibility,below)
  • Receives and displays all packets as they arrive (including packets fromthe tracker GPS beacon)
  • Parses all fixed and mobile APRS® posit formats, except objects (comingsoon) and gridsquare (no plans)
  • Parses all APRS® message formats (including message ACKs)
  • Parses (and scrolls) APRS® status format, and displays as status anypacket it doesn't understand
  • Parses $GPRMC GPS posits, recognizes GPS posits that aren't GPRMC
  • Parses TH-D7A / MIC-E format (position, course & speed)
  • Display bearing and distance in STATUTE miles to each posit received
  • Display distance, speed and heading for GPS stations and stations showingcse/spd
  •  Display temperature and wind data from stations w/Davis and UltimeterII weather units
  • Indicate whether received packets are digipeated

    Compatibility

The HamHUD was developed with a Kantronics KPC3+ TNC.  It is my hopeto get this thing to work with all the TNCs that are commonly used. To do this, I'll need help testing them.

For HamHUD I's parser to work, the callsign, UI path, and UI identifierhave to be followed by  (one or more of) CR, LF, then the rest ofthe
packet, followed by (one or more of) CR, LF.  My KPC3 and 3+ bothdo this by default.

Check that the following settings are correct:
 
MONITOR ON
CRSUP OFF
LFSUP OFF
HEADERLN ON
MHEADER ON
MXMIT ON
PACLEN 0  (means 256)
UNPROTO APXHUD VIA ...
Among these settings are those which force monitored packets to be of theform:
 
KC5TRB-2>GPSLJ,TULSA*,WIDE4-2: <UI>:
$PGRMT,GPS 25-HVS VER 2.22 ,P,P,R,R,P,,35,R*0A
Note that the header and packet data are on seperate lines.

The only real dependencies are these:

  1. The packet must be printed on two lines, seperated by at least a carriagereturn (LF's optional).  The packet must be of the form: CALLSIGN>PATH:<UI>:<CR>{<LF>}

  2. DATA<CR>{<LF>}
  3. The TNC must respond to MYCALL as:  MYCALL____KKKKKK-NN

  4. where K are the letters of the callsign,-NN is the optional SSID, and_'s are spaces.
  5. The TNC must enter Converse mode when K<CR> is sent, and exit Conversemode when <CTRL-C> is sent.
I chose the Kantronics unit for all the right reasons; it seems to be theTNC of choice for mobile trackers.  And, while this isn't exactlya product endorsement, I have had no problems and highly recommend theKPC3PLUS.

The following TNCs are known to work with HamHUDs:
 
TNC Manufacturer / Type
Tested by
Kantronics KPC3+Steve Bragg KA9MVA
Kantronics KPC2Mike Young WB8CXO 
Kantronics KPC9612Bob W2/G3ZFJ 

Only the KPC3+ works with a GPS, though.  On my list of thingsto do is a port-sharing scheme for GPS.  (Note: this was implementedin HamHUD II.)
 

Photos

OK, OK, I'm not a photographer.  But these depict what HamHUD I'slooks like with real-world data.
Below are photos of the HamHUD I that Mike Young WB8CXO built. Nice work, Mike!

Here are some better photos of it:


Notice the Firmware Rev Date in the picture above!  This is onlytwo months after the very first rev of HamHUD firmware!


Bob W2/G3ZFJ put one together, too.  Here's his packaged and onthe dash (right) next to his Harper GPS display.
The next picture is of the prototype, unpackaged.

Backto Top


Design Considerations

This is probably best described by saying what this thing is NOT. It's NOT intended to replace the traditional map-based APRS® programs. It's also NOT intended to store every single message and packet that goesby.   As you will see, this isn't the huge limitation it appearsto be.

By the very nature of APRS®, older information is less important. The HamHUD takes this to the extreme:  every packet is processed anddisplayed ONCE.  That's it.  There's a delay between packetsso you can see them (and since the TNC has SCADS of memory, I say let itbuffer them up :-> ), but once a packet is displayed, it's not stored.

There are precious few exceptions to this "real-time" philosophy. The unit stores your callsign and  your last known position.

In practice, I find that I don't miss much.  Since APRS® retransmitsimportant data often, I usually see messages more than once, and positsmore often than I really need.

On the subject of messaging, one-line messages are often sufficientfor attention getting, light status, etc.  The HamHUD is designedto auto-ACK any message addressed to MYCALL.  To let others know theHamHUD has onboard message display capability, a short message can be addedto your status beacon.

If HamHUDs become more common, it would be interesting, I think, tocome up with a standardize "hail" message, sort of like one ship hailinganother.


Technical Details

The HamHUD is based on the Microchip PIC16C76, a more-powerful member ofthe same midrange family that includes the ubiquitous PIC16F84.  Thischip has a hardware serial port and 384 bytes of RAM.  While thisisn't a lot, it's enough to keep some minimal status, messages, and yourcurrent position in memory.  Also, the floating point calculationsfor bearing and distance take up quite a few bytes of RAM.

The PIC is hooked directly to one of the standardized parallel-interfaceLCD modules, like you get from DigiKey.  My prototype uses a 16x2backlit model, but I've proved to myself that a 20-character-wide displaywould be much more useful.

The HamHUD is hooked to the serial port on the back of the TNC witha standard 9-to-25-pin short modem cable..

I built my HamHUD using a Radio Shack perfboard, using a socket forthe PIC.  All of the parts are available from Radio Shack and Digi-Key.

I am using a full spherical earth model, with the cosine law navigationtrig.

A 16-character LCD is currently supported, and later I hope to supportothers.

Power:  I connected my HamHUD directly to the power switch insidemy KPC3+.  If you want to power it externally, you will have to adda power jack to your case.
 

Parts List

QtyPart Number      DescriptionManufacturerVendorEst Price (US$ qty 1)
1PIC16C76/JWMidrange PIC processor, 20 MHz, EPROM windowed package, 
28-pin sidebraze ceramic DIP
MicrochipDigiKey$15.86
1
1MAX232ACPEDual RS232 transceiver IC with integral charge pump, 
16-pin DIP
MaximDigiKey$4.88
1115-93-328-41-00128 pin 0.3-inch width IC socketMill-MaxDigiKey$2.02
1DMC-16202NY-LY16 x 2 LCD module with yellow LED backlightOptrexDigiKey$26.02
More to come...


Development

The HamHUD is s incremental development project.  I started out byjust monitoring raw packets on this display, then slowly progressed toprocessing them and displaying them in a manner that seemed consistentwith my design goals.

The first packet type I implemented was status.  That way, everythingthat I didn't know what to do with could be displayed as status. Then, I implemented the parsing of Weather, APRS® posits, GPS posits,and messages.

The development of the range and bearing software came last, after Iwas completely sure I'd correctly implemented parsing of the various positformats.

My development cycle goes like this:  I'll burn a chip, and thendrive around with it for a few days, noting what's wrong (Tulsa is VERYactive on 144.39, BTW), and then fixing what is broken or what I don'tlike.   After about two months of this, the code is startingto settle down.

After the source code settles down, I'll set up an open-source archivewith controls so that other hams can contribute.


Notes from the Field

I've been using it as I'm driving around for about two months now, andit's really neat to see the other mobiles' positions, speeds, and courses
relative to yours.  It's also great for mapping DIGI coverage.

One day when I was going to work, I saw a buddy's (KC5TRB-2) mobilealso headed into Tulsa.  He is often out of town, so I figured hewas headed home.  However, over the next few minutes, I saw his rangedwindling, and on an intercept course.  We were going in oppositedirections on the same road!  This kind of interesting stuff becomespossible when you know the other mobile stations' position, bearing, andspeed relative to yours.

If you build one of these, PLEASE, PLEASE!  Pay more attentionto your driving than to the display!  I intentionally ignore minewhen I'm in traffic (yes, we have that in Oklahoma).  Out on the openroad, you can look at it and still see the road.


Example Displays

    APRS Status  (in all displays, a * indicates a digipeated packet)
       
      |*KA9MVA-6 GPSMV |
      |HamHUDdin' it!  |
       
    Weather (Ultimeter or Peet Bros) - HamHUD shows Wind & Temp only
       
      | N5NYP APM325   |
      |70F Wind 10@270 |


    APRS or GPS (fixed or mobile position)

       
      | N5NYP APM325   |
      |2.10 mi @359    |


    APRS messages

       
      | KC5TRB>N5NYP   |
      |Steve's a nut!  |

      (rest of message is scrolled, bank-sign-style, after a short delay)
       

    my GPS mobile (MV is the GPSxyz icon ID from the TNC's path, which in thiscae is a car)
       
      |myMV 23@240     |
      |360919N0955910W |

      Back to Top


Frequently Asked Questions

"So where can I buy one / get a kit / etc."  You can't. This project is currently still a whacky science experiment, and I'm justsharing the results with the ham technical community.  It's not aproduct (yet).

"OK, but I just want to build one up to play with / help you in development/ etc."  OK, you can build your own hardware and burn your ownPIC.  Later, I will publish the PCB files, and maybe we can talk someoneinto making the PCBs.  I told you this wasn't an appliance...

"Could you put a user interface on it, so I can set my messages/mymonitor freq or send TNC commands?"  I really want this one, too,so I can stop lugging around my Radio Shack Model 100 laptop!

I am currently developing the firmware to use an optical encoder knobwith a switch that's engaged when you push the knob in.  That interfacecould handle just about everything, and would be pretty fast to dial throughboth characters and menus.

On-screen prompts will guide you through composing messages, selectingpre-composed messages, and sending TNC commands.  I think what weneed for the last is to have a list of most-often-used commands (like LT,BLT, LTP, GPSHEAD, etc.) that the software "guides" you through, so youdon't have to click out every little character on the knob.

"Is the inter-packet display delay adjustable?" (de KC5TRB) No,not yet.  That's in my plan to do once the user interface is up. The default is set to 4 seconds.  The scrolling delay is set to 250mS between characters.

"Does your thing work with a {PacComm, MFJ, TAPR, BayCom, Timewave},etc TNC?" Honestly, I don't know.  (BayComs won't work becausethey aren't a real TNC) I don't own any of those TNCs.. can you help? See the Compatibility section.

"Why didn't you use a cheaper PIC?  e.g., PIC16F84" I neededthe memory and peripherals in the 'C76.  I suppose I could have doneit in a PIC16F84, but I would have had software serial routines, and verylittle spare memory.  The truth is, I use 'C76's all the time, andI had them around.

It might be possible to implement a subset of the HamHUD functions ina PIC16F84.  Go ahead!

"I wanna map, and a list of stations, and I wanna scroll down thruthem, and double-click to see..."  Well, then, you need one ofthe existing personal-computer versions of APRS®.  It is againstthe design goals of the HamHud to require very little (any?) interactionwith the device.  You're supposed to be DRIVING, remember?

"Can I hook up my laptop with (x)APRS® running on it, while theHamHUD is inline?"  I don't know why you'd want to do that, butyes, you can, with a special RS232 "tee" adapter that you build. Just hook the TNC's GND and TXD lines to the HamHUD.  That way, incomingpackets get displayed, but the HamHUD doesn't try to send commands to theTNC or control the serial data flow while the computer is trying to. One potential caveat is that the current version of HamHUD code is thatit doesn't try to identify TNC commands in the incoming data stream, sothey get interpreted as APRS packets (usually as status).  You mightget a funny display when APRS sends out commands...

Also, be sure to boot the HamHUD BEFORE connecting the computer, sothe HamHUD can get your MYCALL.

"Your range and bearing calculation is at least a hundredth of amile off!"  Granted, in some places it is MUCH worse than that. Due to the limited computational horsepower available, I didn't think Icould implement a real Sodano (eliptical earth) model; it's just a circularearth model.  Well, I was a bit over-conservative there, and a Sodanoalgorithm is in the works, just as soon as I can find one in C <grin>.

Also, there's another (slight) problem.  To keep the parser simple,I chose to simply truncate GPS lats & lons at the 2nd digit after thedecimal.  While at mid-latitudes this isn't usually a problem, athigh latitudes, the earth curves so drastically that the other figuresbecome more significant.  "Fix it," you say?  Wanna write a parser<grin> ?


Contact: Steve Bragg KA9MVA (email: steve _at_ hamhud.net)
Last Modified: July 4, 2006

Legal: The information in the HTML pages, schematic and source code are copyrighted © 1997-2006 by Steven D. Bragg, KA9MVA. License is granted to freely use, reproduce or modify this material, for non-commercial amateur radio purposes only. This information carries no warranty of any kind, including any implied warranty of fitness for any particular purpose. I am not liable for any damage to equipment or other property, or injury, or loss of life, attributable directly to, or related to, the construction or use of a HamHUD.