Date   

Re: Not receiving RF after a while

Lynn Deffenbaugh
 

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

2018-03-04 19:00:54 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 19:10:14 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 19:46:29 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 19:51:24 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 19:56:18 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 20:01:14 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=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 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 20:19:34 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=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 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 20:28:18 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 20:32:44 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 20:37:09 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=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 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=KE4DHK-10>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 20:46:54 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=KE4DHK-10>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 20:51:49 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 20:56:09 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=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 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 21:05:38 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=KE4DHK-10>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 21:09:49 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 21:14:14 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=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 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 21:24:04 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 21:28:17 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=KE4DHK-10>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 21:32:34 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=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 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=KE4DHK-10>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 21:41:34 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 21:46:22 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=KE4DHK-10>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 21:51:18 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=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 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,KE4DHK-10 <http://aprs.fi/?c=raw&limit=&call=KE4DHK-10>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 22:04:29 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 22:08:58 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=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 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN piGate
2018-03-04 22:18:18 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 USS Yorktown
2018-03-04 22:23:08 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=W1GRE-1>:!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org
2018-03-04 22:28:04 EST:*WA4USN-5 <https://aprs.fi/?c=raw&limit=&call=WA4USN-5>*>APRX28,qAR,W1GRE-1 <http://aprs.fi/?c=raw&limit=&call=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 aprs.fi'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)' kj4erj@arrl.net [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 aprs.fi 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 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,TCPIP*,qAC,T2KA:@234422h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 18:45:27 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5* <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,WIDE2*,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@234422h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 19:04:22 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,TCPIP*,qAC,T2KA:@000422h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 19:06:23 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5* <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,WIDE2*,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@000422h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 19:17:21 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,TCPIP*,qAC,T2FRANCE:@001721h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 19:18:26 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5* <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,W4HRS-15* <http://aprs.fi/?c=raw&limit=&call=W4HRS-15>,WIDE2*,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@001721h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 20:30:34 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,TCPIP*,qAC,T2AUSTRIA:@013033h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 20:31:26 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,WIDE2-1,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@013033h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 20:32:58 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5* <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,W4HRS-15* <http://aprs.fi/?c=raw&limit=&call=W4HRS-15>,WIDE2*,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@013033h3254.32N107945.05W#ke4dhk@arrl.net
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 http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html 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)' kj4erj@arrl.net [aprsisce] wrote:
Please send your APRSIS32*.LOG file(s) to me at KJ4ERJ@arrl.net. 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, michael.eckard@odnss.com [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 aprsdirect.com 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 <https://www.aprsdirect.com/details/main/sid/735> 274 03/04/2018 7:18:25 PM-05:00 12.09 miles
Symbol K4CCC-9 <https://www.aprsdirect.com/details/main/sid/4513> 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 <https://www.aprsdirect.com/details/main/sid/735> 82 03/04/2018 11:59:33 AM-05:00 12.09 miles
Symbol KE4DHK-1 <https://www.aprsdirect.com/details/main/sid/1135013> 81 03/04/2018 12:11:00 PM-05:00 1.81 miles
Symbol N702PL <https://www.aprsdirect.com/details/main/sid/57719> 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.

Michael
KE4DHK



Re: Not receiving RF after a while [1 Attachment]

Lynn Deffenbaugh
 

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 aprs.fi 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 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,TCPIP*,qAC,T2KA:@234422h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 18:45:27 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5* <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,WIDE2*,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@234422h3254.32N107945.05W#ke4dhk@arrl.net

2018-03-04 19:04:22 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,TCPIP*,qAC,T2KA:@000422h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 19:06:23 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5* <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,WIDE2*,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@000422h3254.32N107945.05W#ke4dhk@arrl.net

2018-03-04 19:17:21 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,TCPIP*,qAC,T2FRANCE:@001721h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 19:18:26 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5* <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,W4HRS-15* <http://aprs.fi/?c=raw&limit=&call=W4HRS-15>,WIDE2*,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@001721h3254.32N107945.05W#ke4dhk@arrl.net

2018-03-04 20:30:34 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,TCPIP*,qAC,T2AUSTRIA:@013033h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 20:31:26 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,WIDE2-1,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@013033h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-04 20:32:58 EST:*KE4DHK-10 <https://aprs.fi/?c=raw&limit=&call=KE4DHK-10>*>APWW10,WA4USN-5* <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>,W4HRS-15* <http://aprs.fi/?c=raw&limit=&call=W4HRS-15>,WIDE2*,qAR,WA4USN-5 <http://aprs.fi/?c=raw&limit=&call=WA4USN-5>:@013033h3254.32N107945.05W#ke4dhk@arrl.net

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 http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html 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)' kj4erj@arrl.net [aprsisce] wrote:
[Attachment(s) <#TopText> from Lynn W Deffenbaugh (Mr) included below]

Please send your APRSIS32*.LOG file(s) to me at KJ4ERJ@arrl.net. 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, michael.eckard@odnss.com [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 aprsdirect.com 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 <https://www.aprsdirect.com/details/main/sid/735> 274 03/04/2018 7:18:25 PM-05:00 12.09 miles
Symbol K4CCC-9 <https://www.aprsdirect.com/details/main/sid/4513> 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 <https://www.aprsdirect.com/details/main/sid/735> 82 03/04/2018 11:59:33 AM-05:00 12.09 miles
Symbol KE4DHK-1 <https://www.aprsdirect.com/details/main/sid/1135013> 81 03/04/2018 12:11:00 PM-05:00 1.81 miles
Symbol N702PL <https://www.aprsdirect.com/details/main/sid/57719> 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.

Michael
KE4DHK



Re: Not receiving RF after a while

Lynn Deffenbaugh
 

Please send your APRSIS32*.LOG file(s) to me at KJ4ERJ@....  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, michael.eckard@... [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 aprsdirect.com 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.

Michael
KE4DHK

 



Re: Not receiving RF after a while

Michael Eckard
 

Well, I let it run all day today, and it looks like its still having the same problem.  It is transmitting fine, as aprsdirect.com 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.

Michael
KE4DHK

 


Re: Not receiving RF after a while

Lynn Deffenbaugh
 

Good 'nuff.  Never sure if folks know the difference between KISS and humanly-readable packets until we ask.

Even with the TNC in KISS mode, you should be able to see the received packets in a terminal emulator.  Not the headers, but you'll know packets are being decoded and transmitted.  So the suggestion of shutting down APRSIS32 and just letting a terminal emulator run for a few hours receiving is valid.

But do your other tests first and see if you can get it to stay alive as it should.

I run my KJ4ERJ-1 IGate 24x7 for years without a hiccup and it runs on a small netbook and uses a Bluetooth to Serial port converter connected to an OT2m wired to an iCom HT.  Never drops out and rarely even gets a second glance from me.

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



On 3/3/2018 9:55 PM, michael.eckard@... [aprsisce] wrote:
Sorry, Lynn...that packet was after I took it out of kiss mode.  Should have made that clear.  It was in kiss mode before.



Re: Not receiving RF after a while

Michael Eckard
 

Sorry, Lynn...that packet was after I took it out of kiss mode.  Should have made that clear.  It was in kiss mode before.


Re: Not receiving RF after a while

Lynn Deffenbaugh
 

If that's what you see in Putty, your TNC is not in KISS mode.  That's all humanly readable which is some sort of terminal or command mode.  In KISS mode, you will not be able to read the headers of packets, but only the payload.  And there likely won't be any line breaks either.

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



On 3/3/2018 8:33 PM, michael.eckard@... [aprsisce] wrote:
Also, after exiting APRSIS32, I did got back into Putty and the TNC does appear to be receiving packets, such as:

WA4USN-5*>APRX28 :
!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org



Re: Not receiving RF after a while

Michael Eckard
 

Update:  So I've been doing some more reading online and I might have found the problem, or perhaps part of the problem.  After doing some adjustments, I'm receiving RF right now.  (But I have before too so I'll let it run for some time and see if it stops receiving RF, or if it carries on now.)

Here is what I did.  Maybe someone more knowledgeable on this stuff can tell me if this might be the fix, or if what I did has nothing to do with anything.  :)

I realized the PK-232 manual says the box by default looks for 7 bit and even parity.  I lost track, after so many adjustments and trying different things, of whether I had the ports setup the same.  So I decided to give the PK-232 a "rest" command, then I exited the terminal.  I set the COM5 port settings to 9600 baud, 8 bit, no parity, and no flow control.  Then, I set Putty to the same specs and opened another terminal, and then did an auto-baud routine using the "*" command.  

After the PK-232 came up, I set the following commands:

8bitconv on
awlen 8
mon 6
KI $01

I then exited Putty, brought up APRSIS32, and confirmed the port settings for the PK-232 were 8 bit, no parity, etc.

So far, RF coming through.  (I have internet disabled just to see cleanly.)  My uneducated theory is, if this does fix the issue, then maybe I've wrongly convinced myself that the problem was not with the PK-232 settings and that it was "working" with tx before but not recognizing the AX25 packets because the port settings were a bit out of sync and it wasn't handling the last bit properly or something?  (And I would have to also then assume that the similar problem I have been having with Mobilinkd is related to a power saving setting on the Bluetooth port, I suppose.)

I'll enable internet for normal operation and give a SITREP after a few hours, but I wanted to share the above for the good of the order, either (a) so someone can say the above isn't the issue, or (b) if it does happen to fix the problem, the next sucker who tries this can maybe save a few days of headache!

Michael
KE4DHK


Re: Not receiving RF after a while

Michael Eckard
 

Also, after exiting APRSIS32, I did got back into Putty and the TNC does appear to be receiving packets, such as:

WA4USN-5*>APRX28 <UI>:
!3247.46N/07954.49W#WA4USN 146.79- T123.0 www.wa4usn.org


Re: Not receiving RF after a while

Michael Eckard
 

I let it run for a few hours this evening, and consistent with the problem I've been having, it shows now RF packets received.  (I do see it keying the radio when beaconing, though.)   I pulled the logs, and here are a few of the lines that I thought might be pertinent.

Activity:WinMain:2018-03-03T22:10:06.437 RFPort[1] PK232MBX(Simply(KISS)) 1200 via COM5:9600,N,8,1

Port(PK232MBX):WinMain:2018-03-03T22:10:06.437 Starting Port(PK232MBX)
Port(PK232MBX):Port(PK232MBX):2018-03-03T22:10:06.437 CpReader Running on COM5:9600,N,8,1 (1 OpenCmds, 1 CloseCmds)
Port(PK232MBX):Port(PK232MBX):2018-03-03T22:10:06.437 Opening COM5:9600,N,8,1
Port(PK232MBX):Port(PK232MBX):2018-03-03T22:10:06.437 Opening COM5 with 4 Args

Port(PK232MBX):Port(PK232MBX):2018-03-03T22:50:59.375 Sent[75]:<C0 00 82 A0 AE AE>b`<E0 96 8A>h<88 90 96>t<AE 82>h<AA A6 9C>j<AE 92 88 8A>d@c<03 F0>@225059h3254.32N107945.05W#ke4dhk@...<C0>






Re: Not receiving RF after a while

Michael Eckard
 

Ok, station is back up and I've enabled those logs you suggested.  As soon as I hooked back up and opened APRSIS32, I noticed its not catching the RF receives.  I'll let it run a bit and see what those logs say.


Re: Lynn's Availability

Rob Giuliano
 

We'll be thinking of you and your family.
Best of luck to all involved.
 
Robert Giuliano
KB8RCO



From: "'Lynn W Deffenbaugh (Mr)' kj4erj@... [aprsisce]"
To: APRSISCE Group ; APRSISMO
Sent: Saturday, March 3, 2018 11:36 AM
Subject: [aprsisce] Lynn's Availability

 
I'm out of pocket for a while as my first ever granddaughter was born
this past Sunday (almost a week old!) with a cleft palate and we're
hanging around the Nicklaus Children's Hospital in Miami supporting our
daughter and son-in-law where we can.  She's doing well and not in any
imminent danger, but it's a long road ahead of them.  We speak from
experience because our daughter (baby's Mom) was also born with a cleft
palate.

If you want to see a truly boring track, check out the following 4 day
track of my APRSISMO instance:

https://aprs.fi/#!mt=roadmap&z=11&call=a%2FKJ4ERJ-12&timerange=345600&tail=345600

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




Re: Not receiving RF after a while

Rob Giuliano
 

If the computer sends data to the USB port, it will "wake it up" to send it.  It should stay awake until it times out again, so I would have expected periods of data after each transmit.

I'd be thinking about Lynn's comments on RF getting into the system.  How close are the cables to your coax, rf port of the radio, and/or antenna.

Although moreso with HTs where the antenna and everything is right there, RF causes more headaches, especially USB devices.  Do you have chokes on the USB wires?  You can find cables with them fairly easily.
 
Robert Giuliano
KB8RCO



From: "michael.eckard@... [aprsisce]" To: aprsisce@...
Sent: Saturday, March 3, 2018 11:37 AM
Subject: RE: [aprsisce] Re: Not receiving RF after a while

 
Thanks, Ken.  I was not aware of those settings, but I have gone in device manager and turned that feature off with respect to each of the "hub" listings, as you suggested.  Hopefully that helps, but since APRSIS32 was still getting regular beacons, etc. out on the PK-232 after the RF received stations stopped showing up on the scroller, I'm not optimistic that will fix my problem.  In other words, if the power management is shutting off power to the USB port after a period of time or that was otherwise kicking the TNC out of kiss mode or something, wouldn't that equally affect the ability to transmit?  

But I'm eager to try in the hope that it could be a fix.  I'm working on mounting this station in a 4u rack case, so I have the TNC disconnected this morning, but I'll have it back connected and running this evening, which in turn means I should know if that fixed the issue in the morning and will update the post accordingly.

Thanks again.
Michael



Re: Not receiving RF after a while

Lynn Deffenbaugh
 

I see that your station is KE4DHK-10 from your Wiki post.  Unfortunately, I've been rebuilding my OpenStreetMaps tile server after an SSD failure so I had my APRSIS32 RF monitor down.  I just fired it up (well, firing it up, my server is memory-overloaded with the planet import) so I should be able to tell you who is seeing you and what you are seeing once it is all back up and running.

Let us know when you have the TNC reconnected and running so I know when would be productive to check for traffic from KE4DHK-10.

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



On 3/3/2018 11:44 AM, 'Lynn W Deffenbaugh (Mr)' kj4erj@... [aprsisce] wrote:
Are you sure that transmit was still working after the reception quits?  Have you heard the packets on another radio on the frequency or seen the transmit light illuminate on the radio or observe the packet(s) decoded on another APRS station?

Sometimes we think a station is transmitting when in fact the packets being observed are coming via the APRS-IS.

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



On 3/3/2018 11:37 AM, michael.eckard@... [aprsisce] wrote:
Thanks, Ken.  I was not aware of those settings, but I have gone in device manager and turned that feature off with respect to each of the "hub" listings, as you suggested.  Hopefully that helps, but since APRSIS32 was still getting regular beacons, etc. out on the PK-232 after the RF received stations stopped showing up on the scroller, I'm not optimistic that will fix my problem.  In other words, if the power management is shutting off power to the USB port after a period of time or that was otherwise kicking the TNC out of kiss mode or something, wouldn't that equally affect the ability to transmit?  

But I'm eager to try in the hope that it could be a fix.  I'm working on mounting this station in a 4u rack case, so I have the TNC disconnected this morning, but I'll have it back connected and running this evening, which in turn means I should know if that fixed the issue in the morning and will update the post accordingly.

Thanks again.
Michael




Re: Not receiving RF after a while

Michael Eckard
 

Thanks, Lynn.  I'll check those logs as you both suggest. 


In terms of transmitting, I believe it is.  I'll pay closer attention to the issue tomorrow morning if it is not receiving RF again and will confirm by powering up and checking my mobile rig.  But in the meantime, here is what I see on aprsdirect.com.   They are showing that the last station directly heard by mine was our local club digi (WA4USN-5) at 6:29am.   (That is the only fixed station in my area that I'm in reliable range of.)  Conversely, my station (KE4DHK-10) was last heard by the same club digi at 9:21am this morning, which is probably about when I powered the PK-232 down this morning to work on the rack mount box. 


Re: Lynn's Availability

Lynn Deffenbaugh
 

Thank you!  They say they do the repair surgery here between 12 and 18 months which is longer than our daughter which was at 10 months.  Between now and then, the biggest issue is the time required for feeding which they're getting a good handle on now.

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



On 3/3/2018 11:39 AM, michael.eckard@... [aprsisce] wrote:
Thoughts and prayers going out to your grand for a speedy and complete recovery and rehab!



Re: Not receiving RF after a while

Lynn Deffenbaugh
 

Are you sure that transmit was still working after the reception quits?  Have you heard the packets on another radio on the frequency or seen the transmit light illuminate on the radio or observe the packet(s) decoded on another APRS station?

Sometimes we think a station is transmitting when in fact the packets being observed are coming via the APRS-IS.

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



On 3/3/2018 11:37 AM, michael.eckard@... [aprsisce] wrote:
Thanks, Ken.  I was not aware of those settings, but I have gone in device manager and turned that feature off with respect to each of the "hub" listings, as you suggested.  Hopefully that helps, but since APRSIS32 was still getting regular beacons, etc. out on the PK-232 after the RF received stations stopped showing up on the scroller, I'm not optimistic that will fix my problem.  In other words, if the power management is shutting off power to the USB port after a period of time or that was otherwise kicking the TNC out of kiss mode or something, wouldn't that equally affect the ability to transmit?  

But I'm eager to try in the hope that it could be a fix.  I'm working on mounting this station in a 4u rack case, so I have the TNC disconnected this morning, but I'll have it back connected and running this evening, which in turn means I should know if that fixed the issue in the morning and will update the post accordingly.

Thanks again.
Michael



Re: Not receiving RF after a while

Lynn Deffenbaugh
 

Those settings all look good and definitely Simply(KISS) is the way to go for TNCs that can be locked into KISS mode.

If you check Enables / Logging / Port() and Enables / Logging / File Enabled then your RF port will start generating debug information and that information will be placed into the current APRSIS32.LOG file.  These log files rotate every time you restart APRSIS32 and the most recent 10 are kept, so the interesting log information may be in one of the more recent numbered files when you get it.

As Robert pointed out, if the Port() has anything about "missing " that means that data is still coming from the TNC but it isn't KISS data.  Some TNCs fall out of KISS when you power cycle them (especially Kenwood APRS radios prior to the D74) and some just go deaf after a period of operation (the EJ-41U embedded in an Alinco DR-135 has this issue, but the T2/T3-135s are rock solid).

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



On 3/3/2018 11:32 AM, michael.eckard@... [aprsisce] wrote:
Thanks for the response Robert.  On the PK232, I currently have it setup as Simply(KISS), though I once all the kinks are worked out I would like to set it up as KISS with appropriate start/stop commands.   The Mobilinkd was Simply(KISS), too.

The port settings on the PK232 are as follows:

Quiet time: 0
RFBaud is 1200
RF to IS is checked
IS to RF is checked
Enabled is checked
Xmit Enabled is checked
Beacon is checked

Under device, I have it on the correct com port, set for 9600 baud (which is what I have the PK-232 set for).  No parity, one stop bit.  I initially set it up with 7 data bits (which worked fine), then I set 8bit conversion to "on" on the PK-232 based on some of the recommendations on the web, and made the corresponding change in APRSIS32 to 8 data bits, and that worked just fine as well.   Same issue with stopping RF receive after a period of time either way.

Thanks for your thoughts on this.  I'm also happy to set and paste any logs that would be helpful in diagnosing the problem.

I know this isn't a commercial tech support line, so thank you to you and everyone responding to help me troubleshoot this.  I appreciate it.



Re: Lynn's Availability

Michael Eckard
 

Thoughts and prayers going out to your grand for a speedy and complete recovery and rehab!


Re: Not receiving RF after a while

Michael Eckard
 

Thanks, Ken.  I was not aware of those settings, but I have gone in device manager and turned that feature off with respect to each of the "hub" listings, as you suggested.  Hopefully that helps, but since APRSIS32 was still getting regular beacons, etc. out on the PK-232 after the RF received stations stopped showing up on the scroller, I'm not optimistic that will fix my problem.  In other words, if the power management is shutting off power to the USB port after a period of time or that was otherwise kicking the TNC out of kiss mode or something, wouldn't that equally affect the ability to transmit?  

But I'm eager to try in the hope that it could be a fix.  I'm working on mounting this station in a 4u rack case, so I have the TNC disconnected this morning, but I'll have it back connected and running this evening, which in turn means I should know if that fixed the issue in the morning and will update the post accordingly.

Thanks again.
Michael

3621 - 3640 of 35881