CB FM and APRS?

The FCC recently authorized the use of frequency modulation in the Part 95 11 meter Citizens Band. This action was in response to a petition filed by Cobra Electronics. This change, a clear attempt to generate sales of radios for CB radio manufacturers, could well breathe new life into CB radio.

I think the FCC made a mistake, however, by mandating that new radios having FM capability also have AM capability. While this is intended to provide backward compatability, it would probably be better if the FCC had sunsetted use of AM a few years out. Then we’d be rid of the heterodynes and squeals caused by too many AM signals on the same frequency at the same time.

In the same Report and Order, the FCC authorized the use of position reporting systems on the CB band. Expect to see APRS-like reports using packet FM from GPS enabled portable and mobile radio.

I suggest that we watch for increased interest by the general public. There could be a revival of CB radio as it becomes more usable for local communications. No, we’ll never have a resurgence of the 1970s CB boom, but static free local communications at low cost is going to be attractive to a lot of folks.

73 de K2IE

Fun & Games With 3rd Order IMD Products

A local group of hams has been talking on 2 meter FM simplex for as long as I can remember. In recent years, they’ve been using 146.4 MHz as their primary frequency. I recently ran into one member of the group on a local repeater trying to test something. I responded to him, in case he needed assistance. He he told me how the local repeater on 443.200 MHz was bleeding into conversations on 146.4. Trying to be helpful, and knowing who to get in touch with on the tech side of 443.200, I got involved.

The 443.200 repeater in my area is linked to 146.76 MHz. I surmised that 146.76 was the actual culprit. At my location, 10 miles from the repeater, I could not hear the interference. The hams that are being interfered with are much closer to the repeater site than me. They provided links to some recordings and I gave them a listen.

I noticed that in addition to hearing the audio from 146.76 I also heard mixing from 147.12. I reported that to some of the folks at the club responsible for 146.76 as well as to the owner of 147.12. I observed that 147.12 – 146.76 = 0.36 and that 146.76-146.4 also = 0.36. This seemed significant to me although I did not know what it represented. The club president chimed in with the determination that the 2 repeater output frequencies, when mixed, generate a third order intermodulation distortion product on approximately 146.4 MHz. Wow!

From my reading, a third order IMD product is created when two non-linear signals mix. To me, that indicates a problem at one or both of the repeater sites. Some local hams familiar with the situation voiced the opinion that there is no way to fix this for stations close to the 2 repeaters (which are also relatively close to one another). I was told that at least one of the repeater keepers was also heard expressing this position. Based upon my understanding, I initially disputed the “nothing can be done” position with the thought that if the cause is non-linearity, something can and should be done.

Today I tried an interesting experiment. I took 2 HTs which are probably fairly spectrally pure (a Kenwood D74A and a Yaesu VX7R). I set them both to one watt and put a receiver on 146.4 MHz. One radio transmitted on 146.76 and one on 147.12 MHz.

If I keyed up one radio without transmitting on the other, no signal was heard on 146.4 MHz.

However, when I transmitted on both frequencies simultaneously a perfect signal was heard on 146.4 MHz!

If this behavior can be so easily reproduced with two (supposedly) spectrally pure transceivers and provides the same result on multiple receivers — an RTL-SDR stick and a Kenwood TS-2000– there may just be something to the “nothing can be done” school of thought.

73 de K2IE

The Best Time Synchronization for Windows

The best way to synchronize the time of your Windows based PC is not a third party add-on. It is to use the capabilities built into Windows 10.

I have read numerous threads in amateur radio forums about time synchronization for digital modes such as FT8 and FT4. These usually turn into long threads recommending this or that third party solution. None of them are needed.

Here is the solution that I use. It requires only Windows 10.

Open a Windows 10 command prompt as administrator and run the following commands. These stop time synchronization and resets the service to some defaults settings.

net stop w32time
w32tm /unregister
w32tm /register

Next, run regedit. Carefully make the following changes.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config\MinPollInterval
     Set to 10 decimal

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config\MaxPollInterval
     Set to 15 decimal

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Parameters\NtpServer
     Set to time.windows.com,0x9
     If you have a different server you want to use feel free to do so

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient\SpecialPollInterval
     Set to 1800 decimal
     This will update the time every 30 minutes
     You may have to create this key

If your computer is not attached to a domain (normally the case for non-workplace computers), make sure that time synchronization is automatically triggered when your computer is on the network.

sc triggerinfo w32time start/networkon stop/networkoff

Finally, restart time synchronization.

net start w32time

This restarts the time synchronization process. Your time will be synchronized to the ntp server that you specify every 30 minutes.

You can check your work with the following command:

w32tm /query /peers

The output will show that you are synchronized and to what server. I run a local GPS time source. This is what my output looks like:

Peer: ntp.private,0x9
State: Active
Time Remaining: 0.0000000s
Mode: 3 (Client)
Stratum: 0 (unspecified)
PeerPoll Interval: 0 (unspecified)
HostPoll Interval: 10 (1024s)

Peer: ntp.private,0x9
State: Active
Time Remaining: 1784.6442139s
Mode: 3 (Client)
Stratum: 1 (primary reference - syncd by radio clock)
PeerPoll Interval: 17 (out of valid range)
HostPoll Interval: 10 (1024s)

73 de K2IE

The Importance of IPv6 in Amateur Radio

What most of us call an IP address, in the form 1.2.3.4, is really an IP Version 4 (IPv4) address. IPv4 has a serious limitation. The largest number that can be respresented in the 32 bit binary value of an IPv4 address is 2 ^ 32 (4,294,967,296). Believe it or not, these addresses are in short supply.

IPv6 was created as a solution almost 23 years ago. An important specification document was published in December 1998. IPv6 World Launch Day was 10 years ago! IPv6 is not new. IPv6 provides 2 ^ 128 (340 trillion trillion trillion) addresses. So why aren’t we all using IPv6 now?

Aside from a bounty of address space, there are other reasons to adopt IPv6. Large network providers have built new and optimized infrastructure with IPv6 in mind. Here’s an example of how this can work to your advantage.

The 020 Digital Multiprotocol system has bridge to the Brandmeister DMR (BM) system. Low network latency is of critical importance in delivering high quality voice connections. Any network latency created issues are amplified when voice transmissions are passed through multiple applications and protocol transcoding hops.

Using the IPv4 network, ping time between our end of the bridge and BM is about 8 ms. That is actually pretty good. IPv6 blows that away, with about 1.5 ms ping times. That reason was good enough for me to get my hands dirty and modify some Python code to be IPv6 capable.

IPv6 also helps with the problem of NAT and port forwarding on residential routers. Simply put, NAT can be thrown into the trash bin of computing history. Instead of just one address, the minimum network assignment under IPv6 is 64 bits. That is 2 ^ 64 addresses!

Several ham software authors and volunteers are working on updating their software to be IPv6 capable. My amateur radio wishlist for full IPv6 capability includes xlxd, DMRGateway and ircDDBGateway. HBlink will be there once my pull request is merged. That is the Python code I referred to that links the 020 world to Brandmeister.

N7TAE has a functional QnetGateway using IPv6. I could not get it to work with my DVAPs and will need to followup up with Tom, but he has provided a wide range of hardware support including MMDVM devices.

There are a lot of bits and pieces that will be involved with updating amateur radio software, much of it ancient, to IPv6. So let’s start now. This will take time. And, if you’re a ham working on some new software for the amateur radio world, please make sure that it supports IPv6 out of the box.

73 de K2IE

Net 44 and Icom Terminal Mode

Since before the days of the commercial internet, amateur radio operators have had their own Class A block of IPv4 addresses. Net 44 or AMPRNet is a non-routeable amateur radio experimentation network and access is only available to licensed radio amateurs around the world.

While hams have been experimenting with Net 44 since the early days of packet radio, interconnecting RF and wired networks via AX.25, I’m a relative newcomer. A couple members of the 020 Team are up and running on the AMPRNet and looking at potential use cases.

My driving use case is the to get around the limitation of one ircddbgateway behind a single network address translation (NAT). This limitation prevented me from running an ircddbgateway to service my Pi-Star hotspots and to use Icom Terminal Mode on my IC-9700 at the same time. What is the limitation? UDP port 40000, used by the ircddb protocol, must be forwarded to the destination system. As the Highlander said, “There can be only one.”

By establishing a Net 44 subnet behind my firewall and assigning a Net 44 address to the Icom, I get around the single IP NAT limitation. There’s a bit more to this, but a Net 44 gateway can be run on a spare Raspberry Pi or your internet gateway router (or any Linux based host). This article is not, however, meant to be an implementation guide but more of a starting point for thought.

It is also an announcement that XLX020 is now available on the AMPRNet for use by those with Icom Terminal Mode radios. Our gateway address on the AMPRNet is 44.64.12.57 and you can connect to any module using a To Call of /XLX020m (replace m with your module of choice). If you’re on Net 44, feel free to connect.

73 de K2IE

NWS Weather Alerts via Ham Pager

If you’ve been thinking about something useful to do with your amateur radio POCSAG pager, think situational awareness. This has been a strange year not only for dealing with an extreme virus but with extreme weather.

You can subscribe your ham pager to rubric 1081 to receive county specfic weather alers in almost real time. I currently provide feeds to DAPNET for 38 US counties. If your county is not on the list, it can be added upon request.

You can find out more about this service and DAPNET via the DAPNET Wiki.

If you don’t already have a DAPNET paging transmitter in your area you can use your Pi-Star MMDVM-based hotspot. The capability is built-in. If you need a compatible amateur radio pager, they can be found on eBay.

73 de K2IE

Realignment of Modules on 020 Reflectors

We’ve realigned the module usage on the 020 Reflectors. This means that CNJHAM can now be found on XLX020D, XRF020D, and REF020D. Similarly, REF020A is also now reachable via XLX020A, and XRF020A.

Remember, XLX020 is a multiprotocol reflector. You can connect via D-Star, YSF, or DMR protocols.

The Peanut access that used to connect to XLX020C now goes to XLX020A.

73 de K2IE

HamWars: Allstarlink vs PTTLink

If one were to take the story at face value, over the new year holiday, the Board of Directors of AllStarLink sabotaged their own network by instituting a new server infrastructure to replace one that had existed for some time.

According to a statement issued today by Stacy (KG7QIN), “The groundwork was laid for what was to become PTTLink on 29 December 2020 after the unannounced and uncoordinated actions taken by the AllStarLink Board of Directors.  At approximately 5:00 pm Pacific (0100 UTC, 30 December), the admin committee became aware of multiple catastrophic system outages.   Attempts to login to systems to remediate were presented with new IP addresses and messages that the host keys were unknown.   Further investigation revealed that the DNS zone record was updated at the registrar for allstarlink.org moving it from the long time home of caustic-sea.allstarlink.org to Cloudflare.  In addition, an investigation into the IP addresses being presented revealed that they belonged to Google.  (For more information on the AllStarLink admin committee visit: https://wiki.allstarlink.org/wiki/Admin_Committee). Since the admin team was not previously granted access to the DNS control panel, it was unknown at this time if this was the board, or a bad actor.”

The histrionics have been going on back and forth on the app_rpt mailing list for a few days, but this much is clear. There are now two app_rpt based networks to choose from, AllStarLink and PTTLink.

Who is right, who is wrong? From my read, the Board of Directors wanted to regain control over what they viewed as their network. Seems reasonable. From my read, they also acted in typical corporate fashion to quash any kind of dissent over their actions. In other words, not so reasonable.

But what do I know? Just like the Brandmeister vs. TGIF wars that have since calmed down, here’s hoping that these two networks will one day smoke the peace pipe, learn to get along, and interconnect. In the meantime, you can following the bouncing ball as each side lobs it at the other.

73

CNJHAM Now On Hoboken and Elizabeth Repeaters

Thanks to Kenny (K2ZZ) for adding TG31340 to his Hoboken (448.275 CC3) and Elizabeth (449.925 CC3) repeaters. This definitely fills in some holes in our mobile coverage for the DMR ops. You’ll find us on Timeslot 2.

From my home location in Aberdeen (Northern Monmouth County), I have HT coverage from indoors on the 2nd floor. So give it a try and be sure to send your thanks to K2ZZ if you run into him on the air. This is a nice addition to our network capabilities.

73 de K2IE

Important Brandmeister Network Change!

In an effort to prevent hijacking of DMR IDs by unauthorized users, the USA Brandmeister team is rolling out Hotspot Security as a requirement. This will begin on November 30, 2020…but don’t wait. It will take a few minutes of reading and effort on your part to get it setup, but the entire DMR community benefits by restricting the network to authorized users only.

Hotspot Security establishes as password that all of your hotspots will use to logon to the Brandmeister DMR Master Server. This is different from the password that you use to logon to Brandmeister Self Care.

They’ve put together an excellent explanation of how to setup this up on the OpenSpot, Pi-Star and BlueDV platforms.

Kudos to Brandmeister for a good decision.