Update: WXScheduler 2.9.0 is available. The 2.9.0 installer is here.

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. 

Description

WXScheduler is a program that allows your WiRES-X node to be connected to another Room or Node at a predetermined day of week, hour and minute in the specified timezone. If your browser balks downloading WXscheduler-v290-Install.exe and you cannot override the warning, then rename the xxxxx.crdownload file using File Explorer or CMD. NOTE: Recent Windows Security updates may rightly so quarantine WXscheduler-v290-Install.exe. Detecting it as a Trojan. Well that is correct only on the basis that it will install another EXE file You can override this by going into Windows Security –> Protection History and find the most recent “threat” and click the Restore link. Finally this especially occurs if you are using Windows’ OneDrive. Which I highly recommend that you do not use! WXscheduler is written in Python, converted into a Windows EXE, and delivered as an installable Windows application for Windows-7 or higher. Which means the User no longer has to install Python and library packages to run WXscheduler.pyw. Additional information about WXscheduler can be found in the installation folder: WXsched-info.txt WXsched-license.txt WXsched-Python.txt WXsched-updates.txt WXscheduler.pyw (source code) for those who still want to run it as Python program. All I ask is that you pass along any improvements to w9lbr@arrl.net for the benefit of the amateur radio community.

The 2.9.0 update changes:
-Address varying CPU speeds and their impact on the automation

-Fixes the problem when AccHistory.log contains garbage in a location string, causing a non recoverable exception.  Now the corrupt string is displayed in place of the 6 character GridSquare string.

The old 2.6.1 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.

Revision History:

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.

-2025-09-15 Address varying CPU speeds and their impact on the automation

Fixes the problem when AccHistory.log contains garbage in a location string, causing a non recoverable exception.  Now the corrupt string is displayed in place of the 6 character GridSquare string.

– 2023-02-12 2.6.1a Clicking the ‘x’ button on the scheduler menu no longer causes the program to crash

– 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

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.

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.

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

In this post we discuss how the operation of WiRES-X can be customized through the use of the Windows Registry.

People often ask which rooms to listen to. Over the years, I have developed my lists of favorites and I will share them with you. If you think your room or net should be added to the list, let me know.

Dave, W6DS, provides a history for some of the rooms on his HamRadio.Solutions website. To access the YSF histories  directly, click on the Network Digital Monitor link. The NDR uses YSF to acquire the audio and data. The rooms use a WiRES-X to YSF bridge so that these YSF reflectors carry the same traffic as their associated WiRES-X rooms. If you would like to have your room/reflector added to the NDR, contact Dave directly.

FusionTech 21493 WiRES-X YSF

This is naturally my favorite as I’m an original founder from all the way back in 2014. It was originally founded out of Minnesota and a lot of people do check in from the upper midwest. The geographical limits have been removed since WiRES-X provides a global community where a friend just down the street is just as close as a friend from the other side of the planet. It is not a terribly busy room so it’s a good place to let a node, repeater, or hotspot sit. We encourage those who are tuned in to apply the motto, “No call goes unanswered.” If you hear someone put out a call, please answer it even if it is just for a quick “hello.” You never know. You might have just met your next life-long friend.

The net encourages friendly conversations on subjects that are likely interesting to those listening. Technical discussions are encouraged.

Nets

Fusion Technical Net Monday 7:30 PM Central
South Dakota Net Thursday 7:30 PM Central

Website

HamOperator.com

Room audio history is FusionTech Audio History.

Texas-Nexus 21636 WiRES-X YSF

We have a lot of friends in Texas and a lot of them are on this network. The founders of Texas-Nexus got  their start when we were MNWis back in the day. They splintered off to form their own, highly successful, network. This is one of the most popular Rooms on WiRES-X. Stop in to enjoy a warm, friendly, Texas welcome!

Texas-SADRC 40324 WiRES-X and YSF

While we’re on the subject of Texas, here’s another really good group also headquartered out of San Antonio. The San Antonio Digital Radio Club. Also very popular.

Audio history is Texas SADRC.

The-DARC-Room 40012 Wires-X

Another “digital amateur radio club” with a rather clever name. This group is in Minnesota and was also part of MNWis way back in the day. A very friendly group who will be happy to tell you how great the weather is in Minnesota.  Note: They will always try to make it sound cold and miserable except when it’s hot and muggy. Their fiendish goal is to make it sound so terrible you won’t want to move there! And if from that description you get the impression that they’re a great bunch of people, they are!

Nets

AUS-Repeater-Net 24160 WiRES-X and YSF

There is a certain “You think that’s a big knife, THIS is a big knife” about Australian hams. A great sense of humor if you can understand what they’re saying and a welcoming sort of nature. Pete, VK5JP, is one of the many instigators behind this group. You’ll find him always eager to teach foreigners how to speak  “Aussie”.  Make a friend from down under and check out this room. They have a great net which occurs on North America’s Saturday, their Sunday. The time varies between 2:00 PM and 4:00 PM Pacific, depending on the time of year.

Nets

Australia Net Saturday (US) Time varies from 4:00 PM to 2:00 PM Pacific. Check the time zone for South Australia. The nets are 9:30 AM and  6:00? PM local.

CQ-Canada-VE1AO 40678 WiRES-X

The most popular English-speaking net in Canada. And you know Canadian’s. They’re always very friendly. Check them out and make some new Canadian friends.

America-KC-Wide 28054 WiRES-X YSF

This is THE most popular Room in all of WiRES-X and YSF. There is always a net going on, a conversation, or someone to answer your call.

Nets

https://www.kansascityroom-wide.com/nets/

Website

KansasCityRoom-wide.com

Audio history is KC Wide.

CALNET-Group 83196 WiRES-X YSF

I’m an active member of this group. They have repeaters covering a good of Los Angeles, Orange County, San Bernardino, and San Diego counties. A friendly technically-oriented bunch. They also operate one of the largest FM repeater networks in the state covering most of Southern California, San Francisco Bay Area and the California desert regions include Fresno, Bakersfield, and San Bernardino county. If you’re in Southern California, check them out. Give me a call, there’s a good chance I’ll be listening here, to their analog service, or on FusionTech.

Here’s where you can find them:

Website

SoCal Ham (LA Repeater) 21042 WiRES-X YSF

SoCal Ham operates a number of Fusion repeaters in and around Southern California. A current list of repeaters and other information can be found on their website.

Website

SoCalHam.com Link not currently working as of 5 Sept 2025

MVARC-Idaho  43210

This is a very friendly bunch of hams with a  network that covers from Boise to Idaho Falls and points beyond.

Website

MNWis has changed its name to FusionTech. Nothing else changes. The name was changed to better reflect the nature of the organization from Minnesota and Wisconsin midwest centric to global  covering interests in technology and Fusion in particular.

The network is still reachable at Room and YSF 21493. The Fusion Technical Net is the same and the people running it are the same.

The FusionTech network is part of the Bakken Amateur Radio Society (BARS). BARS was formed as a club of amateurs who worked at Medtronic. Since that time the relationship with Medtronic employees has become less connected and subsequently most members are not from Medtronic.

The founders of FusionTech are: Chuck, K0ORK; Pete, AD0MI; and Chris, K9EQ. The net started in 2014 and is the 2nd oldest net to be held using Fusion. (Milwaukee has the honor of being number one.)

It is well documented that the Yaesu DR-1X and DR-2X repeaters can lock up from time to time. When they lock up, they may:

• Not respond to any transmission or control function and
  • Transmit continuously or
  • Not transmit or
  • Transmit for the duration of the time-out timer, go off the air, key up and start all over again.
• The transmission may be digital “noise” or it may be a carrier

There is another form of lock-up in which an attached HRI-200 can be used to reset the repeater.

Why do they lock up?

We don’t know for sure why this happens as we don’t have access to the source code of the repeaters. But guesses can be made from knowing what the problem is, how microprocessor and their software works, and the common mistakes programmers make.

The firmware consists of a number of modules that do specific tasks. Data is sent to a module, the module may call other modules, and it returns with possible data. The input data may contain values that are out of range for the module. For example one value might be mode where 0=FM, 1=DN, 2=VW, and 3=VW. But what if the module receives a 4? It should just stop and return to the calling module with an error indication. Most likely the solution will be to ignore the request and stop processing. That’s what should happen. But a sloppy programmer may NOT VALIDATE INCOMING DATA and allow the ‘4’ to be processed where the results may be unpredictable since no code was written to handle this case. There is good evidence that Yaesu software and firmware DOES NOT VALIDATE INCOMING DATA resulting in an UNHANDLED EXCEPTION.

There are other types of invalid data which should not be processed. The Fusion digital data might have uncorrected errors in it, thus it’s impossible to know what the correct values are. A field of data that is sent may be longer than it should be. This problem is commonly known as a BUFFER OVERFLOW. There is some evidence to support that a buffer overflow is occurring. Since the receiving buffer must be limited in size, too much data may cause the firmware to overwrite values that are past the end of the buffer. These may be critical values that are needed for the correct operation of the repeater.

The repeaters use a real-time operating system. An RTOS is event driven and will perform a function when an event occurs such as a timeout, a signal received, a clock tick, a button push, etc. There may be cases where two events are related such that one must occur before the other. For example, one event may lock access to a hardware resource and the other event clears it. If the order were reversed the hardware resource would never be accessible and the actions of the hardware may be unpredictable or stop altogether. This is known as a RACE CONDITION. It is very likely that this error exists in the firmware and that it may be combined with another firmware error. For example, a BUFFER OVERLOW may result in a RACE CONDITION which the engineers did not see.

As a result of the above firmware problems, it is not easily predictable what the microcontroller may do next. Some systems include a Watchdog Timer. This is a hardware timer that is set for a certain period of time, perhaps 10 seconds. The microcontroller’s firmware periodically resets the WDT if it is running properly. If the WDT times out due to some sort of problem, the hardware resents the controller. We have some evidence that Yaesu has implemented a WDT in the DR-2X repeater. It is therefore apparent that the WDT has been turned off, set to a crazy long value, or that the modules that reset the timer are still running even though nothing else is.

A SOFT LOCKUP may occur if a RACE CONDITION removes access to the receiver and/or transmitter. While the repeater won’t receive or transmit, the other functions are working. This means the repeater can be reset without needing to cycle the power. (There is no reset button like on your PC.)

The Evidence

The most difficult problems to fix are the ones that almost never happen. These lock-up problems are in the category of infrequent but very high risk (a drive to the mountain to reset the repeater. With remotely-controlled repeaters, a lock-up is an unacceptable risk. After all, other repeaters don’t seem to have this problem.

(There is a repeater bug involving the CWID on FM, that is not being discussed here.)

It is very likely that these problems occur while a user is transmitting in the digital mode. We’ve not been able to observe a repeater suddenly locking up without some sort of input to key the transmitter. (However, since we haven’t seen it doesn’t mean it doesn’t happen.)

My observations are that this is more likely to happen when a user is transmitting a WiRES-X command such as changing rooms.

It appears to be more likely if the user has a weak signal into the repeater.

It is more likely to happen on two meter repeaters than on 70 cm repeater.

Notice that each of these conditions have the word “likely”. That’s because there are unknown additional parameters which may be involved. For example, a weak digital signal will cause more digital errors. A particular error may be involved in creating the problem.

It may also be the result of a transmission starting at the exact time the microcontroller is performing a specific function, thus resulting in a RACE CONDITION. This problem is virtually impossible to observe.

It was previously mentioned that using a two meter repeater makes this problem more likely. The issue here is the amount of noise on the two meter band. All of our electronics and networks add noise to the environment. This noise level is much stronger on two meters than on UHF. There is also some evidence that the ethernet cables can deliver RF to the ethernet devices and these devices may act like a mixer. All of this causes more noise making stations effectively noisier. The end result is more bit errors and buffer overflows.

What to do?

The correct answer to this section is to have Yaesu fix their bugs in the microcontroller – but don’t hold your breath. This could be a very costly to find the cause since it is difficult to reproduce. Another problem is that there are no Fusion repeaters in Japan. (Only D* is allowed – that’s along story.) Thus the Japanese engineers working on this project would have no way to experience the problem. (The repeaters can only be operated in a shielded room – thus no noise.) I’ve solved problems like this before and the first step is to make the problem happen more often while monitoring the CPU. Keep trying things until the probability of a lockup increases, then try doing more of that. The business model for this is that spending a bunch of money on this is not likely to sell more radios. I also believe that Yaesu farms out certain tasks, like firmware development, to outside suppliers. In any case there is no guarantee that the firmware engineers use radios outside of the lab.

If the issue is the result of a SOFT LOCKUP, sending a command to the repeater via an attached HRI-200 may resolve the issue. This may only require switching to the repeater page in the WiRES-X software an applying the repeater’s settings with the same value.

If it is a HARD LOCKUP, the only solution is to reset the microcontroller. I.e., turn the power off then on again. Ouch!

• The simplest way to address this problem is to take a timer plug, set it to turn off during a time the repeater is not likely to be in use, then turn it on again as quickly as possible. You may have to put up with a continuous carrier for a good part of 24 hours, but at least you won’t have to drive to the hill.
• If there is Internet connectivity at the repeater site, you might be able to use a Wi-Fi enabled power switch to cycle power remotely. (I do this using my home automation.) Unfortunately this requires the action of a control operator.
• Since it is unlikely Yaesu will fix this problem, the ultimate solution is to have a circuit that will automatically reset a lockup condition. Thus we have the De-lockup Project (below).

De-lockup Project

Attached to this post is a project that will automatically reset a locked-up repeater. The concept was originated by Mike, W0IH. Mike informs me that he does not have the bandwidth to provide support for this project in the long term. It is likely we will be refining the project as time goes on. One thing I’d like to do is eliminate the need for a cheap SWR meter. You can obtain a zip file of the project from here.

The project uses an inexpensive Arduino Uno microcontroller board. In addition there is a relay board plus a few extra components. The circuit does not require you to even take the cover off of your repeater and therefore will maintain the warrantee. You can learn more about Arduino at The Arduino home page.

These photographs of the Tokyo 2024 Ham Faire are courtesy of Masa, JA1WLQ. Also thanks to W4IOD for providing the “relay”!

These photos are courtesy W4IOD. They are presented in four parts, each of which is a PDF. Click the links below for each part.

http://hamoperator.com/files/Hamvention Photos Part 1.pdf

http://hamoperator.com/files/Hamvention Photos Part 2.pdf

http://hamoperator.com/files/Hamvention Photos Part 3.pdf

http://hamoperator.com/files/Hamvention Photos Part 4.pdf

You’re probably aware that turning your Yaesu Fusion radio on whilst holding down one or more buttons causes it to do different things. There’s a self-test on the FT1. The FTM-200 can display supply voltage. The FTM-500 can do cross-band repeat. Right now we have some handy Fusion cheats that work on the FTM-200, FTM-300, and FTM-500 with more to come.

K9EQ_BB_FusionCheats

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/