YSF Global Monitor

W6DS operates a network monitor which simultaneously displays activity on a number of YSF reflectors including MNWis, SoCalHam (K9EQ), US-MVARC (Idaho), US-KENTUCKY, US-SADRC, plus others. In addition, you can listen to the conversations or go back in the transmission history to hear past conversations by clicking on the reflector. It also shows technical data so you can see how well you are getting in. What you want is the minimum number of sequence errors. Check out the Network Digital Radio Monitor.

Repeaters Inputs with Bursty Noise

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.”


Repeater Lock-Ups

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.

On Repairing PA’s of Repeaters and Radios

If you are experiencing low or no power output…..
1. Replacing a blown final does not necessarily fix the problem that caused the blown final. Never replace a blown final in anything where you haven’t gone through and figured out if there was a reason the final blew. These are very rugged transistors that should last a very long time.
2. Some failures are related to heat, most are not. The DR repeaters have excellent cooling. Unless the fans have died, temperature should not be a problem.
3. There have been, er, problems in the past. Being that I’ve been in Fusion since the very beginning, I have had a few radios where finals blew. The root cause many failures in the repeaters has been resolved a long while ago. DR2s never had any issues. Later DR1s were fine.
Suggestion: Add a 10 amp fuse between the power supply and the Tx. This can prevent burning of the PCB should the final end up in a “high current” mode. Not a likely event, but good insurance against a potentially much more expensive repair. (If the transistor is biased on with no RF input, the current draw will go to about 15.5A. All of that power is used to heat up the transistor and the PCB.)
4. The official Yaesu replacement transistor is not available on the open market. You must purchase it from Yaesu. I have successfully replaced PA’s, but be advised your specific non-Yaesu replacement transistor might have characteristics that won’t play well with the other components on the board.
My suggestion: Unless you’re really set up to do this stuff and are willing to match a replacement transistor to the circuit, let Yaesu do the repair. If Yaesu did not do the repair, we shouldn’t get concerned when someone reports multiple PA failures.
From another post:
First, replacing the transistor may not fix the problem. One has to wonder why it failed. These transistors should not fail under normal use (i.e., no lighting). High bias voltage can easily kill a PA.

I had a similar problem with an FTM-400. Blown PA, no bias. Forget what I did, but I could have kicked myself for not checking the bias and working on that problem before I put the new transistor in. As I recall I just worked my way through the bias circuitry and fixed what was wrong. My recollection is that the bias was bad on both the driver and the PA so I ended up looking at the common circuitry.
Note that the PA transistors you can buy from places like RF Parts are different transistors from those that Yaesu uses. For a number of years now they have been purchasing Mitsubishi transistors with a custom part number. My guess is that they have been selected for consistent parameters in the 430-450 range whereas the standard part is specified for 450-470. This means variation in the standard part may require fine tuning of the input/output circuitry.
I had a DR-1X who’s power output went to zero. Fortunately I had placed a 10 amp fuse in series with the Tx which blew and protected the PA transistor. (Otherwise it sits at 16 amps and melts itself.) The problem was a failing solder joint on an inductor that was used to provide RF isolation to the transistor that engaged the Tx low pass filter network band switch relay. It really helps if the Tx frequency is on the same band that the output filter is on! This is an example of a non-PA failure that could have killed the PA. These transistors should not fail and if they do there’s probably a reason.
Aside: In the above I ended up bypassing the relay so it always used the 440 MHz low pass since I only use the repeater on UHF. Figured one less failure point. Funny thing is that it worked fine on VHF (of course) but that the spurious emissions were still pretty low. It would easily meet FCC spec with a duplexer on the output.

Repeater Power Output

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.

Battery Hints and the FT-70

What’s up with the FT-70 battery indicator? Why does it seem like the battery doesn’t last very log?

The FT-70 doesn’t actually know the state of charge of the battery. It only knows the voltage – which can be misleading while the battery is being charged. The Battery Management Unit within the battery pack is responsible for managing the charging and discharging of the battery. While computers and smart phones generally use the BMU to display state of charge, I’ve never seen an HT that does that.

You are correct that the charging indicator does not show a battery level, it displays a timed barograph that slowly fills in since the HT has no data from the BMU.

Also note that the first several charge/discharge cycles on a Li-ion battery will be vastly different from the subsequent cycles. The first couple of cycles are need to condition the battery. Generally capacity will increase for the first few cycles.

To have the battery last as long as possible:
1. Don’t over discharge the battery. My rule-of-thumb is to stop using the battery (if convenient) when the Rx voltage reaches 7.4 V. At this point 80% of the battery capacity has been used. Most of the capacity is given up between 7.4 and 8.0 volts.
2. Don’t charge a hot battery. Heat is the enemy of Li-ion. It really likes nice, comfortable room temperatures around 70F/20C. Best not to leave it in the sun in a parked car!!!
3. Don’t overcharge. It’s fine to pull the battery out of the charger before it is fully charged. Generally the last 10% (8.0V+) goes slower because of the reduced charge current. Pulling it out at 8.0V will extend the number of charge cycles and have very little impact on stored capacity.
4. Avoid using 5 watts. At high power the radio generates a lot of heat – with the heat sink right up against the battery. It also places the greatest demand on the battery – especially if the battery is more than 70% discharged. The higher discharge current also creates more internal heating within the battery.