FT70D High Power Problems

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.

FT70D spectrum on low power
FT70D on High Power
FT70D on High Power



Node Cycling In and Out

This post addresses a WiRES-X node that constantly leaves and rejoins a room.
 
This type of problem is almost always the result of a networking issue. When certain networking problem occur the HRI-200 software will wack out (a technical term). 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.
6. Did I mention, turn off everything on the router you don’t need?
 
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. This is because the port check uses the Yaesu servers in Japan to perform the test, not the room server you’re trying to connect to. Routing issues can cause one to work whilst the other doesn’t.
 
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.)



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

 




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.



WiRES-X Online/Offline

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.




WiRES-X and USB Problems

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!