The HamOperator YSF Reflector is currently supporting MNWis, US Kentucky, and America-Link. A test reflector runs at US K9EQ.

A project has been going on at the HamOperator to improve the YSF Reflector software. Why do this?

The original software is very basic and offers very little capability and control. It also creates a HUGE problem when trying to bridge YSF hotspots to WiRES-X rooms because it just passes the data along with no filtering. That means whatever garbage gets sent to the reflector, it doesn’t even need to be Fusion, that same data is sent to every connection including the bridged WiRES-X node. When the WiRES-X node gets this data it can misbehave or crash. Hence a project to fix these problems.

And while we’re fixing problems, why not make it better by giving it more capabilities?

Current differences between the standard YSF Reflector software and the K9EQ version:

• Decodes all meta data including FICH and all data fields for every mode.
• Extensive logging allows selected logging of parameters needed to determine “what’s going on?”.
• Filters to drop packets if:
  • The FICH is invalid
  • The FICH does not pass sanity checks
  • Data Wide packets
  • Wires-X control packets
• Outputs a text file of connected nodes to simplify dashboards.
• Performance reporting
• Options can be changed in a *.ini file
• Ability to host multiple YSF Reflectors on a single server
• Internal documentation of the program (comments)
• Several builds are available:
  • Windows
  • Linux
  • Debian server (MNWis and US Kentucky are running in the “cloud”)

Future enhancements will include:

• Drop problematic WiRES-X packets with invalid room/node number in the CSD1 field
  • Future improvement: Edit the packets to remove the problematic information
• Ability to black list callsigns and IP addresses.
• Kerchunk filter to drop short key-ups
• Remote control and status reporting of the reflector via Fusion text messages
• Integrated dashboard removes need for php and greatly reduces CPU overhead and network bandwidth
• Programmed reporting of audio levels informing users if their mic level is too high or too low
• Integration with IMRS
• New, engineered and reviewed API to more tightly integrate hotspots with the reflector
• Ability to programmatically send messages
• Ability to programmatically edit data fields on the fly (i.e., change GPS data, call sign, etc.)
• Improve internal program documentation
• Complete program re-write in Python. This will provide the ultimate in portability

The reflector will not support non-Fusion communications such as DMR or D*. The reason for this is that non-Fusion systems do not include all of the data that Fusion provides. This would force the reflector to become the lowest common denominator resulting in technology and feature restrictions.

The intent is for our version of YSF Reflector to be open sourced. It will be developed and enhanced with feedback from the Fusion community. By using good engineering practices, our hope is to provide a high quality service that equals or exceeds the existing quality of the Fusion/WiRES-X system. This is an enhancement to WiRES-X, not a replacement.

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