[aprssig] EMERGENCY test...

[andrewemt]

It is interesting that VE7HMW-9's packet tocall (destination) callsign starts with all digits instead of letters, indicating the Mic-E status bits are all zero. So, either someone is "fixing" his tocall (maybe because it doesn't look like a valid callsign, though this is worse), or he actually is sending emergency.  His latitude does look a little south for a Canadian,  but not unreasonably so for a mobile, considering where his home fixed station is. You'd think that if those three bits got mangled then more would have been mangled to give him a totally ludicrous position instead of one relatively close to home.

Just my $.02.

Andrew, KA2DDO




Sent from my Verizon Wireless 4G LTE smartphone


-------- Original message --------
From: "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to>
Date:08/08/2014  10:51  (GMT-05:00)
To: TAPR APRS Mailing List <aprssig at tapr.org>
Cc:
Subject: Re: [aprssig] EMERGENCY test...

VE7HMW-9's emergency beacons are showing up at aprs.fi's raw packets.
However, they're flagged with issues, so they aren't processed into his
database.

I suspect that there's a digipeater or IGate in the area that has
PASSALL enabled and is gating invalid packets to the APRS-IS causing the
Mic-E bits (mbits: below) to be 000.

2014-08-07 19:36:26 EDT: *VE7HMW-9
<http://aprs.fi/?c=raw&limit=&call=VE7HMW-9>*>461QTP,VE7DID*
<http://aprs.fi/?c=raw&limit=&call=VE7DID>,WIDE3-3,qAR,UBC39
<http://aprs.fi/?c=raw&limit=&call=UBC39>:`2Txm"Q>/]"3m}2004 BUICK REGAL= *[Rate
limited (< 5 sec)]*
    type: location
    format: mice
    srccallsign: VE7HMW-9
    dstcallsign: 461QTP
    latitude: 46.19 °
    longitude: -122.9486666666667 °
    course: 253 °
    speed: 18.52 km/h
    altitude: -5 m
    symboltable: /
    symbolcode: >
    mbits: 000
    posresolution: 18.52 m
    posambiguity: 0
    comment: ]2004 BUICK REGAL=

2014-08-07 19:38:26 EDT: *VE7HMW-9
<http://aprs.fi/?c=raw&limit=&call=VE7HMW-9>*>461QTP,VE7DID*
<http://aprs.fi/?c=raw&limit=&call=VE7DID>,WIDE3-2,qAR,VA7REF-1
<http://aprs.fi/?c=raw&limit=&call=VA7REF-1>:`2Txm"Q>/]"3m}2004 BUICK REGAL=
*[Location changes too fast (adaptive limit)]*
    type: location
    format: mice
    srccallsign: VE7HMW-9
    dstcallsign: 461QTP
    latitude: 46.19 °
    longitude: -122.9486666666667 °
    course: 253 °
    speed: 18.52 km/h
    altitude: -5 m
    symboltable: /
    symbolcode: >
    mbits: 000
    posresolution: 18.52 m
    posambiguity: 0
    comment: ]2004 BUICK REGAL=

And then there's this interestingly corrupted packet:

2014-08-07 19:38:28 EDT: *VE7HMW-9
<http://aprs.fi/?c=raw&limit=&call=VE7HMW-9>*>4Y1PYW,WIDE1-1,qAR,VA7REF-1 <http://aprs.fi/?c=raw&limit=&call=VA7REF-1>:EGAL=
*[Unsupported packet format]*
    srccallsign: VE7HMW-9
    dstcallsign: 4Y1PYW

So it appears to this outside observer that there's something going on
between the RF environment and the APRS-IS.  But if you actually
received the Emergency packets on your radio (and it wasn't a
third-party packet), then it would seem to indicate a bad digipeat
rather than a bad Igate.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 8/8/2014 10:31 AM, Keith VE7GDH wrote:
> A few times over the last week or so, a few emergency beacons have
> been received from a VE7HMW-9, but the operator says he didn't have it
> set to emergency. The emergency beacon was decoded by an FTM-400D and
> also showed at findu.com, but not on aprs.fi.
>
> For a test, I will be sending several emergency beacons from VE7GDH-9
> in a few minutes with a status text of...
>
> "This is a test - NOT an emergency."
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140808/bb2e55dd/attachment.html>
-------------- next part --------------
_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig