Always test repeaters in FM! Your ear can determine a lot of things. On digital, the range goes down and people that get into the repeater fine don’t notice it.

About 90% of the time when people complain about bursty noise, it’s the antenna system. If you’re running a duplexer and there IS ANY kind of bad connection, that bad connection will act like a diode. You get the diode effect whenever two dissimilar metals are in contact! What often happens is that as antennas are blown about they develop bad connections between sections. Really good repeater antennas have everything welded, don’t use a bunch of different metals (like solder, brass, and copper), and pretty much don’t bend in the wind. (And they cost $600 – $1,200.)

So see if you still have the problem into a dummy load. This is basic troubleshooting. If not, it’s your antenna system.

Keep in mind these bad connections can be anywhere. It can be caused by coax, coax connectors, or you may have a bad filter/duplexer. In this last case, the dummy load comes in handy again by testing with it placed at the output of the duplexer instead of the output of the transmitter.

More power makes this worse. Sometimes you’ll have some arcing at 100 watts and none at 25.

When I last had this problem, it took me months to solve it. I had gone through everything in the rack. Bonded all the metal together. Checked and verified all coax cables, duplexer, etc. Tried different antennas. It was still there.

I finally ended up figuring out how to DF the source of the noise. The antenna was on the roof of this big building that was full of bolts holding things together. I fixed a Verizon antenna that had a loose N connector and aming bolts (really Verizon?). That wasn’t it. I went around tightning down everything I could. About 100 bolts later, the noise went away.

So the point is this can also be caused by a nearby antenna, the tower, etc. Had this problem on one repeater that was on its own tower. We moved the antenna to the broadcast tower (and much closer to the broadcast antennas) and the problem went away.

You will also find that the problems at 2 meters are much, much worse than at UHF. Because of the proliferation of computers and networks, two meters has just plain gotten real noisy. In the incident on the roof of the building, we couldn’t even operate a 2 meter repeater because of all the interactions with the hundreds of miles of CAT cable and thousands of computers and network devices. Unless you are truely miles away from civilization, my preference is to run a repeater on UHF.

This is from Martin, GW3XJQ

“I must have spent years tracking down the ‘rusty bolt effect’ causing intermittent ‘crackling audio’, so annoying and would disappear for weeks and then return for no apparent reason. But of course, there is always a reason and always a solution to a problem.

“I bonded everything in sight and to ground with copper tape and rods, heavy conductor and thought it was fixed, until one day it came back! This was on a UHF FM repeater and the effect can be demonstrated by simply scratching a screwdriver blade against any metal associated with the repeater, even when I resolved the problem. As you say Chris, electrical and RF connections must be perfect and using only top quality connectors, cables and testing for continuity and insulation resistance using professional test equipment.

“The only effective solution in the end, was to opt for separate aerials for transmit and receive frequencies and with vertical separation on the tower. With a duplex system and one aerial, the noise would always return. It was all down to the fact that the building housing the repeater was constructed using steel reinforced concrete and which was deteriorating with the effects of time and weather and ‘blowing’ of some concrete panels. It was impossible to electrically bond all the structural steel.

“The repeater is now Yaesu Fusion AMS, plus WiRES X and all is well. Hopefully, this discussion will help others with similar problems.”

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.

The DR repeaters are calibrated in the middle of the band. For UHF that is 440.000 MHz. You may want to check the power output at that frequency as you are operating right at the band edge. While you’re at it, measure the Tx current. At the lower power output the current should be lower, otherwise it could indicate a problem.

Under no circumstances should the Tx current be above 10 amps (I recommend a 10 amp fuse in the Tx power supply line) and will more typically be around 7 amps. At 30 watts it should be less.

There are differences in the DR-1X depending on when it was produced and/or which updates it has received. Early units should only be run on medium power, especially on UHF.

The DR-1 does not sense SWR. It simply looks at voltages in the output filter that should be represent a higher SWR as an apparent higher output power thus causing input power to be slightly reduced. Variations in the frequency response characteristics of the filters and amplifier gain will cause the output to vary over the 430-450 MHz range. You can always recalibrate the output at your frequency of interest but be careful. It has been my experience that the output can also be greater than 50 watts on certain frequencies.