Date   

Re: Mobile Tracker & Mobile I-Gate in Tandem

Rob Giuliano
 

That number corresponds to the KISS protocol stream.

This is similar to a dual radio port communicating with KISS where one stream is one radio port and the other radio port on another stream. 

If I recall, stream 0 is the standard communication stream in the TT4.  So, if set to zero and used, it would interfere with the KISS RF data.  The TT4 then uses this setting as an "ignore this".  When set to any other value (1,2,...) it will send the data on that stream and the attached device (computer) can handle the data as an additional data stream.
 
Robert Giuliano
KB8RCO



From: "kb5ako@... [aprsisce]"
To: aprsisce@...
Sent: Wednesday, March 7, 2018 12:50 PM
Subject: Re: [aprsisce] Mobile Tracker & Mobile I-Gate in Tandem

 
All I had to do was to set GKRelay to 8. It was a zero. Thank you very much. What is the significance of the numerical designator for GKRelay?

Victor, KB5AKO



Re: Mobile Tracker & Mobile I-Gate in Tandem

Victor Watkins, KB5AKO
 

All I had to do was to set GKRelay to 8. It was a zero. Thank you very much. What is the significance of the numerical designator for GKRelay?

Victor, KB5AKO


Re: Mobile Tracker & Mobile I-Gate in Tandem

Rob Giuliano
 

Assuming your TT4 has a GPS connected, you need to pass the GPS data through the TT4 the computer port, then tell APRSISce/32 (APRSIS32) to look for the GPS data.

Assuming the A-port is connected to the APRSIS32 computer and the TT4 is in KISS mode to communicate with APRSIS32, the TT4 settings needed:
  AMODE KISS
  ABAUD 19200
  GKRelay 8        (any value > 0 will work)
 
Now in APRSIS32, you need to open the Port you are connected to.
From Menu >Configure >Ports >TT4 (or the name you used)
  Now check the box next to "GPS/NMEA" to tell the app GPS data is there.
Next Enable using that GPS:
  Menu > Enables >GPS Enabled
 
You should see list of satellites across the bottom and the box at the top left with GPS information.

Robert Giuliano
KB8RCO



From: "Victor Watkins kb5ako@... [aprsisce]"
To: aprsisce@...
Sent: Tuesday, March 6, 2018 7:22 PM
Subject: [aprsisce] Mobile Tracker & Mobile I-Gate in Tandem

 
I have a mobile tracker and a mobile I-gate hooked up to a laptop in my vehicle using aprsis32 and a TT4. How do I set the mobile igate location to automatically follow where my tracker is? Currently, I have to set it to a fixed location. But, I want the I-gate location to follow my vehicle tracker location. How do I do this?

Victor, KB5AKO




Re: Mobile Tracker & Mobile I-Gate in Tandem

Adam Mahnke
 

Where is the GPS hooked up? 

You either need to use APRSIS32 to run everything through the tt4 with the GPS hooked up to the laptop

Or

Have beaconing turned off on APRSIS32 and have the GPS pass through from the tt4 to the software.

There should be some documentation on the wiki about how to do that

I've done what you're trying with a D710 successfully for quite some time.

Adam
Kc2ant



From: aprsisce@... on behalf of Victor Watkins kb5ako@... [aprsisce]
Sent: Tuesday, March 6, 2018 6:12:08 PM
To: aprsisce@...
Subject: [aprsisce] Mobile Tracker & Mobile I-Gate in Tandem
 
 

I have a mobile tracker and a mobile I-gate hooked up to a laptop in my vehicle using aprsis32 and a TT4. How do I set the mobile igate location to automatically follow where my tracker is? Currently, I have to set it to a fixed location. But, I want the I-gate location to follow my vehicle tracker location. How do I do this?

Victor, KB5AKO


Mobile Tracker & Mobile I-Gate in Tandem

Victor Watkins, KB5AKO
 

I have a mobile tracker and a mobile I-gate hooked up to a laptop in my vehicle using aprsis32 and a TT4. How do I set the mobile igate location to automatically follow where my tracker is? Currently, I have to set it to a fixed location. But, I want the I-gate location to follow my vehicle tracker location. How do I do this?


Victor, KB5AKO


Mobile Tracker & Mobile I-Gate in Tandem

Victor Watkins, KB5AKO
 

I have a mobile tracker and a mobile I-gate hooked up to a laptop in my vehicle using aprsis32 and a TT4.

How do I set the mobile igate location to automatically follow where my tracker is?

Currently, I have to set it to a fixed location. But, I want the I-gate location to follow my vehicle tracker location.



Victor, KB5AKO


Ham Radio Shack clearance sale.....Rigs for sale.

Daniel White
 

Hi

I am clearing a SK shack on behalf of the XYL.

Here are the equipment remaining after some hamfests....

Icom 7700,ICOM IC 7800
ANAN-100D SDR
Yaesu FTDX 5000
Flex 6500,Flex 6300
Kenwood TS-2000LE, Kenwood TS 990
Ten-Tec Omni VII model 588AT
Ten-Tec Orion II
Alpha 9500
ACOM 2000A, Icom PW1
Ameritron AL-1500,Ameritron AL-82
Commander 2500

More pictures and details over email....  ki7iyd@...

Prices are good enough and willing to ship or meet up in my QTH


KI7IYD
Daniel L White
73



Re: Not receiving RF after a while

Lynn Deffenbaugh
 

And consider the following RF-received packets by APRSIS32 stations:

2018-03-05T03:30:34.776 [1]KE4DHK-10>APWW10,TCPIP*,qAC,T2AUSTRIA:@033034h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-05T03:31:11.971 APRS-IS [1]KE4DHK-10>APWW10,WA4USN-5,WIDE2-1,qAR,WA4USN-5:@033034h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-05T03:31:12.184 RF Feed [2]KE4DHK-10>APWW10,WA4USN-5*,WIDE2-1,qAR,KE4DHK-10:@033034h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-05T03:31:12.987 RF Feed [3]KE4DHK-10>APWW10,WA4USN-5*,WA4USN-3*,qAR,KQ4G-1:@033034h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-05T03:31:13.032 RF Feed [4]KE4DHK-10>APWW10,WA4USN-5*,WA4USN-3*,qAR,KX4DOR-12:@033034h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-05T03:31:13.041 RF Feed [5]KE4DHK-10>APWW10,WA4USN-5*,W4GSR-3*,WIDE2*,qAR,N4HUV-10:@033034h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-05T03:31:14.358 RF Feed [6]KE4DHK-10>APWW10,WA4USN-5*,WIDE2*,qAR,KQ4G-1:@033034h3254.32N107945.05W#ke4dhk@arrl.net
2018-03-05T03:31:47.264 APRS-IS [0]KE4DHK-10>APWW10,WA4USN-5,WA4USN-3*,qAR,WA4USN-5:@033034h3254.32N107945.05W#ke4dhk@arrl.net

So, your original packet was injected directly to the APRS-IS at 03:30:34.776 and at approximately the same time transmitted via RF with a WIDE2-2 path.

At 03:31:11.971 WA4USN-5 gated a copy of that packet which had been digipeated by itself decrementing the WIDE2-2 to WIDE2-1. Where was that packet for the intervening 37 seconds?  I suspect WA4USN-5 is the source of the delays because all subsequent RF receptions of the packet were via that (apparently delayed) digipeat.

03:31:12.184 KE4DHK-10 received the digipeated packet apparently direct from WA4USN-5 (0.21 seconds)

03:31:12.987 KQ4G-1 received a re-digipeated copy from WA4USN-3 who replaced the WIDE2* with it's own station ID (1.01 seconds for the additional digipeat)
03:31:13.032 KX4DOR-12 received that same copy of the packet (0.05 seconds additional propagation)

03:31:13.041 N4HUV-10 received a redigipeated copy from W4GSR-3 who did a better callsign insertion and retained the WIDE2* (1.07 seconds for the additional digipeat)
03:31:14.358 KQ4G-1 received a re-digipeated copy from a digipeater that didn't do callsign insertion, but retransmitted WIDE2* (2.387 seconds for the unknown digipeat)

03:31:47.264 WA4USN-5 copied the WA4USN-3 digipeated copy after another 35 second delay, again pointing the delay to WA4USN-5

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

On 3/4/2018 10:32 PM, 'Lynn W Deffenbaugh (Mr)' kj4erj@arrl.net [aprsisce] wrote:


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

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



3361 - 3380 of 35629