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.

Connect to XLX as XLX!

Yes, you can connect to an XLX reflector with D-Star without having to use an XRF or DCS connect string! This is a supported feature of ircDDBGateway (which is leveraged by the Pi-Star distribution).

If you’re running a recent version of ircDDBGateway (such as the one in Pi-Star 4.1 releases), you can connect via an XLXnnnmL type command.

In this case nnn is the 3 digit reflector number and m is the module letter.

For example:

XLX020AL

ircddbgateway will then use DCS to make the connection to connect to module A of reflector XLX020.

For this to work properly, be certain that the following is set in your ircddbgateway config file:

xlxHostsFileUrl http://xlxapi.rlx.lu/api.php?do=GetXLXDMRMaster

You can check this in the Pi-Star expert mode configuration for ircDDBGateway.

73

Optimum Lowers Boom on TiVo

We were afraid that this would happen and it did.

The Federal Communications Commission (FCC) recently removed its mandate for cable providers to support cable cards and tuning adapters. While the technology is old and not without issues, it is a way for customer owned devices to view cable programming on their own device, such as a TiVo. It also gets the customer out of paying for a cable set top box.

For several weeks, I’ve been having a problem with an Optimum/Altice provided tuning adapter constantly rebooting. This has prevented me from watching channels delivered via switched digital video (SDV). It has also caused my TiVo to temporarily malfunction as the cable card attempts to remap channels each time the tuning adapter is not seen as available by the TiVo.

After numerous calls, disconnects, outright lies by customer service reps, and 2 FCC complaints, Boris from Optimum called today and said they do not have a replacement tuning adapter for me and that my only recourse is a cable box.

Here is the an excerpt of an email that I received as a followup to the call.

As per our today conversation, we need to inform that Channels that use Switched Digital Video technology are not available when using a CableCARD with a TiVo CableCARD-compatible device. These customers will need a digital set top box to view Switched Digital Video Channels.
Tuning Adapters are no longer available in Altice East Retail stores.

Also of interest to some readers:

In the Hudson, Newark / Elizabeth and Paterson service areas, we do not deliver programming through SDV technology.

This is not good. Wonder what TiVo’s play is going to be here? Wonder which providers are next to drop tuning adapter support.

As for me, at least I’m in a good over the air (OTA) antenna area.