IMRS Active on NJ2DG Fusion Repeater

An IMRS connection to the XLX020 reflector has been activated on the NJ2DG Fusion repeater in Martinsville, NJ. All XLX020 modules are now accessible via the repeater.

To select a module, simply transmit with the DGID set to any of (10 .. 35). DGID 10 is XLX020 Module A, DGID 11 is XLX020 Module B, etc. Module D (CNJHAM) uses DGID 13.

Unlike DMR, there is no initial keyup required to connect to the chosen module. This is about as easy as it gets, once you learn how to change the transmit DGID on your radio.

Wires-X is still available via DGID 50 with an inactivity timer of 10 minutes. The IMRS connected modules do not have an inactivity timer.

The NJ2DG Fusion repeater in Martinsville is on 441.400 MHz (+5).

73 de K2IE

Update: Crisis Averted

Thanks to LX1IQ for getting us restored as the rightful owner of XLX020! Also thanks to SA7SVR for agreeing to voluntarily move his XLX to a different number. I have suggested to LX1IQ that we do some analysis to see if a faulty system clock situation did indeed break our registration.

(Original Post)

We’re in a bit of a crisis situation at XLX020. Sometime last night we appear to have lost our XLX registration to ANOTHER XLX020 located in Sweden. While I’m not totally clear on why this happened, we did have a problem at our cloud provider this week. That problem somehow involved the system clock and created unusual timestamps on a bunch of critical files, including a file that tracks registration phone-home calls. Our cloud provider ended up migrating us on an emergency basis to a different physical host but we didn’t become aware of the clock/filestamp issue until today.

Note the file listing below with the dates “Oct 31 2223”!

$ ls -l | grep 2223
-rw-r-----  1 root  adm              7385678 Oct 31  2223 auth.log.1
-rw-rw----  1 root  utmp            13949952 Oct 31  2223 btmp.1
-rw-r-----  1 root  adm             46307238 Oct 31  2223 daemon.log.1
-rw-r-----  1 root  adm              4878047 Oct 31  2223 fail2ban.log.1
-rw-r-----  1 root  adm              1362469 Oct 31  2223 messages.1
drwxr-xr-x  2 drats drats               4096 Oct 31  2223 ratflector
-rw-r-----  1 root  adm             47846088 Oct 31  2223 syslog.1
-rw-r-----  1 root  adm              1322013 Oct 31  2223 user.log.1


Today, I noticed fewer connections on the XLX020 dashboard and started to investigate. Looking at the official XLX Reflectorlist I saw that there is now a reflector in Sweden which has taken our place in the 020 slot. It seems to have been implemented just today by SA7SVR

So right now, we’re in a bit of a limbo situation. I have reached out to SA7SVR as well as the XLX admin team in Luxembourg to see if we can get this remedied and get our registration back. I’m hoping that everyone will be amenable and sympathetic to the situation we were put in.

It also shows the underlying weakness in the XLX registration system. If a system problem, which has not yet been fully diagnosed or understood can lead to the revocation of a longstanding and popular XLX number, that is disturbing.

I’ll keep you updated.

73 de K2IE

Mumblemeister?

Brandmeister is out there innovating again.

There’s a low latency VOIP solution based upon on an open source codec. The codec is called Speex and, as the name indicates, is optimized for speech. So bring on Mumble.

Mumble is a multiplatform VOIP client that makes use of Speex. It has been integrated into the Brandmeister backend and is currently being tested with a few select talkgroups…CNJHAM 31340 is one of them. You can also get on 3100 and some others.

So if you’re brave (and aren’t going to bug me or BM for support), give it a try. Your user ID is your CALLSIGN-DMRID (ex. N0CALL-1234567 and case matters) and your password is your BM hotspot security password. You’ll need to add mumbleeast.repeater.net as your server.

Remember, this is a test. This is only a test, so your mileage may vary.

73 de K2IE

Holiday Mystery on 472 kHz

I decided to monitor the activity on 472 kHz tonight (630 meters). I fired up WSJT-X and saw that at least one station was in the holiday spirit.

Somehow, the transmitting station managed to send data that displayed “Ho Ho Ho” right in the waterfall, without any decoding.

It is nice to see that there are still surprises out there on the radio. They did seem to also transmit a callsign but it was not readable to me. Any ideas about who this Christmas elf is?

73 de K2IE

New YSF Capabilities on XLX020

The Yaesu Fusion radios have a new capability when used with Pi-Star and an XLX reflector. You can now use the transmit DGID to talk on any of the enabled modules. Here is how it works.

Configure your Pi-Star instance to enable WiresX Passthrough.

Use the Wires-X function of your radio to connect to the XLX reflector of your choice. For example, XLX020 is #66396.

Set your transmit DGID to the number representing the module you wish to talk on. For example, Module A is DGID 10. Module D is DGID 13. See this link for the full list of modules.

Thanks to all those behind XLX and Pi-Star for making this feature available. YSF and XLX are now better than ever!

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