DMR Tech Talk
Collaboration of Amateur Radio Projects

A few years ago after getting deep into Digital TV I was tempted by the lure of multiple free FM signals in a similar way with HD Radio.  Imagine 2-3 choices for every FM station and one of them is commercial free in most larger cities. Consider most secondary HD channels are exactly that, commercial free! Sound cool?  What I learned is that yes, the digital future opens up many options, but it has its shortcomings, too.  I have a vehicle from 2010 and even then, HD radio was not considered important enough to make it a standard feature.  So, I read, I read some more.  I eventually found this neat adapter called an ISimple PXAMG Gateway.  This is a small box that has a has a wiring harness that plugs into the back of your car radio and into the HD radio box.  The HD radio tuner plugs into that.  So, in essence, you are adding 2 small boxes to your vehicle to get HD radio.  They’re small enough to fit under the center console easily and out of the way. 

But, here’s where it gets a little tricky.  Most car antenna systems use a RG62 93 ohm coaxial cable which is a transmission line at FM 88-108 MHz but at AM 530-1710 kHz with an electrically short monopole, the transmission like acts as part of the antenna at that frequency. So, you’re out of luck looking for a 93 ohm splitter to simultaneously be able to support the old radio tuner with all of the presets and your new one. You have to make a choice here.  Do I use the old radio functions, which are easier and maybe have more presets or do I fully commit over to the new tuner which may have an unorthodox way of changing bands and presents?  You could use a very low loss 75 ohm splitter.  Then you have a 1.5:1 VSWR mismatch on FM.  But… You have a problem with the very narrow band and electrically short AM antenna, which has horrible efficiency to begin with, if you do this.  The antenna will work on AM, just about half as well, or maybe even worse when you try and use a splitter. (Most splitters are rated for 5 MHz and up too.  So, you have to search hard to find one that has respectable insertion loss at 0.5 MHz, the bottom end of the AM broadcast band.)

Anyhow, this device I purchased called a PXAMG had issues with random radio system freezes and reboots at temps < 10C/50F.  This irritated me to no end when my bluetooth mobile phone conversations would not work. What the heck is that?  I could not find any cold solder joints inside the box or poor workmanship.  I can only assume something else in there does not respond well to users north of the 35th parallel.  I never had issues with warmer temperatures.  I also tried two different wiring harnesses. I updated to the latest firmware.  Perhaps the chipset they chose is garbage.  I don’t know.  This whole experience made me think how good engineering has been tossed aside for cheap and not fully tested and designed solutions these days.  I digress…

There’s another fly in the ointment to consider.  Currently, HD radio signals from the transmitter are limited to less than -14dB below the amplitude of analog carrier, i.e. 4% of the analog transmit power. That’s quite significant.  This means HD radio is limited to the immediate city and adjacent suburbs, not the ones that are medium or farther out.  There are areas that are 20 mins from the downtown skyscrapers that lose WLS-HD1 in Chicago for example.  The analog signal easily carries another 20 miles- at least.  When I think of HD Radio, I also think of D-Star.  The error correction is awful. Go behind a bunch of trees and be prepared for packet loss. Ouch.

My advice:  If your vehicle comes with HD radio preinstalled, you’re set to enjoy more options if you don’t stray too far from the transmitters. If it doesn’t, then don’t waste your time with some converter box/HD radio gateway.  It’s not reliable enough.  At some point we will be more digital on FM, less analog, just like the UK is.  I just hope the FCC allows the broadcasters more transmit power to make up for the multipath and error correction issues that HD radio has.

It’s happened to many of us networking Motorola DMR repeaters with IPSC. Sooner or later, we stumble into a NAT problem. In fact, this is arguably the single most vexing problem with IPSC.

The secret to fixing the problem is understanding it, and IPSC is just a little bit weird. It’s clear that Motorola’s intention was to create a protocol that would be as absolutely reliable as possible. To do this, they simulate an IP multicast environment with IP unicast (which is probably the only paradigm 99.999% of us have worked in) and they do it in a way that defeats most common NAT/PAT problems quite elegantly. As a point of reference, most of us are not actually using “NAT” (Network Address Translation) per se, we’re really using PAT (Port Address Translation) — They’re very similar, but this would be a good time to check out the differences between NAT and PAT if you’re not already familiar.

We often hear of the “master” IPSC device. The “master” device has one and only one role that makes it different than any other peer: The master’s unique (additional) job is to keep track of the devices in the IPSC system. In IPSC, each device sends all user data (voice, text messages, etc.) to every other IPSC device directly. This is what I mean by “simulates multicast with unicast”. The master’s one unique task is to keep track of the devices in the IPSC system and report a list of them to each new peer that joins, and to update it when a peer leaves. The master builds this list by examining the source IP address and UDP port number of registration packets from new members. To be very, very clear, and this has come up many times: Traffic is not routed through the master, it only coordinates a list of IPSC devices in the system.

Now we have the crux of the problem! What if we have two repeaters behind the same PAT? This isn’t going to work, because the master will pick up their public IP address and public UDP ports. But with many NAT/PAT products, the two repeaters will not be able to communicate with each other over the public address. Think about, let’s say we have the following setup:

Repeater A: 192.168.1.100:50000
Repeater B: 192.168.1.101:50001
Public IP: 123.12.13.4

When A and B register with the master, the master will record repeater A at 123.12.13.4:50000 and repeater B at 123.12.13.4:50001. The master will tell them both about each other, but when repeater A tries to send data to repeater B at 123.12.13.4:50001, many (most?) NAT/PAT devices will not forward the traffic — realizing that the devices are on the same network “behind” it, the NAT/PAT will not “hairpin” or “loop” the traffic back. The problem is only exacerbated if the IPSC system master is also behind the NAT/PAT.

The problem can get worse, In some cases the NAT/PAT will also randomly change the source UDP port for each session. In this situation, let’s say that Repeater B is now on some other public IP address. When Repeater A registers to the master, the source UDP port would be changed to s0me other number, say, 32111. So the master records A at 123.12.13.4:32111, and distributes a new peer list to all of the members of the IPSC. In order for Repeater A to have sessions opened in its firewall (assuming it has one), it tries to contact the other IPSC members, which should “open the door” so to speak for them to communicate. Let’s say that Repeater C in this case is at 1.12.123.1:50000. When repeater A tries to contact C, the source UDP port is again randomly changed for that flow, and is now 44433. A tries to contact C with source port of 44433, but C is expecting to “hear” A on 32111, and C is also simultaneously trying to contact A on 32111 as well. You guessed it, the two never end up making the connection.

These types of problems are becoming more and more prevalent as the lack of available IPv4 address space becomes a bigger problem. In particular, many of our repeaters are located in remote areas where Internet service is problematic. Because of this we end up using cellular data devices, which are notorious for implementing CGNAT (Carrier Grade NAT), which is also synonymous with randomly translating ports — and because this NAT takes place on the carrier side, not in a device we can control, there’s really very little we can do about the problem.

This isn’t a new problem, and many have written about it before, but the solutions always involve manipulating the NAT/PAT process rather than eliminating it as a problem. Stay tuned for two upcoming articles outlining how two different amateur DMR groups, who didn’t have the luxury of using a different PAT device, moving to public IP addresses, etc. solved this problem. Both solutions use the open source DMRlink software.