Iain I see what you mean. Are you sure the speed of the Client WK was the "default" value? Another point maybe that I have set for autospace, although I dont think that is the problem. What was the keying speed of each of the WKs with the case you present?
All I can say that here it works real fb. Actually similar to using the keyboard. The only difference is the added latency in the order of half a second or less. If you can not accept that, dont waste your time with WK remote. For me, the benefit of using a paddle is worth that additional delay. /paul Sendt fra min iPad > Den 09/03/2014 kl. 17.26 skrev "iain macdonnell - N6ML" <[email protected]>: > > Hi Poul-Erik, > > I observed the problem, then explored the cause. I assure you it is > real (or was at the time). Here's an attempt at depicting the problem > graphically: > > https://plus.google.com/photos/103976355713671908425/albums/5988823147749984001?authkey=CNj2yKKlvoifXw > > I don't see any way around this other than perhaps to introduce a > delay before sending the first character - the delay would need to be > the difference in length between the first character and the > longest-possible subsequent character (some prosign, I suppose - or > perhaps a zero), since we don't know what (or how long) that character > is until the operator has finished keying it. > > Setting the client to a significantly higher speed than the server > doesn't seem practical, and still doesn't really solve the problem - > the difference in speed would have to be huge to make a zero no longer > than an 'E'! > > 73, > > ~iain / N6ML > > > > On Sun, Mar 9, 2014 at 5:09 AM, Poul Erik Karlshøj (PKA) > <[email protected]> wrote: >> Iain >> It is true that the WK in remote configuration does decode the padle input >> and hence cannot send a character before it is finished. But this does NOT >> lead to what you mention. There is absolutely no problem in sending N6ML at >> any speed on a Server/Client set up. What You may have run into is the >> situation where the Client WK has been set to a too low speed - that will >> introduce some embarassing space insertion. >> >> When adjusting the speed (on the Client window) you adjust the speed by >> which you key the Server WK (and the TX). The Client WK automatically is set >> to a slightly higher speed (call it the "default speed"). I have checked >> this at various speeds. Sending "the quick brown fox jumped over the lazy >> dog" the Server WK will just finish the word lazy when you have finished the >> whole sentence. It is the case at speed 15 wpm and it is the case at 30 wpm.. >> >> You can set the Client WK at any higher speed than the default (using the >> Client WK potentiometer) and in this way key more ahead of the Server WK, >> but this only advisable if you know you will not be break'ed. Setting the >> Server WK at 15 wpm I can finish the sentence when the Server just finished >> the word Fox. The Server WK keeps on with "jumped over the lazy dog" while I >> sit back and enjoy. However if you force the Client key to a speed below the >> default speed you will get exactly what you describe. >> >> You are right that Remoterig does it in a different way and that one can use >> any keyer. This may well be a good reason to use that (more expensive) >> solution. I have heard many Remoterig signals and many of them produce >> strange effects, maybe when there are packet loss on the IP. I dont know if >> WK server Client setup would be any better in that situation - but I do >> think so. The WK solution will only output valid characters - or nothing. >> >> Just to be clear: I have no interest whatsoever in the Winkeyer product - >> despite it may seem so :-) >> >> 73 de OZ4UN >> Poul-Erik >> >> Sendt fra min iPad >> >>> Den 08/03/2014 kl. 17.44 skrev "iain macdonnell - N6ML" <[email protected]>: >>> >>> The problem I had with the WKremote solution is that it sends a letter >>> at a time. It has to wait for you to key a complete letter before it >>> sends it over the network to the remote site. This results in strange >>> spacing - it takes longer to key in a '6' than it does to send a 'N', >>> so, e.g., my callsign comes out as "N <space> 6ML". >>> >>> I believe that the RemoteRig solution sends individual elements (dits >>> and dahs), not complete letters, over the network to avoid this >>> problem. >>> >>> I had a problem with my remote WinKeyer a while back. Intermittently, >>> CW would come out "warbly" (almost like RF getting into the keying >>> line, but it wasn't that). When the weather got really cold (by W6 >>> standards - i.e. below 40F:), it'd fail completely first thing in the >>> morning, until I turned the K3 on and let things warm up for a while >>> (the WinKeyer sits on top of the K3). I was worried that it was >>> something inside the K3 that was failing, but after I replaced both >>> the WinKeyer and the cable connecting it to the K3, it's been 100% >>> fine since. I still don't know if it was the WinKeyer or the cable >>> that was causing the problem, but didn't want to have to make a second >>> trip in those "frigid" temps :) >>> >>> 73, >>> >>> ~iain / N6ML >>> >>> >>> >>> On Sat, Mar 8, 2014 at 7:01 AM, Poul Erik Karlshøj (PKA) >>> <[email protected]> wrote: >>>> Hi David >>>> If you mean how to set-up the Winkey Server/Client there is a very well >>>> written document available on K1EL website: >>>> http://k1el.tripod.com/WKremote.html >>>> It is indeed very easy and simple to set up if you follow that document. >>>> It did not take me many minutes before I had adjusted to operating RC CW >>>> that way: you have a small latency from the WK when using two linked WKs. >>>> But it is really not a problem in my view. I have used CW for over 50 >>>> years. For very fast QSK QSOs, though, I think you would not like it. For >>>> standard bk-type QSOs its indeed useable - even when through an internet >>>> connection with 200 msec ping-time. >>>> >>>> If you mean RC in general, there are many ways to do it. My low-cost >>>> solution is just one. >>>> Anyone want to know more contact me off-list. >>>> >>>> 73/OZ4UN >>>> Poul-Erik >>>> >>>> -----Oprindelig meddelelse----- >>>> Fra: David Cutter [mailto:[email protected]] >>>> Sendt: 8. marts 2014 11:22 >>>> Til: Poul Erik Karlshøj (PKA) >>>> Cc: [email protected] >>>> Emne: Re: [Elecraft] K3 - WinkeyUSB Keying Issue >>>> >>>> What an astonishing idea! I have hesitated to make a remote station >>>> because of the latency problem, but this will encourage me to look >>>> further. Do you have a diagram of your set-up you could share? >>>> >>>> 73 >>>> >>>> David >>>> G3UNA >>>> >>>> ----- Original Message ----- >>>> From: "Poul Erik Karlshøj (PKA)" <[email protected]> >>>> To: <[email protected]> >>>> Cc: "Elecraft Email List" <[email protected]> >>>> Sent: Saturday, March 08, 2014 8:40 AM >>>> Subject: Re: [Elecraft] K3 - WinkeyUSB Keying Issue >>>> >>>> >>>>> Jed, I would also suspect the cable (having had some problems with one >>>>> myself). >>>>> >>>>> Not directly related: I have just tried connecting two winkeyers in >>>>> Server/Client mode. It works great. I just came back from a short trip to >>>>> OX and worked RC on internet with a 200 msec delay and it worked real >>>>> nice. Used a WK-compatible keyer from G3ZLP at the Client end and an >>>>> original Winkeyer in the shack at home. It is certainly an easy way to >>>>> operate remotely using a paddle. >>>>> >>>>> OZ4UN/Poul-Erik >>>>> >>>>> Sendt fra min iPad >>>> ______________________________________________________________ >>>> Elecraft mailing list >>>> Home: http://mailman.qth.net/mailman/listinfo/elecraft >>>> Help: http://mailman.qth.net/mmfaq.htm >>>> Post: mailto:[email protected] >>>> >>>> This list hosted by: http://www.qsl.net >>>> Please help support this email list: http://www.qsl.net/donate.html ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[email protected] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
