Date   

Re: UTM Coordinates

YT9TP - Pedja
 

On 21.03.2018 01:36, netnutmike@yahoo.com [aprsisce] wrote:
   If it can, can someone point me in the right direction.  And if it cannot, has anyone used a tool that can work with APRS and provide UTM coordinates?

Check SarTrack.

I used it for APRS iGate so I was not so interested in maps. I think it can use UTM coordinates.

http://www.sartrack.co.nz/Software.html

--
Pedja YT9TP


UTM Coordinates

James Myers
 

Hi everyone,


   I have been using aprsisce for a while now.  Our club recently started getting involved with a new K9 SAR group.  We are going to start providing communications support for them.  We had our first exercise this past weekend and they record coordinates in UTM not in lat/lon.  They also use a tool called SARTopo for the maps and it used UTM.  I did manage to be download maps for offline usage but cannot figure out if aprsisce has the ability to report in UTM.


   If it can, can someone point me in the right direction.  And if it cannot, has anyone used a tool that can work with APRS and provide UTM coordinates?


   Thanks, have a great week.


Mike

K3DO


Re: iPhone

Thomas Testa
 

Ok Lynn thanks for the fast response.
                             Tom , N2 UFM


On Mar 7, 2018, at 6:08 PM, 'Lynn W Deffenbaugh (Mr)' kj4erj@... [aprsisce] <aprsisce@...> wrote:

 

Apple doesn't support the Bluetooth SPP (Serial Port Profile) feature
from iOS which is required to communicate with the current MobilinkD
TNC.  Therefore there cannot be any software that will provide such
access from Apple iPhones.

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

On 3/7/2018 5:42 PM, tmtlu3@... [aprsisce] wrote:
> Is there a APRSISCE app that will allow me to link my IPhone to a MobilLinked TNC?
>
> TNX, Tom N2UFM
>
> ------------------------------------
> Posted by: tmtlu3@...
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>


Re: iPhone

Lynn Deffenbaugh
 

Apple doesn't support the Bluetooth SPP (Serial Port Profile) feature from iOS which is required to communicate with the current MobilinkD TNC.  Therefore there cannot be any software that will provide such access from Apple iPhones.

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

On 3/7/2018 5:42 PM, tmtlu3@yahoo.com [aprsisce] wrote:
Is there a APRSISCE app that will allow me to link my IPhone to a MobilLinked TNC?

TNX, Tom N2UFM

------------------------------------
Posted by: tmtlu3@yahoo.com
------------------------------------


------------------------------------

Yahoo Groups Links




iPhone

Thomas Testa
 

Is there a APRSISCE app that will allow me to link my IPhone to a MobilLinked TNC?

TNX, Tom N2UFM


Re: Mobile Tracker & Mobile I-Gate in Tandem

Rob Giuliano
 

I don't remember if you originally cross posted or not, but ...

If you post specific questions on the TT4 and how it works in the TT4 Yahoo group, Byon (Byonics) or Allen (vhsproducts) provide great feedback.
 
Robert Giuliano
KB8RCO



From: Rob Giuliano
To: "aprsisce@..." Sent: Wednesday, March 7, 2018 1:36 PM
Subject: Re: [aprsisce] Mobile Tracker & Mobile I-Gate in Tandem

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

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.

3321 - 3340 of 35595