<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi folks,<br>
<br>
I'd like to get some recommendations on beacon configuration for
group tracking scenarios. The main scenarios I have in mind are:<br>
<ol>
<li>A caravan of 2 or 3 vehicles traveling to a common
destination. The trip could be 30 minutes or 15 hours, could
involve a mix of highway speeds (75 MPH) and city speeds (20 MPH
or less). The point of APRS tracking would be to give at least
one vehicle the means to find the other if needed, due to
getting separated in traffic, taking different exits, loss of
cellphone communication, etc. The vehicles will usually, but
conceivably not always, be within simplex range of each other
(owing to lack of external antennas and high speeds in some
cases).<br>
</li>
<li>Hikers in 2 groups in a large park/wilderness area. A similar
goal as before - give at least one group the means to find the
other assuming nothing but APRS beacons as communication. Here
I would assume that the hikers will be within simplex range
(say, a mile or two) of each other at 5W.</li>
</ol>
One could also add other similar scenarios, such as coordinating
search and rescue parties, tracking SKYWARN volunteers, etc.<br>
<br>
There are a few special things about these scenarios:<br>
<ol>
<li>We may not usually care about getting frequent position
updates. During the minutes / hours in which one party is not
trying to locate the other, we don't care too much about getting
frequent updates.</li>
<li>When one group is trying to locate the other, default position
update timings will likely be way too long. For instance, 5
minutes or even 2 minutes at 70MPH is a lot of miles and a lot
of potential exits that may or may not have been taken. A lot
of SmartBeaconing scenarios have 30 minutes between beacons at
20MPH, which is unreasonable for tracking someone in city
traffic. (And, according to my reading, could actually be even
longer at speeds between the low and high speed, oddly enough)</li>
</ol>
One could conceivably use a TinyTrak AIO or similar device for the
group being tracked, though in my particular case it will likely be
a locked VX-8GR. Neither the TinyTrak nor the 8GR responds to APRS
position query packets (?APRSP), so that is out. The TH-D72A does,
but it is also larger and for various reasons is also the stronger
tracker device.<br>
<br>
For the hiking scenario, we could conceivably use a 440 frequency
since it is unlikely that a digipeater would be of any help at all.
This puts less of an importance on restricting transmit rates. A
lot of testing suggests that battery drain on APRS HTs is usually
due to engaging the RX side, not the TX side, so I would not have
battery concerns on a simple 1-minute interval.<br>
<br>
For the car travel, we would probably want to use WIDE1-1 (are there
any digis that would answer to WIDE2-1 but not WIDE1-1?) to get a
little help from nearby digis, due to the likelihood of greater
separation and more challenges to RF signals getting out. It seems
a bit annoying to have a 1-minute beacon going from a restaurant
parking lot for an hour on 144.390, but perhaps it is not as bad as
I am making it out to be. It seems that if I set the low speed on
SmartBeaconing to, say, 5MPH to prevent this, and set the high rate
to 2 minutes and the low rate to 5 minutes, it would lead to some
very long intervals at, say 10MPH (70/10*2 is 14 minutes). An odd
little gap in the SmartBeaconing design, that.<br>
<br>
What are suggestions to both meet the objectives and be friendly to
other RF users?<br>
<br>
Thanks,<br>
<br>
John<br>
KR0L<br>
</body>
</html>