[aprssig] New Project: WHERE-IS

Fred Hillhouse fmhillhouse at comcast.net
Thu Mar 9 08:07:11 CST 2017

Since WHO-IS and WHO-15 have the same response, why not use WHERE-IS and WHERE-15?


The WHO -15 is useable from a mobile while I don’t believe WHO -IS works. The 15 is made into a 4-bit code for TX whereas the IS will not resolve to four bits. But I haven’t tried this from my D72 so I can’t be sure. From an internet only client it doesn’t matter which one is used.


Best regards,

Fred N7FMH




From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Kenneth Finnegan
Sent: Thursday, March 09, 2017 12:32 AM
Cc: TAPR APRS Mailing List
Subject: Re: [aprssig] New Project: WHERE-IS


On Sun, Mar 5, 2017 at 2:24 PM, K4FHK <k4fhk at knobbe.us> wrote:

The callsign I would like to use is "WHERE" (and by extension, WHERE-
IS). Just like WHO-IS is being used for callsign->name look-ups, I
would like to use WHERE for this project. (It does not appear that
anyone has been using it in the last two years). Can I just roll with
it, or is there a process to claim use of this callsign?


There's no formal process for reserving global tactical calls. I'd say as long as you find no evidence of it being used by someone else (with a time allowance for servers dying and being offline for a few weeks like you did) and you put something up which beacons periodically (as simple as a 0,0 "NULL" location every hour would do) you've claimed it in my book.


The tool sounds neat. My one word of warning would be that, since the difference between APRS callsigns and AX.25 callsigns hasn't always been well defined, some RF users (particularly with radios with APRS built in) won't be able to address a message to an SSID outside 1-15. You might want to have it support a numeric SSID as another alias as well, or come to terms with having users complain that they can't reach your service.

Kenneth Finnegan


On Sun, Mar 5, 2017 at 2:24 PM, K4FHK <k4fhk at knobbe.us> wrote:


Bob was asking in a different email some time ago if anyone was working
on interesting APRS related projects. I had meant to announce this
project sooner, and his email reminded me to finally sit down and write
about it.

I would like to do two things with this email. For one, announce a new
project that will hopefully be of use to Ham radio operators. Secondly,
I would like to inquire on how to "reserve" or "register" a special
callsign for this project.

The callsign I would like to use is "WHERE" (and by extension, WHERE-
IS). Just like WHO-IS is being used for callsign->name look-ups, I
would like to use WHERE for this project. (It does not appear that
anyone has been using it in the last two years). Can I just roll with
it, or is there a process to claim use of this callsign?

This callsign would be used for the following project: 

As we all know, mobile APRS users can get a list of other stations by
listening to RF and waiting for beacons or objects with position
information. Radio or GPS equipment can then calculate and show a
distance and direction to a station of interest.

But what to do if that station of interest only beacons on APRS-IS and
not RF? Or if the station is out-of-range where even digipeated packets
do not reach the mobile user? 

This is where WHERE-IS comes in handy. A small script on my server
listens for packets with position information on APRS-IS of all
stations, except weather stations. The list of APRS types monitored is
" !=;)\@'` ", which as you can see includes objects and items as well.
Compressed position information is supported. For all these, it will
record the callsign, the GPS position and timestamp of the last
position report.

This information can then be queried with an APRS text message to the
callsign WHERE once you permit me to use that. Until then, the system
uses K4FHK-WI. The system will then respond with the relevant data such
as direction and distance.

For this to work, the callsign of interest must have transmitted an
APRS packet with position data on RF or IS. In addition, the station
inquiring needs to have transmitted a packet with position information
as well. This project uses the Vincenty formula (over the WGS-84
ellipsoid) to calculate the bearing and distance between inquiring
station and station of interest, and returns that information via APRS
message to the inquirer.

The usage is as follows: 

Send an APRS message to K4FHK-WI (or WHERE later) with one of the
following commands. Note that the callsign is case-sensitive to cover
items and objects. For mobile stations, lower case may work, but I
suggest still using proper case. For items and objects, proper case is

-- "where CALLSIGN"
or just "CALLSIGN"

For the full information, simply send the callsign of interest as the
command. The system will respond with the bearing and distance of your
station to CALLSIGN, as well as the age of its last position report or
beacon. It will respond with an APRS message, with or without
acknowledgments, depending on how your request was received. If
acknowledgments are used, it will try a maximum of 10 times with 30
second intervals to deliver the message.


Sent: W1ARN-1
Rcvd: W1ARN-1: 33.61 miles 352.73 deg N (4 min ago)

-- "direction CALLSIGN"
or "dir CALLSIGN"

The system will respond with only the direction and age of the last beacon.

Sent: dir W1ARN-1 (*2-14:41:20)
Rcvd: W1ARN-1: 352.73 deg N (1 min ago)

-- "distance CALLSIGN"
or "dis CALLSIGN"

The system will respond with only the distance and age of last beacon.

Sent: dis W1ARN-1 
Rcvd: W1ARN-1: 33.61 miles (5 min ago)

Note that you can also get the distance in different units. Supported
are miles, nautical miles, feet, yard, meters and kilometers.

Sent: dis W1ARN-1 @yards 
Recv: W1ARN-1: 59151.02 yards (3 min ago)

Supported are @miles/@mi, @nm, @yards/@y, @foot/@f, @meters/@m, and @km. Anything not understood is returned in miles as is the default. This also applies to the general "where" query, like "where W1ARN-1 @f".

-- "position CALLSIGN"
or "location CALLSIGN"
or "pos CALLSIGN"
or "loc CALLSIGN"

The system will respond with the GPS coordinates of the station and age
of last beacon.

Sent: pos W1ARN-1
Rcvd: W1ARN-1: 36.467333 -86.476167 (2 min ago)

-- "last CALLSIGN"

This command will result in the timestamp (in UTC) of the last beacon
of that station.

Sent: last W1ARN-1
Rcvd: W1ARN-1: 2017-03-05 20:45:47 UTC

-- "help"

And if you can't remember all the above, sending HELP will provide a
quick reminder of the syntax.

Sent: help (*2-14:49:52)
Rcvd: Cmds: where/loc/pos/dis/dir/last <call> (@ m/km/ft/y/mi/nm)

Using this system, you can get distance and bearing to IS-only stations
on RF. Or if you are pressed on time and don't want to wait 20 minutes
for another beacon from the station of interest, so you can quickly
query that information by messaging the Where-Is system.

But wait, there's more!

You can also set "alerts" on a station. For example, if you are out of
range of a station of interest, you can request an alert to be sent to
you once you get "within range" of that station.

-- "alert CALLSIGN @ x miles"
or "alert CALLSIGN < x mi"   (or m, km, y, ft, nm)

This will "arm" an alert on the given callsign. If either your station,
or the station of interest closes the given distance (in essence, if
the distance between the next positional beacon of either station is
smaller than the given distance), you will receive an alert via APRS


Sent: alert K4FHK-8 < 5 mi
Rcvd: Will alert you within 5 miles of K4FHK-8

Once the distance is closed, you will receive an alert:

Rcvd: Alert: K4FHK-8 is 0.01 mile 90 deg E (21:06:24 UTC)

If you closed the distance, meaning your beacon was the last one that
brings the distance closer together, you will receive the distance and
bearing, and the age of the stations last beacon like in the "where"
If the other station closed the distance with its beacon, you will
receive the timestamp of that closing beacon as shown in the example.
In case the other stations beacon was closing the distance, it is
possible that your station may have been unattended, and a hard
timestamp might be preferred over the age, since you may not have a
time reference of your last beacon.

-- "alert CALLSIGN > x miles"

You can also receive an alert when the distance between two position
packets exceed a given distance by using the "greater than" operator
instead of the "small than" operator.

Sent: alert K4FHK-8 > 1 f
Rcvd: Will alert you outside 1 foot of K4FHK-8

Once the stations "moves away", you will receive an alert:

Rcvd: Alert: K4FHK-8 is 159.8 feet 112.22 deg ESE (21:52:10 UTC)

If you have an alert set, you can modify it simply by sending another
alert command. So if you want to adjust the distance, simply send
another message with a different distance.

-- "cancel CALLSIGN"

You can also cancel an alert set on a callsign by sending the "cancel"

Sent: cancel K4FHK-8
Rcvd: Alert for K4FHK-8 canceled.

Note that alerts are automatically canceled once an alert message has
been sent to you. These are in a sense a one-time alerts. There is no
provision for continuous alerts. There is also currently no provision
to obtain a list of alerts you may have set, although that might be
added in the future if there is interest.

So what might these alerts be used for? 

- Let's say you and your Ham buddy are traveling from opposite
directions to a common meeting place that does not have a repeater, and
you want to be alerted when you are within range of each other for a
chat on a simplex frequency. Simply set an alert for the other station
and choose a distance. If both of you are within range, you'll get an
alert via APRS message.

- Let's say my wife is shopping in town and I want to prepare a
candlelight dinner, I can set an alert from my handy on the tracker in
her car for, say 5 miles, and once she is returning from town and is
getting close, I'll get my reminder via the alert on the HT. (Note that
this is a fictional scenario since I can't cook. :)

- Let's say I'm going shopping with my HT on my hip, and I want to be
alerted in case my car gets stolen. I can set an alert to notify me if
my car is farther away than I would expect.

- Perhaps the best use-case is for travelers. Let's say you are
traveling through several States, and want to tune into local repeaters
on your way. Prior to travel, you can set alerts for each repeater
(provided there is a positional object on APRS-IS or it) for a chosen
distance, and once you are on the road, you will receive APRS messages
when you get within range of these repeaters.

While you can have only one alert for a given callsign, you can create
alerts for as many callsigns as you like. Alerts also don't expire.

I think this project demonstrates there are other uses for APRS than
just tracking your position on maps. I leave you to be the judge on the
usefulness of the position alerts or ability to query other stations
positions, including IS-only stations. 

If you like to play around with this, use the callsign K4FHK-WI. I
certainly welcome any feedback you may have. Enjoy!


PS: In Middle Tennessee, we actually built upon this system. Since I'm
tracking position beacons from all stations in a database already
(there are 360,000 positions going back to Jan 1st, 2016), we
implemented a passive monitoring system for some of our repeaters.
Basically, if repeaters, or other station, do not beacon within a given
time period, we will be alerted via email, SMS and/or APRS message that
a beacon is overdue. This allows us to detect failures of equipment
(for example, power failure after a thunderstorm) when equipment is
falling silent. For example, if 3 or 4 beacon intervals do not yield a
beacon on APRS-IS, the monitoring system will alert us (via email, SMS
message and APRS message) that equipment may have failed. It has come
in handy a couple times already. We will also get a notification once a
monitored system has beaconed again and is thus considered "online"
again. Getting messages automatically sure beats keeping an eye
manually on APRS maps.

aprssig mailing list
aprssig at tapr.org


This email has been checked for viruses by Avast antivirus software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20170309/ed31c3ca/attachment.html>

More information about the aprssig mailing list