[aprssig] APRStt and SAR... Revised proposal (a)

[Amir Findling]

Instead of DMTF and position formats, why not just teach users how to
manually beacon their position?

Having been dabbling with Yaesu's System Fusion, using digital mode,
position is automatically sent with every voice transmission. I have not
played enough to know if the location format is compatible with SAR (in
NYS, using UTM/NAD83 or WGS84, not the more modern flavors).

Now a friend of mine has connected his Yaesu FT-1DR to his Samsung phone,
using the OEM cable and a USB to microUSB converter. On the phone, he runs
the W2APRS app (not in the Play Store, Google it) and can see any station's
APRS beacon received on a map or even aerial. Maps are downloadable, so it
is even working when off grid. Makes things so much easier, but I have not
yet been able to replicate what he did. May also be done with a Kenwood
D72, I believe

So there are many newer avenues for using APRS in SAR that are coming on
the horizon.
-- 

73 de Amir K9CHP

Liverpool Amateur Repeater Club www.W2CM.org
Radio Amateurs of Greater Syracuse  www.ragsclub.org
Wilderness SAR www.wsar.org
Eagle Valley Search Dogs www.evdogs.org
On May 18, 2015 1:57 PM, "Tom Hayward via aprssig" <aprssig at tapr.org> wrote:

> On Mon, May 18, 2015 at 9:48 AM, Robert Bruninga via aprssig
> <aprssig at tapr.org> wrote:
> > My understanding is that some SAR teams verbally report their position
> with
> > an xxxyyy report which is the middle 3 digits of a nominal 5 digit grid.
> > They drop the LSB and MSB since they are generally known to be in a 1 kM
> > area.  But to place them unambiguously in a 10 km area, they would need
> an
> > XxxxYyyy report...  Did I get this right?  And the accuracy of a
> truncated
> > xxxyyy report is to the nearest 100m grid?
>
> Let's make sure we're on the same page here. Here's the spec for the
> system I was describing:
> https://www.fgdc.gov/usng/USNGInfoSheetsCv5_4pages.pdf
>
> What was once just a commonly used shorthand is now codified in the
> USNG spec (and MGRS is identical within the scope of my use of the
> system).
>
> > So, here is the Revised Proposal (a):
> >
> >>> Sar teams... without APRS radios can simply report their XxxxYyyy grid
> >>> location by DTMF followed by their radio's ANI report placing them on
> the
> >>> APRS map automatically.
> >
> >> A big assumption you're making is that DTMF is ubiquitous for SAR teams.
> >> In my region, most of the radios that are used on searches do not have
> >> DTMF ability; they are the non-keypad version. Some (like me) do have a
> >> keypad and DTMF on at least one of their radios, but I wouldn't say this
> >> is standard.
> >
> > Well, I don't think anyone has a solution for automatically using them
> for
> > position/status reporting.  But SAR teams that did want to use automatic
> > position reporting can buy new radios (Baofang) for $40 and gain this
> > capability.  Or not...
>
> I was more concerned about adoption. I can deploy one of these APRStt
> to APRS translators, but I don't see it being used by more than just
> myself. Having a technology and getting any value back from it are
> unfortunately different things. You're trying to bridge this gap with
> DTMF. It's a good idea, but in the context of my team it's easier to
> just hand out dedicated trackers than convince someone to buy a new
> DTMF radio and teach them how to encode positions with it.
>
> >>> 2) Question.  After an initial report of XXxxYYyy to place the station
> on
> >>> the map, would subsequent xxyy reports be adequate to then update
> >>> positions and automatically assume the initial most significant bytes X
> >>> and Y and then keep track and only roll them over when a 9 transitions
> to
> >>> a 0 or vice versa?
> >
> >>I would avoid using YYXX, because XXYY has an existing meaning. The
> >>abbreviations truncate digits from the UTM coordinate as they lose
> >>precision, rather dropping the most significant digits....  I would
> >>preserve this standard over the air, so it is more natural for a searcher
> >>to report by punching in DTMF digits. The savings of airtime is
> negligible.
> >
> > XXXXXYYYYY - 1m square
> > XXXXYYYY - 10m square
> > XXXYYY - 100m square
> > XXYY - 1km square
> >
> > Its not so much air time as it is key punching.
>
> You're relying on a human to be the encoder of this protocol, so using
> a protocol the human already knows (and uses regularly with voice) is
> going to be the most accurate and efficient. Training them to drop a
> different set of digits when using DTMF than when using voice to
> report coordinates will be difficult. I assumed you were valuing air
> time more than training difficulty. If it just comes down to key
> punching, I think the searcher will still be more comfortable punching
> keys for the coordinate abbreviation system they already know, even if
> it's two digits longer.
>
> > I'm not so sure that we need subject found, since this automatic
> reporting
> > is for routine updates and it would be assumed that when the subject is
> > actually found that the reporting becomes NON-routine and urgent and
> Voice
> > and other means would be used.
>
> I added "subject found" because I see value in having a position with
> that status automatically transferred to a navigation device. The use
> case would go something like this:
> 1. First team finds subject, sends position with status "subject found".
> 2. APRStt receiver translates message to APRS and transmits.
> 3. Nearby team with APRS transceiver attached to mapping device
> receives position.
> 4. First team asks for some assistance via voice.
> 5. Second team looks up subject find position on mapping device and
> navigates to that location.
>
> > So could this format support those teams that use the informal "xxxyyy"
> > voice reporting now?
>
> As mentioned, it's not so informal.
>
> Tom KD7LXL
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20150518/029f911d/attachment.html>