WXScheduler is a program that allows WiRES-X nodes to automatically switch to a Room or Node at a predetermined date and time. It’s written in Python, but we now have a Windows installer which does not require the installation of Python. 

The installer is available here. The Github repository is here.

If you experience problems, please use the Fusion Technical Net to report them (preferred), via Github issues, or email.

Update 14 Feb 2024: Users that have OneDrive on their computer but have disabled it report problems running the program. The program looks for the OneDrive folder. If it exists, it installs the configuration file there. If it doesn’t exist, it uses the local directory on the C: drive.

More information:

WXScheduler was written by Bill, W9LBR. It has been packaged as an .exe with a Windows installer by Chris K9EQ. In addition, the following changes have been made.
– 2023-01-10 2.5.1 Removed radioID error messages from the log (there were too many of them and they didn’t add value)
Added an icon for the program
– 2023-02-12 2.6.1a Clicking the ‘x’ button on the scheduler menu no longer causes the program to crash

The installer creates a WXScheduler directory under the WIRESXA directory where the Yaesu software lives. It installs the following files:
– Readme.txt, this text
– WXScheduler.pyw, the Python source file
– WXScheduler.ico, the icon file
– WXScheduler.exe, the executable
– Uninstal.exe, the program to uninstall WXScheduler

The uninstaller removes these files and the directory. It does not remove the .json
configuration file one directory above.

The packaged version displays the GUI without a shell console. If you want the console as well,
rename the file to *.py instead of *.pyw. You’ll then need to open up a shell (command prompt)
and launch with a 32-bit Python interpreter as in: “C:\python32 WXSheduler.py”.
The source code is available at https://github.com/K9EQ/WXScheduler.
Also see HamOperator.com for more information about WXScheduler.

Drop in on the Fusion Technical Net to discuss the program. The net is held Monday at 7:30 PM US Central time in Room or YSF 21493.

Bill has done a fantastic job with this program. I hope that my minor additions make it easier for
a wider audience to benefit from it.

Note that the WXScheduler is either stored in the \OneDrive\Documents\WIRESXA folder, if it exists, or in the user’s Documents\WIRESXA folder. So if you can’t find it in your WIRESXA folder, you may have OneDrive so look there.

Bill’s original text file, WXScheduler.txt, follows:

WXscheduler.pyw is a Python 3 program that automates certain aspects of Wires-X Room/Node connections according
to a user defined schedule.

Schedulable operations:
– Settings->Call settings
– Unlimited TOT
– TOT(TimeOut Timer)
– Settings->General settings
– Round QSO Room connection
– Accept calls while in Round QSO Rooms
– Back to Round QSO after disconnect
– Return to Room
– Room ID
– Connect <Node/Room>
– Disconnect
– Restart Wires-X App

Immediate operation:
– Force Disconnect

Scheduler Settings Example (Automatically reconnects after network glitch):

– MnWis Fusion Net every Monday 7:30pm US/Central time

– First segment (net usually lasts at least 60 minutes)
Occurs: [every]
Week Day: [Mon]
Hour: [19]
Minute: [28]
Event’s Timezone: [US/Central]
Description: [start MnWis Fusion Net]
[x] RoundQSO Room connection
[ ] Accept calls while in Round QSO Rooms
[x] Back to Round QSO after disconnect
[x] Return to Room
Room ID: [MNWIS]
[x] Unlimited TOT
TOT(TimeOut Timer): [60]
Command: [Disconnect]
Argument: [ ]

– Second segment (net running over 60 minutes – switch to LocFav-ROOM on timeout)
Occurs: [every]
Week Day: [Mon]
Hour: [20]
Minute: [30]
Event’s Timezone: [US/Central]
Description: [after MnWis Fusion Net]
[x] RoundQSO Room connection
[x] Accept calls while in Round QSO Rooms
[x] Back to Round QSO after disconnect
[x] Return to Room
Room ID: [LocFav-ROOM]
[ ] Unlimited TOT
TOT(TimeOut Timer): [10]
Command: [none]
Argument: [ ]

NOTE #1: WXscheduler.pyw MUST BE RUN ON THE SAME WINDOWS PC and under the SAME USER ID as
the Wires-X PC application.

NOTE #2: When the Windows screen is LOCKED, this prevents WXscheduler’s scheduled keyboard/mouse
automation from occuring. Suggest: [Settings->System->Power&Sleep->Screen turn off after NEVER]

WXscheduler v2.5 updates:
– Schedule settings now require a Timezone parameter.
– Compensation for Daylight Savings Time is now automatic on a per timezone basis
– Load Python Timezone package using Windows Command Prompt:
pip install pytz
– WXscheduler.cfg is now more portable and user editable
– User’s HOME path is now resolved at run time and no longer saved in WXscheduler.cfg
– JSON data fields are now saved in pretty mode
– When WXscheduler-v2.5 detects an existing WXscheduler.cfg without timezone data fields,
the user will be prompted to set their local timezone value and all existing events will
be updated with the local timezone value.
– WXscheduler’s main window:
– Scheduled events are displayed in chronological order
– When the main window is moved, its new position is remembered. And all sub-windows
will be opened in the same position. This replaces PySimpleGUI’s default of centering
window within the display.
– [Add Event] and [Delete Event] buttons have been replaced with the [Scheduler] button that
when clicked provides a new window with buttons: [New] [Delete] [Update] [Cancel]

WXscheduler v2.4 updates:
– Additional exception debug information
– Changed main window title from “Wires-X Scheduler” to “WXscheduler (v…)”

WXscheduler v2.3 update:
At startup determines whether Microsoft OneDrive is active or not and locates
the Documents/WIRESXA and user/Desktop folders accordingly.

WXscheduler v2.2 updates:
At startup verifies:
– Wires-X.exe is accessable at its standard location
– /Users/????/Documents/WIRESXA folder is accessable (where WXscheduler.cfg is stored)

WXscheduler v2.1 updates:
Better displays exception information
Shows expected WIRESXA pathname to last heard data file

WXscheduler v2.0 update adds:
Display Last Heard information that the Wires-X application updates once a minute.
If available, Lat/Lon displayed as 6-character Grid Square.

Wxscheduler v1.3 updates:
Last Heard information now correctly displays the newer Yaesu models
(i.e. FT5-D, FTM-200, and FTM-500)
Desktop\Wires-X_Last_Heard.html contains hypertext encoded callsigns
that perform a QRZ.com callsign lookup.

Prerequisites (versions below are what was tested on):

Windows PC (win7 and higher)
Wires-x App (Ver-1.550)
Python 3 (32-bit) because Wires-X App uses the win32 UI
site-packages: PySimpleGUI, pywinauto, pytz

Installing Python:

Recommend going to https://www.python.org/downloads/windows/
to find a Python release that matches Windows on your PC.

After installing Python, use a CMD window to load site-packages:
– pip install pywinauto PySimpleGui pytz

Installing WXscheduler.pyw:

Copy WXscheduler.pyw to your Desktop

Double click on the WXscheduler.pyw icon to launch the program.

Hint: To see any startup or run time issues:
– Open a CMD window
– Copy WXscheduler.pyw WXscheduler.py
– WXscheduler.py

Enjoy,

Bill
w9lbr@arrl.net

If you want to set up an HRI-200 on Starlink, AT&T, or use you phone as a hotspot, there’s a problem. You need to open incoming ports and that can’t be done in many cases. The answer is to use a VPN to tunnel past your ISP to the raw Internet. One solution for some carriers is to use the PDN mode which does not require incoming ports to be open. But that may still not work.

The other problem is we’re running out of IPv4 space. New ISPs, such as Starlink, don’t have a lot of IPv4 addresses. IPv6 solves this problem plus many others. Thus it’s no problem for each ISP subscriber to have thousands of unique IPv6 addresses. Unfortunately the WiRES-X software DOES NOT support IPv4. At all. IPv6 will become more and more dominant and this will just become a bigger problem.

If you set up a PDN (no HRI-200), a commercial VPN will work well. With a VPN, your IPv4 traffic will be sent in an IPv6 tunnel. At both ends, your node and the Internet, IPv4 addresses will be used. This works because PDN does not require any incoming ports to be open. It may be that Starlink provides this service automatically. Don’t know.

If you use an HRI-200 then YOU NEED to open an incoming port. Most every commercial VPN does not permit assigning specific ports for incoming traffic. This is because they will share a single IPv4 address between dozens of subscribers. A couple of VPN providers do permit this. I have used Golden Frog’s VyprVPN in the past for this purpose. VyprVPN is a “high end” VPN service and will cost you quite a bit more than free or low-cost VPNs ($60/yr). You’ll need to turn off the NAT firewall so make sure your exposed computer is well protected! This will give you complete, unfiltered access to the Internet – something you can’t get with your ISP!

See https://www.vyprvpn.com/

Many people have reported Fusion repeater lock-ups that required the repeater to be shut down (power removed) and rebooted. I’ve had repeater lock happen as well with an HRI-200 directly connected to the DR2X. In this particular case I believe the event was triggered by sending a number of commands from the radio (such as the GM mode) which resulted in a race condition within the firmware.

I have previously observed that invalid data (I.e., with a lot of bit errors or badly formed packets from a hotspot) can also cause the lock-up. My assumption is that this is a problem of not validating inputs to a function prior to executing the function. The invalid data is not handled correctly and causes one of the lock-up faults I mention below to occur.

I have observed that data is more likely to be invalid if there is a lot of noise on the signal. Also a major source of problems are badly behaving hot spots that inject all sorts of crap into the data stream. There’s no control over these devices and it just gets worse as there is more work being done converting from one thing to another thing, etc.

Communications software is EXTREMELY HARD to write and much of what I see out there is poorly documented (which leads to bad code) and poorly tested.

Reflectors such as YSF or FCS are pretty dumb when they relay signals. They look for an incoming packet from one of the connected hotspots and just send that same packet out to all the other hotspots (including bridges to WiRES-X). Garbage in, garbage out. To address this I have modified the YSF reflector software to be very aggressive at dropping packets with CRC errors, invalid data in fields, and most importantly invalid FICH headers. The FICH header is extremely important for everything to work right. (You can look up FICH headers in the System Fusion documentation published by Yaesu.) This modified software is running on MNWis, Princeton Kentucky, MVARC (Idaho) and America Link. It has dramatically reduced the number of problems with WiRES-X problems.

So what is a “lock-up”. A lock-up occurs when the processor looses track of what it was doing and either halts or ends up executing invalid code. In either case it is no longer processing the code it was intended to run. Events that cause the processor to, using a technical term, go out to out to lunch can result of errors in the software that cause it to happen, corrupted memory, invalid states in a state machine, incorrectly handled race conditions, or a really nasty thing called priority inversion (where a high priority task which is pre-empting use of the CPU is waiting for a low priority task to complete, which can’t complete because, well, it’s not high priority.)

How to solve the problem?
First of all, the repeater firmware should never crash. Since it is very hard (but not impossible) to write code with no bugs, most continuously operating real-time systems will incorporate a “watch dog timer”. It is the purpose of this timer to detect when the “wheels have fallen off the processor” and perform a reset.

Since we can’t modify the repeater’s software, there are some actions we can take.

First would be to prevent bad data from getting into the system. A careful examination of the logs possibly combined with audio recordings could be helpful.

A quick fix might be to install a timer on the power supply such that the repeater’s power is removed for a short time once or several times a day.

I have a technical concept for a generic lock-up detector that would reboot the repeater in the event of a lock-up without the need to make any modifications. Not sure if I’ll work on this because I don’t know how much interest there would be. This solution would also work with non-Yaesu repeaters.

One further note. I made an observation that this problem was more likely to occur on 2 meters than on 440. Why? My theory is that there is a lot more interaction with the environment on 2 meters. Computer networks, small power supplies, computers, almost everything digital generally creates a lot more noise on 2 meters than it does on 440 MHz. I observed a situation where mixing products were occurring on a 2 meter repeater in a noisy environment. This repeater would lock up regularly. My theory was that the mixing products contained a lot of noise along with the C4FM signal causing a high number of bit errors and thus crashing the repeater. This was observed on a DR1X.

If you are struggling with this problem, I suggest you contact Juan at Yaesu Customer Service with your details. Provide Juan with as much information as you can.

I use VyprVPN from GoldenFrog. It is necessary to turn of NAT for your account. That means that each VPN connection is a raw connection straight to the Internet. YOU HAVE NO PROTECTION OTHER THAN WHAT YOU PROVIDE!!! (The same company will rent you a VPN that you can host on your own cloud provider where you can control port forwarding – but I suspect this is well beyond most folks.)

What’s the difference between using an HRI-200 and directly connecting to the radio?

1. It is the only option for connecting a repeater to WiRES-X.
2. It uses UDP communications sent directly to the Room. So network communications are very efficient.
PDN uses TCP instead of UDP. (Why use UDP? UDP is simple. If anything gets lost, it is dropped. Good for real-time communications. If a packet is missed with TCP, it will keep retrying up to a limit which is not good for real-time. VoIP, VPN’s, Netflix, etc. all use UDP.)

The PDN TCP packets (non-HRI-200) are sent to a server in Japan. This server converts the packets to UDP and then sends them to the selected room in the same way the HRI-200 does. So by using the HRI-200 you bypass a drip to Japan and a potentially problematic conversion from TCP to UDP and back to TCP for the return trip to your station.

Yaesu uses the TCP approach to get around forwarding of ports. The WiRES-X PDN software establishes a TCP connection with the Yaesu server. It’s through that connection stations can contact you even though you don’t have an open port. With the HRI-200, stations just get your IP address and send you packets directly. This is why PDN cannot efficiently host a room – all room traffic would have to go to Japan for the conversion process.

In a previous post (2016) I described what the HRI-200 does. Why it is the way it is is somewhat historical from the history of WiRES, WiRES-II, and now WiRES-X. Obviously an Ethernet port on the back with an embedded processor to run things would be a better way to go. I can only guess that the ROI is simply not there for Yaesu. They do, after all, have to make a profit.

One further note. It’s probably a good thing non-Yaesu equipment doesn’t connect to WiRES-X. The biggest problem in bridging hotspots (YSF, FCS, etc.) to WiRES-X is that the hotspots are bad neighbors. They generate bad packets, do crazy things, and can really trash a network. As a room operator we have no control over who tries to connect, so at least the Yaesu equipment has gone through compatibility testing. Believe me, very little testing is done on hotspot software.

MNWis (21493) bridges to YSF (21493) via a YSF Reflector where I have extensively modified the code to drop bad packets, control information, and all manner of things that shouldn’t see there way into the WiRES-X node. I had to do this because we were constantly having hotspots connect and mess everything up. It got very, very tiring working with the (mostly new) hotspot owners to fix their problems. I mean the conversations were endless and constant! So I just dropped anything that looked bad in the YSF Reflector software and the problems went away as well as a few hotspots who could no longer connect or talk to people.

System engineering is critical. We need Yaesu to play the roll of system engineering to keep all the Fusion products working with each other. It’s so nice that all the Fusion equipment basically works the same way and does the same thing all of the time! 

BTW, you can bring your questions/comments to the MNWis Fusion Technical Net held Monday’s at 7:30 PM Central in the above mentioned locations.

When a WiRES-X node keeps going online then offline, this type of problem is almost always the result of a networking issue. A networking problem will occur and will wack out the HRI-200 software. Once the software has been wacked out, it will continue to cycle in and out of whatever room it is connected to. Restarting the WiRES-X software usually solves the problem.

Router problems:
1. Turn off UPnP. It should never be used!!!!!!
2. Turn off all quality of service features like those to improve Xbox gaming or VoIP functions. (Yes I know we’re using VoIP so you’d think it would help.)
3. In fact turn off everything you don’t have to have.
4. Some routers are total crap and need to be rebooted every few weeks.
5. You’re not using Wi-Fi are you? Wired is always better than wireless – we should know! Drop-outs in Wi-Fi can cause this issue.

ISP problems:
1. Something as simple as the ISP dropping your connection for a few minutes in the middle of the night when they’re doing maintenance.
2. The ISP just doing a bad job of getting packets to you during prime evening Netflix viewing.
3. The ISP switching your IP address. (I think CenturyLink just does this for the fun of it.)

Computer:
1. Make sure Win10 doesn’t put the USB interface to the HRI-200 to sleep. It really, really likes to do this. Just going to the obvious place in the control panel to turn this feature off doesn’t really turn it off. See the documents on running Win 7/10 24x7x365 remotely in the Fusion Help section at HamOperator.com.
2. Make sure the computer isn’t crap. Cheap computers may not have quite the reliable communication interfaces that we need.
3. Banish all RFI and ground loops. Make sure RF is not getting into the USB interface to the HRI-200. This can cause message errors and really screw things up.
4. Make sure you computer actually has enough power to run the HRI-200 reliably. Get one of those USB power thingies and make sure you have a solid 5VDC under load.

Over the air:
1. Bad data on the WiRES-X network can mess things up. This happens mostly with hotspots that are bridged into the WiRES-X room. On MNWis and a few other networks we’ve banished this problem by banishing FCS and running YSF server software that banishes bad data from hotspots. So if you have this problem in one room, say AmericaLink and not others, there may be nothing you can do.
2. Yaesu radios that are running really old firmware or have not had the firmware updated correctly (I.e., “I did the main CPU but I’ll get around to the DSP later.”)

Side note:
The port check should not be relied upon to definitely prove it’s working or not working. The test is not exactly the same as actually communicating with the Yaesu list servers and the room server. So it can lie to you with false positives and false negatives.

You may also experience a similar problem if the Yaesu list servers are not able to keep up with the demand or if maintenance is being done. (When they do maintenance in the wee hours of the morning, that’s right in the middle of the day for us.)

And keep in mind the MNWis Fusion Technical Net held in MNWis WiRES-X and YSF # 21,493 Monday nights at 7:30 PM Central.

If you’re having problems with USB problems when using WiRES-X with or without other programs, read on.

The WiRES-X software is pretty good at identifying the HRI-200 vs. connecting directly to the radio. Windows, however, is very bad at managing USB ports. The WiRES-X software makes two USB connections: One as a virtual COM port and the other as a sound device. Windows is also very bad at managing sound devices.

Virtual COM ports can be identified by the port number (a real pain as it is always changing – see below) or by identifying the hardware via the manufacturer and product number that is burned into the USB device. Generally software that does not provide an option to specify the COM port (as with the HRI-200) is using the hardware identification to establish the association.

When Windows sees a USB device it will enumerate it and create a driver for it. If you move it to another port it will, for reasons we can only guess at, create another driver. It will keep making new drivers as long as you have USB ports and USB devices left. Why, we can only guess. Periodically it may be necessary to go through a clean out all of these “drivers” that Windows keeps making and saving until the end of time. You can do this from the command line or from within Device Manager.

I have found WiRES-X to play nicely with other devices. For example I have no problem running hotspots, Ham Operator Deluxe, WSJT-X, etc. on the same computer that is running WiRES-X.

You may find it beneficial to use a USB 2.0 vs. 3.0 port. Why? USB limits the number of connections that can made per USB controller. Keep in mind that several of the ports on you computer may use the same controller. Also, each USB device may use more than one connection. As I recall sound devices generally use two connections: One for the audio and one for control. A USB 2.0 controller supports 255 connections. How do I know? I actually ran up against this limit using a couple of 16 port USB hubs. USB 3.0, while faster, does not permit as many connections. I don’t remember the exact number as it has been some time, but the number SIX sticks in my brain. As you might imagine, it is very easy to burn up six connections. Also keep in mind that the USB controller may be servicing hardware that is internal to the computer. It all depends on how the computer was designed. Top end computers will generally have a higher controller to port ratio. Bottom line: you may want to use USB 2.0 if you have been using USB 3.0.

Perhaps try something like this:
1. Blow away the WiRES-X and any conflicting software. Make sure everything is unplugged from USB.
2. Blow away all of the USB drivers. Just uninstall them. Don’t worry, the files to recompile a driver are still on the computer. [Device Manager with admin. Enable option to view all devices. Delete drivers under COM ports. Delete drivers under sound devices (except for hardware built into your computer.)]
3. Install the WiRES-X software. Allow it to associate with the USB devices it needs by plugging in the HRI-200, etc. If you’re not using an HRI-200, you may find it beneficial to use an external USB audio device for WiRES-X. If you can use USB 2.0 ports.
4. With WiRES-X happy running, install the other software. Plug in the necessary USB devices so it can similarly make the association. At this point everybody should be happy with both programs running just fine.
5. Write down which device was plugged into which USB port. In the future, always use the same USB port for the devices. We don’t want Windows creating more drivers.

Good luck solving the USB problems!

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

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()

Python Program

Bill, W9LBR, developed a Python program that runs on the WiRES-X computer. The software has been updated as of 12-Feb-2024. See more here.

This is from his description:

WXscheduler.pyw is a Python 3 program that automates certain aspects of
Wires-X Room/Node connections according to a userrdefined schedule.
To that end WXscheduler.pyw must be run on the same Windows PC
that hosts the Wires-X application controlling either an HRI-200 or
a USB connected radio that supports PDN operation.

Schedulable operations:
– Connect
– Disconnect
– SetUnlimitedTOT
– SetTimeoutTOT
– Restart Wires-X App

Manual operation: Button that causes a Force Disconnect

Bonus operation: Displays Last Heard information that the Wires-X app
updates once a minute. Converting Lat/Lon into Grid Square if available.

A zip file containing instructions and the Python program is available at WXScheduler.

Update History

2 June 2023 v1.3 updates: – Last Heard now displays FT5-D, FTM-200, and FTM-500 correctly – Desktop\Wires-X_Last_Heard.html now generated to be viewed with PC browser

12 Feb 2022 updates: – Corrected grid square rendering of GPS coordinates as displayed in the Last Heard frame – version (v1.2) now displayed in main window title

5 Feb 2022 minor updates: – Fixed Last Heard display of recently manufactured FT70-D radios – WXscheduler.txt is now in DOS format, making it easier to read with Notepad 2022 version of WXscheduler.pyw – A scheduled event now performs multiple actions – Added File->Settings->Call settings actions – Fixed issue when Wires-X App is minimized – Fixed issue when Wires-X Settings window left open