[aprssig] Delayed packets

Ron Stordahl ron.stordahl at digikey.com
Tue Jun 6 13:07:30 EDT 2006


Using a MFJ1270C with UIDIGI-ROM, I simulated a busy channel by shorting 
input pin 3 to ground.  That line, called squelch input, when low 
illuminates the DCD light, and the TNC withholds sending.  I then sent a 
packet from another tnc which it would otherwise immediately digipeat.  
I waited 5 minutes, and raised the squelch input and that packet, which 
had been queued, was immediately transmitted. 

I don't know how deep the queue can be, but in any case if the digi 
considered the channel busy it does queue, and apparently for a 
considerable time.

The MFJ1270C is designed to run open squelch, but other digi's 
apparently do expect the radio to be squelched.  Or the internal open 
squelch circuits could be badly adjusted.

This seems to me to be a likely explanation of delayed packets in some 
instances.

Ron Stordahl, N5IN


Tim Cunningham wrote:
> If the delay is in a digipeater, somebody could have DWAIT programmed 
> to something other than 0. In this scenario, if a digipeater delayed 
> and waited for a clear channel because DWAIT was greater than zero, 
> the packet could be delayed in a busy network. The delay could depend 
> on how much activity is on the network. This would be a real good 
> argument for DWAIT=0 on a digi or SlotTime=1 and PPersitance=255 on a 
> UIDIGI. The other possible parameter would be an extreme setting for 
> TXdelay in the case of a digipeater. If the issue is not related to a 
> digipeater, then these settings would not be applicable. I have seen 
> cases in the past where a digipeater would fire off a load of packets 
> waiting in the queue because of these parameter settings. However, 
> eight minutes is a rather lengthy period of time.
>
>
>
> Tim - N8DEU
>
>
>
> ----- Original Message ----- From: "Bruce W. Martin, KQ4TV" 
> <aprs at almostanywhere.com>
> To: "TAPR APRS Mailing List" <aprssig at lists.tapr.org>
> Sent: Tuesday, June 06, 2006 10:37 AM
> Subject: Re: [aprssig] Delayed packets
>
>
>> I recently had a discussion with some others about this very 
>> subject.  He was in Huntsville, Alabama and his packet was 
>> immediately I-Gated  by the local Huntsville I-Gate and 8 minutes 
>> later, after 4 or 5  update packets, his position was I-Gated by my 
>> javaprssrvr running on  a Gateway 2000 P200 with a built in serial 
>> port. I know the packet  went through 2 digis to get to me about 100 
>> miles north in Tennessee.  The delay seemed to be in the digipeaters.
>>
>> Bruce, KQ4TV
>>
>>
>> On Jun 6, 2006, at 8:38 AM, Wes johnston wrote:
>>
>>> WRT uiview, we had two stations near here doing it and in each case  
>>> they were UIview, which lead me to my previous conclusion.  Your  
>>> report that a copy of xastir did it is the first I've heard of the  
>>> problem outside uiview. This begs the question: what do these  
>>> delayed packet igates have in common? this could lead us to  
>>> pointing fingers at a particular brand of USB serial adapter.  I  
>>> have one that is based on the prolific chipset that won't program  
>>> my TT3 b/c the last packet never gets sent until another one comes  
>>> along to "push" it out.  Many laptops and some desktops are now  
>>> coming with USB on the motherboard for serial ports, could that be  
>>> the problem?
>>>
>>> Wes
>>>
>>> ----- Original Message ----- From: "Curt, WE7U" <archer at eskimo.com>
>>> To: "TAPR APRS Mailing List" <aprssig at lists.tapr.org>
>>> Sent: Tuesday, June 06, 2006 9:16 AM
>>> Subject: Re: [aprssig] Delayed packets
>>>
>>>
>>>> On Tue, 6 Jun 2006, Wes johnston wrote:
>>>>
>>>>> Although it is difficult to prove, this delayed delivery of a  
>>>>> packet seems
>>>>> to always revolve around the UI-View client.
>>>>
>>>> Very difficult to prove, considering it isn't true!  ;-)
>>>>
>>>> I know of at least one Xastir client that has had the same sorts of
>>>> difficulty, gating things in either direction late.  It appears to
>>>> be a function of that particular machine 'cuz I don't recall hearing
>>>> of others that do it.  Never figured out why it does it on that one,
>>>> which is owned by a nearby friend of mine.
>>>>
>>>>
>>>>> running uiview in our area to stop igating and the problem went  
>>>>> away for us.
>>>>> Please let us know what you find.  Unfortunately, we all know the 
>>>>> chances of
>>>>> fixing this....
>>>>
>>>> Because the author is SK?  Yea, but I thought all of UI-View's ills
>>>> could be fixed with a plug-in...  More than likely somebody will
>>>> write a plug-in to replace the igate functionality if it's possible
>>>> to do that particular piece with the plug-in API.  I've come to the
>>>> conclusion that people won't ever let UI-View die a natural death.
>>>> More than likely people will keep older Windows versions around
>>>> after newer Windows releases make it obsolete, just to run UI-View.
>>>>
>>>> -- 
>>>> Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
>>>> "Lotto:    A tax on people who are bad at math." -- unknown
>>>> "Windows:  Microsoft's tax on computer illiterates." -- WE7U
>>>> "The world DOES revolve around me:  I picked the coordinate system!"
>>>>
>>>> _______________________________________________
>>>> aprssig mailing list
>>>> 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
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> 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




More information about the aprssig mailing list