Flexradio says the Maestro manufacturing has been held up for several months due to a shortage of parts caused by Covid-19. This unit was snatched up from the QRZ.com online swapmeet and it’s a beauty.
Shown above in it’s travelling mode. All it needs is a wifi connection. It has an internal battery that will run quite a few hours. Portable operation gets a lot simpler with this device. A mic or a paddle is all it needs to get on the air. Back at the shack it looks equally at home with a paddle and a microphone.
The Maestro is an option that is not essential because all operations can be done with a pc or a laptop alone but this is for those of us who still like knobs. The knobs on the Maestro have an expensive-radio feel. It’s a pleasure to operate with this option.
Open two slices on the 6600 and two instances of WSJT-X. Configure the settings so one slice goes to one instance and the other slice goes to the other instance. In operation one would click the Enable Tx button to establish a qso on one of the WSJT-X instances. A user could also click the Enable Tx button on the other instance to establish a second qso. Both instances would take turns in using the transmitter and the two qso’s would be completed in due time.
How it actually works:
Clicking on Enable Tx on the first instance causes a third slice to open for no reason and no transmission is made. Clicking the Enable Tx again to stop the transmission leaves the third slice still open. Clicking Enable Tx again closes the third slice and starts a normal transmission. In other words instead of initiating a normal qso the Enable Tx button toggles a third receiver slice for no reason. This behavior is repeatable each time. The second instance of WSJT-X doesn’t seem to have any issues, only the first instance.
Progress: A workaround was tested using the MultiFlex feature and a second computer. Setting up a second computer with Smartlink and WSJT-X then dialling into the same Flex 6600 works fine. Only problem is it requires a second pc and it requires a second Internet connection and bandwidth usage. And it’s not the way the Flex is supposed to work.
Idea for next troubleshooting effort: In WSJT-X configuration make the radio type Kenwood TS2000 instead of Flex6xxx. This is a suggestion obtained from a YouTube video.
Using Kenwood is not a solution because that radio type does not have a TCP option. No way to connect to the FlexRadio.
Followup June 21, 2020: It’s working now, full SO2R mode, by connecting to the 6600 with two separate computers. This is using a feature called MultiFlex where two connections can be made to the 6600 simultaneously. The single transmitter is first come first serve but as soon as the first connection is done with a qso the second connection has the transmitter available for a qso. Using two computers and the accompanying bandwidth is not what was hoped for but this satisfies the SO2R definition. Now for a contest to test it under stress. Meanwhile the hunt for a single computer solution will continue in the background.
Mark this day, February 29, 2020, which is leap day. A new FlexRadio 6600 transceiver was ordered today and that’s a big leap. The advertising seems to emphasize both FT8 and remote operation. What could be better?
Actually this is a picture of the 6600M meaning it has the Maestro front panel builtin. A 6600 and a Maestro were ordered separately so it can be used remotely. It’s a big step breaking out of the Icom juggernaut. The plan is to see which radio performs better and sell the other. Beating an IC-7610 will be a big challenge.
The 6600 arrives! The Maestro is on back order. The 6600 is even more beautiful in person. A perfect project for the Covid lockdown using a pc and SmartSDR while waiting for the backordered Maestro. Now to see it perform. First tests are to feed a signal to WSJT-X and count FT8 decodes. The antenna here at home is hookup wire with a tuner which is not equivalent to the 43′ vertical at the remote base but it’s good for testing. Evaluating a few passes shows fewer decodes and poorer SNR just as expected. It’s not a real test until both radios are on the same antenna but it does demonstrate how easy it is to get up and running on FT8. The challenge begins.
Testing at home before the journey to the remote site.
Installed at the remote site and operating, squeezed between a battery and the 7610.
The installation went 99 per cent smoothly with only one issue remaining. That one remaining issue turned into a 5 week nightmare to troubleshoot. Issue: The 6600 cannot be reached over Comcast Xfinity internet service. It cannot be accessed over the Internet if the Internet provider at the client end is Comcast Xfinity. Access works when the client is on a AT&T mobile hotspot and the same with the client on an iphone in the wifi hotspot mode. Flex support says Xfinity has implemented a new security feature called Advanced Security and that might be the issue. An attempt is being made now to work on this issue, so far with little luck and much frustration.
All indications point to Xfinity being the problem so a new modem was ordered which is XFi capable. The existing modem is too old to have that new Xfinity security feature. Modem is scheduled to arrive this week.
Followups: Arriss model TG1682G modem purchased from eBay arrives. The new ebay modem worked great for Internet access but it did not provide the feature needed which is XFi. Working with Comcast technicians over the phone it was finally disclosed that the XFi feature is only available on Comcast supplied modems. A Comcast modem was ordered, arrived, and activated. XFi works now and Advanced Security was turned on and off. No joy. Same results. The 6600 cannot be reached. A Flex community forum post said someone had the identical problem. He said the old modem, an Arriss 862G, worked but his new one didn’t. An Arriss 862G was immediately ordered from ebay and it’s arrival is being anxiously awaited, as of April 24. Meanwhile, Flex still has an open ticket but it is on hold til all the gyrations are exhausted on this end. The AT&T Hotspot still works and is being utilized as a temporary alternative.
Followup May 10, 2020. The Arriss 862G produced identical results. No joy.
A vpn (virtual private network) was set up as a test on Comcast Xfinity and it works (ExpressVPN). Go figure. That is a second work around along with the AT&T mobile hotspot but not a solution. Dan Quigley, the manager of support at Flexradio became involved. He looked at traceroutes and theorizes where there is a problem in the network. He is comparing good traceroutes to bad traceroutes. Zayo is the provider at the destination and all connections work once they get to Zayo (except clients with Comcast). They also work if they go through the last couple of Comcast routers, the highest of which has the host name or dns of “910fifteenth”. That is the address of the “Internet Hotel” in downtown Denver, which is a peer location to handoff Internet service to multiple providers in the region. The router directly above that is “1601milehigh”. That is the address of the small Comcast building in the parking lot of Mile High Stadium. Dan thinks that might be where some packet filtering is going on. Contacting Comcast Advanced Repair was fruitless and frustrating. Very much no joy and no progress.
Meanwhile a network probe was installed at the Strasburg end to see if any packets are reaching the Flex. They ARE. The Wireshark sniffer shows an oversized TCP packet is being generated by the Flex but only with Comcast at the client end. The size of the packet is 1514 bytes and the MTU (maximum transmission unit) in the remote router is 1492. An error shows up on wireshark from the remote router says the packet should be fragmented. So the packets are not getting blocked or filtered by Comcast apparently. Why is the Flex not fragmenting packets and why is it only when we are using Comcast. The VPN also uses Comcast and it causes no problem. Why? This information has been forwarded to Dan Quigley at Flex and his ideas are being anxiously awaited. No response from Flex in three days. (Or ever)
Followup: Success! We figured the problem out on our own after “putting in the work” as they say. It is solved by a simple parameter change on our own equipment. A connection from a client using Comcast with no VPN works perfectly now. Audio is not choppy. Full panafall display works just as it should. CW is smooth. All is good. The simple and free change? Reducing MTU on the client router from 1500 to 1478. That’s it. Ready the long and tedious explanation?
Changing the MTU causes the pc to send a SYN packet with a MSS (maximum segment size) specification of 1438. By the rules of the Internet the Flex is therefore obligated to send no packet with a payload bigger than 1438 bytes. The Flex adds on the header overhead of 54 bytes, which can’t be reduced, for a total of 1492. Bingo. The MTU of the remote router is 1492. That number is prescribed because the Internet service uses the protocol of PPPoE which is limited to 1492. Here is the key to the original failure which requires a more detailed explanation.
The Flex was generating packets that were 1514 in length and the remote router was correctly dropping them and sending back an error message. Unfortunately Flex has ICMP turned off which means it was never getting those error messages. The Flex would retry the oversized packet several times and give up. A connection request always timed out and failed. Why did other Internet carriers work? The answer lies in the MTU of those networks. Just by luck the MTU’s deep in their networks were always 1478 or smaller. The client PC always performs a Path MTU Discovery as part of beginning a connection for the purpose of discovering the smallest MTU deep in the network. This detail was researched from a Cisco white paper. The PC uses that number in a SYN packet telling the far end host how big the host’s payload can be. At that point the host, the Flex, would generate packets no bigger than 1492 and therefore would not overflow the remote router. Connection successful.
How was this solution figured out? It has apparently not been written about in the Flex community forum based on multiple searches producing nothing. Comcast was no help in network troubleshooting. Flex’s only response has been to direct us to the wrong culprit, the network. Certainly Flex has added to the problem by having ICMP turned off which caused it to not even receive the error messages. If it had received the errors it possibly could have adjusted the packet size on the fly and fixed the problem without intervention. But that’s just speculation. No doubt Flex has a good reason to have ICMP turned off. Here is one good explanation which also includes an easy way to turn it back on if one had shell access. https://www.thegeekstuff.com/2010/07/how-to-disable-ping-replies-in-linux/
The big puzzle was why the Flex was sending packets that were too large. How did the Flex determine the size of those packets? A little digging provided the answer: MSS or maximum segment size. MSS is the payload size. By the rules the host can vary the size of a packet by changing the size of the payload as long as it’s not bigger than the MSS. The host cannot exceed the MSS. A header with a fixed size is wrapped around that payload. Next logical question is how is MSS set? A little more digging provided the answer: A client PC runs Path MTU Discovery and sends a SYN packet to the remote host which includes the MSS calculated from that Discovery. Consider this. The Comcast network could be so good that all their routers have the maximum MTU. Therefore the PC could be sending a SYN packet with a MSS that is ok for Comcast but too big for the network at the remote site. At that point it was easy to use Wireshark to show what the actual MSS was in the SYN packets. Indeed it was too large. Next question is how could the MSS be reduced? The answer lies in the fact that Path MTU Discovery looks at all the MTU’s in all the routers along the path including the router at each end. It then uses the smallest MTU found to calculate MSS. Aha. Maybe if the router at the client end had the smallest MTU the Path Discovery would calculate a small MSS. Changing the MTU on the router at the client end was tried. The MTU was manually set to a number that caused the MSS to be small enough not to cause an error when the Flex generated it’s reply. That MTU number is 1478. MSS is calculated by the machine to be 1438. The fixed header is 54 bytes which is wrapped around the payload of 1438 bytes for a total of 1492. Joy. That is the MTU of the remote router and it is happy. Problem solved.
Sidebar: Why did some networks work and not others? The Internet service at the remote site is provided by a wireless ISP which uses a protocol of PPPoE. PPPoE and ADSL both add 8 bytes of overhead to the packet headers which reduces the MTU the to customer by 8 bytes. The customer only gets to use 1492 instead of what is standard for most Internet which is 1500. That is most likely why the connection to the Flex also failed when we tested it on Century Link. Century Link uses ADSL which also limits the MTU to 1492. As for why it works on VPN the answer probably is in the MTU of one of the routers used along the way by the VPN. Same possibility with the AT&T Mobile Hotspot. Some hop has a small MTU, which results in a smaller MSS, which results in the Flex sending smaller packets, which results in a good connection.
Trying to help others from suffering this is the post made to the Flex Community Forum:
Can’t connect to Flex using Smartlink over Comcast but works ok with other providers?
The post included a very short synopsis and solution in the hopes of helping some one out there.
Followup May 30, 2020: A new Evenroute IQ Router replaced the client side router and improved throughput. Evenroute calls what it does fixing “buffer bloat”.
Changed out the old Linksys E2500 router today for an upgraded Linksys EA6350. Two problems are addressed. First the E2500 has the lowest lan-to-wan throughput of any Linksys router, per tomshardware.com. The EA6350 is much better. Second, out of all the Linksys routers the E2500 is one of only a few that are susceptible to the new vpnfilter malware, per https://www.symantec.com/blogs/threat-intelligence/vpnfilter-iot-malware. The E2500 has blocked some web sites even when using the I.P. address which is a good hint that it has the malware.
Win4…Suite by VA2FSQ supports the following radios for remote base operation:
See your radio on the list? With one of these radios remote base operation is snap. Put a PC with Windows Pro at the site of the radio, install Win4…Suite, and access it from anywhere in the world over the Internet using Remote Desktop Connection. Notes on this blog and elsewhere show the details of how easy it is to do it. Use a home station as a remote base when away from home or build a remote base away from covenants and noise that can be reached from home. There are many methods to enable a remote base but the Win4…Suite system is proven and inexpensive. https://va2fsq.com/ No affiliation, just a fan.
RS-BA1 Version 1.96 consists of two parts. One is the back connection to the radio and the other is the user interface showing the control panel of the radio. The first is called Icom Remote Utility and the second is RS-BA1 Remote Control. They appear as two separate icons on the pc desktop. The Utility has to be up and running in order to start the Remote Control. Once it’s installed it’s just a matter of clicking on Connect.
To begin the installation load the software on your pc and open the Utility and click Setup Wizard.
The IC-7610 has a server built in so click the upper left, (A radio with Server function). When the Setup for a Remote PC window appears click Next. In the next window, Server Information, enter the I.P. address of the IC-7610. We are using a router at the remote site with port forwarding so we enter the I.P. address of the router Internet connection followed by a colon and the port number we chose. For more port forwarding information see another post on this blog:
Once the I.P. address and port number is entered click Next. When the User ID and Password appear obtain this information from the IC-7610 Menus.
Click Connect and the following screen should appear:
Next click the tab Radio List and the IC-7610 should appear automatically. Click on the radio to highlight the line and click on Connect. A window with the information regarding the virtual com port will appear. Note this port for later. Click OK and the “<<Connected>>” message should appear.
Notice under Audio Device Speaker is the speaker in the display. To configure this in the Radio List window click Settings. To hear monitor audio click AF. This window should appear. Notice the Mute button is pressed by default. Click on Mute to unmute the audio. Monitor audio from the remote should be coming through the monitor speakers. Levels can be set by ear listening for the least distortion.
Part one is working, the back connection to the radio. All that is needed to see the control panel is to open the icon for the RS-BA1 Remote Control. Click Connect Set to enter radio parameters.
The com port is the virtual com port noted from the paragraph above. The radio frequency should now appear and clicking on buttons here should change settings on the IC-7610.
At this point an operator could use CW and SSB with no further software. In our installation we are running digital modes using Win4IcomSuite so we don’t need to use this control panel. We are running RS-BA1 for the ability to monitor audio remotely which we cannot do with Win4IcomSuite at this time.
This installation is using RS-BA1 version 1.96. It is much easier to configure than previous versions in my opinion.
Update: RS-BA1 is not being used these days since Win4IcomSuite was released.
Note that this is a very specific installation and probably won’t be identical to anybody else’s but maybe there will be some universal information imparted here. The PC’s at both ends are running Windows 10 build 1803.
Part 1 – Win4IcomSuite and WSJT-X
Part 2 – Remote Operation with Port Forwarding and Remote Desktop
Part3 – Audio for monitoring with RS-BA1
Part 1 – Win4IcomSuite and WSJT-X
At last, the very popular Suite by Tom Blahovici, VA2FSQ, has been released for Icom radios, Win4IcomSuite. Why is this a big deal? Win4IcomSuite has builtin com port sharing which gives us the ability to use more than one application with CAT. If we use Icom’s RS-BA1 third party apps are stopped from using CAT simultaneously.
Win4IcomSuite will be abbreviated WinSuite from here on. Installation took me two attempts but once I followed Tom’s official instructions to the letter it works flawlessly.
The first attempt became unstable after a few weeks and I set everything aside. The instability manifested itself in choppy audio ( short dropouts ), freezing of WSJT-X, and decoding stopping. Four things changed before I tried my successful second installation attempt so I don’t know for sure which change made the difference. First the router was replaced and upgraded. Second Tom came out with a new version of WinSuite. Third, Icom came out with a new version of the USB drivers. Fourth, OmniRig had not been used on the first attempt but was used on the second attempt. I suspect OmniRig was the change that made the difference.
With attempt No. 1 I couldn’t get OmniRig to work but I could get WSJT-X working without OmniRig so I settled for that. Tom sent me an email suggesting doing it that way would cause instability:
I Noticed you mention you were having issues with instability with WSJT….
On my website under documentation, 3rd party software, it shows that you should use Omni-Rig not hamlib. The issue is instability with HamLib.
Make sure you use the latest Omni-Rig definitions for the 7300 and 7610 which are IC7300DATA and IC7610DATA. These can be downloaded form the Omni-Rig site.
I didn’t understand Hamlib and OmniRig. Finally a sketch by John, KC0RF, helped my comprehension.
Hamlib is integrated within WSJT-X and provides definitions for many, many radios including the IC-7610. WSJT-X also provides a setting to bypass the Hamlib definitions in favor of OmniRig. OmniRig does the same thing as Hamlib but OmniRig’s definitions for the IC-7610 apparently are more stable. I found this to be true.
Following John’s sketch it seems the logical starting point would be to get the radio talking to WinSuite. Get WinSuite working with the IC-7610 over the USB without running 3rd party software ( WSJT-X ).
Referring to Tom’s instructions, prepare the IC-7610 by pressing the MENU button, then on the screen press SET>Connectors>CI-V and make the settings look like this:
On the next menu page set the CI-V USB baud rate to 115200. Notice there are two CI-V baud rate fields. Only change the one that says USB. Tom says:
“You should use 115200. That way you can use the scope too.”
Now start up WinSuite and go to settings if it doesn’t come up automatically. Tools>Settings…> Hardware & User Preferences>
In this menu the COM Port was added and the correct baud rate. The IC-7610 rate we just set is 115200 so that is what is used here. COM 3 is chosen after looking at Device Manager ports and choosing the first Silicon Labs port. Click Connect and the button changes to Disconnect if all is well. If so, click Save.
Upon clicking Save the radio panel window should appear.
Congratulations if this comes up. As a test, click on a band button and see if the radio changes bands. If an error message comes up instead of this screen try the other Silicon Labs port. This completes the first step which was to get WinSuite working with the IC-7610.
Referring to John’s sketch and to the WinSuite manual the next step is to configure virtual com connections. WinSuite recommends the application called com0com.
Arbitrarily COM14 will connect to WSJT-X and COM15 will connect to WinSuite.
Next step is to connect one end of the virtual com port cable to WinSuite. Go to Tools>Settings.. again. This time click the tab for 3rd Party SW/HW. In the Aux/CAT Port 1 fields enter COM15 and the baud rate, 38400. Click Connect. If all is well the button will change to Disconnect. Click Save.
Now bring up WSJT-X and go to settings (File>Settings>) and click the tab marked Radio.
OMNIRIG MUST BE INSTALLED AND CONFIGURED BEFORE CONTINUING OR NOTHING BELOW WILL WORK.
The setup for OmniRig will be inserted here. -Ed
Here is how WSJT-X should be configured.
IC-7610 is supported in WSJT-X release 1.9.0-rc3 and later. As of this writing we are running 1.9.1. Select OmniRig Rig 1 for radio. Other fields will be grayed out because they are for Hamlib which we have just ceased to be using when we entered OmniRig in the radio field.
Test this configuration by clicking on the Test CAT button. It should turn green indicating WSJT-X is working with the IC-7610 CAT simultaneously with WinSuite through OmniRig.
Mode Field: Set to None or Data/Pkt. At the end of every transmission wsjt sends a mode command to the radio. If this field is set to USB it will switch the radio out of Data mode into USB mode. The Mode command also changes the filter to the default which is F2. Manually change F2 on the radio to 3000 or 3600 and this will be the default wsjt switches to.
Old screensnap. Radio should be OmniRig Rig1-Ed.
Congratulations. CAT is working with WinSuite and with a 3rd party application at the same time. Although it sounds simple it’s really a big deal to have two applications using CAT at the same time and it’s thanks to WinSuite.
Click the Audio tab and set up the audio configuration. For this installation it is USB Audio CODEC.
Part 2 – Remote Operation
Next step is to access the station remotely. This involves setting up the router for port forwarding and setting up remote desktop connection. My port forwarding is discussed in an earlier post, https://w0qlremotebase.wordpress.com/2016/04/04/port-forwarding/
Next is remote desktop. In my experience the Microsoft application Remote Desktop Connection works the best. I have also tried RealVNC and Teamviewer. The biggest objection to the Microsoft application is that it is included only in the Windows Professional editions, not Windows Home. The others are free and work on any Windows version. Microsoft is integrated into Windows Pro and makes better use of Internet bandwidth. The screen paints more smoothly and has sharper resolution in my opinion.
In the remote PC which is connected by a USB cable directly to the IC-7610 open remote settings. On Windows 10 click on Start>Settings. In the Find A Setting field type in Remote and select Remote Desktop Settings. Slide the enable remote desktop button to on.
Next is the client side. This can be any pc running Windows and does not need to be Windows Pro. In fact other operating systems have apps for remote desktop such as the iOS free app Microsoft Remote Desktop for the iPad. It works but there isn’t much screen geography to get everything in. To make a connection from the client pc to the remote type in Remote Desktop Connection into the field by the start icon and select the Remote Desktop Connection desktop app.
Before entering the address take a look at the options by clicking the Show Options down arrow. Click the Display tab. Sliding the Small-Large slider will dictate how much of your home screen is occupied by the remote. I like to leave some room for local apps along one side at home but one can play with it to see.
Next click the Local Resources tab. Near the bottom uncheck the Printers and Clipboard boxes then click More… and uncheck every box.
Click OK, click General tab and click Save. Now we are ready to put in the computer address. Use the I.P. address of your router at the remote, the WAN or Internet address. The remote pc desktop pops up and can be operated just as if sitting in front of it.
Sidenote on pc’s: My remote site is solar powered meaning it runs on 12 volts DC. I could power a standard desktop tower pc through an inverter but that would be a huge hit to the power budget. I could also use a laptop with a car charger and run it at 12 volts without an inverter. Instead of either of these I chose a third option and that is one of the new Intel NUC computers which will run directly on 12 volts. I bought the NUC the same time as the IC-7610. It is a i3 processor, generation 7. It has run flawlessly on 12 volts and can be turned off and restarted remotely perfectly. If your site is commercially powered this would not be a concern.
The installation is really quite clean, simple, and straightforward once one has moved up the learning curve a bit. On my first attempt I was close but oh so far away. It has been stable for almost a week now with no glitches. Still not sure which of the changes contributed the most but as a whole it is working great and I’m making lots of contacts.
Thanks to Tom and John for all the help and hand holding.
Part 4 – RS-BA1
For a digital operation currently there is no easy way to monitor the audio at the client because the audio stays at the remote for processing. That’s where RS-BA1 comes in as a solution. It runs by itself using the ethernet jack on the IC-7610 (as opposed to the USB jack used up to this point) and provides monitor audio at the client over the Internet.
Update: Recent releases of Win4IcomSuite include audio support making RS-BA1 unneeded.
Sidenote: RS-BA1 runs flawlessly for CW and SSB with no third party apps needed. Many YouTube videos confirm this. The issue arises when we want to run digital modes because they are third party software and they want to use CAT control, too. When RS-BA1 starts up it takes control of the CAT channel and excludes any third party software, even port sharing applications. That’s why it was such a blessing when Win4IcomSuite became available. It does everthing RS-BA1 does, some things even better, plus it has built in port sharing for the CAT. However WinSuite currently doesn’t have monitor audio when using it remotely because the audio stays on the remote. Tom says he is working on a way to have audio at both locations and he anticipates a July, 2018 release. At that time using RS-BA1 should no longer be necessary. Meanwhile we need RS-BA1.
Installing and using RS-BA1 is discussed in another post:
Screensnaps using a pair of Lantronix UDS2100 as a serial tunnel for the LP-100A Wattmeter at the remote end and a PC on the client end running LP-VCP. Other models of Lantronix should would work similarly. Note, we are assuming I.P. settings are already successfully entered and all screens up to this point except Network are left at factory default.
Client end 192.168.1.151 Serial 1.
2. Client end Connection screen.
3. Remote end 192.168.1.74 Serial 1 screen. Again we are assuming I.P settings are previously completed and defaults have been taken up to here, other than Network screen.
4. Remote end Connection screen.
The serial tunnel comes up when the Lantronix UDS2100’s are power cycled. Flashing TX and RX lights indicate success.
Thanks to Lantronix Support for their excellent Online Product Tutorials, especially the Serial Tunneling Tutorial video which helped me figure out how to get these two units talking. Link: http://ltxfaq.custhelp.com/app/answers/detail/a_id/1119?_ga=2.257160971.1857314135.1522260527-1723113648.1521596445
Update: Since a computer had to be at the site to provide remote access for the radios, we ended up plugging the wattmeter into the computer instead of these Lantronix units. The units are not being used but there is no technical reason why they couldn’t be.
Many have asked for more detail about setting up the Microbit Remote Rig RRC1258MKIIS units. Jumpers inside must be configured and on the outside there are a lot of connectors to deal with. Here are some pictures of the setup used at our two remote bases. Use these pictures along with the Remote Rig manual to explain what is connected where.
The very first step is to install the jumpers. Notice the orientation carefully because the manual is confusing on this. The Ethernet connector is on the left.
Next to set up is the “control” end where the TS-480 front panel will be located. It’s very simple and clean with just a few cables. The Kenwood extension cable is used between the front panel and the front of “control” Remote Rig. That knob on the right controls CW sending speed. Also notice the mini-USB connector at the lower left hand side. That will be connected later for CAT control.
The back end of the “control” Remote Rig has only a 12 volt power cable and the Ethernet connection to the router.
Now we get into more of a mess on the “radio” end. This is the end of the setup where the transceiver and antennas reside. The backside is quite clean with only a 12 volt power cable and an Ethernet connection. It’s the front side that looks like spaghetti.
It’s still fairly possible to follow the cables in the picture below.
CAT control was not hooked up yet in the above pictures. In the two pictures below you can see both ends of the RS-232 cable connected to make CAT work. First it’s plugged into the transceiver’s RS-232 port on the right.
Remote Rig also provides independent data channels that can be used to control almost anything. One is being used here at the “radio” end for CAT control. Connect the other end of the cable to the correct RS-232 port on the Remote Rig. I chose to use Com 2. At the control end a cable will need to be added between the computer and the Remote Rig to complete the CAT circuit. The computer in this case is used only for CAT control and nothing to do with any remote control functions. No RS-232 connector on newer computers? No problem. At the “control” end the Remote Rig has a USB port and a USB cable can be used between the pc and the Remote Rig.
Make an end-to-end test in the shack and when everything is working to your satisfaction the “radio” setup can be moved to the remote site. Good luck.