Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - K9SO

Pages: [1] 2
No replies ... so apparently the RRC 1258 units are not repairable. Into the landfill it goes. >:(


After years of reliable operation linking my IC-706MKIIg control head (panel), my RRC1258 control unit stopped working. The radio panel screen is blank and I have no audio transfer in either direction. The control unit shows ERROR on the UDP command status line.

I have several systems based on the RRC1258 and have multiple links to the same radio unit (only one at a time of course). My other links work fine. At least one of them is on the exact same network with the exact same settings. My system consists of 4 Icom radio panels linked to one radio. So I have 4 RRC1258 control units linking to one RRC1258 radio unit. All other locations still work perfectly. I have the radio panels in two fixed locations, one in my car, and one in a battery operated "go box".

I swapped out the suspect RRC1258 control unit with a known good one and cloned the settings. The replacement works fine.

The suspect unit is linking fine: it can still turn on/off the radio through the PWK link and the CW keying link still functions so this failure of COM0 or UDP only is puzzling. No audio or data for the display unit.

This is not a network issue as other units (control heads) on the same network and a known good replacement work fine. I tried reflashing the firmware with no joy.

Is this unit repairable?


I have not been able to find a single p/n marking on the microphone, even after opening it up (it is only marked KENWOOD), but it does have a lighted Touch Tone pad. It looks like MC-53DM as seen at this link, but it has the round 8-pin microphone connector that mates with the B2000:

I was told that it was the original microphone shipped with the B2000, but maybe an original owner can verify that.

I used the power pin strapping as shown in the RRC manual for the D710 setup.



I could not find any two pins that shorted together following the PTT switch, yet it keyed the radio directly. Of course: the radio supplies power via the microphone connector.

This microphone apparently needs 8-9v of power in order to operate. Adding in the 8v power strap solved the problem. Of course, that is not noted in the strapping instructions for the Kenwoods.

Maybe you could note that this is necessary for some Kenwood microphones in a future manual update.

Thanks for the help.


Is the pin labeled "GND" on the aux/mic strapping block supposed to be connected to chassis ground? Because it is not.

Yes, it seems simple ... but I already have about 8 hours into troubleshooting this so please bear with me.

The adapter plugged into the aux/mic jack without the microphone does not key the unit. It is a brand new Kenwood MJ-88 and it ohms out as it should.

When I install the red PTT and GND straps only, the unit does not key but the microphone PTT button does not key the unit either.

When I install the MIC GND strap, the unit keys immediately and unkeys when I remove the microphone from the adapter.

I notice that the pin labeled GND on the strapping block is not connected to chassis ground.

I have a new installation trying to use a RC2000 head to control a Kenwood TS-B2000. The radio, control head, and microphone works perfectly when together (no RCC's).

I have them connected via a pair of RRC-1258MKII's and everything works as it should except for the microphone connection. I've had CW on the air QSOs and it all works... until I plug in a microphone into the aux/mic jack of the Control RRC. I have double and triple checked the strapping, but when I plug in the microphone connector, the link keys up the radio immediately (goes to transmit mode). The mic PTT switch has no effect. When the connection to the radio mic input is removed (at the radio end), the Control RCC still appears to key the PTT line (RX audio is muted at the Control end).

The control end cable is a store-bought MJ-88 adapter used per the RRC instructions. Brand new Control RRC, older unit at Radio end.

I'm at a loss as to explain this behavior. I have 4 other sets of RRC's all running perfectly on other radios in my network and I thought I knew what I was doing  ... until now.


General discussion / Re: iPhone Hot spot connection
« on: 2020-01-05, 18:28:32 »
Thanks Mitch, I got it to connect to the iPhone hotspot now, but it still won't connect to my radios. I'm trying to use an IC-706 remote head link through a pair of RRC's. I've done this remotely and successfully for years but now I'm trying to connect via a Verizon hot spot.

I'm pretty sure I have the port forwarding done correctly and I can see the radio RRC webserver fine from outside my LAN. I'm also certain of the serial settings since it works on everything else other than Verizon.

I use my Verizon hotspot for my FlexRadio remote connections as well as my Icom radios via their RS-BA1 software. They work perfectly.  I just can't get these RRC's to connect.

My Control RRC setup is what is confusing me I think. When I connect it via Verizon, I can't see the web server and the Microbit setup manager I connect to it wants to see a DNS server, netmask and server settings.

Can anyone help with the control RRC settings?

Thanks and 73,

General discussion / iPhone Hot spot connection
« on: 2019-12-22, 16:42:48 »
I've seen other posts on this subject here but I've not seen any meaningful replies.

I can connect to my home Wifi network, other Apple devices and even Android hot spots easily but I cannot connect to my iPhone hot spot. In fact, often, the SSID does not even appear in the scan list ... even when other devices are connected to the hot spot and working properly.

I'm beginning to think there is some incompatibility between the RRC-1258's WiFi adapter and Apple.

Does anyone have suggestions?


Thank you for your answer Mike. This link on the RR site seems to discuss jitter settings in CW mode where it discusses a  "CW Handler". I guess that really only means keying delay.

But I don't fully understand how keying delay would increase tolerance to jitter. A brief explanation would be appreciated.


I'm using an external keyer and have gone back to CW keying using my auxiliary RRC link via the RJ45 I/O connector. That's because my FlexRadio 6600/Maestro pair doesn't properly adjust for Internet delays (RTT) and jitter any more with their new SmartSDR v3.x software... I get messed up CW when using the Flex approach now.

Because I'm using an external keyer, I was wondering if the CW paddle RRC jitter corrections are still applied when using the IN0 (I/O connector pins 4&8) method of keying? Or must I use the RRC built in keyer to get that protection?

I'm operating from 800 miles away and have an average RTT of about 72mS. All seems to be working fine, but I'm wondering if I shouldn't just be using the built in keyer?


Thank you Mike. Just received my (self-powered) CT-17 and all is working fine now.

A null modem IS required for proper connection (at least for COM1).


Thank you for that hint Mike. I will try that.

Since the connector on the RemoteRig unit is female and the CI-V to serial adapters are expecting a typical male connection, would I also need a NULL modem or Null modem cable to connect?


I have my remote site linked for a remote control head operation with the IC-706 radio. Everything is working perfectly. Just like being there.

However, I would like to add a secondary and independent CI-V control link for CI-V CAT control of a separate IC-746PRO at the same site. At first blush, it would seem that I could use either unused COM port (COM1 or COM2) in a "serial server" mode. In other words, connect a CAT program to COM1 locally and a Serial to CI-V adapter to the COM1 port at the remote site to provide CAT control of the IC-746.

I have tried both COM1 and COM2 without any success. I am asserting CTS/RTS in case the adapter needs power from those leads.

Is this mode of operation using a Serial to CI-V adapter even possible? Any hints or suggestions would be appreciated.



I operate the IC-706 over a NC to Chicago Internet link. Two different cable ISPs (Comcast and Time-Warner). 

I found that most of my packet dropouts were in my LAN. I had a lot of luck solving this problem by giving my radio data PREMIUM priority in the router and changing all other traffic to STANDARD. Do this in the router QoS settings, especially at the radio end. I was getting dropouts even with nearly zero traffic on the LAN.

I still get an occasional dropout, probably ISP related, and buffer settings helped a bit there too.

Incidentally, I had the same problem with my "MAGIC JACK" VoIP connection. QoS settings fixed that too.


Pages: [1] 2