[aprssig] Delayed packets
Ron Stordahl
ron.stordahl at digikey.com
Tue Jun 6 14:22:45 EDT 2006
In my original reply I said that pin 3 was the squelch input to the
MFJ1270C (also MFJ1270B). This is an error...it's pin 5. From the rear
of the TNC this pin is the second one counting from the right.
While it seems unlikely that you would be providing squelch information
from the radio to the MFJ1270B, it is possible I suppose. The MFJ1270C
has a jumper J3, which when removed, does not allow external squelch
input to be seen. The MFJ1270B does not have a similar option, thus if
you are providing squelch input (grounded means the tnc withholds
transmitting), this could be an issue. I do not know what outputs are
provided from the FT-1500M on the MiniDIN-6 connector you make reference
to, nor do I know if you have pin 5 connected in the cable to the MFJ.
If you do you should disconnect it as it's unneeded and could contribute
to the delay problem.
But both the 1270B and 1270C do have a DCD led on the front panel. You
should be able to tell by looking at this if the DCD led is overly
active. You can monitor the audio using a common portable mp3 player
headphone using the speaker jack on the rear of the TNC. If the DCD
light comes on without a packet signal this is a problem with the tnc's
open squelch detection circuit. I have never had such a problem and so
have not looked into how this would be corrected. With the number of
pots on the board I would guess it's probably one of them. It's
probably in the manual.
Ron, N5IN
Bruce W. Martin, KQ4TV wrote:
> 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
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
More information about the aprssig
mailing list