How could a GPS unit integrated with a SOTA transceiver assist in activations? I’ve been turning that thought over for a while now after seeing David VK5KK’s GPS and Arduino based grid square locator (posted to the ‘VK Homebrew’ group on facebook). The ready availability of cheap GPS units with a simple serial interface makes the option straight-forward. As my homebrew rigs are using Arduino Nanos and si5351 breakout boards, the GPS is just another (serial) attachment.
GPS data supplies latitude, longitude, height in meters ASL, and date and time in UTC from the network of low earth orbiting satellites. Apparently, GPS horizontal coordinates are accurate to within 4 meters, and commonly 3 meters, depending on the number of satellites the unit can ‘see’. Being on a summit is the best possible place to be for getting a GPS fix, because the sky is clear to the horizon for 360 degrees (is there a summit where this is not the case, trees notwithstanding?). The ublox 6M device returns lat and long coordinates in degrees to 5 decimal places, which should give a theoretical accuracy of 1.1 meters north-south.
GPS time is another much-written-about topic. An accurate display of UTC date and time is useful as all SOTA logging is UTC, and the UTC rollover is a big thing for VK chasers if you are on a summit around 00:00UTC. Apparently GPS time may be up to 19 seconds behind UTC, due to the insertion of leap seconds in terrestrial time. Perhaps I should bear this in mind at rollover.
Not surprisingly, GPS altitude (elevation) accuracy has been explored in depth on SOTAWatch. There’s more to GPS altitude measurement than meets they eye. The discussions run on and on. I’ll leave it to Ron VK3AFW to provide a nice take-away for amateurs like me:
As a rule of thumb I would take a reading of 30 m below the summit as maybe beyond the extent of the AZ and a reading of 20 m as being maybe within the AZ but I would really want to do a difference measurement between the known summit (cairn or similar marker) and the operating position.
Back to the GPS experiment. My idea is to have the GPS data populate the LCD display with the push of a button, for (say) 5 seconds, after which the display reverts to the usual VFO and rig control data. It would report latitude and longitude, UTC date and time, grid square, and elevation. Elevation could be a useful confirmation that you are in fact within the summit activation zone (given Ron’s heuristic). The code to map coordinates to a grid square is about 30 lines of Arduino C and is freely available online.
It is also possible to map lat/lon coordinates to SOTA summit coordinates to determine your distance to the actual summit. This would require the Arduino to store pre-loaded summit coordinates. An alternative might be to use a GSM-enabled MCU to call a web service to do that calculation, assuming the summit has mobile phone access.
I purchased a Ublox 6M GPS module from Core. It is a small (tiny!) PCB with the antenna/receiver module on a short flying lead, with the tiniest of tiny coax connectors I have ever seen. Pray this doesn’t break. Note the background is a 20c piece.
The GPS module connects to any Arduino digital pins for serial data transfer. I used D2 and D3. GPS power can be 3.3 or 5v which I took from the Nano. On power-up the module detects satellites and starts emitting strings of data on its serial line (depending on its configuration) at a rate of about one every second. The format is something called NMEA and of course there are a number of ‘standards’. The ublox 6m can be told to only send certain messages, I didn’t bother to alter the default configuration. Most simple scripts appear to just ignore all but the strings that contain GPS summary data. Some scripts just do string parsing. Others use a library. I tried the Adafruit GPS library. The TinyGPSPlus library does some useful things but takes more memory and requires an Arduino Due for its floating point processing.
Before trying to get a script working, I connected the GPS module up to a Windows 10 machine running ublox’s U-center software. To do this, you need a serial to USB converter. I used this one from Altronics. It translates the bare wire Rx and Tx serial lines to USB. U-center is a sophisticated application that displays satellite maps, and a bunch of other information streaming off the little GPS device. There are a number of videos to give you the idea.
The Nano dedicates its only on-board serial hardware to the USB connection for downloading software and at runtime for the serial monitor, accessed via the Arduino IDE. You need to preserve these pins for these purposes. So to connect up a second serial device, you can use a software serial emulation. SoftwareSerial comes built-in with the Arduino IDE. There’s a lot of discussion online from people not getting this working but it worked first time for me.
I implemented a loop to read a serial character from the ublox GPS and write it to the serial monitor, resulting in a stream of NMEA strings appearing. Next, I tried Adafruit_GPS library, but could not get it to work, the object never decoded a message despite messages being present. So I coded up a simple string parsing algorithm (using Arduino String class) that tokenises the comma separated fields in the messages.
The u-blox 6 Receiver Description with Protocol Specification defines all of the NMEA messages and is easy to follow. I picked out the following messages with fields I might want to use:
Recommended Minimum data:
$GPRMC,083559.00,A,4717.11437, N, 00833.91522, E, 0.004, 77.52, 091202,,,A*57
utctime^ ^lat ddmm.mmmm ^long ddmm.mmmm ^spd ^course ddmmyy
Course over ground and Ground speed:
Where sog=knots, kph=km per hour.
GNSS Satellites in View:
^ nbr satellites in view
Where NoSv=Satellites in view.
Global positioning system fix data:
Where NoSV=Satellites Used, Range 0 to 12; msl=MSL Altitude (Height above mean sea level ).
Time and Date:
$GPZDA,082710.00,16, 09, 2002,00,00*64
utctime^ dd mm yyyy
$GPGGA (Global positioning system fix data) gives me lat, long, UTC time, number of satellites, and altitude.
$GPRMC (Recommended Minimum data) adds speed in knots and (UTC) date.
$GPVTG (Course over ground and Ground speed) gives me speed in km/h but I can calculate that from the speed in knots field in $GPRMC.
$GPZDA (Time and Date) gives me atomised dd/mm/yyyy date fields but I can do that in software from the date field in $GPRMC.
$GPGSV (Satellites in View) gives me the number of satellites the GPS is currently seeing (compared with the number of satellites used to get a fix in $GPGGA), which is kind of useful as an indicator of proximity to a fix at power-up.
My software detects and parses $GPGGA, $GPRMC and $GPGSV messages, and does format and type conversion where necessary for the LCD.
Lat/lon unit conversion
Lat/lon data is the NMEA messages is the form “ddmm.mmmm”. The algorithms that require lat/long data need degrees (with a decimal fraction of a degree). This is simply the “mm.mmmm” value divided by 60 and added to the “dd” sub-field. For example, in the latitude field “4717.112671”, the “dd” subfield is 47 (degrees), the “mm.mmmm” subfield is 17.112671 minutes, which when divided by 60 gives 47.28521118 degrees. This figure is suitable for the gridsquare and distance algorithms.
Now to calculate grid square. Grid square locators (the Maidenhead Locator System) are designated by combination of 2 letters (AA-RR)(a field), the squares by 2 numbers (00-99),and 2 sub-squares letters (aa-xx).). i.e. QF56OD is the location Sydney, Australia. The algorithm to calculate grid square from lat and long was easily found online. There are many implementations of this as well as other location calculators, including this one from Ian VK7IS which I used as a cross-check.
Distance to a Point of Interest (a SOTA Summit)
If we have a current lat and long, and we know the lat and long of a particular point of interest (say, a SOTA summit) we can calculate the straight-line distance. This is done in the SOTA Finder app, and has given me straight-line distance to the actual summit when walking into the activation zone. The algorithm to do this was found online.
Because the date of last activation on SOTA Finder doesn’t change very often (or at all?), I suspect the app loads up the entire SOTA summit coordinates database and stores it on the installed device. There may be a way to tell it to refresh, if so, please tell me in a comment below. For my little device, I would need a static table of points of interest, a subset of SOTA summits for VK3. Nanos have 1KBytes of EEPROM.
I declared a type for a SOTA summit with summit designator (8 bytes), lat (4), long (4), altitude (2 bytes) and summit name (16), a total of 34 bytes per summit. To make this feasible, a bigger MCU such as a Teensy, with the option for an SD card would be needed. Let’s see if we can prove the concept on a Nano with a handful of summits.
I loaded a list of summits drawn from VK3/VC into a static array, and hit memory problems at about 20 summits. I wrote the algorithm to determine the lineal distance between the current location and all of the known summits. The nearest, with distance, is displayed on the serial monitor at any time.
The 1 second pulse from a GPS receiver can be used to discipline an oscillator. Not really a priority for HF or SOTA, but apparently it’s been done by BiTX40 experimenters.
What use is this? As suggested, it could be build it into a rig. To recap, imagine a push button on the front panel that flips the display between the normal VFO frequency and associated transceive information to GPS information, including lat/long, UTC, elevation, name and lineal distance to the nearest SOTA summit, all subject to the limitations discussed. Pragmatically, there is no compelling need to do this, because all of this information is available on your smartphone apps. But it’s an interesting option, now low cost and feasible.
There are further opportunities to use GPS as the basis for supported logging. If your transceiver knows your location, SOTA summit reference, and UTC, it could log data during the period of your activation. If you could capture callsigns your rig could log for you. Perhaps use PTT or key line to trigger a voice recorder for the first 10 seconds of each transmission. Later, play it back to extract the callsigns. Or call out to an online voice recognition service to extract the callsigns for you. I leave this notion to others to explore further.