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

[Tom Hayward]

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