YSF WiRES-X Unintended Node Switching

A problem exits with YSF/MMDVM hotspots bridging to WiRES-X rooms. Here’s what happens.

A user has a hotspot and accesses it using a Fusion HT. They use the WiRES-X control mode to change the hotspot to different YSF Reflectors. Let’s say the user wants to access MNWis (Room #21,493):

  • They enter the number of the YSF Reflector, “US MNWis 21493”, which is 37,624. The hotspot switches to US MNWis 21493 which is bridged to WiRES-X Room # 21,493.
  • The user leaves their radio in the WiRES-X control mode. They hear stations, but when they talk, nobody answers and nobody is talking.

Here’s what happened: When they keyed up to transmit, their radio sent a command to switch to Room #37,624. The Wires-X node that was previously connected to #21,493 now connects to #37,624 which belongs to a very nice gentleman in France.

How does this happen?

The Fusion transmitted data includes callsign fields CSD1, CSD2, and others. We’re interested in CSD1. This 10-byte field contains two items: The room number of the connection and; The TxID or DP-ID of the radio. A typical CSD1 looks like 21493F0yxh where 21493 is the room number and F0yxh is the DP-ID. The ‘21493’ in this field will cause a Wires-X node to switch to that room. 

When the radio IS NOT in Wires-X control mode, the CSD1 field will be: ‘*****F0yxh’ and no switch will be made.

Bottom line:

DON’T USE WiRES-X control mode to talk through a hotspot or MMDVM!

Workarounds and fixes: (Updated 23-Aug-2019)

Node operators who are experiencing this problem should use the WiRES-X block feature to prevent the node from switching to the room that has the YSF reflector number.

For example: Assume that our node connects to MNWis, Room # 21,493. Our node also provides bridging to “YSF MNWis 21493” which is # 37,624.

  • In the View->Node-Info(N) window press “Add”.
  • In the “Input ID” dialog box enter the YSF reflector number. In our example this is “37624”.
  • Press “OK” then “Close”.
  • When a station using the YSF bridge still has WiRES-X control mode enabled accesses the node, the command to switch rooms will be rejected by the WiRES-X software. The software will indicate a rejected attempt to switch rooms.

As an alternative, set the node so that connection changes are not allowed.

  • File->Settings->Call Settings->Uncheck “Round Room Connection”.
  • Un check “Accept calls while in Round Room QSO.
  • Check “Return to Room”
  • Fill in the WiRES-X room number. Example: 21493.

YSF server side solutions:

I maintain a version of YSF Reflector that has filters to prevent hotspots causing problems with WiRES-X nodes. My first step is to drop all packets that contain an incorrect WiREX-X room number. Eventually I plan to replace the first 5 bytes of CSD1 with ‘*****’. This last step is difficult to do because it requires the reflector to decode the data, modify it, then recompute the CRC. This also involves working with the interleaving and forward error correction. It is obviously easier to just drop the packets, but that may confuse people on the YSF side since nobody on the WiRES-X side will hear them.

If you are interested in running the enhanced YSF Reflector software that will fix this problem at some point, please contact me privately.

73,

Chris, K9EQ




WiRES-X Automation

Yaesu does not provide a mechanism that allows the WiRES-X software to be controlled by another program, i.e., having another program switch to a certain Room when a net starts.

Windows does, however, permit another program to send events to a program. Each window, menu item, and dialog in a Windows program has a unique identifier. It is possible to use these identifiers to send “message” to the WiRES-X software.

The WiRES-X Automation Project’s purpose is to bring together people who are interested in developing this technology and sharing their results.

To get things going, here are two mechanisms for automating WiRES-X:

1. AutoIT: http://www.autoitscript.com
2. Python – an excellent programming language found at python.org

Dave, N9TOW, provided the following information:

Packages I have installed on my WiresX system.
C:\Users\WiresX>pip list
comtypes (1.1.3)
pip (9.0.1)
pypiwin32 (220)
pywinauto (0.6.3)
setuptools (28.8.0)
six (1.10.0)
https://github.com/pywinauto/pywinauto

To install

pip install -U pywinauto

Script that executes changing channels on WiresX app

import time
from pywinauto import Application
 app = Application().connect(path=”C:\Program Files (x86)\YAESUMUSEN\WIRES-X\wires-X.exe”)
app.WiresX.menu_select(“Connect(C)->Connect To(T)”)
time.sleep(1.5)
app.InputID.Edit.set_edit_text(“21493”)
time.sleep(.5)
app.InputID.OK.click()
time.sleep(4)
dialogs = app.windows()
##app.Dialog.CloseButton.click()




Mobile WiRES-X Nodes

FT2D, FTM-100, and FTM-400 Can Now Be Used As Mobile Node

Yaesu has now released software and firmware that enables the FT2D, FTM-100 and FTM-400 to be used as a WiRES-X mobile node. You’ll need to update the radio’s firmware and install WiRES-X software version 1.510 from HRI-200 and radio downloads at Yaesu.com. Instructions are available at the download site.

A document listing the current  firmware and software for Fusion rados is on the Fusion Help page here.

Stop by for the MNWis Monday night Fusion Technical Net for more information.