CW Transmission Errors

[K5DN]

I have recently noticed that my CW transmissions are partially garbled.  I don't know exactly when this started, or what might have changed.  The severity varies from time to time,  but it typically anywhere from about 3 to 30% of characters sent have extra or missing dots/dashes.  The rx audio is quite good during these periods. Here is my setup:

Radio: K3 Twins
RemoteRig RRC-1258 MKIIS, firmware 2.75
Control ISP - cable, 15Mb/s down, 1.2Mb/s up
Radio ISP - WISP, typically 2Mb/s down, 2Mb/s up (advertised rates 750K up/down)
Keyer- external
Key delay = LF delay = 250ms
Audio - 2 x Linear 16bit 8khz

Also have a desktop computer at the remote running NaP3 (with LP-Pan) and some antenna control stuff; computer is accessed with VNC.

I took the control RRC to the remote site to test back to back, and found no problems with the RRC's; CW was solid.  I have done a bunch of ping testing, and the results vary a lot with time of day.  I am pinging the WISP radio unit, as I have not been able to ping anything behind it.

Typically, in the light usage hours in the middle of the day, I can usually do a 100 ping sequence and get 70ms max, 45ms ave, 0 lost.  Sometimes the max will be 150ms or so, with just a few in this range; sometimes there are 2% or so lost.  Testing the CW transmission in these conditions still result in around 3-5% errors.

In the evenings, the ping times do get up into the 150-200ms range, but not often more; there are sometimes 2-4% lost.  The CW at these times is substantially worse.

Can anyone advise how to trouble-shoot this problem?  It seems to me like the ISP performance is not so bad to be causing it to this degree.

Thanks,
Bob K5DN

[sm2o]

Hi

If you have set Key delay to 250ms. The Radio-RRC collect data for 250ms before starting to transmit. If a packet is lost or there is a intermittent delay of more then 250ms there will be missing or delayed parts of the sent character. This is nothing the RRC can do anything about.
In non realtime system TCP/IP or other mechanisms can be used to ensure the data is comming through by retransmissions, acknowledges etc. But in a realtime system like the RRCs you do not get any advantages of such mechanisms as the information is getting old immediately if it's not comming at the right time.

So the answer is, increase the Key delay or find out why the Internet connection is not as good as before.

I always recomend that people use the same ISP in both ends if it's possible, often the narrow sector is where the ISP connect to each other. In there own networks they often have very powerful backbone networks.

WIth tools like pingplotter you can often see where the problem is.

73 de mike

[K5DN]

I understand.  I am running ping, tracert, and PingPlotter trying to figure out what is going on.  I have to learn enough to convince the WISP tech that he needs to work on it.  I sent him some plots, and waiting on him now.

It does look like there is one hop in the path causing trouble, only in one direction.

Thanks for your immediate response.

[K5DN]

Mike,

Can you provide some details of the CW data that is sent?

Packet size;
data rate;
Which port is it sent to (sip, rtp, control?);
UDP packets?;
is data sent continuously, or just when key input detected?.

This info may help to analyze the problem.

Thanks,
Bob

[sm2o]

Hi

It's sent over the control port. A message is sent on every change of the inputs I think. But all the other data tranfer  is also sent via the same port so there are lot of traffic.

73 de mike