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