Skip to main content

Step 2: set up COM port links & test

To make this easy, do the following setup OFF the VPN, with both PC's actually on the same LAN, and test with the VPN after verifying the setup.

Due to the nature of serial ports, only one application/device can be connected to a COM port, which is why COM port linked pairs must be used to link applications together. Com0Com makes virtual COM ports in pairs. Both ports are "open" for applications to connect to, and when data is sent into one port, Com0Com shifts it to the other linked port and broadcasts it.

Using Com0Com, make at least 1 virtual COM port pair on both PC's. In this example, the server PC will have the pair set as COM2 & COM3, the radio PC will have COM4 & COM5.

Run this command in a CMD window on the server PC (alternatively , make a batch file for each command, to make setup easy.)

> com2tcp-rfc2217 COM3 41000

This will link COM3 to a telnet session on TCP port 41000.

Run this command on the radio PC:

> com2tcp-rfc2217 \\.\COM4 192.168.xxx.xxx 41000

Where 192.168.xxx.xxx is the LAN Ip address of the server PC. This will link the radio PC's COM4 port to the server PC's COM3 port via TCP. Open a PuTTY window on both PC's, and link them to the open COM port on the PC (COM2 and COM5). Anything you type into one PuTTy session should appear in the other. If you can do that, the link is working.

Note that this method uses unsecured telnet to transfer data, which is why a VPN is used instead of exposing port 41000 to the wider internet via the home router.

Connect the radio laptop back to the VPN on the hotspot like in Step 1 to verify the link still works over the internet.

Next, plug the radio into the radio PC. In this example, the radio uses a REAL serial port, and is connected to COM1 (a virtual serial port might have a higher number like COM6, for example).

Set up the Telnet COM link using the two commands as above, but on the radio PC, open up a seperate CMD window and run the following command: > hub4com \\.\COM1 \\.\COM5

The chain of connections now looks like so:

radio COM <--> Virtual COM5 <--> Virtual COM4 <--> Telnet via TCP <--> Virtual COM3 <--> Virtual COM2 <--> RCForb Server

Note that only one application is connected to each COM port. no other applications may use any COM ports in this chain while running the radio. To interface the radio with another application on the RCForb client end (like N1MM Logger+ for logging), see this document about connecting N1MM to the client software (TL;DR: enable the virtual serial port in the RCForb client settings, connect N1MM to that virtual port and configure N1MM for an Elecraft K3 radio.)
If another application on the LOCAL machines (the servr and radio PC's, NOT the client!) needs to acess the radio, more virtual COM pairs must be made, and Hub4COM used to add those pair to the chain. To add another open port to the Radio PC, first make another virtual pair (COM6 & COM7), then modify the hub4com command described above like so:

> hub4com \\.\COM1 \\.\COM5 \\.\COM6

This will link COM6 into the 'hub' that links the radio into the virtual port chain, so now the chain looks like this:

radio <-[hub]-> COM5 <--> COM4 <--> Telnet <--> COM3 <--> COM2 <--> RCForb
                   |-> COM6 <--> COM7 (open)

Which allows another application on the radio PC to acess the radio. On the Server PC, TWO more sets of virtual ports (COM8 & COM9, and COM10 & COM11) are required, as the port COM2 normally used by the server will instead be used by hub4com. Change the RCforb server to connect to COM9 instead of COM2, and Run hub4com on the server PC:

> hub4com \\.\COM2 \\.\COM8 \\.\COM10

The chain now resembles:

radio <-[hub]-> COM5 <--> COM4 <--> Telnet <--> COM3 <--> COM2 <-[hub]-> COM8 <--> COM9 <--> Server
                                                                                                                              |-> COM10 <--> COM11 (open)

Back to top