I’ve been working on a cure for a problem encountered during long RTTY QSO’s where the transceiver will drop out of transmit and lock up. Initially, I thought this might be due to RFI. So I tried some ferrite clamp-on devices on the K3 to P3 to Computer control cables. Next I read up on RFI cures and came across K9YC’s suggestion to use CAT-5 or CAT-6 cable rather than standard RS-232 cables. So, I set about on a small adventure building a set.

The first approach I took was to adapt converters for RJ-45 connector to DB-9 connector. This would allow me to use standard RJ-45 CAT-5 or CAT-6 cables. I was able to make up one set but really had trouble on the second set. So I abandoned that approach and purchased DB-9 solder connectors. This morning I was finally able to build the two cables needed to connect the K3 to the P3 and then P3 to the computer.

The cables work great but the problem remains. Now I’m not sure it’s due to RFI. Plus, an interesting twist has been added, perhaps an improvement. With the RS-232 cables the K3 would lock up and I’d have to shut down N1MM and turn it back on to recover. With the CAT-6 cables I’m now able to just switch to receive and get it back up and running. That could be an improvement or perhaps I just didn’t tumble to this recovery option in past attempts. Gee whiz. At least with the short QSO’s in contests I do not encounter this problem. More later on this adventure.

 

SHARE
Previous articleWebsite Design II
Next articleJOTA Webinar
Jim-K5ND

Freelance writer and active Scouting volunteer. Retired publishing and communication executive who writes for fun and to finance his hobby, amateur radio.

7 COMMENTS

    • Hi Walter, thanks for your suggestions. I’ve spent some time this morning trying to zero in on the problem. It appears to be within N1MM. Press tune on the K3 and it will run all day at 100 watts. Run the computer direct to the K3, bypassing the P3, and the same problem happens. The only time I corrected the problem is when I mistakenly ran the rig with an error message showing from N1MM that contact with the radio was lost. Thus, MMTTY was controlling the radio without N1MM on top. Ran all day long without dropping power. I do a bit more checking and inquire to the N1MM digital list. Thanks again for getting me thinking along some different lines and taking a more methodical approach to finding the problem. 73, Jim, K5ND

        • Hi Eric, I applied a fair bit of ferrite to the cables. Plus, the cable I’m using for the Winkey has the ferrite built in. Didn’t solve the problem. I’m amazed that the one selection for the PTT configuration makes all the difference. Not sure I can explain that one. But, happy that it is resolved. Yet another adventure. 73, Jim, K5ND

  1. Computers often have poor grounding practices, so it might be an issue with the PC rather than the cables. Have you tried doing something similar using your Mac?

    If it doesn’t happen there, I would suspect grounding issues with the PC. Then it would be time to re-read the section on the “Pin 1 Problem” in K9YC’s paper until it is straight in your mind. I always have to re-read it myself, and I have an EE degree.

    http://audiosystemsgroup.com/RFI-Ham.pdf

    Jim uses K3’s, so his advice should be pretty applicable.

    http://www.qrz.com/db/K9YC

    • That’s the article where I found the idea for the CAT-6 cables. It’s pin 5 there that’s ground and the K3 has a RF choke on the pin running to ground. Need to look at the computer side of the connection next. That may very well be my next move on this. Querying the N1MM-Digital Group hasn’t revealed any insight. Thanks so much for your suggestions, Walter.

      When I do discover the issue, I will say “It was intuitively obvious to the most casual observer” — the phrase that you’ve used for your id. I heard that a great deal in U.S. Air Force tech school.

      73, Jim, K5ND

      • I spent some time reviewing the connections from N1MM to the radio. Found that selecting “PTT for Radio Command Digital Mode” eliminated the problem. Drop that selection and the problem re-appears. While I’m using AFSK with VOX, perhaps there is some sort of noise on the PTT line (like RFI or ground loop) that snags the transceiver. Not sure that this one is really solved.

What do you think?