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.

Update: WXScheduler 2.7.5 is available. The 2.7.5 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. 

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.

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/

The other day I was working my Fusion repeater with my FT70D. Since I was “DX” I had the HT on high power. Although it looked like I was getting into the repeater just fine, I couldn’t enter the WiRES-X control mode. However when I switched to low power I WAS able to control the repeater.

What gives? Why could I control the repeater (node) on high power, but not on low power?

Back at the house where my repeater is located, the problem still existed. I could use the WiRES-X control mode on low power but not on high power. Since I’m within 10 meters of the repeater, signal strength couldn’t be an issue.

Looking at the output spectrum of the FT70 revealed the problem. On high power there were some spurs that shouldn’t have been there. The spurs were much weaker on low power. Other radios didn’t exhibit the spurs. Click on the images to compare and see the details.

Photos show the waveform capture from an FT5 during a MNWis net. Note that they are not symmetrical around zero. The 2nd image has more detail and you can see that the waveforms are not symmetrical. The clipping sound is heard when the audio level hits the limits even though it is still not at 100%. Odd.

I don’t know why Yaesu doesn’t make this public, but they don’t. You can download version 1.44 of the IMRS LAN firmware. This solves some problems with LAN connections constantly dropping.

During the Monday Night Fusion Technical Net, a comment was made that it was possible to use an FT5D to receive C4FM on 29.250. This started a conversation about other HT’s as well. Thanks to W4IOD, AD0MI, N0PXT, and N0OQL, we now have the definitive answer for most of the Yaesu Fusion radios.

Background

Using 29.250 for C4FM has become popular as 10 meter conditions have improved significantly. The Yaesu FT-991(A) is the only radio that is capable of Tx and Rx on 10 meters as well as operating in Group Mode (GM). When the band is open, you may see or hear C4FM traffic on this frequency.

One way to check 10 meter band conditions is to tune AM down to the CB frequencies near 27.195 MHz. If you hear a lot of racket, then 10 is probably open.

The ‘A’ band must be used since the ‘B’ band on all radios cannot tune 10 meters.

Analysis

Note that none of these radios can transmit on 29.250. In addition if 29.250 works, then six meters will work as well.

The following radios cannot receive 29.250 MHz since they don’t tune down that low, bummer:

Mobile Radios: FTM-100, FTM-200, FTM-300, FTM-400, FTM-3200, FTM-3207, FTM-7250

HT’s: FT-70D

The following HT’s tune 29.250 and DECODE C4FM (show callsign and switch between DN/VW)* but do not provide audio:

FT-1D (US version), FT-2D, and maybe FT-3D

*Must be set to Rx DN or VW.

The following HT’s will receive C4FM on 29.250 but cannot engage GM. GM is handy for seeing the callsigns of stations that are beaconing.

FT-1D (Japan version) Interesting! Maybe the JP versions of other HT’s will do this as well.

The FT1D and FT2D can enter GM using the following process:

1. Enter 29.250 on the A side.
2. Enable both A and B if both sides are not enabled.
3. Switch to the B side.
4. Press the GM key.

The following HT’s can receive 29.250 and can enter GM. Note that they display the GM information but do not beacon:

FT-5D

Bottom line

The FT-5D has more C4FM capability since it allows reception wherever it tunes while other radios do not.

Some thoughts about Fusion, digital modes, and the future.

Fusion uses the lower layers of the P-25 architecture. Modulation, transport, framing, etc. The primary differences revolve around what’s in the packet. For example: The use of call signs instead of unit IDs. So Fusion shares most of P-25. FWIW, Fusion is also very similar to DMR. The primary difference is that it doesn’t use TDMA – jamming two separate channels into the space of one.

P-25, DMR, NXDN(Kenwood), IDAS (Icom), and Fusion use the same vocoder. D* uses a much older and obsolete vocoder.

Fusion and D* have been optimized, although differently, for Amateur Radio. DMR, NXDN, and IDAS have been optimized for commercial services, like taxi cabs. P-25 has been optimized for government services, like police departments.

Fusion was actually designed by Motorola in that period of time that Motorola owned Yaesu. This benefits Fusion since the vocoder and the signal processing firmware are pretty much the same as what Motorola uses in their radios. (Believe me, not all signal processing firmware is designed the same!) Thus, the performance of Fusion is pretty darn good. Add to that an additional layer for FEC provided by Yaesu’s modification to P-25, and the performance of Fusion is better than all the others. (D* is substantially worse than the other protocols.)

What we see from this is that most of the communication industry has evolved around the same technologies even though the systems are not directly compatible with one another. This is why it is so easy for a hotspot to translate between DMR, P-25, NXDN, IDAS, and Fusion. But is this the best we can do?

No. Digital performance could be much better. C4FM already blows away FM with superior range and capability, but it was intentionally limited – to work with FM/PSK transmitters and receivers like those used with FM.

FM is a non-linear system thus it does not transmit all the information it could in the available bandwidth. Linear systems, such as OFDM, can provide higher bit rates lower error rates, better resistance to fading and multipath, amongst other things. The problem is OFDM requires linear amplifiers and thus is not compatible with all the FM/PSK transmitter and receiver designs.

Personally, I’d like to see OFDM as an option for digital’s future.

But all digital systems could be made better by some enhancements at the repeater site. The use of multiple, diversity receivers incorporating very low-level discrimination could improve receiver sensitivity by as much as 10 dB. That means HT would perform almost as well as a mobile rig with no changes required of the user. Having multiple diversity receivers at various locations around a city could mean that a low power HT would work virtually anywhere in that city. Sadly, there doesn’t seem to be a market for doing such things. (This technology is well understood and used by your cell phone.)

One last note. Several attempts have been made to build multi-protocol radios incorporating DMR, Fusion, D*, FM, and others into a single unit. Should be simple, right? But we have yet to see such radios on the market. If we did, they wouldn’t do Fusion as well as Yaesu, or D* as well as Icom, or DMR as well as Motorola. Why? Protocols are damn hard to get right. They are even harder to get working really, really well where they take into account all the things that can go wrong with data transmission. (Hotspots try to do the conversion, but never work as well as going “native”.)

I would argue that the amateur community should focus on those systems designed for Amateur Radio. Ultimately those will be easier to use and better suited for the job. (Police departments and taxi cabs should not use Fusion!) A good user experience is critical if digital, any digital, is to become generally accepted.

One last note: Nothing prevents Icom from building a Fusion radio. Every last little detail about Fusion is public information, particularly since most of it comes from P-25 – for which Icom builds radios. The only proprietary aspects of Yaesu’s system are WiRES-X and IMRS.

Purchasing amateur radios that do digital help support the future of digital by encouraging companies to develop more and better digital features. Buying commercial Chinese radios just helps the Chinese economy.

DG-ID is like a CTCSS tone, but for digital. It filters out signals with different DGID’s as well as having the ability to do split DG-ID’s (like split CTCSS). DG-ID can be in a state of Rx & TX (DG-ID), Rx Only, Tx Only, and Split Rx & Tx (different DG-ID).

DG-ID servers as a means of selective signaling for access to a repeater or for a WiRES-X node. For the repeater it has a couple of different applications (IMRS and access purposes) while with WiRES-X it offers control of voice and control access.

DG-ID’s cannot be reused within the same configuration or network. For a repeater that means the DG-ID can only be in the LOCAL, RPT GROUP, or GROUP. There will be issues if in an IMRS network has anything with the same DG-ID.

DG-ID Repeater usage

LOCAL DG-ID: There are two factors:
1) The DG-ID it will not be sent down IMRS links and only allow access to the local repeater.
2) In an IMRS set-up, you will always hear the status beeps: One for end conversation; Two for link drop/end; and three for a repeater is not connecting with the DG-ID/IMRS group.

RPT GROUP DG-ID: This offers the ability for an IMRS link to be established in a one-way direction. The DG-ID used is the LOCAL DG-ID of the other repeater that you are calling. If users are using DG-ID Tx AND RX they will not hear beeps the confirmation beeps (see above).

Example of RPT GROUP usage:

San Diego Repeater – Local 1         Los Angeles Repeater – Local 2, RPT GROUP 1

San Diego users using DG-ID 1 stay on San Diego for usage; Los Angeles users use DG-ID 2 stay on Los Angeles for usage. Los Angeles users who use DG-ID 1 will establish a one-way link to San Diego and will communicate with one another until the IMRS TOT is reached. Once the link drops it is reestablished by someone using DG-ID 1 on the Los Angeles repeater group as San Diego cannot establish the link as it is not a RPT GROUP.

GROUP DG-ID: offers the ability for an IMRS link to be established in either direction by any of the repeaters that have it programmed into IMRS. If users are using DG-ID Tx AND Rx they will NOT hear the confirmation beeps.

Example of GROUP usage:

San Diego – Local 1, GROUP 10                 Los Angeles Repeater – Local 2, GROUP 10

San Diego users use DG-ID 1 only stay on San Diego for usage. Los Angeles users use DG-ID 2 only stay on Los Angeles for usage. San Diego or Los Angeles users that use DG-ID 10 will connect to one another via IMRS and stay connected till the IMRS TOT times out.

Overall example with LOCAL, RPT GROUP, and GROUP:

San Diego – LOCAL 1 – RPT GROUP (blank), GROUP 10

Los Angeles – LOCAL 2 – RPT GROUP 1 – GROUP 10

San Diego: DG-ID 1 talks locally, using DG-ID 10 talks between San Diego and Los Angeles

Los Angeles: DG-ID 2 talks locally, using DG-ID 10 talks between San Diego and Los Angeles. DG-ID 1 establishes a link between San Diego and Los Angeles.

WiRES-X & DG-ID Local

Using WiRES-X with a DG-ID, it is not recommended to use the LOCAL DG-ID if you have an IMRS setup with a DG-ID. Here’s why: WiRES-X will hear all the confirmation beeps from IMRS (argh!). Also WiRES-X will hear everyone but only talk locally since a LOCAL DG-ID is being used.

Example of WiRES-X and IMRS (with three repeaters in an IMRS Network)

• San Diego – LOCAL 1 – RPT GROUP (blank) – GROUP 10, 20, 99
• Los Angeles – LOCAL 2 – RPT GROUP 1, 3 – GROUP 10, 30, 99
• Chicago – LOCAL 3 – RPT GROUP (blank) – GROUP 20, 30, 99
• WiRES-X – DG-ID 99
• DG-ID 10 connects San Diego to Los Angeles
• DG-ID 20 connects San Diego to Chicago
• DG-ID 30 connects Los Angeles to Chicago
• DG-ID 99 connects all together along with WiRES-X

In this setting the users can do the following, per repeater, with the DG-ID’s.

San Diego:

• DG-ID 1 is local.
• DG-ID 10 establishes a link between San Diego and Los Angeles.
• DG-ID 20 establishes a link between Los Angeles and Chicago.
• DG-ID 99 establishes a link between San Diego, Los Angeles, Chicago and WiRES-X.

Los Angeles:

• DG-ID 2 is local.
• DG-ID 1 establishes a one-way link between Los Angeles and San Diego.
• DG-ID 3 establishes a one-way link between Los Angeles and Chicago.
• DG-ID 10 establishes a link between San Diego and Los Angeles.
• DG-ID 30 establishes a link between Los Angeles and Chicago.
• DG-ID 99 establishes a link between San Diego, Los Angeles, Chicago and WiRES-X.

Chicago:

• DG-ID 3 is local.
• DG-ID 20 establishes a link between San Diego and Chicago.
• DG-ID 30 establishes a link between Los Angeles and Chicago.
• DG-ID 99 establishes a link between San Diego, Los Angeles, Chicago, and WiRES-X

Once an IMRS link is established ALL the DG-ID’s in the repeater can be used to keep the link active. If in the San Diego example a link is established, then DG-ID’s 1, 10, 20, and 99 can all be used to keep the link alive. DG-ID that established the link is the only one that will be transmitted by San Diego.

If a link established by DG-ID 10 on the San Diego repeater, the repeater will Rx DG-ID’s 1, 10, 20, and 99 but will only transmit back DG-ID 10. Therefore, if you have DG-ID 99 set-up in your radio for Tx & Rx you will be able to talk down the link but you will not hear anything because the repeater is Tx DG-ID 10.

Information from N9UPC.