[aprssig] Delayed packets

[Bruce W. Martin, KQ4TV]

These look like a likely possibilities in the case of one of the  
digipeaters in question for my situation. Since the situation I spoke  
of has one digi in Tim's area and the other is one that I manage. I  
will need to look at the settings. The digi is an MFJ-1270B/UIdigi  
1.9b3 and a Yaesu FT-1500M. I used Tim's guidelines to setup the  
UIdigi chip but that is about a year ago since I installed that one  
at the site. Since this digi has the TNC connected to the radio via  
the MiniDIN-6 connector the squelch and volume knobs don't affect  
what the TNC hears. Any suggestions?

Bruce, KQ4TV


On Jun 6, 2006, at 12:07 PM, Ron Stordahl wrote:

> 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
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig