How reliable an internet connection is needed for A K3 remote to work well?
Locked
12
12
 
|
A while back we tried Remoterig with a Kenwood radio and the CW generated was poor on the other end. This was presumably from dropped packets and or latency issues (Comcast on one end and a terrestrial microwave connection on the other end). Some dits/dahs were lost and others were prolonged, due to the lost stop signal. My understanding of the remoterig protocol for CW is it's not very robust, with no error correction or ACKing.
We got around the CW problem by using a VNC and the CW is generated at the host end within the VNC window, using N1MM, directly keying the radio. If we were to use a K3 and K3/remote for the radio, would there be potential radio control issues due to the flaky internet connection, or is there redundancy and/or error correction built into the Elecraft remote protocol? Barry W2UP |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
Run pingtest.net and make sure you have a grade A rating. You don't need much bandwidth as 1mbs in each direction is lots if you are the only user. However, latency issues will cause problems.
As I understand it, the K3/remote uses a remoterig interface. The problem may not be your ISP, but the routers you are using at both ends can contribute to your issues just as simply. Btw, I have been running a remote base with a ts480 for about 8 years. I do run CW by hosting n1mm at the far end and using a winkeyer. Mike va3mw > On Jul 13, 2014, at 9:36 PM, Barry <[hidden email]> wrote: > > A while back we tried Remoterig with a Kenwood radio and the CW generated was > poor on the other end. This was presumably from dropped packets and or > latency issues (Comcast on one end and a terrestrial microwave connection on > the other end). Some dits/dahs were lost and others were prolonged, due to > the lost stop signal. My understanding of the remoterig protocol for CW is > it's not very robust, with no error correction or ACKing. > > We got around the CW problem by using a VNC and the CW is generated at the > host end within the VNC window, using N1MM, directly keying the radio. > > If we were to use a K3 and K3/remote for the radio, would there be potential > radio control issues due to the flaky internet connection, or is there > redundancy and/or error correction built into the Elecraft remote protocol? > > Barry W2UP > > > > > -- > View this message in context: http://elecraft.365791.n2.nabble.com/How-reliable-an-internet-connection-is-needed-for-A-K3-remote-to-work-well-tp7591154.html > Sent from the Elecraft mailing list archive at Nabble.com. > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
In reply to this post by Barry
Barry,
The RemoteRig system generates its own CW using an internal protocol, which solves latency issues. You use your key at the control end and the radio side RRC generates a clean CW without hiccups. It has error control and is (I believe) very robust. I know of someone doing 40 wpm full BK with no problem, but your mileage will vary, depending upon the internet connection. As for the internet connection; there is a lot of discussion on the RemoteRig forum at their web site www.remoterig.com, so you can search there. In general, here are some tips: The sum of bandwidth required: - COM0 serial port bps - COM1 and/or COM2 bps if used (i.e. for CAT or rotor control) - which CODEC you are using, refer to appendix A in the Manual or http://www.remoterig.com/wp/?page_id=388 I use CODEC 0 for almost all of my stations, which has proven to be more than adequate for SSB and CW. - If you are running single or dual-channel audio (this doubles the codec rate requirement) - There is some overhead in the 20-50 bps range Remember also that this is doubled, up and down! Most DSL lines are asynchronous and have a lot less bandwidth going up than down, but the internet provider usually only advertises the down speed. You need therefore to take into account that the bandwidth used by RemoteRig is the same in both directions. Take into account the serial ports sent over the RRC, including CAT. It is not always necessary to run them at 38,400 bps! I recommend setting the K3 to 9600 bps to reduce your bandwidth that way. I also need to point out that I believe that the latency is far more important than the bandwidth, especially once you are over about 250k bps. Often 3G lines have severe latency problems making them unusable, and satellite is not advisable at all. Feel free to contact me directly if you have any further questions. 73, Mitch DJ0QN Mitch Wolfson DJØQN / K7DX Neubiberger Str. 21, 85640 Putzbrunn Skype: mitchwo - Home:+49 89 32152700 - Mobile:+49 172 8374436 Echolink: 3001 - IRLP: 5378 On 14.07.2014 03:36, Barry wrote: > A while back we tried Remoterig with a Kenwood radio and the CW generated was > poor on the other end. This was presumably from dropped packets and or > latency issues (Comcast on one end and a terrestrial microwave connection on > the other end). Some dits/dahs were lost and others were prolonged, due to > the lost stop signal. My understanding of the remoterig protocol for CW is > it's not very robust, with no error correction or ACKing. > > We got around the CW problem by using a VNC and the CW is generated at the > host end within the VNC window, using N1MM, directly keying the radio. > > If we were to use a K3 and K3/remote for the radio, would there be potential > radio control issues due to the flaky internet connection, or is there > redundancy and/or error correction built into the Elecraft remote protocol? > > Barry W2UP > > > > > -- > View this message in context: http://elecraft.365791.n2.nabble.com/How-reliable-an-internet-connection-is-needed-for-A-K3-remote-to-work-well-tp7591154.html > Sent from the Elecraft mailing list archive at Nabble.com. > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] > ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by Barry
Barry - I've been playing around with a RemoteRig at K4VV, where Mike W0YR had set up remote operating using VNC and Mumble/Skype for audio. The performance of the Internet connection there (which is wireless) is pretty bad - audio dropouts making CW essentially impossible for any real contest.
On the pingtesting, the latency sometimes is in the 45 ms range, sometimes in the 150 ms and occasionally even longer. It usually looks fine if you do a single pingtest, but do a ping test of 100 pings and you start to see the problem. So, I tried RemoteRig and with highly variable latency (high jitter) of the connection, the RemoteRig audio is no better than what we were getting on Mumble. The rig control works much nicer than the VNC approach, but the Internet connection just won't support usable remote audio for CW in a contest. For RTTY and SSB, good enough - but not for CW. The parameters you can change in RemoteRig include a lot of buffers and packet size changes. You can change them independently for the TX audio and the RX audio. I ran a test on the air with Shin JA1NUT, since he is a CW "purist" - he said my CW was odd, as he called it "every now and then you have a 'brainstorm'" - the variable latency would cause some CW sending buffering apparently. I could improve that on the TX side, but could never get the RX audio usable over that connection. So, now Rick AI1V is working with the wireless ISP to see if we can improve the Internet performance. As the folks from Microbit put it "RemoteRig can't replace lost packets." By the way, there is a beta version of the K1EL WinKey Remote software that gives you sidetone at the local WinKey - we've been using that to get around having to always do keyboard CW with the remote N1MM via VNC. 73 John K3TN |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
For control of the K3-line I don't think jitter and latency of the IP connection generally is a big problem.
The Elecraft software for remote control of the KPA500 and KAT500 is very user-friendly. The difficult part for a CW operator is in producing nice CW and in obtaining a good quality CW audio. I have used RC for many years and think I have quite some experience for CW but very little for SSB. I have been using K1EL Winkey Remote for a while and it's my impression that it is performing very well (basically similar to using a keyboard). It connects two winkeyers over IP and is described on K1EL website. Whereas I have heard quite many RemoteRig CW signals that sounded "odd" with occasionally dashes being way too long, I think I can truly say that a solution based on two linked Winkeyers will not have that problem (but it might have other problems). If someone has made a thorough comparison I would be very interested. There is a fundamental difference in the way the two solutions operate. The Winkey Remote is locally decoding and sending the character across the IP as a decoded character which is converted to a CW character in the Winkeyer connected to the rig. It will therefore only transmit a valid CW character (character set defined by K1EL). If you send an illegal character (by mistake or by sending some national special non-recognizable characters), the Winkeyer will output nothing but just writes an asterix in the decoded window. The keying will be indistinguishable from "keyboard CW", which may sound boring for some. If you keep ahead in the buffer, you can only insert space between characters (one space element) and between words (three space elements). If you want to insert a bit more space e.g. between sentences, you will have to let the buffer go empty. With some training you can make it sound fairly nice. And it gives you a good feeling of using a paddle for CW and of course the flexibility having eyes and one hand free while sending CW. I use an USB- Winkeyer in the shack (connected to a notebook) and a Winkey-compatible keyer from G3ZLP (half price). The solution is true low cost - unlike the RemoteRig. I have operated from OX-land with a ping time around 120 msec and from various places in OZ mostly with ping times about 20-30 msec. There is no big difference. The biggest contribution for the delay in CW comes from the decoding in the local Winkeyer - it is close to half a second and a bit annoying if you encounter a very eager/impatient CW operator. It is not for true QSK operation (even if you with the K3 can listen through your own sending). Maybe RemoteRig is superior in that respect. For the audio I use IP-Sound (which connects over a VPN) and can operate from 8 kbit (GSM or PCM coding) using about 16 kbit/s with a fine audio quality for CW. Much better than Skype. My friend Steph F5NZY says he has good results with using the VoIP in Teamviewer. I use Teamviewer for access (rig control) to the shack, but I do not get acceptable audio from Teamviewer VoIP. If the internet connection is such that you have drop-outs of the audio in Skype, I think you better forget about using any remote solution. I would be pleased to be proven wrong. I have no financial or other interest in any of the products mentioned above. /73 de OZ4UN Paul -----Oprindelig meddelelse----- Fra: Elecraft [mailto:[hidden email]] På vegne af John K3TN via Elecraft Sendt: 16. juli 2014 12:39 Til: [hidden email] Emne: Re: [Elecraft] How reliable an internet connection is needed for A K3 remote to work well? Barry - I've been playing around with a RemoteRig at K4VV, where Mike W0YR had set up remote operating using VNC and Mumble/Skype for audio. The performance of the Internet connection there (which is wireless) is pretty bad - audio dropouts making CW essentially impossible for any real contest. On the pingtesting, the latency sometimes is in the 45 ms range, sometimes in the 150 ms and occasionally even longer. It usually looks fine if you do a single pingtest, but do a ping test of 100 pings and you start to see the problem. So, I tried RemoteRig and with highly variable latency (high jitter) of the connection, the RemoteRig audio is no better than what we were getting on Mumble. The rig control works much nicer than the VNC approach, but the Internet connection just won't support usable remote audio for CW in a contest. For RTTY and SSB, good enough - but not for CW. The parameters you can change in RemoteRig include a lot of buffers and packet size changes. You can change them independently for the TX audio and the RX audio. I ran a test on the air with Shin JA1NUT, since he is a CW "purist" - he said my CW was odd, as he called it "every now and then you have a 'brainstorm'" - the variable latency would cause some CW sending buffering apparently. I could improve that on the TX side, but could never get the RX audio usable over that connection. So, now Rick AI1V is working with the wireless ISP to see if we can improve the Internet performance. As the folks from Microbit put it "RemoteRig can't replace lost packets." By the way, there is a beta version of the K1EL WinKey Remote software that gives you sidetone at the local WinKey - we've been using that to get around having to always do keyboard CW with the remote N1MM via VNC. 73 John K3TN -- View this message in context: http://elecraft.365791.n2.nabble.com/How-reliable-an-internet-connection-is-needed-for-A-K3-remote-to-work-well-tp7591154p7591235.html Sent from the Elecraft mailing list archive at Nabble.com. ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
In reply to this post by Barry
Here's some real-world experience from the three of the six remotes we
operated this past weekend from WRTC: Our Network at WRTC HQ: Either 100/9 Mbps WRTC-only or 20/20 Mbps shared with the hotel network. PR1T: ~384 Kbps using multiple technologies Typical ping time: 170-190 mS Number of routing hops to PR1T: >30 (!) Typical jitter: less than 20mS How it worked: We obviously had some router issues between us. When it worked, it worked very well. However, we would have dropouts where we would loose communications completely between the sites for 5-30 seconds. We kept a ping window up all the time so we could test. The RRC boxes allow you to adjust CW sending so that it sounds normal on the other end. In the PR1T case, we used the K3/0 mini for all the audio and rig control, but we used TeamViewer to operate N1MM remotely. We used N1MM to send automated CQs and exchanges... this worked well, as we were sending keystrokes only. SK9HQ@SK3W: ~284 kbps asymmetric DSL Typical ping time: 170-195 mS: Number of routing hops to SK3W: ~15 Typical jitter: lless than 10mS How it worked: Very well. We could send CW from the RRC locally, and it sounded good. I adjusted the RRC to take the transit times into account. We also used TeamViwer to control WinTest locally at SK3W (easy, and it also gave us all the local station control interfaces at SK3W) W1VE@K2LE/1: 1.5/.7 Mbps asymmetric DSL Typical ping time: 50-55 mS; Number of routing hops to K2LE/1: ~10 Typical jitter: less than 10 mS How it worked: Flawlessly. We networked N1MM over a VPN; Andy was at his staiton in Vermont, and the second operating position was at WRTC HQ. All CW was sent from the remote. Note that in all cases, we were able to run very high rates (>200/hr on both CW and SSB); being remote did not affect the ability to make fast QSOs. From prior experience, I can tell you that attempting to run RemoteRig and a K3 over Multipoint-to-Point Wireless ISPs is very, very difficult. In this case, you are on a TDM half-duplex connection, and there is HUGE opportunity for dropouts and very high jitter. (which is going to be a killer). If you are trying to remote to a mountain top, find someone (like another ham) who has high-speed (Fiber or Coax), and run a point-to-point link on 5 GHz... This can work very well, and there is a lot of cheap gear out there to let you get the job done inexpensively. For portable operation, 4G LTE cellular hotspots/modems work very well -- as long as location is fixed. I've tried it mobile ( from New England) and it is so-so, though we have a lot of mountains in New Hampshire. Bottom line: RemoteRig and K3s run very well over pretty low speed connections. Just make sure jitter is low and fairly consistent. Latency can be fairly high, but you must adjust settings to compensate on CW. 73, Gerry W1VE Gerry Hull, W1VE | Hancock, NH USA | +1-603-499-7373 AKA: VE1RM | VY2CDX | VO1CDX | 6Y6C | 8P9RM <http://www.yccc.org> <http://www.yccc.org/> <http://www.facebook.com/gerryhull> <https://plus.google.com/+GerryHull/posts> <http://www.twitter.com/w1ve> On Sun, Jul 13, 2014 at 9:36 PM, Barry <[hidden email]> wrote: > A while back we tried Remoterig with a Kenwood radio and the CW generated > was > poor on the other end. This was presumably from dropped packets and or > latency issues (Comcast on one end and a terrestrial microwave connection > on > the other end). Some dits/dahs were lost and others were prolonged, due to > the lost stop signal. My understanding of the remoterig protocol for CW is > it's not very robust, with no error correction or ACKing. > > We got around the CW problem by using a VNC and the CW is generated at the > host end within the VNC window, using N1MM, directly keying the radio. > > If we were to use a K3 and K3/remote for the radio, would there be > potential > radio control issues due to the flaky internet connection, or is there > redundancy and/or error correction built into the Elecraft remote protocol? > > Barry W2UP > > > > > -- > View this message in context: > http://elecraft.365791.n2.nabble.com/How-reliable-an-internet-connection-is-needed-for-A-K3-remote-to-work-well-tp7591154.html > Sent from the Elecraft mailing list archive at Nabble.com. > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] > Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
Gerry - How does one measure jitter?
All - We have the CW issues worked out, using a VNC window and having the transmitter connected directly to N1mm, rather than trying to send CW iover the network. My remaining question is - in the presence of a somewhat flaky Internet connection, for whatever reason - latency, jitter, etc. - is there any problem with the K30 control of the K3? For example, when turning the AF gain or tuning knob, will they follow well, or will there be dropouts of radio commands, hinder reliable operation? TU, Barry W2UP |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
Barry,
Do a long series of pings (ping address -n 500 will let it run 500 times) Jitter is the difference between ping times (100ms ping and 120ms ping is 20mS jitter) "My remaining question is - in the presence of a somewhat flaky Internet connection, for whatever reason - latency, jitter, etc. - is there any problem with the K30 control of the K3? For example, when turning the AF gain or tuning knob, will they follow well, or will there be dropouts of radio commands, hinder reliable operation? " Yes, everything will go to hell if internet connection is bad... knobs don't react fast, display does not update fast, etc. However, don't panic. Unless the problem persists, it will go away quickly. Hint: Don't turn knobs like audio or power fast. Each pulse from the knob is sent as a UDP packet... If you turn too fast based on the connection speed, the vlue won't change much. Turn slowly and it will update regularly. I found that with our PR1T connection, screen updates and knob turning would recover, unless the connection went down for a long time, and I get that DANG LOUD SIT tone in the remote. If I get that, I just cycle the power on the front panel of the K3/0 mini, and it ususally comes right back. -Gerry Gerry Hull, W1VE | Hancock, NH USA | +1-603-499-7373 AKA: VE1RM | VY2CDX | VO1CDX | 6Y6C | 8P9RM <http://www.yccc.org> <http://www.yccc.org/> <http://www.facebook.com/gerryhull> <https://plus.google.com/+GerryHull/posts> <http://www.twitter.com/w1ve> On Wed, Jul 16, 2014 at 10:10 AM, Barry <[hidden email]> wrote: > Gerry - How does one measure jitter? > > All - We have the CW issues worked out, using a VNC window and having the > transmitter connected directly to N1mm, rather than trying to send CW iover > the network. > > My remaining question is - in the presence of a somewhat flaky Internet > connection, for whatever reason - latency, jitter, etc. - is there any > problem with the K30 control of the K3? For example, when turning the AF > gain or tuning knob, will they follow well, or will there be dropouts of > radio commands, hinder reliable operation? > > TU, > Barry W2UP > > > > > -- > View this message in context: > http://elecraft.365791.n2.nabble.com/How-reliable-an-internet-connection-is-needed-for-A-K3-remote-to-work-well-tp7591154p7591241.html > Sent from the Elecraft mailing list archive at Nabble.com. > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] > Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by Barry
> Hint: Don't turn knobs like audio or power fast. Each pulse from the knob > is sent as a UDP packet... I'm late to join this thread, but was curious so read a couple before deleting. What I bring up below may have been discussed before. I'm not much of a network person, but I believe UDP packets are tossed out with no error correction at all (like unproto X25 packet). Having lived in a packet loss environment for a long time (years) and running IRLP, I can tell you that when a packet it lost, it is lost. The command, audio, whatever, will be lost and have to be repeated in order to get it through. As I said, this may have been discussed before and I'm sorry for any repetition it brings. It also causes pretty bad holes in the audio if it is sent UDP. Gary -- http://ag0n.net 3055: http://ag0n.net/irlp/3055 NodeOp Help Page: http://ag0n.net/irlp ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
On Wed, Jul 16, 2014 at 12:13 PM, AG0N-3055 <[hidden email]> wrote:
> >> Hint: Don't turn knobs like audio or power fast. Each pulse from the knob >> is sent as a UDP packet... > > I'm late to join this thread, but was curious so read a couple before > deleting. What I bring up below may have been discussed before. > > I'm not much of a network person, but I believe UDP packets are tossed > out with no error correction at all (like unproto X25 packet). Having > lived in a packet loss environment for a long time (years) and running > IRLP, I can tell you that when a packet it lost, it is lost. The > command, audio, whatever, will be lost and have to be repeated in order > to get it through. As I said, this may have been discussed before and > I'm sorry for any repetition it brings. It also causes pretty bad holes > in the audio if it is sent UDP. The flip-side is that use of a "reliable" protocol, such as TCP, which detects and retransmits dropped packets, causes increasing latency over time (the more packets get retransmitted, the further behind "real time" you get). For something like a "real time" audio stream, it generally better to just accept the packet-loss. The problem of increasing latency can affect UDP too - some types of unreliable links cause a sequence of packets to get queued, then all transmitted in a burst. This causes a gap in the stream, followed by that increased latency as all of the packets received in the burst, and any thereafter, need to get played sequentially. Buffering can help to smooth this out, but the more you buffer, the greater your baseline latency, which is a big deal for remote operation - e.g. tuning around the band, looking for CW signals with a narrow filter engaged - if there's any significant latency, you've already tuned past the signal before you hear it. It's a tricky problem area. My personal software solution uses UDP and a moderately-sized buffer, and when the buffer builds up to a point where the latency is more than I like, I click a button to dump the contents of the buffer, and return me to low-latency. ~iain / N6ML ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for a K3 remote to work well?
|
|
In reply to this post by Barry
Barry and others,
I have been following the discussion and want to add the description of a problem and its solution that I encountered with my remote operation. My set-up: Control site: Manhattan, New York; k3/0 mini to RemoteRig with wireless to WiFi router to Cable ISP (ping 10ms; 15Mbps forward; 1Mbps return); more than 25 strong WiFi networks in range Radio site: Town of Clinton, NY (rural); K3/100 to RemoteRig with wireless to WiFi router to cable ISP (ping 16ms; 55Mbps forward; 25Mbps return); only my own WiFi Network in range Parameter settings: All settings of the RemoteRig and Elecraft equipment at both ends were without any exception at the values recommended by Microbit and Elecraft in the manuals Problem: Dropped packets resulting 0.1 - 1 sec audio drop outs both ways and messed up CW; worse during business busy hour (5 - 6 pm) and at night from 8 - 11pm Solution: The problem is clearly not caused by line speed or ping time. At first I though the problem might be congestion at the cable node in the City (400+ business and residential users on the fiber fed node), but the cable company convinced me with tests that I witnessed that this was not the issue. Then I talked to some folks about WiFi issues. What I learned is that most WiFi equipment as-delivered is set for channel 6 as default and most users leave it there. I checked my router in the City and found it was on channel 6. I changed my router to channel 8 and the dropped packet problem completely disappeared and CW is just fine. So the problem appears to have been something we hams are all familiar with - QRM. My suggestion is, if you are having a dropped packet problem and are using WiFi in a dense WiFi environment as part of your remote system, try changing your router WiFi channel as a first very easy step to solving the problem. 73, Buzz W3EMD Message: 9 Date: Sun, 13 Jul 2014 18:36:27 -0700 (PDT) From: Barry <[hidden email]> To: [hidden email] Subject: [Elecraft] How reliable an internet connection is needed for A K3 remote to work well? Message-ID: <[hidden email]> Content-Type: text/plain; charset=us-ascii A while back we tried Remoterig with a Kenwood radio and the CW generated was poor on the other end. This was presumably from dropped packets and or latency issues (Comcast on one end and a terrestrial microwave connection on the other end). Some dits/dahs were lost and others were prolonged, due to the lost stop signal. My understanding of the remoterig protocol for CW is it's not very robust, with no error correction or ACKing. We got around the CW problem by using a VNC and the CW is generated at the host end within the VNC window, using N1MM, directly keying the radio. If we were to use a K3 and K3/remote for the radio, would there be potential radio control issues due to the flaky internet connection, or is there redundancy and/or error correction built into the Elecraft remote protocol? Barry W2UP ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
In reply to this post by mcduffie
On 7/16/2014 12:13 PM, AG0N-3055 wrote:
> I'm not much of a network person, but I believe UDP packets are tossed > out with no error correction at all (like unproto X25 packet). I am a network person. When you use UDP, it is up to the protocol layer above to handle dropped packets. For example, a volume knob should send a value, not just +1 or -1, and in a remote environment, it'd be good to send a full set of "settings" periodically. ... or each UDP command could require an ACK via UDP. Or a few dozen other answers. For voice, where latency is more important than dropped sound, you usually don't try to replace the lost packets. 73 -- Lynn ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for a K3 remote to work well?
|
|
In reply to this post by James Beitchman
Keep in mind too that WiFi channels overlap quite a bit. If the problem
is WiFi activity on channel 6, you'd have to go to 3 or 9 to be completely clear. 73 -- Lynn On 7/16/2014 1:51 PM, James Beitchman wrote: > What I learned is that > most WiFi equipment as-delivered is set for channel 6 as default and most > users leave it there. I checked my router in the City and found it was on > channel 6. I changed my router to channel 8 and the dropped packet problem > completely disappeared and CW is just fine. ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for a K3 remote to work well?
|
|
I think you mean channels 1, 6 or 11 to avoid overlap on the 802.11 2.4 GHz
band. Other WiFi bands may differ. http://en.wikipedia.org/wiki/List_of_WLAN_channels Regards, David McAnally WD5M On Wed, Jul 16, 2014 at 4:40 PM, Lynn W. Taylor, WB6UUT < [hidden email]> wrote: > Keep in mind too that WiFi channels overlap quite a bit. If the problem > is WiFi activity on channel 6, you'd have to go to 3 or 9 to be completely > clear. > > 73 -- Lynn > > Regards, David McAnally Ting Referral Discount <https://z4omok6qd.ting.com/> On Wed, Jul 16, 2014 at 4:40 PM, Lynn W. Taylor, WB6UUT < [hidden email]> wrote: > Keep in mind too that WiFi channels overlap quite a bit. If the problem > is WiFi activity on channel 6, you'd have to go to 3 or 9 to be completely > clear. > > 73 -- Lynn > > > On 7/16/2014 1:51 PM, James Beitchman wrote: > >> What I learned is that >> most WiFi equipment as-delivered is set for channel 6 as default and most >> users leave it there. I checked my router in the City and found it was on >> channel 6. I changed my router to channel 8 and the dropped packet >> problem >> completely disappeared and CW is just fine. >> > > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] > Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for a K3 remote to work well?
|
|
In reply to this post by Lynn W. Taylor, WB6UUT
There are only actually 3 wifi channels at 2.4ghz for 20mhz spacing, and
they are 1, 6 and 11. By using any of the other numbers you are overlapping the adjacent channel. Whey they let you pick 2,3,4,5, etc., is beyond me. By using 8, you will be getting interference from both channels 6 and 11, so I would recommend that you use 1 or 11, or, better yet, move to 802.11AN and use the 5Ghz band and then you can also take advantage of 40Mhz bandwidth, full 3x3 Mimo and much better speeds of over 300Mhz. I would also make sure you lock down your current router to 802.11G or 802.11N if you can. If anything else joins your network and it is B, it drops down to the old B speeds. In fact, all your router has to do is hear other traffic (your neighbour) and a B device connected and it will drop down that speed. Surprised that your neighbours can actually impact your bandwidth by not being connected? The 802.11 spec is designed to play nice with your neighbours and not QRM them. :) Mike va3mw (yes, I used to install stuff like this for a living) On Wed, Jul 16, 2014 at 5:40 PM, Lynn W. Taylor, WB6UUT < [hidden email]> wrote: > Keep in mind too that WiFi channels overlap quite a bit. If the problem > is WiFi activity on channel 6, you'd have to go to 3 or 9 to be completely > clear. > > 73 -- Lynn > > > On 7/16/2014 1:51 PM, James Beitchman wrote: > >> What I learned is that >> most WiFi equipment as-delivered is set for channel 6 as default and most >> users leave it there. I checked my router in the City and found it was on >> channel 6. I changed my router to channel 8 and the dropped packet >> problem >> completely disappeared and CW is just fine. >> > > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] > Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by Lynn W. Taylor, WB6UUT
Fortunately, this is one group I DON'T have to explain to about
overlapping frequencies. See the picture--it will make it clear as day. There are fundamentally (in the US) only 3 frequencies that correspond to channels 1,6, and 11. In Europe, you also get a 4th frequency on channel 14. Channels 12-14 are only legal outside the USA. http://en.wikipedia.org/wiki/List_of_WLAN_channels On Wed, Jul 16, 2014, at 02:40 PM, Lynn W. Taylor, WB6UUT wrote: > Keep in mind too that WiFi channels overlap quite a bit. If the problem > is WiFi activity on channel 6, you'd have to go to 3 or 9 to be > completely clear. > > 73 -- Lynn > > On 7/16/2014 1:51 PM, James Beitchman wrote: > > What I learned is that > > most WiFi equipment as-delivered is set for channel 6 as default and most > > users leave it there. I checked my router in the City and found it was on > > channel 6. I changed my router to channel 8 and the dropped packet problem > > completely disappeared and CW is just fine. > > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] -- Eric Ross ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
In reply to this post by Barry
Another solution if your hardware and router support it is to move to 5ghz. Much less chance of interference but wireless range is less.
-------- Original message -------- From: Eric Ross <[hidden email]> Date: 16/07/2014 6:05 PM (GMT-05:00) To: [hidden email] Subject: Re: [Elecraft] How reliable an internet connection is needed for a K3 remote to work well? Fortunately, this is one group I DON'T have to explain to about overlapping frequencies. See the picture--it will make it clear as day. There are fundamentally (in the US) only 3 frequencies that correspond to channels 1,6, and 11. In Europe, you also get a 4th frequency on channel 14. Channels 12-14 are only legal outside the USA. http://en.wikipedia.org/wiki/List_of_WLAN_channels On Wed, Jul 16, 2014, at 02:40 PM, Lynn W. Taylor, WB6UUT wrote: > Keep in mind too that WiFi channels overlap quite a bit. If the problem > is WiFi activity on channel 6, you'd have to go to 3 or 9 to be > completely clear. > > 73 -- Lynn > > On 7/16/2014 1:51 PM, James Beitchman wrote: > > What I learned is that > > most WiFi equipment as-delivered is set for channel 6 as default and most > > users leave it there. I checked my router in the City and found it was on > > channel 6. I changed my router to channel 8 and the dropped packet problem > > completely disappeared and CW is just fine. > > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] -- Eric Ross ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
In reply to this post by Barry
RemoteRig/RRC uses UDP (Realtime Data Protocol) for Audio, and I'm sure a
lot of other stuff. This is the best mode for most of what we are doing with remote ham radio. Signaling is modified Session Initiation Protocol (SIP), also UDP. All that you need to know is that it will do fairly well over pretty rotten internet connections. Speed itself, as well as bandwidth, are important, but latency and jitter are what is going to play havoc with a quality connection. If you are doing remote in-country in the US, you are not going to see many issues (unless you are on a wireless Multipoint-to-point network or any other network using TDM/time slicing techniques.). I'm amazed at how fast the Microbit gear recovers after a network loss. They have done a good job. The K3 - RRC combo is awesome for remote! 73, Gerry W1VE Gerry Hull, W1VE | Hancock, NH USA | +1-603-499-7373 AKA: VE1RM | VY2CDX | VO1CDX | 6Y6C | 8P9RM <http://www.yccc.org> <http://www.yccc.org/> <http://www.facebook.com/gerryhull> <https://plus.google.com/+GerryHull/posts> <http://www.twitter.com/w1ve> On Wed, Jul 16, 2014 at 5:36 PM, Lynn W. Taylor, WB6UUT < [hidden email]> wrote: > On 7/16/2014 12:13 PM, AG0N-3055 wrote: > >> I'm not much of a network person, but I believe UDP packets are tossed >> out with no error correction at all (like unproto X25 packet). >> > > I am a network person. When you use UDP, it is up to the protocol layer > above to handle dropped packets. > > For example, a volume knob should send a value, not just +1 or -1, and in > a remote environment, it'd be good to send a full set of "settings" > periodically. > > ... or each UDP command could require an ACK via UDP. > > Or a few dozen other answers. > > For voice, where latency is more important than dropped sound, you usually > don't try to replace the lost packets. > > 73 -- Lynn > > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] > Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
Re: How reliable an internet connection is needed for A K3 remote to work well?
|
|
In reply to this post by Iain MacDonnell - N6ML-2
It is standard to use UDP (RTP) over VoIP for the reasons given by Iain.
Over a corporate network, VoIP traffic should have a QoS tagging on the IP packets which causes routers to prioritise it. VoIP over the internet has always been done for cost, not quality reasons, as the whole concept behind IP networks is at conflict with constant rate traffic; the telephone industry devised ATM as a packet network for that application (although they are now moving to IP, because voice is no longer the dominant bandwidth user - but I am sure they will prioritise their voice traffic). RTP has a marker bit which indicates a safe place to dump a latency buffer's contents. Conceivably setting this during tuning would be a good idea. If the remote operation protocol doesn't user RTP, someone has been re-inventing the wheel. As someone mentioned WiFi. It is generally accepted, in the VoIP world, that WiFi and VoIP don't mix because WiFi introduces additional latency. I believe it also does link level retransmission which, means latency can be particularly bad if you don't have ideal conditions. -- David Woolley Owner K2 06123 [ Top quoted through list policy, not preference. ] On 16/07/14 20:35, iain macdonnell - N6ML wrote: > The flip-side is that use of a "reliable" protocol, such as TCP, which > detects and retransmits dropped packets, causes increasing latency > over time (the more packets get retransmitted, the further behind > "real time" you get). For something like a "real time" audio stream, > it generally better to just accept the packet-loss. The problem of > increasing latency can affect UDP too - some types of unreliable links > cause a sequence of packets to get queued, then all transmitted in a > burst. > It's a tricky problem area. My personal software > solution uses UDP and a moderately-sized buffer, and when the buffer > builds up to a point where the latency is more than I like, I click a > button to dump the contents of the buffer, and return me to > low-latency. ______________________________________________________________ Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email] |
|
|
Is QoS well implemented in IPv4?
Per-Tore / LA7NO On 18 July 2014 11:22, David Woolley <[hidden email]> wrote: > It is standard to use UDP (RTP) over VoIP for the reasons given by Iain. > Over a corporate network, VoIP traffic should have a QoS tagging on the IP > packets which causes routers to prioritise it. VoIP over the internet has > always been done for cost, not quality reasons, as the whole concept behind > IP networks is at conflict with constant rate traffic; the telephone > industry devised ATM as a packet network for that application (although they > are now moving to IP, because voice is no longer the dominant bandwidth user > - but I am sure they will prioritise their voice traffic). > > RTP has a marker bit which indicates a safe place to dump a latency buffer's > contents. Conceivably setting this during tuning would be a good idea. If > the remote operation protocol doesn't user RTP, someone has been > re-inventing the wheel. > > As someone mentioned WiFi. It is generally accepted, in the VoIP world, > that WiFi and VoIP don't mix because WiFi introduces additional latency. I > believe it also does link level retransmission which, means latency can be > particularly bad if you don't have ideal conditions. > > -- > David Woolley > Owner K2 06123 > > [ Top quoted through list policy, not preference. ] > > On 16/07/14 20:35, iain macdonnell - N6ML wrote: > >> The flip-side is that use of a "reliable" protocol, such as TCP, which >> detects and retransmits dropped packets, causes increasing latency >> over time (the more packets get retransmitted, the further behind >> "real time" you get). For something like a "real time" audio stream, >> it generally better to just accept the packet-loss. The problem of >> increasing latency can affect UDP too - some types of unreliable links >> cause a sequence of packets to get queued, then all transmitted in a >> burst. > > >> It's a tricky problem area. My personal software >> solution uses UDP and a moderately-sized buffer, and when the buffer >> builds up to a point where the latency is more than I like, I click a >> button to dump the contents of the buffer, and return me to >> low-latency. > > > > > ______________________________________________________________ > Elecraft mailing list > Home: http://mailman.qth.net/mailman/listinfo/elecraft > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[hidden email] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html > Message delivered to [hidden email] Elecraft mailing list Home: http://mailman.qth.net/mailman/listinfo/elecraft Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[hidden email] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html Message delivered to [hidden email]
73,
Per-Tore / LA7NO |
«
Return to Elecraft
|
1 view|%1 views
| Free forum by Nabble | Edit this page |