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

[Robert Bruninga]

Thanks for the reference!  Now I know what we are talking about.  You're
probably right.  Just use XXXYYY always and then it matches training and
there is no ambiguity until one goes what 100km away?  And that is beyond
the range of most APRStt receivers.  Problem I guess is when the operations
are near a 100km grid corner....?

Bob

-----Original Message-----
From: Tom Hayward [mailto:esarfl at gmail.com]
Sent: Monday, May 18, 2015 1:25 PM
To: Robert Bruninga; TAPR APRS Mailing List
Subject: Re: [aprssig] APRStt and SAR... Revised proposal (a)

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