I have had a Wires-X Node at my QTH since November 2015. I use it to provide Wires-X access for our 2 meter repeater. It uses an HRI-200 (the only way at the time), a FTM-100DR, and a Windows PC for the software. The FTM-100 runs medium power, as I am 39 miles from the repeater site. I have had the Yaesu cooling fan installed for probably at least 6 years. A 7 element yagi in my garage rafters helps.

In May 2024, I stood up an XLX reflector using a cloud server. I also added a transcoding server on a Raspberry-Pi. I bridged the XLX module B to Wires-X at my shack, with a MMDVM hotspot and a FTM-400DR PDN node.

It all worked, but there was about a 4 second delay for the XLX traffic to finally get to the repeater. Based on info from K9EQ, I understood that PDN nodes use TCP protocol and has to go through a Yaesu server in Japan. I thought maybe this was a big part of the delay in my system, so I got the idea to get another HRI-200, with the hope it might decrease the lag time.

A big problem with that idea, is that on a typical home LAN, an ISP gives you a DHCP IP address, and your internal router supplies IP addresses for your local network. An HRI-200 requires certain ports to be open, so there would be no way to differentiate two HRI-200s.

There were a few online resources that talked about certain VPN providers who allow port forwarding, but there was a cost involved, though not outlandish. But since I already had a cloud server providing me the XLX reflector, why not utilize that?

I started to research rolling your own VPN, and most mentioned were OpenVPN and Wireguard. The latter sounded easiest, and was known for it’s simplicity and speed. So I went with Wireguard. Installation was relatively easy. When I was working on this step, it was weeks before I had all the other parts and pieces ready, but I did get public and private keys setup using a Windows client, which I would be using for Wires-X.

My shack Windows 10 PC is used for various other things, rig control, logbook, digital modes, and a Wires-X PDN node, etc. So I needed another PC for this new Wires-X node/HRI-200 setup. I had recently purchased two mini-pc’s with Windows 11, which were relatively inexpensive and use a minimum amount of power. So I got another one for this new Wires-X node. I loaded and configured the Wireguard client, and all seem to be working, at least basic access to the internet. Now I needed a registration # for my node.

I have two other nodes, one from 2015 and the other PDN from 2019. It shouldn’t have been a big deal to register another one. Yaesu is weird about this, you must register with a new ID and login. So I followed the procedure to get sent the link for the registration for a new Node/Room ID. I filled out the form and submitted it, and from what I remember, all went OK. It seems like I got a success message, but I did not get an email afterwards. I could not remember if I got one after the previous registrations, and it seems like I recalled the process being a bit flaky. So I figured I’d need to wait a few days, especially since it was a Friday USA Eastern time.

But I waited and waited. I should have known something was not right. I sent an email to John Kruk, then the Yaesu USA Wires-X email address. I did not hear back from them. Then I finally decided something was wrong and I should resubmit, which I did. This time I received a confirmation email that it was received.

This time it was Thursday evening, mid-day Friday in Japan. I figured I wouldn’t hear anything until mid-next week. But opening my email on Saturday morning, the registration complete email was in my mailbox. Thank you Yaesu for getting this done so quickly.

I went to work getting things Wires-X setup on the new PC. A few hiccups as I am trying to use a Bluetooth keyboard, though I hate the touchpad, so I have a USB Wireless mouse, and both were being difficult. After I got those working properly, time to try the Wires-X thru the VPN. I had already added rules to allow the Wires-X ports through the cloud server firewall. So I finally tried the Wires-X port check. The only port that worked was Wires-X control. This is pretty common, so I started looking at firewall, etc.

This led to few hours of web searching and trying things. My networking knowledge is limited, but I am pretty good at web searching and filtering out noise from valuable info. I ended up downloading Wireshark. This is a pretty powerful tool, but requires some knowledge to get anything out of it. I was able to capture some communication whilst running the Wires-X port check. From what I could tell, my PC was communicating with the Yaesu server. I saw nothing that looked like a failure. So I was stumped without some more research.

Eventually I realized that Wireguard communicates via a certain port. I had already allowed that port through the firewall, but how would communication get to the Wires-X ports? I had read dozens of websites, and it seemed like they never covered my situation. Many were scenarios that were different enough that they would not help.

Then I came across this: https://serverfault.com/questions/1067746/port-forwarding-with-wireguard

This line was the key line:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 56000 -j DNAT --to-destination 10.66.66.2

I changed tcp to udp, changed the port to the first wires-x port, 46100, changed the ip address to the one wireguard gives me, and repeated it for the other 5 wires- x ports. Voila! It worked. My Wires-X port check now passed. I can’t imagine ever finding this if I had to rely on buying and reading books about tcpip!

Now it was just a matter of completing the Wires-X settings for the correct frequency of my hotspot and the wires-x room. And everything was working.

Now the not so great news – it did not help the lag time keying up the repeater that much. Maybe 1/2, 3/4 of a second faster than the PDN node. Still 3+ second delay. How normal that is, I am not sure. It’s not ideal, but usable for providing increased digital capabilities for this system. If I did not also have the repeaters node located at my QTH, and just needed to provide a bridge, it would probably be better. The VPN seems to add almost as much lag as PDN mode did. But I would not have known unless I tried.

I had attempted to put in a ticket to Brandmeister. They indicate in multiple places on their various websites that they offer bridging capability to Wires-X and XLX. After 3+ months, not sure if I will ever hear back from them. Other systems have had this done, but someone told me they were not sure if they still offered this service (despite what their website says).

I tested D-Star and DMR again, and all seem to work into the XLX927 and be transcoding properly. I will keep this configuration and monitor it over the upcoming weeks for any issues.

The additional benefit is that I have freed up my PDN node for use without disrupting the YSF to Wires-X bridge.

Here is a block diagram showing the basic components of the system.