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

[Robert Bruninga]

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?

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...

>> 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.  The initial XXxxYYyy report
would place someone on the map with an accuracy of typical APRS +/-50m.
Then as they move around  they can update that report with just xxyy with
the MSB rolling over when they cross into the next 1km grid.  They could
send another XXxxYYyy periodically just to make sure the system has them in
the right grid.

Here might be the protocol.. (where ANI is the automatic radio DTMF ID on
release of PTT)

AXXxxYYyy+ANI for subsequent reports in the 1km grid
Bxxyy+ANI for subsequent reports (reporting increments of 100m movements)
Cx+ANI for a change in status (x)

> 0 - off duty
> 1 - Standing by
> 2 - enroute (meaning to assigned start point)
> 3 - returning (RTB after search)
> 4 - searching
> 5 - searching with special (dog team, etc)
> 6 - Resting,eating,etc
> 7 - Clue found
> 8 - Send assist
> 9 - Subject Found

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.  But that is the goal, to come up with the
top 10 routine status report digits.

The only time that an xxyy report would become ambiguous would be if the
station moved more than 5km between making an update report.  And if he did,
he could send in a XXxxYYyy report.

So could this format support those teams that use the informal "xxxyyy"
voice reporting now?

Bob, WB4aPR


Hmm, here are some ideas...
- RTB (returning to base)
- Taking a rest break
- Standing by (waiting for command)

- Instead of "something found, checking", I'd use "heard voice response".
- Instead of "evidence likely", how about "found a clue" and "found the
subject".
This differentiates the status between finding a footprint and finding the
subject.

Tom KD7LXL