[aprssig] packet delays through internet

[Russ Chadwick]

On 7:59 PM, Stephen H. Smith wrote:
> On 3/20/2011 1:07 PM, Russ Chadwick wrote:
>>
>> Significant packet delays were noted through an I-gate that consisted 
>> of a D710, UI-View and Comcast ISP.
>>
>> After we changed UI-View to having no flow control, expected delays 
>> of just a few seconds were noted almost all of the time.
>>
>>
>
>
> Did you try hardware handshaking (CTS/RTS conductors) on both ends?   
> This would appear to be the most positive flow control, assuming the 
> cable between the two devices has the conductors required.

Stephen,

No.  After removing the Xon/Xoff from UI-View, we ran with no flow 
control on either the D710 or the computer.  Then we did the 22 hour 
test, and found no problem.  That is the way that this I-gate will 
operate for our upcoming EOSS twofer balloon flights on April 2.

>
>
>
> By the way, did you ever determine where the numerous corrupted 
> versions of the two balloons' callsigns that appear on my maps came 
> from?   It would appear that somewhere, someone was running an igate 
> or digipeater in PASSALL  a.k.a. "junkque" mode.
>
> It could have easily been these corrupted packets retransmitted to 
> your igate that choked it with bogus X-on/X-off characters.....

We have not found anyone who was running their APRS set-up with PASSALL 
on.  What we did notice during our tests this past weekend was that when 
the packets were being delayed by the Xon/Xoff flow control in UI-View, 
a significant number of the packets (like one-third or more) had 
character errors somewhere in the packet when they finally appeared on 
findU.  When we removed the flow control from UI-View, all of the packet 
errors went away.  It appears that both the bad packet problem and the 
delayed packet problem were caused by the Xon/Xoff flow control in UI-View.

Russ  KB0TVJ