Loading ...
Sorry, an error occurred while loading the content.

Re: [aprsisce] APRSIS storing delayed duplicates?

Expand Messages
  • James Ewen
    The easy answer is that you re running APRS in your vehicle. That s why we know where you ve been. But your subject suggests delayed packets. That s a problem
    Message 1 of 16 , Dec 25, 2012
    • 0 Attachment
      The easy answer is that you're running APRS in your vehicle. That's
      why we know where you've been.

      But your subject suggests delayed packets. That's a problem with
      Kantrtonics TNCs running in KISS mode that has been beaten to death.
      Do a Google search on KPC KISS delayed packets.

      APRSIS does not store packets. There's no storage mechanism in the
      APRSIS network. The problem is in the hardware being used.



      On 12/25/12, Warren Brandt <warren_brandt@...> wrote:
      >
      > Please look at my track home and tell me what is causing this:
      >
      > http://aprs.fi/#!call=a%2FKC0U-8&timerange=3600&tail=3600
      >
      > Thanks,
      > Warren - KC0U
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >

      --
      Sent from my mobile device

      James
      VE6SRV
    • Warren Brandt
      That s interesting, considering that I live in Kansas. Thanks for looking!
      Message 2 of 16 , Dec 27, 2012
      • 0 Attachment
        That's interesting, considering that I live in Kansas.

        Thanks for looking!

        --- In aprsisce@yahoogroups.com, NICK LERRO <w3nrl@...> wrote:
        >
        >
        > I've been following your track and see no issues
        > i see you left KofP up 476 north to exit near rt 209 in Lehigton, pa on to
        > what seem like a large circle or some what of circle went north then south direction maybe the signal was suppressed as your driving, at points it seemed you were driving around in all direction but prior to that all did look good
        >
        >
        > Best of 73 de
        > W3nrl / Wqez375
        > 10-10 # 75801
        > Nick
        >
        >
        > To: aprsisce@yahoogroups.com
        > From: warren_brandt@...
        > Date: Wed, 26 Dec 2012 01:35:03 +0000
        > Subject: [aprsisce] APRSIS storing delayed duplicates?
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > Please look at my track home and tell me what is causing this:
        >
        >
        >
        > http://aprs.fi/#!call=a%2FKC0U-8&timerange=3600&tail=3600
        >
        >
        >
        > Thanks,
        >
        > Warren - KC0U
        >
      • Warren Brandt
        Yes, I know that I am using APRS in my vehicle. I guess I should be more specific with my question. My track jumps back and forth on my route home. The raw
        Message 3 of 16 , Dec 27, 2012
        • 0 Attachment

          Yes, I know that I am using APRS in my vehicle. 

           

          I guess I should be more specific with my question.  My track jumps back and forth on my route home.  The raw data has many “duplicate position packets” that are time-stamped out of order, causing my track to display abnormally.  I have been using this setup for several years, and this has never happened before.

           

          None of the digipeaters used in my trip home are using a KPC-3+, so I don’t think that is the problem.

           

          Perhaps I am using the wrong terminology, as the website aprs.fi is obviously using stored information to reproduce my track.  Is aprs.fi not part of the APRSIS network?

           

           

           

          From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
          Sent: Tuesday, December 25, 2012 11:09 PM
          To: aprsisce@yahoogroups.com
          Subject: Re: [aprsisce] APRSIS storing delayed duplicates?

           

           

          The easy answer is that you're running APRS in your vehicle. That's
          why we know where you've been.

          But your subject suggests delayed packets. That's a problem with
          Kantrtonics TNCs running in KISS mode that has been beaten to death.
          Do a Google search on KPC KISS delayed packets.

          APRSIS does not store packets. There's no storage mechanism in the
          APRSIS network. The problem is in the hardware being used.

          On 12/25/12, Warren Brandt <warren_brandt@...> wrote:
          >
          > Please look at my track home and tell me what is causing this:
          >
          > http://aprs.fi/#!call=a%2FKC0U-8&timerange=3600&tail=3600
          >
          > Thanks,
          > Warren - KC0U
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >

          --
          Sent from my mobile device

          James
          VE6SRV

        • Fred Hillhouse
          Could be that some has PASSALL on. That would pass a mangled packet. However that is not likely the case here. The evidence points to a bunch of delayed
          Message 4 of 16 , Dec 27, 2012
          • 0 Attachment
            Could be that some has PASSALL on. That would pass a mangled packet. However that is not likely the case here.  The evidence points to a bunch of delayed packets. How do you know there are no KPC3+s in use? It looks like WX0U-1 is a Kantronics.
             
            APRS.FI acquires data from APRS-IS. It is a "display port".
             
            Best regards,
            Fred, N7FMH
             
             


            From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Warren Brandt
            Sent: Thursday, December 27, 2012 11:31
            To: aprsisce@yahoogroups.com
            Subject: RE: [aprsisce] APRSIS storing delayed duplicates?

             

            Yes, I know that I am using APRS in my vehicle. 

            I guess I should be more specific with my question.  My track jumps back and forth on my route home.  The raw data has many “duplicate position packets” that are time-stamped out of order, causing my track to display abnormally.  I have been using this setup for several years, and this has never happened before.

            None of the digipeaters used in my trip home are using a KPC-3+, so I don’t think that is the problem.

            Perhaps I am using the wrong terminology, as the website aprs.fi is obviously using stored information to reproduce my track.  Is aprs.fi not part of the APRSIS network?

            From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
            Sent: Tuesday, December 25, 2012 11:09 PM
            To: aprsisce@yahoogroups.com
            Subject: Re: [aprsisce] APRSIS storing delayed duplicates?

             

            The easy answer is that you're running APRS in your vehicle. That's
            why we know where you've been.

            But your subject suggests delayed packets. That's a problem with
            Kantrtonics TNCs running in KISS mode that has been beaten to death.
            Do a Google search on KPC KISS delayed packets.

            APRSIS does not store packets. There's no storage mechanism in the
            APRSIS network. The problem is in the hardware being used.

            On 12/25/12, Warren Brandt <warren_brandt@...> wrote:
            >
            > Please look at my track home and tell me what is causing this:
            >
            > http://aprs.fi/#!call=a%2FKC0U-8&timerange=3600&tail=3600
            >
            > Thanks,
            > Warren - KC0U
            >
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >

            --
            Sent from my mobile device

            James
            VE6SRV

          • Fred Hillhouse
            Snippet from APRS.FI RAW logs: 2012-12-25 13:48:00 UTC: KC0U-8 APOTC1,WIDE1-1,qAR,KC0U-1:!/;5gR64b dTG 2012-12-25 13:48:00 UTC:
            Message 5 of 16 , Dec 27, 2012
            • 0 Attachment

              Snippet from APRS.FI RAW logs:

              2012-12-25 13:48:00 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5gR64b<>dTG
              2012-12-25 13:48:00 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,WX0U-2:!/;5^`66*N>_MG [Rate limited (< 5 sec)]
              2012-12-25 13:48:15 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5i[66'/>_OG
              2012-12-25 13:49:07 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5gF64J.>[BG
              <-Duped below
              2012-12-25 13:50:37 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5ge65Bx>dRG
              2012-12-25 13:51:13 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;6I$64IT>cCG
              2012-12-25 13:53:07 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;6HA64$'>kAG
              <-Duped below
              2012-12-25 13:55:04 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5fa64$#>mAG
              <-Duped below
              2012-12-25 13:56:10 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5eO63nS>$AG
              <-Duped below
              2012-12-25 13:56:48 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5Yn63og>vEG

              2012-12-25 13:57:42 UTC: KC0U-8>APOTC1,MATFLD,WIDE1*,qAR,WX0U-2:!/;5gF64J.>[BG [Duplicate position packet]
              2012-12-25 14:00:42 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;6HA64$'>kAG
              [Duplicate position packet]
              2012-12-25 14:02:22 UTC: KC0U-8>APOTC1,MATFLD,WIDE1*,qAR,WX0U-2:!/;5fa64$#>mAG
              [Duplicate position packet]
              2012-12-25 14:02:41 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5eO63nS>$AG
              [Duplicate position packet]

              Two digipeaters in question are, WX0U-1 and MATFLD. WX0U-1 is using a KPC3+ V8.2 and MATFLD is unknown. However for MATFLD, it is likely the user is using a PC with a KPC3+ TNC in KISS mode. The TOCALL for MATFLD is unknown by APRS.FI.

              Unless someone can show me differently ...

              Best regards,

              Fred, N7FMH

               

               

              ________________________________

                      From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Fred Hillhouse
                      Sent: Thursday, December 27, 2012 13:07
                      To: aprsisce@yahoogroups.com
                      Subject: RE: [aprsisce] APRSIS storing delayed duplicates?
                     
                     
                       

                              Could be that some has PASSALL on. That would pass a mangled packet. However that is not likely the case here.  The evidence points to a bunch of delayed packets. How do you know there are no KPC3+s in use? It looks like WX0U-1 is a Kantronics.
                      
                      APRS.FI acquires data from APRS-IS. It is a "display port".
                      
                      Best regards,
                      Fred, N7FMH
                      
                      


              ________________________________

                              From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Warren Brandt
                              Sent: Thursday, December 27, 2012 11:31
                              To: aprsisce@yahoogroups.com
                              Subject: RE: [aprsisce] APRSIS storing delayed duplicates?
                             
                             
                               

                                              Yes, I know that I am using APRS in my vehicle. 

                                              I guess I should be more specific with my question.  My track jumps back and forth on my route home.  The raw data has many “duplicate position packets” that are time-stamped out of order, causing my track to display abnormally.  I have been using this setup for several years, and this has never happened before.

                                              None of the digipeaters used in my trip home are using a KPC-3+, so I don’t think that is the problem.

                                              Perhaps I am using the wrong terminology, as the website aprs.fi is obviously using stored information to reproduce my track.  Is aprs.fi not part of the APRSIS network?

                                                                              From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of James Ewen
                              Sent: Tuesday, December 25, 2012 11:09 PM
                              To: aprsisce@yahoogroups.com
                              Subject: Re: [aprsisce] APRSIS storing delayed duplicates?

                                               

                              The easy answer is that you're running APRS in your vehicle. That's
                              why we know where you've been.
                             
                              But your subject suggests delayed packets. That's a problem with
                              Kantrtonics TNCs running in KISS mode that has been beaten to death.
                              Do a Google search on KPC KISS delayed packets.
                             
                              APRSIS does not store packets. There's no storage mechanism in the
                              APRSIS network. The problem is in the hardware being used.
                             
                              On 12/25/12, Warren Brandt <warren_brandt@... <mailto:warren_brandt%40yahoo.com>

              > wrote:
                             
              >
                              > Please look at my track home and tell me what is causing this:
                             
              >
                              > http://aprs.fi/# <http://aprs.fi/> !call=a%2FKC0U-8&timerange=3600&tail=3600
                             
              >
                              > Thanks,
                              > Warren - KC0U
                             
              >
                             
              >
                             
              >
                              > ------------------------------------
                             
              >
                              > Yahoo! Groups Links
                             
              >
                             
              >
                             
              >
                             
              >
                             
                              --
                              Sent from my mobile device
                             
                              James
                              VE6SRV

                                                             

            • James Ewen
              On Thu, Dec 27, 2012 at 9:31 AM, Warren Brandt ... Aha, so you do know the root cause then... I was of course being funny with that
              Message 6 of 16 , Dec 27, 2012
              • 0 Attachment
                On Thu, Dec 27, 2012 at 9:31 AM, Warren Brandt <warren_brandt@...> wrote:

                > Yes, I know that I am using APRS in my vehicle.

                Aha, so you do know the root cause then... I was of course being funny with that comment. You asked a very generic question, so a very generic answer seemed appropriate.

                > I guess I should be more specific with my question.

                That always works best. If you have specific question in mind, asking that question gets us to the root of the issue. I did take the generic question and drill down to the actual problem, but it doesn't sound like you did the research on the KCP delayed packets issue, otherwise you would not be asking these following questions. So, once again we embark upon an exploration into the inner workings of the APRS world. No worries, I do this for fun. Some people get upset with the "nerdy/techy" details, but perhaps others will read and learn as we go along. Yes, this will be fairly long, grueling, and dry, but this is what it takes to understand WHY things happen the way they do.

                >  My track jumps back
                > and forth on my route home.  The raw data has many “duplicate position
                > packets” that are time-stamped out of order, causing my track to display
                > abnormally.

                Can you provide the specific packets that are timestamped out of order? Looking at the raw packets for KC0U-8 (the callsign in the link previously given), there are no packets with embedded timestamps in the last 1000 packets recorded.

                http://aprs.fi/?c=raw&call=KC0U-8&limit=1000&view=normal

                These packets have timestamps which indicate when the aprs.fi server saw them, but they do not have embedded timestamps which would indicate when they were created. If you enable timestamps on your tracker, you will be able to observe the delayed packet issue much easier. Temporarily enabling timestamps for diagnostic purposes is very helpful for those who are not familiar with picking issues like this apart. It really shows the issue very clearly.

                > I have been using this setup for several years, and this has
                > never happened before.

                It very probably has, but you may have never noticed it before. The problem is so prevalent that Hessu at aprs.fi has implemented filters that specifically work to try and mask out the delayed data so people quite pestering him asking why his site makes their track zig-zag all over the place. It's not an issue with aprs.fi, nor with the APRS-IS, but rather a problem with the transport hardware that delivers packets to the APRS-IS.

                > None of the digipeaters used in my trip home are using a KPC-3+, so I
                > don’t think that is the problem.

                Really? Can you be sure?

                 WX0U-1>APN382

                That's the most common digipeater that is handling your packet, and it is reporting that it is a KPC-3 v8.2. (It is also wasting airtime sending out a malformed echolink object. If you know the operator, let him know it needs to be fixed)

                MATFLD>APSUN

                Here's another digipeater handling your packets. It is possibly running APRS+SA, with no indication of what type of TNC is attached.

                However, the issue is not normally with the digipeaters, but rather at the i-gate side of things.

                 KC0U-1>APWW10
                 KC0U-1>APTT4

                This i-gate is running APRSISCE/32 with a TT4, both of which are making noise, which is why we see packets from each. Many of the packets are being gated by others, which might indicate more delayed packet propagation. This station is fixed, so you'll never see it zig-zagging around showing the delayed packets. It isn't sending timestamps, so we can't use its data for analysis.

                 AUBURN>APNW01

                This looks like a WX3in1. This station is sending packets with timestamps, which allows us to look to see where there's a problem in your area...

                 WX0U-2>APRX26

                This station is running APRX with an unknown TNC. This station could probably stop advertising the HAMDINNER that happened back on Dec 15.

                So, we've covered the stations that have handled your packets, and we know for sure that at least one of them is reporting that it is using a Kantronic TNC.  There are two stations that we do not know what they are running for TNCs, and the other 2 look to be running a TT4, and a WX3in1 unit.

                Let's go back and look at the packets from AUBURN which have the nice timestamps in them.

                I'm going to use just a small sample of the packets for this analysis. AUBURN uses a DDHHMM timestamp so we don't get resolution down to the second, but the delays are gross enough that we don't need that level of granularity to see the issue.

                http://aprs.fi/?c=raw&limit=&call=AUBURN

                2012-12-27 16:55:25 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@271655z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 16:58:56 UTC: AUBURN>APNW01,PBHWHS*,WIDE2-1,qAR,KC0BS:@271655z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 16:59:51 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@271650z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:00:25 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@271700z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:02:33 UTC: AUBURN>APNW01,KC0NGU-8*,qAR,KC0BS:@271700z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:03:40 UTC: AUBURN>APNW01,WIDE2-2,qAR,WX0U-2:@271655z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:05:26 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@271705z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:07:50 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@271700z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:08:34 UTC: AUBURN>APNW01,LAW,PBHWHS,WIDE2*,qAR,KC0BS:@271705z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:10:26 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@271710z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:13:12 UTC: AUBURN>APNW01,KC0NGU-8*,qAR,KC0BS:@271710z3858.61NS09548.54W#W2 KSn-N aprs@...
                2012-12-27 17:14:23 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@271705z3858.61NS09548.54W#W2 KSn-N aprs@...

                For clarity, let's get rid of all the unchanging information.

                I have highlighted the packets sent directly from AUBURN to the CORE-2 APRS-IS server. Note the embedded creation timestamp at the end of the lines below matches the APRS-IS received timestamp at the front. Now look at timestamps on the packets handled by KC0BS and WX0U-2. I've done the math and included the time delay for you on each line.

                16:55:25 TCPIP*,qAC,CORE-2:@271655z
                16:58:56 PBHWHS*,WIDE2-1,qAR,KC0BS:@271655z  (Delayed by ~3 minutes)
                16:59:51 MATFLD*,WIDE2-1,qAR,WX0U-2:@271650z   (Delayed by ~9 minutes)
                17:00:25 TCPIP*,qAC,CORE-2:@271700z
                17:02:33 KC0NGU-8*,qAR,KC0BS:@271700z    (Delayed by ~2 minutes)
                17:03:40 WIDE2-2,qAR,WX0U-2:@271655z    (Delayed by ~8 minutes)
                17:05:26 TCPIP*,qAC,CORE-2:@271705z
                17:07:50 MATFLD*,WIDE2-1,qAR,WX0U-2:@271700z   (Delayed by ~7 minutes)
                17:08:34 LAW,PBHWHS,WIDE2*,qAR,KC0BS:@271705z   (Delayed by ~3 minutes)
                17:10:26 TCPIP*,qAC,CORE-2:@271710z
                17:13:12 KC0NGU-8*,qAR,KC0BS:@271710z        (Delayed by ~3 minutes)
                17:14:23 MATFLD*,WIDE2-1,qAR,WX0U-2:@271705z    (Delayed by ~9 minutes)


                Analysis of your raw packets is much harder because you do not have timestamps embedded, but you can go through the raw packets and see that every packet handled by WX0U-2 is being delayed. Other good packets which aren't delayed are getting flagged however due to the interleaving with delayed packets. If a 9 minute old packet finally gets delivered to the APRS-IS, and then  good packet is delivered 2 seconds later, aprs.fi will flag the good packet as being "Too fast" and tags it  [Rate limited (< 5 sec)]. There's nothing wrong with the packet, it just was delivered too soon after a delayed packet. Other good packets can be tagged with [Location changes too fast (>500 km/h)] if delivered closely after a delayed packet, and the distance/time calculations show that the station was moving at a very high rate of speed.

                > Perhaps I am using the wrong terminology, as the website aprs.fi is
                > obviously using stored information to reproduce my track.  Is aprs.fi not
                > part of the APRSIS network?

                Yes, aprs.fi does create a very large database of historical APRS information. It uses that information to be able to provide you with the information that you are asking for. aprs.fi however is NOT part of the APRS-IS network. aprs.fi is a bunch of servers that are connected to the APRS-IS network, and they capture and archive the data heard via the APRS-IS stream. The APRS-IS is comprised of 5 main servers, and a much larger number of smaller tier-2 servers which all simply share the available data in real time. There is no archiving of information on the APRS-IS. aprsD, did have the ability to provide a historical dump, if you connected to port 14579, you would get a quick dump of some buffered data, which would allow you to "catch up" on what happened recently, and then continue with real time data. This is a user connection port, and would never be shared with another peer or upstream server.

                The APRS-IS is like listening to the local repeater. If you turn on your radio, and listen, all you will hear is the real time audio (information). You won't be able to find out what happened yesterday or last week. If someone were recording all the audio, and had a server where you could play back the audio, then that would be similar to what aprs.fi does. The delayed packet issue could be thought of as someone listening to the repeater input, and recording the audio, and then playing it back minutes later. Think of how that would screw up the conversations taking place. Going to the archive server and listening to the screwed up audio later is what you are doing when going to aprs.fi today. You can't fault the server playing back screwed up audio... it only provides that which it is provided to it. 

                As I have already stated, the issue is so prevalent that Hessu at aprs.fi has implemented filters that try to block the delayed packets. The issue is so complex that it is nearly impossible to filter out only the delayed packets, and as such we lose some good packets, and we still let some bad ones through. You are seeing the few bad ones sneaking through.

                The problem with Hessu attempting to filter bad packets is that it masks the true issue. It's kind of like going to the doctor when you are feeling a bit weak. The doctor gives you iron pills because you are a little anemic, and your red blood cell count is down. He sends you on your way, but but you still keep falling over when standing... the true issue behind all the symptoms being that your right leg has been taken by a tiger in the night. (Sorry, a little Monty Python slipped in there!)

                Band-aid solutions simply work to cover up the issue. The proper solution is to correct the issue in the KPC-3 hardware. A kludge work around is to power cycle the offending hardware about once a week. These TNCs accumulate delays, and a weekly cleanse clears the delays that are accumulating.

                Contact WX0U and KC0BS and let them know of the problem. If they are reasonable individuals, they will listen take action. More probably however, you will get a response such as "My station is working perfectly, look at my packets! It's not my packets, it's yours, you have the problem." and "You don't know what you are talking about, shut up and go away... leave me alone!". If you can show clear evidence like the AUBURN packets with embedded timestamps, with data from multiple stations showing the delays, you may be able to convince the offending stations that it is indeed their stations causing the problem. You will need a very clear understanding of the issue, and be prepared to back up your claims. Again, I suggest you go read the information about the KPC-3 delayed packets that is available on the web, and have that as well as the raw data available to prove your claims.

                Good luck! 

                --
                James
                VE6SRV

                PS. If you were paying attention, you would notice that WX0U is a common source of issues in your local area:

                WX0U-1 is sending a malformed echolink object.
                WX0U-2 is sending an object which should have expired on Dec 16.
                WX0U-2 is delaying packets by about 8 minutes.

                WX0U is trying to play APRS but is not all that good with the details, which make or break the APRS network...
              • Warren Brandt
                aprs.fi says WX0U-1 is a KPC-3 v8.2, it doesn t say that it s a plus. It s been in service for years without issue. Anyway, thanks for looking at it for me.
                Message 7 of 16 , Dec 27, 2012
                • 0 Attachment
                  aprs.fi says WX0U-1 is a KPC-3 v8.2, it doesn't say that it's a plus. It's been in service for years without issue.

                  Anyway, thanks for looking at it for me.


                  --- In aprsisce@yahoogroups.com, "Fred Hillhouse" <fmhillhouse@...> wrote:
                  >
                  > Snippet from APRS.FI RAW logs:
                  >
                  > 2012-12-25 13:48:00 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5gR64b<>dTG
                  > 2012-12-25 13:48:00 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,WX0U-2:!/;5^`66*N>_MG
                  > [Rate limited (< 5 sec)]
                  > 2012-12-25 13:48:15 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5i[66'/>_OG
                  > 2012-12-25 13:49:07 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5gF64J.>[BG
                  > <-Duped below
                  > 2012-12-25 13:50:37 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5ge65Bx>dRG
                  > 2012-12-25 13:51:13 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;6I$64IT>cCG
                  > 2012-12-25 13:53:07 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;6HA64$'>kAG
                  > <-Duped below
                  > 2012-12-25 13:55:04 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5fa64$#>mAG
                  > <-Duped below
                  > 2012-12-25 13:56:10 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5eO63nS>$AG
                  > <-Duped below
                  > 2012-12-25 13:56:48 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5Yn63og>vEG
                  >
                  > 2012-12-25 13:57:42 UTC:
                  > KC0U-8>APOTC1,MATFLD,WIDE1*,qAR,WX0U-2:!/;5gF64J.>[BG [Duplicate position
                  > packet]
                  > 2012-12-25 14:00:42 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;6HA64$'>kAG
                  > [Duplicate position packet]
                  > 2012-12-25 14:02:22 UTC:
                  > KC0U-8>APOTC1,MATFLD,WIDE1*,qAR,WX0U-2:!/;5fa64$#>mAG [Duplicate position
                  > packet]
                  > 2012-12-25 14:02:41 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5eO63nS>$AG
                  > [Duplicate position packet]
                  >
                  >
                  > Two digipeaters in question are, WX0U-1 and MATFLD. WX0U-1 is using a KPC3+
                  > V8.2 and MATFLD is unknown. However for MATFLD, it is likely the user is
                  > using a PC with a KPC3+ TNC in KISS mode. The TOCALL for MATFLD is unknown
                  > by APRS.FI.
                  >
                  > Unless someone can show me differently ...
                  >
                  > Best regards,
                  >
                  > Fred, N7FMH
                • Fred Hillhouse
                  http://www.aprs.org/tocalls.txt Compare the TOCALL below with what is on the link above and tell me if you can tell if it is plus or not. WX0U-1
                  Message 8 of 16 , Dec 27, 2012
                  • 0 Attachment
                     
                    Compare the TOCALL below with what is on the link above and tell me if you can tell if it is plus or not.
                     
                     WX0U-1>APN382 <-- The TOCALL is the APN382
                     
                    I did snip the section of interest.
                     APN          Network nodes, digis, etc
                          APN3xx  Kantronics KPC-3 rom versions
                          APN9xx  Kantronics KPC-9612 Roms
                          APNAxx  WB6ZSU's APRServe
                          APNDxx  DIGI_NED
                          APNMxx  MJF TNC roms
                          APNPxx  Paccom TNC roms
                          APNTxx  SV2AGW's TNT tnc as a digi
                          APNUxx  UIdigi
                          APNXxx  TNC-X  (K6DBG)
                          APNK01  Kenwood D700 (APK101) type
                          APNK80  KAM version 8.0
                          APNKMP  KAM+
                     
                    I think your questions have been answered but perhaps not with the answer you wished for.
                     
                     
                    Best regards,
                    Fred, N7FMH
                     
                     
                     

                    From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Warren Brandt
                    Sent: Thursday, December 27, 2012 14:44
                    To: aprsisce@yahoogroups.com
                    Subject: [aprsisce] Re: APRSIS storing delayed duplicates?

                     


                    aprs.fi says WX0U-1 is a KPC-3 v8.2, it doesn't say that it's a plus. It's been in service for years without issue.

                    Anyway, thanks for looking at it for me.

                    --- In aprsisce@yahoogroups.com, "Fred Hillhouse" <fmhillhouse@...> wrote:
                    >
                    > Snippet from APRS.FI RAW logs:
                    >
                    > 2012-12-25 13:48:00 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5gR64b<>dTG
                    > 2012-12-25 13:48:00 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,WX0U-2:!/;5^`66*N>_MG
                    > [Rate limited (< 5 sec)]
                    > 2012-12-25 13:48:15 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5i[66'/>_OG
                    > 2012-12-25 13:49:07 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5gF64J.>[BG
                    > <-Duped below
                    > 2012-12-25 13:50:37 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5ge65Bx>dRG
                    > 2012-12-25 13:51:13 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;6I$64IT>cCG
                    > 2012-12-25 13:53:07 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;6HA64$'>kAG
                    > <-Duped below
                    > 2012-12-25 13:55:04 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5fa64$#>mAG
                    > <-Duped below
                    > 2012-12-25 13:56:10 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5eO63nS>$AG
                    > <-Duped below
                    > 2012-12-25 13:56:48 UTC: KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1:!/;5Yn63og>vEG
                    >
                    > 2012-12-25 13:57:42 UTC:
                    > KC0U-8>APOTC1,MATFLD,WIDE1*,qAR,WX0U-2:!/;5gF64J.>[BG [Duplicate position
                    > packet]
                    > 2012-12-25 14:00:42 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;6HA64$'>kAG
                    > [Duplicate position packet]
                    > 2012-12-25 14:02:22 UTC:
                    > KC0U-8>APOTC1,MATFLD,WIDE1*,qAR,WX0U-2:!/;5fa64$#>mAG [Duplicate position
                    > packet]
                    > 2012-12-25 14:02:41 UTC: KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2:!/;5eO63nS>$AG
                    > [Duplicate position packet]
                    >
                    >
                    > Two digipeaters in question are, WX0U-1 and MATFLD. WX0U-1 is using a KPC3+
                    > V8.2 and MATFLD is unknown. However for MATFLD, it is likely the user is
                    > using a PC with a KPC3+ TNC in KISS mode. The TOCALL for MATFLD is unknown
                    > by APRS.FI.
                    >
                    > Unless someone can show me differently ...
                    >
                    > Best regards,
                    >
                    > Fred, N7FMH

                  • James Ewen
                    On Thu, Dec 27, 2012 at 12:57 PM, Fred Hillhouse ... Be aware that the TOCALL is a human entered parameter. As such it can be any value that the human entering
                    Message 9 of 16 , Dec 27, 2012
                    • 0 Attachment
                      On Thu, Dec 27, 2012 at 12:57 PM, Fred Hillhouse
                      <fmhillhouse@...> wrote:

                      > http://www.aprs.org/tocalls.txt
                      >
                      > Compare the TOCALL below with what is on the link above and tell me if you
                      > can tell if it is plus or not.
                      >
                      > WX0U-1>APN382 <-- The TOCALL is the APN382
                      >
                      > I did snip the section of interest.
                      >
                      > APN Network nodes, digis, etc
                      > APN3xx Kantronics KPC-3 rom versions
                      > APN9xx Kantronics KPC-9612 Roms
                      > APNAxx WB6ZSU's APRServe
                      > APNDxx DIGI_NED
                      > APNMxx MJF TNC roms
                      > APNPxx Paccom TNC roms
                      > APNTxx SV2AGW's TNT tnc as a digi
                      > APNUxx UIdigi
                      > APNXxx TNC-X (K6DBG)
                      > APNK01 Kenwood D700 (APK101) type
                      > APNK80 KAM version 8.0
                      > APNKMP KAM+

                      Be aware that the TOCALL is a human entered parameter. As such it can
                      be any value that the human entering it desires. The assumption is
                      that the person entering the information into the packet understands
                      what they are doing. We see many instances where the user just blindly
                      copies something they have seen elsewhere, without having an
                      understanding of what it is they are doing.

                      As with just about anything, we are basing our observations on the
                      available data. Bad data can lead to bad observations. Incomplete data
                      can lead to incomplete observational conclusions.

                      --
                      James
                      VE6SRV
                    • Keith VE7GDH
                      Warren KC0U wrote... ... A KPC3+ per se isn t a problem with delayed packets... e.g. a stand-alone digipeater. It s when it s used in KISS mode with an APRS
                      Message 10 of 16 , Dec 27, 2012
                      • 0 Attachment
                        Warren KC0U wrote...

                        > None of the digipeaters used in my trip home are using a
                        > KPC-3+, so I don't think that is the problem.

                        A KPC3+ per se isn't a problem with delayed packets... e.g.
                        a stand-alone digipeater. It's when it's used in KISS mode with
                        an APRS client that it's a problem. After a period of time, it
                        starts delaying the output on the serial port.

                        > Perhaps I am using the wrong terminology, as the website aprs.fi
                        > is obviously using stored information to reproduce my track. Is
                        > aprs.fi not part of the APRSIS network?

                        No, it isn't. The website aprs.fi gets data from the APRS-IS. The
                        APRS-IS gets data from IGates and shares that data between all
                        the servers that make up the APRS-IS, and clients such as UI-View,
                        APRSISCE/32 etc. can if they wish get data from the APRS-IS.
                        The site aprs.fi does store data, but it gets it from the APRS-IS.

                        The APRS network consists of the stations themselves, the
                        digipeaters, and the IGates. Whatever the IGates hear, they "gate"
                        to whatever server they are connected to. All the servers share
                        the data between themselves. Clients can connect to one of
                        the servers and get some or all of the data from the APRS
                        network. Sits like findu.com, aprs.fi, db0anf.de etc. can
                        connect to the APRS-IS and get whatever data they want.
                        The three I named would likely have a "full feed" from the
                        APRS-IS... i.e. everything that was gated but not thrown
                        out because it was a duplicate. The APRS-IS uses 30 second
                        dupe checking, so packets delayed by less than 30 seconds
                        won't show up. However, copies of a packet delayed by more
                        than 30 seconds will show up on places like aprs.fi...
                        or in your own APRS client if you were getting a feed
                        from the APRS-IS.

                        There are two likely causes of delayed packets.

                        One would be a digi holding onto packets and later digipeating
                        them... e.g. the digi could be in a location where the frequency is
                        VERY busy, and it might have to wait a while before there was
                        no activity before sending a digipeated packet... or the digi could
                        be using squelched audio and the squelch could be on the hairy
                        edge. It's better if the TNC sees unsquelched audio from the
                        radio and it determines itself if it is receiving noise or data.

                        The other common cause of delays are the IGates themselves.
                        It could be one on a very under-powered computer with a
                        slow CPU and not enough RAM, but I would think a more
                        likely cause at an IGate would be a KPC3+ running in KISS
                        mode. It's a known problem. UI-View is capable of restarting
                        itself on a scheduled basis. This takes the TNC out of KISS
                        mode and puts it back into KISS mode when it starts up
                        again. There could be other reasons why an operator would
                        like to restart it, but an added benefit of this is that it also
                        restarts the TNC.

                        There isn't anything you can do about delayed packets...
                        except track down the cause(s) and notify the operators
                        so they at least know about the problem. Some won't
                        know what you are talking about and will tell you that
                        "their station/digi or whatever has been operating for
                        years without any problems" and others will look into it
                        and hopefully take some kind of action. It's sometimes
                        easier to track down the cause by watching / listening on
                        RF, but viewing raw data at e.g. aprs.fi can sometimes
                        lead to clues... e.g.

                        2012-12-27 20:03:27 UTC:
                        KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1
                        :!/;5XK63m6> st

                        KC0U-8 was heard direct and gated by your KCOU-1. No
                        problems so far. Then about 9 minutes later...

                        2012-12-27 20:12:25 UTC:
                        KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2
                        :!/;5XK63m6> st [Duplicate position packet]

                        This appears to be an identical packet. I suppose it is possible
                        that KC0U-8 had not moved and it just happened to have
                        exactly the same location is the earlier beacon, but given
                        that other beacons before and after make it look like it
                        was moving, a more likely explanation is that either your
                        own WXOU-1 spat out the digipeated copy, but with a delay,
                        or... it was delayed by the nearby WX0U-2. That was just
                        one example. In another I looked at, WX0U-1 was a
                        possible culprit.

                        I'm looking at the data at the following URL. WX0U-1 and
                        WX0U-2 came up often as possible suspects. If it's a digi
                        causing the delays, you might be able to spot it on RF if
                        you watch long enough. If it's an IGate causing them,
                        looking somewhere like aprs.fi can yield clues... e.g.
                        a packet that went through a particular digi and was
                        gated by two different IGates but with a delay, would
                        point at the second digi as being the cause, as both would
                        have heard the digi at the same time. When the delayed
                        packet shows up but via a different digi path, it would
                        take some more digging to prove if a digi caused the delay
                        or if it was caused at the IGate level.

                        http://aprs.fi/?c=raw&call=KC0U-8&limit=1000

                        73 es cul - Keith VE7GDH
                        www.ui-view.org
                        --
                        "I may be lost, but I know exactly where I am!"
                      • Steve Daniels
                        Is it possible for APRSIS to command a KPC-3+ to restart to clear the delay, am thinking here that if there is Lynn could perhaps code a restart system. That
                        Message 11 of 16 , Dec 27, 2012
                        • 0 Attachment

                          Is it possible for APRSIS to command a KPC-3+ to restart to clear the delay, am thinking here that if there is Lynn could perhaps code a restart system. That cycles the KPC in the early hours of the morning each day/week.

                          I realise this is slightly off topic

                           

                          Steve Daniels

                          Amateur Radio Callsign G6UIM

                          Torbay Freecycle  Owner

                          http://uk.groups.yahoo.com/group/torbay_freecycle

                          APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

                           


                          From: aprsisce@yahoogroups.com [mailto: aprsisce@yahoogroups.com ] On Behalf Of Keith VE7GDH
                          Sent: 27 December 2012 21:57
                          To: aprsisce@yahoogroups.com
                          Subject: Re: [aprsisce] APRSIS storing delayed duplicates?

                           

                           

                          Warren KC0U wrote...

                          > None of the digipeaters used in my trip home are using a
                          > KPC-3+, so I don't think that is the problem.

                          A KPC3+ per se isn't a problem with delayed packets... e.g.
                          a stand-alone digipeater. It's when it's used in KISS mode with
                          an APRS client that it's a problem. After a period of time, it
                          starts delaying the output on the serial port.

                          > Perhaps I am using the wrong terminology, as the website aprs.fi
                          > is obviously using stored information to reproduce my track. Is
                          > aprs.fi not part of the APRSIS network?

                          No, it isn't. The website aprs.fi gets data from the APRS-IS. The
                          APRS-IS gets data from IGates and shares that data between all
                          the servers that make up the APRS-IS, and clients such as UI-View,
                          APRSISCE/32 etc. can if they wish get data from the APRS-IS.
                          The site aprs.fi does store data, but it gets it from the APRS-IS.

                          The APRS network consists of the stations themselves, the
                          digipeaters, and the IGates. Whatever the IGates hear, they "gate"
                          to whatever server they are connected to. All the servers share
                          the data between themselves. Clients can connect to one of
                          the servers and get some or all of the data from the APRS
                          network. Sits like findu.com, aprs.fi, db0anf.de etc. can
                          connect to the APRS-IS and get whatever data they want.
                          The three I named would likely have a "full feed" from the
                          APRS-IS... i.e. everything that was gated but not thrown
                          out because it was a duplicate. The APRS-IS uses 30 second
                          dupe checking, so packets delayed by less than 30 seconds
                          won't show up. However, copies of a packet delayed by more
                          than 30 seconds will show up on places like aprs.fi...
                          or in your own APRS client if you were getting a feed
                          from the APRS-IS.

                          There are two likely causes of delayed packets.

                          One would be a digi holding onto packets and later digipeating
                          them... e.g. the digi could be in a location where the frequency is
                          VERY busy, and it might have to wait a while before there was
                          no activity before sending a digipeated packet... or the digi could
                          be using squelched audio and the squelch could be on the hairy
                          edge. It's better if the TNC sees unsquelched audio from the
                          radio and it determines itself if it is receiving noise or data.

                          The other common cause of delays are the IGates themselves.
                          It could be one on a very under-powered computer with a
                          slow CPU and not enough RAM, but I would think a more
                          likely cause at an IGate would be a KPC3+ running in KISS
                          mode. It's a known problem. UI-View is capable of restarting
                          itself on a scheduled basis. This takes the TNC out of KISS
                          mode and puts it back into KISS mode when it starts up
                          again. There could be other reasons why an operator would
                          like to restart it, but an added benefit of this is that it also
                          restarts the TNC.

                          There isn't anything you can do about delayed packets...
                          except track down the cause(s) and notify the operators
                          so they at least know about the problem. Some won't
                          know what you are talking about and will tell you that
                          "their station/digi or whatever has been operating for
                          years without any problems" and others will look into it
                          and hopefully take some kind of action. It's sometimes
                          easier to track down the cause by watching / listening on
                          RF, but viewing raw data at e.g. aprs.fi can sometimes
                          lead to clues... e.g.

                          2012-12-27 20:03:27 UTC:
                          KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1
                          :!/;5XK63m6> st

                          KC0U-8 was heard direct and gated by your KCOU-1. No
                          problems so far. Then about 9 minutes later...

                          2012-12-27 20:12:25 UTC:
                          KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2
                          :!/;5XK63m6> st [Duplicate position packet]

                          This appears to be an identical packet. I suppose it is possible
                          that KC0U-8 had not moved and it just happened to have
                          exactly the same location is the earlier beacon, but given
                          that other beacons before and after make it look like it
                          was moving, a more likely explanation is that either your
                          own WXOU-1 spat out the digipeated copy, but with a delay,
                          or... it was delayed by the nearby WX0U-2. That was just
                          one example. In another I looked at, WX0U-1 was a
                          possible culprit.

                          I'm looking at the data at the following URL. WX0U-1 and
                          WX0U-2 came up often as possible suspects. If it's a digi
                          causing the delays, you might be able to spot it on RF if
                          you watch long enough. If it's an IGate causing them,
                          looking somewhere like aprs.fi can yield clues... e.g.
                          a packet that went through a particular digi and was
                          gated by two different IGates but with a delay, would
                          point at the second digi as being the cause, as both would
                          have heard the digi at the same time. When the delayed
                          packet shows up but via a different digi path, it would
                          take some more digging to prove if a digi caused the delay
                          or if it was caused at the IGate level.

                          http://aprs.fi/?c=raw&call=KC0U-8&limit=1000

                          73 es cul - Keith VE7GDH
                          www.ui-view.org
                          --
                          "I may be lost, but I know exactly where I am!"

                        • Lynn W Deffenbaugh (Mr)
                          I plan to provide some sort of periodic execution of s in the upcoming port renovations, specifically for this purpose. Lynn (D) - KJ4ERJ -
                          Message 12 of 16 , Dec 27, 2012
                          • 0 Attachment
                            I plan to provide some sort of periodic execution of <Open/CloseCmd>s in the upcoming port renovations, specifically for this purpose.

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

                            On 12/27/2012 5:34 PM, Steve Daniels wrote:

                            Is it possible for APRSIS to command a KPC-3+ to restart to clear the delay, am thinking here that if there is Lynn could perhaps code a restart system. That cycles the KPC in the early hours of the morning each day/week.

                            I realise this is slightly off topic

                             

                            Steve Daniels

                            Amateur Radio Callsign G6UIM

                            Torbay Freecycle  Owner

                            http://uk.groups.yahoo.com/group/torbay_freecycle

                            APRSISCE/32 Beta tester and WIKI editor http://aprsisce.wikidot.com

                             


                            From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com ] On Behalf Of Keith VE7GDH
                            Sent: 27 December 2012 21:57
                            To: aprsisce@yahoogroups.com
                            Subject: Re: [aprsisce] APRSIS storing delayed duplicates?

                             

                             

                            Warren KC0U wrote...

                            > None of the digipeaters used in my trip home are using a
                            > KPC-3+, so I don't think that is the problem.

                            A KPC3+ per se isn't a problem with delayed packets... e.g.
                            a stand-alone digipeater. It's when it's used in KISS mode with
                            an APRS client that it's a problem. After a period of time, it
                            starts delaying the output on the serial port.

                            > Perhaps I am using the wrong terminology, as the website aprs.fi
                            > is obviously using stored information to reproduce my track. Is
                            > aprs.fi not part of the APRSIS network?

                            No, it isn't. The website aprs.fi gets data from the APRS-IS. The
                            APRS-IS gets data from IGates and shares that data between all
                            the servers that make up the APRS-IS, and clients such as UI-View,
                            APRSISCE/32 etc. can if they wish get data from the APRS-IS.
                            The site aprs.fi does store data, but it gets it from the APRS-IS.

                            The APRS network consists of the stations themselves, the
                            digipeaters, and the IGates. Whatever the IGates hear, they "gate"
                            to whatever server they are connected to. All the servers share
                            the data between themselves. Clients can connect to one of
                            the servers and get some or all of the data from the APRS
                            network. Sits like findu.com, aprs.fi, db0anf.de etc. can
                            connect to the APRS-IS and get whatever data they want.
                            The three I named would likely have a "full feed" from the
                            APRS-IS... i.e. everything that was gated but not thrown
                            out because it was a duplicate. The APRS-IS uses 30 second
                            dupe checking, so packets delayed by less than 30 seconds
                            won't show up. However, copies of a packet delayed by more
                            than 30 seconds will show up on places like aprs.fi...
                            or in your own APRS client if you were getting a feed
                            from the APRS-IS.

                            There are two likely causes of delayed packets.

                            One would be a digi holding onto packets and later digipeating
                            them... e.g. the digi could be in a location where the frequency is
                            VERY busy, and it might have to wait a while before there was
                            no activity before sending a digipeated packet... or the digi could
                            be using squelched audio and the squelch could be on the hairy
                            edge. It's better if the TNC sees unsquelched audio from the
                            radio and it determines itself if it is receiving noise or data.

                            The other common cause of delays are the IGates themselves.
                            It could be one on a very under-powered computer with a
                            slow CPU and not enough RAM, but I would think a more
                            likely cause at an IGate would be a KPC3+ running in KISS
                            mode. It's a known problem. UI-View is capable of restarting
                            itself on a scheduled basis. This takes the TNC out of KISS
                            mode and puts it back into KISS mode when it starts up
                            again. There could be other reasons why an operator would
                            like to restart it, but an added benefit of this is that it also
                            restarts the TNC.

                            There isn't anything you can do about delayed packets...
                            except track down the cause(s) and notify the operators
                            so they at least know about the problem. Some won't
                            know what you are talking about and will tell you that
                            "their station/digi or whatever has been operating for
                            years without any problems" and others will look into it
                            and hopefully take some kind of action. It's sometimes
                            easier to track down the cause by watching / listening on
                            RF, but viewing raw data at e.g. aprs.fi can sometimes
                            lead to clues... e.g.

                            2012-12-27 20:03:27 UTC:
                            KC0U-8>APOTC1,WIDE1-1,qAR,KC0U-1
                            :!/;5XK63m6> st

                            KC0U-8 was heard direct and gated by your KCOU-1. No
                            problems so far. Then about 9 minutes later...

                            2012-12-27 20:12:25 UTC:
                            KC0U-8>APOTC1,WX0U-1*,qAR,WX0U-2
                            :!/;5XK63m6> st [Duplicate position packet]

                            This appears to be an identical packet. I suppose it is possible
                            that KC0U-8 had not moved and it just happened to have
                            exactly the same location is the earlier beacon, but given
                            that other beacons before and after make it look like it
                            was moving, a more likely explanation is that either your
                            own WXOU-1 spat out the digipeated copy, but with a delay,
                            or... it was delayed by the nearby WX0U-2. That was just
                            one example. In another I looked at, WX0U-1 was a
                            possible culprit.

                            I'm looking at the data at the following URL. WX0U-1 and
                            WX0U-2 came up often as possible suspects. If it's a digi
                            causing the delays, you might be able to spot it on RF if
                            you watch long enough. If it's an IGate causing them,
                            looking somewhere like aprs.fi can yield clues... e.g.
                            a packet that went through a particular digi and was
                            gated by two different IGates but with a delay, would
                            point at the second digi as being the cause, as both would
                            have heard the digi at the same time. When the delayed
                            packet shows up but via a different digi path, it would
                            take some more digging to prove if a digi caused the delay
                            or if it was caused at the IGate level.

                            http://aprs.fi/?c=raw&call=KC0U-8&limit=1000

                            73 es cul - Keith VE7GDH
                            www.ui-view.org
                            --
                            "I may be lost, but I know exactly where I am!"


                          • James Ewen
                            Further analysis and evidence... *05:56:10 UTC: AUBURN APNW01,TCPIP*,qAC,CORE-2:@280556z* *05:56:13.132 AUBURN APNW01,MATFLD*,WIDE2-1,qAR,KC0U-1:@280556z*
                            Message 13 of 16 , Dec 27, 2012
                            • 0 Attachment
                              Further analysis and evidence...

                              05:56:10 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@280556z
                              05:56:13.132  AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,KC0U-1:@280556z
                              05:56:14.204  AUBURN>APNW01,MATFLD*,KC0WNY*,qAR,KC0U-1:@280556z
                              05:59:37 UTC: AUBURN>APNW01,WIDE2-2,qAR,KC0BS:@280556z (delayed by 3:26)
                              06:00:41 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@280546z (delayed by 14:31)
                              06:01:10 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@280601z
                              06:01:13.549  AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,KC0U-1:@280601z
                              06:01:14.513  AUBURN>APNW01,MATFLD*,KC0WNY*,qAR,KC0U-1:@280601z
                              06:03:25 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@280551z (delayed by 12:15)
                              06:03:53 UTC: AUBURN>APNW01,WIDE2-1,qAR,KC0BS:@280601z (delayed by 2:43)
                              06:06:10 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@280606z
                              06:06:13.664  AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,KC0U-1:@280606z
                              06:06:14.657  AUBURN>APNW01,MATFLD*,KC0WNY*,qAR,KC0U-1:@280606z
                              06:08:19 UTC: AUBURN>APNW01,WIDE2-2,qAR,W0BZN:@280606z (delayed by 2:09)
                              06:09:03 UTC: AUBURN>APNW01,W0BZN*,WA0D-1*,qAR,W0BZN:@280606z (delayed 2:53)
                              06:09:44 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@280556z (delayed by 13:34)
                              06:11:10 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@280611z
                              06:11:13.865  AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,KC0U-1:@280611z
                              06:11:14.734  AUBURN>APNW01,MATFLD*,KC0WNY*,qAR,KC0U-1:@280611z
                              06:11:49 UTC: AUBURN>APNW01,N0KTA*,qAR,W0BZN:@280611z (delayed by 39 seconds)
                              06:12:47 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@280601z (delayed by 11:37)
                              06:15:25 UTC: AUBURN>APNW01,LAW*,WIDE2-1,qAR,KC0BS:@280611z (delayed by 4:15)
                              06:16:11 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@280616z
                              06:16:13 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@280606z (delayed by 10:02)
                              06:17:56 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@280611z (delayed by 6:45)

                              The blue packets are injected directly into the APRS-IS stream CORE-2 server by AUBURN. This tells us exactly when the packet was generated. Within a second that packet would be on the air.

                              The green packets are what KC0U-1 heard on RF. It can not hear AUBURN directly, but there are 2 digipeaters in range that are handling the packet. MATFLD handles the packet about 3 seconds after the packet enters the RF network (There may be a slight clock discrepancy between the APRS-IS servers and the timestamp from KC0U-1, but it is a consistent discrepancy) Almost 1 second later the KV0WNY digipeater handles the packet. These packets will not show up on the filtered APRS-IS feed because the duplicate filters drop the packets. These packets are being pulled from a non-filtered feed, and are therefore available for analysis.

                              Any packets in red are packets that sat in a KPC-3 waiting to be delivered to the attached computer, and then on to the APRS-IS servers. Because the delays were longer than the 30 second dupe filter, these packets get accepted as valid packets even though the timestamp shows HUGE delays. 

                              05:56:10 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@280556z
                              05:56:13.132  AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,KC0U-1:@280556z
                              06:09:44 UTC: AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,WX0U-2:@280556z (delayed by 13:34)

                              We can see direct evidence here that MATFLD is not to blame as KC0U-1 heard MATFLD digipeat the packet on RF 3 seconds after it was injected into the APRS-IS stream by the source station. 13 minutes and 34 seconds later WX0U-2 finally gets around to sending the packet it heard MATFLD digipeat through to the APRS-IS servers.

                              This is as blatant evidence as you can possibly find. We have the original packet sent to the APRS-IS stream, the packet heard nearly immediately on RF, and the delayed packet ultimately sent to the APRS-IS servers many minutes later. All timestamped to show the delivery times.

                              James
                              VE6SRV
                            • Keith VE7GDH
                              James VE6SRV wrote... ... Sorry, but I view all of my email i n plain yext format, but the timestamps work for me. However, why isn t the seconf copy, digi d
                              Message 14 of 16 , Dec 28, 2012
                              • 0 Attachment
                                James VE6SRV wrote...

                                > Further analysis and evidence...
                                >
                                > *05:56:10 UTC: AUBURN>APNW01,TCPIP*,qAC,CORE-2:@280556z*
                                > *05:56:13.132 AUBURN>APNW01,MATFLD*,WIDE2-1,qAR,KC0U-1:@280556z*
                                > *05:56:14.204 AUBURN>APNW01,MATFLD*,KC0WNY*,qAR,KC0U-1:@280556z*
                                > *05:59:37 UTC: AUBURN>APNW01,WIDE2-2,qAR,KC0BS:@280556z
                                > (delayed by 3:26)*

                                > The blue packets are injected directly into the APRS-IS stream
                                > CORE-2 server by AUBURN. This tells us exactly when the
                                > packet was generated. Within a second that packet would be
                                > on the air.

                                Sorry, but I view all of my email i n plain yext format, but the
                                timestamps work for me. However, why isn't the seconf copy,
                                digi'd by MATFLD and gated just 3 seconds later, discaded as
                                a dupe?

                                > The green packets are what KC0U-1 heard on RF. It can not
                                > hear AUBURN directly, but there are 2 digipeaters in range
                                > that are handling the packet. MATFLD handles the packet
                                > about 3 seconds after the packet enters the RF network (There
                                > may be a slight clock discrepancy between the APRS-IS
                                > servers and the timestamp from KC0U-1, but it is a consistent
                                > discrepancy) Almost 1 second later the KV0WNY digipeater
                                < handles the packet. These packets will not show up on the
                                > filtered APRS-IS feed because the duplicate filters drop the
                                > packets. These packets are being pulled from a non-filtered
                                > feed, and are therefore available for analysis.

                                Ah... I didn't know you could get an unfiltered feed.

                                > Any packets in red are packets that sat in a KPC-3 waiting to be
                                > delivered to the attached computer...

                                One possible explanation, but a likely one.

                                > and then on to the APRS-IS servers. Because the delays were longer
                                > than the 30 second dupe filter, these packets get accepted as valid
                                > packets even though the timestamp shows HUGE delays.

                                The timestamps sure make it easy to spot delayed packets.

                                73 es cul - Keith VE7GDH
                                www.ui-view.org
                                --
                                "I may be lost, but I know exactly where I am!"
                              Your message has been successfully submitted and would be delivered to recipients shortly.