Hmm... like maybe someone has too short of a TxDelay setting, such that his oscillators are still slewing when he (or a digi) is transmitting?
From: "Lynn W. Deffenbaugh (Mr)" <ldeffenb-***@public.gmane.org>
Subject: Re: [aprssig] EMERGENCY test...
for Emergency.
out of aprs.fi, I decided that it was a wasted effort.
chain resulting in some garbling of the early bits of the transmission.
Only ears on the air in his vicinity will truly answer our curiosities.
Post by andrewemtIt 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 --------
Date:08/08/2014 10:51 (GMT-05:00)
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=
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
Post by Keith VE7GDHA 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."
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig