[aprssig] UTM grid (was: APRStt for SAR using...) Yes!

Thu May 16 18:48:29 EDT 2013

Before this spins off to Fox News, remember the topic is simply that
ALL SAR groups in the USA use UTM grids and usually for routine
position reporting of their location in the field, they use a 3x3
digit report.  This is a report to the nearest tenth of a km or about
100 meters.

Since APRStt is perfect as-is for reporting NUMBERS with DTMF, this
topic is only about how simply APRStt can be configured to allow SAR
teams (without APRS) to report in  using precedures they are already
expert at using and then having those positions automatically appear
on the same APRS tactical map as every one else.

And all SAR folks are required by training to know how to read a UTM
grid map which they are *required* to use.

And it is entirely local.  You want to use it, just do it.  You dont
want to use it, then good luck trying to get every single team
outfited with a working APRS tracker...

Bob, WBAPR

On Thu, May 16, 2013 at 10:54 AM, Tom Russo <russo at bogodyn.org> wrote:
> On Thu, May 16, 2013 at 03:03:10PM +0100, we recorded a bogon-computron collision of the <steve at daniels270.eclipse.co.uk> flavor, containing:
>> I collected a lot of information a year or so ago, and if I recall you need
>> the reference point and ellipsoid scale for each area.
>
> Given a geodetic datum (and WGS84 is sorta the standard for APRS already),
> the ellipsiod is defined for all UTM zones in the same way.
>
> The globe is divided into 60 six-degree zones (numbered 1-60), starting from
> 180W-174W as zone 1, increasing to the east.  The central meridian of each
> zone is the reference point for each zone, and is assigned a "false easting"
> of 500000m.  Once you've determined which 6-degree zone contains your longitude,
> conversion from lat/lon to UTM in that zone is straightforward based
> on the difference between that longitude and the zone's central meridian,
> though the formulas are pretty hairy.
>
> UTM coordinates within a zone are always positive, and decrease going west
> from 500000m at the central meridan, and increase to the east.  Since the
> zones are so large, it would be unnecessary for zone information to be
> included in the strictly local APRStt input --- for any given pair of
> northing and easting in the vicinity of the search, there can be only one zone
> to which they would refer (even if the search straddles a zone boundary, there
> would be no ambiguity --- low valued eastings would be in the higher numbered
> zone, high valued eastings in the lower).  One would simply need to code the
> local APRStt system (which would presumably be temporary infrastructure anyway)
> to do the math.
>
> The problem with this scheme of Bob's is that for it to work, field resources
> still need a GPS to get either their UTM coordinates or their Lat/Lon
> (depending on how one decides to set up APRStt).  Then they need to
> type in those coordinates into a DTMF pad, just so they can be on APRS,
> presumably so that those responsible for having full incident situational
> awareness get the information.  And if they're not using a GPS, but rather
> using crude map-based methods to pick off coordinates, there is not much value
> to having them type in high-precision UTM coordinates either.
>
> As one of the New Mexico State Police incident commanders for search
> and rescue, I would see almost no benefit to asking teams to follow this
> procedure over simply radioing their positions by voice on request, and having
> our comms specialists at base enter the data into APRS in the comfort of the
> incident communications center so it can be shared around the incident
> management team easily.  We *already* have them call in that information,
> and where we use APRS we do so to *simplify* information transfer and
> decrease radio chatter, not add complexity to team assignments.
>
> APRS in an automated portable tracker has a benefit both to incident management
> (who get to see the data without pulling it constantly) and to the deployed
> resource (who get to have that data pushed without having their work
> assignments constantly interrupted to pull out a GPS and read it off over the
> air).  APRStt sounds like the worst of both worlds --- we still have to task
> field resources to do manual data entry, still need to handle correcting
> broken manual data (usually by calling back and getting clarification) AND it
> is using a technique that is more time consuming and at least as error prone
> as relaying coordinates by voice to a human sitting in front of a better data
> entry system.
>
> This sounds like a solution desperately in search of a problem.  I would rather
> see time and energy spent working to get better, lighter, and more reliable
> two-way, automatic APRS devices into searcher's hands.  Two-way devices
> tied to mapping GPS units allow not only searchers to report their current
> locations to the IMT, but for positional data to be transmitted back to them
> from the IMT (via objects) to aid them in the completion of their assignments
> without adding extra procedures for them to follow.
>
>> -----Original Message-----
>> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
>> Of Lynn W. Deffenbaugh (Mr)
>> Sent: 16 May 2013 13:39
>> To: TAPR APRS Mailing List
>> Subject: [aprssig] UTM grid (was: APRStt for SAR using...)
>>
>> On 5/16/2013 7:45 AM, Robert Bruninga wrote:
>> > Now all I gotta do is refresh myself on the UTM grid to LATLONG
>> conversion.
>>
>> Copy me on what you learn because the last time I looked there isn't
>> jsut one UTM grid, but several localized versions that use different
>> reference points and conversion equations.
>
> --
> Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
> Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
>  echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig