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.

The tuner really doesn’t care much about the frequency. It really cares a lot about the impedance!  You want to avoid antenna lengths where they can present a high impedance to the tuner at a desired operating frequency. 23′ is a “magic” number as it avoids resonating on any of the ham bands. (If it resonates on 40, you’re screwed on 20.) 

Next point: The AT-180 is designed to match to ALMOST 50 ohms. It is not designed to be a universal tuner. It will take a resonant antenna that might have higher SWR at the band edges and flatten that out so the transmitter is happier.

The AT-180 (and all internal tuners) will not improve an antenna’s performance. It will simply make the transmitter happy. Why? Because you are tuning the transmission line. A tuner placed at the antenna, like the AH-4, tunes the antenna and can therefore improve the antenna performance. My universal antenna is a 46′ dipole, fed by 39′ of 450 ohm ladder line into an AH-4. That combo will tune EVERYTHING from 80 to 6 meters.

For more information, see the HF tab on HamOperator.com.

It may be difficult for the tuner to match 50 to 50 ohms at certain frequencies. It is almost always matching a non-resistive load that is likely not 50 ohms. I suggest playing with the antenna and feed line lengths. I really recommend investing in the AH-4. Probably one of the best remote tuners ever made!

73,
Chris, K9EQ

Conduct CW QSOs from your computer, tablet or smart phone! HamRadio.Solutions offers a Virtual Band with several bands where you can hold CW QSOs. The sit lets you set all your CW parameters. You can even hook up your keyer and use that. Or just listen to the QSOs. You can select audio, text or both, so you can compare what you copy with that which was sent. Give it a try! This service is provided courtesy of David, W6DS.

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.

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.

I use VyprVPN from GoldenFrog. It is necessary to turn of NAT for your account. That means that each VPN connection is a raw connection straight to the Internet. YOU HAVE NO PROTECTION OTHER THAN WHAT YOU PROVIDE!!! (The same company will rent you a VPN that you can host on your own cloud provider where you can control port forwarding – but I suspect this is well beyond most folks.)