[aprssig] Delayed packets (yet again)

Sat Aug 26 09:18:35 EDT 2006

In various parts of the country I have also narrowed it down twice to 
two different RF issues.
1. I found a TNC/Radio combination that was not using DCD, but was 
instead using squelched audio for the TNC to decode. When the squelch 
was left OPEN, the TNC would not transmit until it's internal buffer 
got full and then DUMPED the entire contents of  it's buffer in one 
continuous stream.
2. Similar issue as above, but the root cause was a digi that 
routinely heard a continuous stream of packets from so many other 
digi's that it would also que all the messages until it's buffer got 
full and then would do a DUMP of it's contents. (It could hold about 
2 minutes of continuous packets when it did transmit).

In both cases above these happen to be on KPC-3's. I have never bench 
proven if this could occur with other TNC's/Firmware versions.

I have seen delays from I-Gates as well cause the problem, but have 
never PROVEN whether it was a slow computer/local connectivity 
problem, or a problem with the APRS server it was attached to.

Mark Cheavens
KC5EVE
At 10:03 PM 8/25/2006, you wrote:
>Recently kc4pl and I saw enormous delays on RF.  We've seen igate 
>delays from ww6jc in a nearby town running ui-view.  At anyrate, 
>kc4pl is running TNC-x and an ax.25 stack connected to 
>javaaprs.  What we saw was /were delays on the order of 60 to 90 
>seconds.  I was sending packets that were uniquely numbered so we'd 
>know which got thru and which didn't.
>
>We suspected that perhaps TNCx was hearing too many packets on 
>frequency to TX, so he QSY'ed the radio.  I send a few more 
>packets.  Then it dawned on us that he wasn't seeing the packets I 
>send for 60 to 90 seconds.  As soon as he saw them appear in the 
>ax.25 stack, they were digipeater.  In the process of reaching under 
>the desk, he may have reset or momentarly interrupted the power to 
>the TNCx.... so we're not sure if the tnc-x is the problem or the 
>ax.25 stack in linux.  Or maybe some part of the system needed a 
>break. At this time, we're waiting for the delays to happen again so 
>we can figure out if it's TNC-x or ax25 stack.
>
>Possible theories include that TNCx may have a memory leak...
>tncx may spend so much time servicing interrupts in a busy channel 
>that it can't deliver data to the serial port.
>ubuntu ax25 may have a problem.
>
>Really don't know anything difinitive at this point.
>Wes
>
>On 8/25/06, Tim Cunningham 
><<mailto:tim_cunningham at mindspring.com>tim_cunningham at mindspring.com> wrote:
>There was a delayed packet discussion specifically concerning IGates 
>recently. We did a through study into the problem in my area and 
>isolated the problem to a UI-View station operating as an IGate. 
>Since that discussion there were a few other folks across the 
>country who wrote off-line that they experienced the same issue with 
>UI-View in their areas. This issue was specifically limited to a 
>UI-View IGate that was injecting packets greater than 1 minute later 
>than another IGate using APRS+SA. Many of the packets were time 
>stamped to verify the delay. It was not a digipeater delay because 
>we could see two IGates hearing the same packet from the same 
>digipeater being injected into the APRS-IS greater than one minute apart.
>
>IGates that are experiencing delays should consider using filtered 
>port 14580 and limit their data to under 100 to 200km using the 
>m/100 to m/200 qualifier. When an IGate tries to process the full 
>feed they are going to run slower depending on their computer 
>configuration and whether they are using a dial-up feed or a high speed link.
>
>There are many sources of delays that also include digipeaters. The 
>first step is to identify if the delay is the USB to serial 
>converter which should be fairly easy by visual observation on how 
>long it takes a decoded packet to appear on the screen. Then, it 
>becomes only a measure of time from that point to when it appears on 
>the APRS-IS.
>
>
>
>73's,
>Tim - N8DEU
>Huntsville, Alabama
>
>
>
>
>----- Original Message -----
>From: <mailto:w0jrt at yahoo.com>J T
>To: <mailto:aprssig at lists.tapr.org>TAPR APRS Mailing List
>Sent: Friday, August 25, 2006 1:26 PM
>Subject: [aprssig] Delayed packets (yet again)
>
>
>In one of the many "delayed packet" discussions there was talk about 
>some serial-to-USB converters causing issues.  I can't seem to find 
>this discussion in the archives.  Does anyone recall the 
>make(s)/model(s) of the serial-to-USB converters that are known or 
>suspected of being problematic?  And perhaps suggest a model that is 
>known to work well?
>
>I've been communicating with an I-gate owner whose station is 
>injecting delayed packets into APRS-IS.  He's too busy to study and 
>fix the problem (unfortunately for the rest of us) so I'm trying to 
>help gather some information that may make it easier to debug the 
>problem.  He swapped TNCs but that didn't fix it.  He mentioned that 
>he uses a serial-to-USB converter so hopefully I can talk him into 
>experimenting with a different one or coming up with another solution.
>
>-Jerome, W0JRT
>
>
><http://us.rd.yahoo.com/evt=43256/*http://advision.webevents.yahoo.com/mailbeta>All-new 
>Yahoo! Mail - Fire up a more powerful email and get things done faster.
>
>
>----------
>_______________________________________________
>aprssig mailing list
><mailto:aprssig at lists.tapr.org>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>_______________________________________________
>aprssig mailing list
><mailto:aprssig at lists.tapr.org>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20060826/db7ebc92/attachment.html>