Author Topic: WiFi - How I finally have reliable remote CW keying with my RRC-1258 pair  (Read 4095 times)

G0KPE

  • Newbie
  • *
  • Posts: 4
    • View Profile
    • Email
My pair of RRC-1258 MK11s are running v2.95 firmware. My 'control' 1258 is fitted with the (now-discontinued) internal WiFi option board. The remote 'radio' 1258 is connected via ethernet to the home router.

I have been trying for goodness knows how long, to get reliable, clean remote CW keying of my radio, but was experiencing mini-gaps where there should have been a dit or a dah, instead there were dropouts and gap delays that resulted in rogue morse characters. The dropouts/gaps would be about once every 8-15 seconds of any of my CW transmissions. This made my sending difficult to read for a receiving station and made me not want to use the RemoteRig solution. I have read many similar stories on this forum with no solution given that I could spot.

It's Christmas at the moment and I have some free time. After many hours of testing, experimenting and analysis, I have concluded that the internal RemoteRig WiFi option does not work well enough to give reliable CW remote sending. Something in the way that it functions or how the motherboard controls it, is causing periodic timing issues in the UDP strings associated with remote CW keying. Audio streaming is brilliant and rarely has audible dropouts, given a good WiFi Access Point signal and good connection through to the remote radio. The internal WiFi is therefore fine for SSB operating but it is just not right for CW. Testing with an Ethernet cable connection to a router gives perfect remote CW keying.

The internal RemoteRig WiFi option board is no longer available to purchase due to parts obsolescence, so it is doubtful that there will ever be a firmware update to address this CW keying issue using the internal WiFi module option.

I have had to stop using the RemoteRig internal WiFi board for my CW QSOs, and having had success with experimental tests, I have changed to using an external WiFi device. My remote CW keying is finally working correctly and cleanly, allowing me to confidently use my RemoteRig setup for CW QSOs without concern that my sending is being poorly received.     

The external WiFi unit that I am using and that I can recommend for RemoteRig RRC-1258 MKII CW operators is a GL.iNet 300N-V2 Mini Smart Router. I got mine from Amazon. It connects to the 'radio' RRC-1258 with an Ethernet cable and the GL.iNet box runs from a 5Vdc source. I use a spare phone charger.  See attached pic.

Last note:- For reliable clean remote CW keying, there needs to be a good WiFi Access Point signal path for the control end, and a good quality, stable network connection with the remote radio end. UDP data packets are employed by RemoteRig for the remote CW keying. UDP are 'real-time' data transfers with no missed-packet retries. TCP/IP does have missed data packet resends but is not suited for real-time applications like our remote radio CW keying. TCP/IP is slower and has much more 'overhead' handling of each data packet. With a poor WiFi signal or slow internet connection, you may well have some UDP data packet losses that will affect your remote CW keying. Try to ensure that you operate within as good a WiFi signal as possible and with a good network/internet connection at the Radio end and at the Control end.

I hope this is useful for other CW operators who have been struggling with their RemoteRig RRC-1256 MKII remote CW keying.

73
Carl
G0KPE
« Last Edit: 2023-12-27, 19:31:25 by G0KPE »

sm2o

  • Administrator
  • Hero Member
  • *****
  • Posts: 3041
    • View Profile
    • sm2oan
    • Email
Hi

You did not say anything about the most important setting to use CW. The "Key Delay ms" if you increase the buffering by increasing Key Delay, CW works OK in most situtations. With Key Delay =0 you need an extremly good Internet connection to make it work

73 de mike

G0KPE

  • Newbie
  • *
  • Posts: 4
    • View Profile
    • Email
Hi Mike,

Thanks for responding. Although my ping return time is <10ms here on my home network where I have been experimenting, I have the TX delay set all the way to max (250ms) and use the local sidetone from my RRC-1258 control unit. I have the LF delay set to 450ms so that I do not hear the radio's sidetone on the AF streaming link, which BTW is perfect - no dropouts. I have made many adjustments to the TX delay value in my experimenting.

It is easy to set up a test to demonstrate the CW dropouts/gaps when using the internal WiFi board option in an RRC-1258 MKII, as long as you are close enough to be able to monitor your radio's transmissions off-air on a separate receiver. I have a portable receiver to listen to, plus I have a waterfall display to observe my remotely keyed transmissions. I have both the Control and the Radio RRC1258 MKIIs connected to the same home router. The radio one is connected on Ethernet, the Control one is WiFi-connected.

With a paddle key attached to the RRC-1258 MKII, hold down the dit or the dah paddle. Listen to the off-air transmissions. Within 15 seconds of key-down you will hear the first gap dropout, with others following.

One of my tests was to add a switch to Input 0 (set as KEYER), to generate what should be a constant key-down carrier. This is not the case though. There are gaps in the transmissions. Listening to the Control RRC sidetone, there are audible glitches every second. I have observed that the remote radio transmission gaps, when they occur, are synced with these audible sidetone glitches. When using Ethernet or an external WiFi device, the audible sidetone glitches remain but there are no remote transmission gaps, just the expected constant carrier. It is as if the Control RRC-1258 with the internal WiFi board fitted, is sometimes missing the paddle key input states at the exact instant of those 1-second glitches. Is that possible Mike?

As I mentioned in my original post, moving away from the internal WiFi and instead using an external WiFi unit has removed these remote transmission glitches/gaps and my CW is exactly as keyed (currently with that 250ms delay).

73
Carl
G0KPE

« Last Edit: 2024-01-01, 14:53:46 by G0KPE »