Re: Not receiving RF after a while

Lynn Deffenbaugh

Case in point:  Consider the raw packets recorded by from the APRS-IS for your local digipeater WA4USN-5:

2018-03-04 19:00:54 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 19:10:14 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 19:46:29 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 19:51:24 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 19:56:18 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 20:01:14 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0
2018-03-04 20:10:38 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 20:19:34 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0
2018-03-04 20:24:04 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 20:28:18 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 20:32:44 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 20:37:09 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0
2018-03-04 20:42:08 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 20:46:54 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 20:51:49 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 20:56:09 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0
2018-03-04 21:00:58 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 21:05:38 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 21:09:49 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 21:14:14 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0
2018-03-04 21:19:04 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 21:24:04 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 21:28:17 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 21:32:34 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0
2018-03-04 21:37:19 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 21:41:34 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 21:46:22 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 21:51:18 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0
2018-03-04 21:59:49 EST:*WA4USN-5 <>*>APRX28,qAR,KE4DHK-10 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 22:04:29 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 22:08:58 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0
2018-03-04 22:13:44 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 22:18:18 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 22:23:08 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#WA4USN 146.79- T123.0
2018-03-04 22:28:04 EST:*WA4USN-5 <>*>APRX28,qAR,W1GRE-1 <>:!3247.46N/07954.49W#PHG6460/SC2,W3 CV-10 CHARLESTON,SC 146.79- T123.0

So, does this mean that KE4DHK-10 isn't hearing every packet from WA4USN-5?  Nope.  it just means that sometimes W1GRE-1 delivers the packet to the APRS-IS network closer to's connection or faster than KE4DHK-10.

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

On 3/4/2018 10:19 PM, 'Lynn W Deffenbaugh (Mr)' [aprsisce] wrote:

Oh, and one other thing.  The APRS-IS can not be used to analyze the RF behavior of any APRS station. The APRS-IS network does duplicate suppression.  This means that only the FIRST copy of any packet is actually propagated through the network.  If your station is transmitting beacons directly to the APRS-IS and via RF, it should never actually show up as going over the air.  Unless aprsdirect uses something completely different, it cannot accurately represent RF traffic.

The log file that I sent earlier is captured from a private back-feed of ALL (not dupe-suppressed) RF packets received by APRSIS32 IGates.  This allows better, but still not completely, remote analysis of RF propagation.

That said, inspection of KE4DHK-10's raw packets at shows something very interesting.  It shows your direct (TCPIP*) APRS-IS packets, but further shows packets that were digipeated by WA4USN-5 and/or WA4USN-3 and gated by WA4USN-5.  If you look closely at these packets, you'll notice that there is something your local RF environment that is delaying packet delivery by 2-3 MINUTES.  Consider the following sets of duplicated packets:

2018-03-04 18:44:22 EST:*KE4DHK-10 <>*>APWW10,TCPIP*,qAC,
2018-03-04 18:45:27 EST:*KE4DHK-10 <>*>APWW10,WA4USN-5* <>,WIDE2*,qAR,WA4USN-5 <>
2018-03-04 19:04:22 EST:*KE4DHK-10 <>*>APWW10,TCPIP*,qAC,
2018-03-04 19:06:23 EST:*KE4DHK-10 <>*>APWW10,WA4USN-5* <>,WIDE2*,qAR,WA4USN-5 <>
2018-03-04 19:17:21 EST:*KE4DHK-10 <>*>APWW10,TCPIP*,qAC,
2018-03-04 19:18:26 EST:*KE4DHK-10 <>*>APWW10,WA4USN-5* <>,W4HRS-15* <>,WIDE2*,qAR,WA4USN-5 <>
2018-03-04 20:30:34 EST:*KE4DHK-10 <>*>APWW10,TCPIP*,qAC,
2018-03-04 20:31:26 EST:*KE4DHK-10 <>*>APWW10,WA4USN-5 <>,WIDE2-1,qAR,WA4USN-5 <>
2018-03-04 20:32:58 EST:*KE4DHK-10 <>*>APWW10,WA4USN-5* <>,W4HRS-15* <>,WIDE2*,qAR,WA4USN-5 <>
The first pair had a 65 second delay between the APRS-IS packet and the duplicate gated by WA4USN-5.  This RF packet was actually digipeated by WA4USN-5 and likely one other digipeater (the one that set WIDE2*) and then copied back by WA4USN-5.

The second pair had a 121 second delay with similar propagation showing in the used RF path.  The third pair was 65 seconds delayed.

The fourth set is even more interesting as the packet was copied and gated by WA4USN-5 with a 52 second delay and then re-copied by WA4USN-5 by way of the W4HRS-15 digipeater another 92 seconds later or 144 seconds (over 2 minutes) after the original packet was injected.

There are some serious delays going on in your RF network, likely caused by someone running a KPC-3+ in KISS mode for long durations.  This may actually be the WA4USN-5 IGate.  Please read for more information on this issue.

These delays shouldn't cause any reception problems on your own station, but they can certain completely confuse any attempts at packet analysis.  Thankfully you have the hhmmss timestamp enabled so we can uniquely identify each packet.

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

PS.  I believe the APRS-IS duplicate suppressing window is typically set at 30 seconds so duplicate packets received within this window will be summarily dropped and not propagated.  And I believe it is actually 30 seconds after the last duplicate was dropped, not 30 seconds after the first packet was received, but I'm not sure about that.

On 3/4/2018 10:01 PM, 'Lynn W Deffenbaugh (Mr)' [aprsisce] wrote:
Please send your APRSIS32*.LOG file(s) to me at I'll be glad to take a look at them.

I monitored your station's RF reception reports as well as other stations hearing your beacons and have attached that log.  It appears that you were working fine from 16:33UTC (when I started) through 17:27 after which your statio was still transmitting and being copied by 2 digis on the way to the KX4DOR-12 and KQ4G-1 APRSIS32 IGates.

Your station again starts receiving RF at 01:19UTC and continued to receive through 02:51 when I captured the log.

Question: How do you run your squelch?  Is the PK232 capable of doing tone detection and running continuously open squelch or does it need the radio to squelch to be able to hear "quiet" in order to transmit?  Is it possible that you have the squelch set such that when conditions get a certain way that signals don't open the squelch to allow the TNC to hear for decoding?

Did you restart the TNC or do you have any idea why the reception restarted at 01:19?

And the station is still receiving as I type this message.

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

On 3/4/2018 7:30 PM, [aprsisce] wrote:
Well, I let it run all day today, and it looks like its still having the same problem.  It is transmitting fine, as shows that my station was heard 3 mins ago by my nearest digi.  But the last time any station heard me (including that same digi) was around noon (pasting below, if this works):

Stations that heard KE4DHK-10 *directly* during March 2018.

Station Number of packets Latest heard Longest distance
Symbol WA4USN-5 <> 274 03/04/2018 7:18:25 PM-05:00 12.09 miles
Symbol K4CCC-9 <> 1 03/01/2018 8:05:11 PM-05:00 127.62 miles

Stations *directly* heard by KE4DHK-10 during March 2018.

Station Number of packets Latest heard Longest distance
Symbol WA4USN-5 <> 82 03/04/2018 11:59:33 AM-05:00 12.09 miles
Symbol KE4DHK-1 <> 81 03/04/2018 12:11:00 PM-05:00 1.81 miles
Symbol N702PL <> 7 03/04/2018 9:57:04 AM-05:00 3.47 miles

I looked at the log file, and my novice eye does not see anything obvious. I'd be glad to email the log file to someone if you're willing to look.  Otherwise, I'm at a loss of what else to try.


Join to automatically receive all group messages.