[aprssig] Group tracking

[Lynn W. Deffenbaugh (Mr)]

Did you really mean to recommend WIDE2-1,WIDE2-2 for a mobile path?  Or 
was that supposed to be WIDE1-1,WIDE2-2 with proportional pathing enabled?

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 4/30/2012 6:47 PM, Bob Bruninga wrote:
>
> Simple answer!
>
> Proportional pathing for the caravan with WIDE2-1,WIDE2-2 path.  
> Everyone hears everyone else at a one minute rate for up-to-date live 
> situational awareness but most of your packets are direct and do not 
> bother anyone in the area.  Half of your packets may make it to a 
> local digi, but only 1/4^th will bother the surrounding area.  Same 
> goes for hiking.
>
> Bob, WB4APR
>
> *From:*aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] *On 
> Behalf Of *John Goerzen
> *Sent:* Monday, April 30, 2012 5:41 PM
> *To:* TAPR APRS Mailing List
> *Subject:* [aprssig] Group tracking
>
> Hi folks,
>
> I'd like to get some recommendations on beacon configuration for group 
> tracking scenarios.   The main scenarios I have in mind are:
>
>  1. 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).
>  2. 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.
>
> One could also add other similar scenarios, such as coordinating 
> search and rescue parties, tracking SKYWARN volunteers, etc.
>
> There are a few special things about these scenarios:
>
>  1. 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.
>  2. 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)
>
> 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.
>
> 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.
>
> 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.
>
> What are suggestions to both meet the objectives and be friendly to 
> other RF users?
>
> Thanks,
>
> John
> KR0L
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120430/bef4daf7/attachment.html>