Tag: D-Star

Need A Radio Check?

Next time you think about interrupting a digital voice QSO for a radio check, think again and connect to XLX020 Module S.

There, you’ll find our DV Bot. Key up on the module and try something like “This is <Insert Callsign>. May I have a radio check please?” No doubt, this will lead you down an amusing rabbit hole.

The DV Bot is a voice to text interface to ChatGPT, the much talked about artificial intelligence backend. Yes, AI does digital voice!  Give it a try and let me know what you think in the comments.

73 de K2IE

020 in 2020: An Update on the 020 Project Multiprotocol Digital Network

You may know it as CNJHAM, because that is how it all started. CNJHAM was first implemented as a lone StarNet smart group. CNJHAM then begat XLX020. Hardware transcoding was soon implemented and followed by links to Brandmeister DMR and YSF Fusion. In this new year, we’ve added Wires-X (for connection from Fusion repeaters) as well as P25 connections.

CNJHAM/XLX020A can be reached via the following methods:

D-Star Callsign RouteCNJHAM via Quadnet
D-Star ReflectorsXLX020A, XRF020A, REF020DXLX020A preferred
D-Star RepeatersNJ2DG-A
NJ2DG-C
W2RJR-B		Fulltime
Brandmeister DMRTG 31340CNJHAM
Fusion YSFYSF 44977US CNJHAM
DTMF 44977
Wires-XCNJHAMDTMF 28255
P25TG 31340Pi-Star
NXDNTG 31340Pi-Star
XLX DMRXLX020AEnable DMRGateway in Pi-Star
XLX YSFXLX020ASome Pi-Star config required

Jersey StrongWhatever the protocol, CNJHAM is Jersey Strong!

73 de K2IE

D74A and XLX Special Character Woes

A fellow New Jersey ham was having the hardest time using my XLX reflector. He could connect to a reflector module. He could hear conversations, but none of his transmissions were making it out over the reflector. Strangely, he had no such problems when using a DPlus reflector. His radio is a Kenwood D74A.

He uses a SharkRF openSpot2 as his hotspot. While helping to search for a solution, I remembered a thread I saw on the Pi-Star Forums. The author complained of not being heard on an XLX reflector via a D74A. The cause and the solution had nothing to do with Pi-Star, but rather it proved to be a quirk with the D74A and the XLX software.

Apparently the D74A allows any character to be entered into the Callsign Extension field. These are the 4 bytes following the “/”. While these characters were orignally made available to support reciprocal operations and portable suffixes, they are now commonly used to identify the type of radio being used. So my D74A callsign is setup as K2IE____/D74A (the underscores represent spaces). My friend’s radio had “@?” in the Callsign Extension field. These unexpcted characters seemed to cause the XLX reflector to ignore the attempted transmission.

The Icom radios support only A-Z and 0-9 in the callsign extension field. The D74A allows lowercase and special symbols too. Don’t use anything other than A-Z and 0-9 in the Callsign and the Callsign Extension fields and you won’t have this problem.

To make things more interesting, the ham who reported this issue is visually impaired. He relies upon the radio’s voice prompts. However, the Kenwood D74A voice prompting system ignored the @? characters completely, so he never had any idea that they were present. Another local ham who was alerted to the special character problem on the D74A spotted the issue and fixed things.

73 de K2IE

D-Star & DMR Interoperability

If you’re a fan of either D-Star or DMR, you have probably noticed the proliferation of multi-protocol gateways. These gateways, such as the XLX020 system, permit users of radios of one type to communication with users of radios of another type. Multiprotocol gateways help to defragement the amateur digital landscape.

However, there can be issues if the transmitting operator is not registered on both systems. Have you been on a DMR radio and seen the transmitting party display as radio id 0? They are a D-Star (or Fusion or P25 or NXDN) operator who has not registered a DMR radio number.

For DMR operators who have not registered with their nearest D-Star gateway, transmissions could even fail to pass through the D-Star gateway to connected D-Star repeaters.

Therefore, k2ie.net highly recommends that all amateurs using any digtial voice mode register for BOTH a DMR radio id and with a local D-Star gateway, whether or not you have a corresponding digital radio.

You can register for a DMR radio ID at http://www.radioid.net. Hams in Europe and Africa should register at http://www.ham-digital.org.

If you’re not sure of your local D-Star gateway, you can follow the instructions at https://www.dstargateway.org/D-Star_Registration.html.

73 de K2IE

You Say Protocol, I Say Reflector…

Is XLX a protocol? Is it a type of reflector? Why are we asking these questions?

There is a bit of a debate going on now in D-Star circles as to how the end user (you OM or YL) of a hotspot or repeater should connect to an XLX reflector. I’ve exchanged emails with some notable folks in amateur radio software development circles (Luc LX1IQ, Andy MW0MWZ, and Tom N7TAE) on the subject. The software developers are all in agreement. XLX is not a protocol, it is a type of reflector. On that point, they are quite correct.

To varying extents, each have indicated that the preferred way to access a reflector is via the protocol, node and module notation. Using this paradigm, to access XLX020A via DExtra protocol, you’d connect to XRF020A. But there could be an XRF020A that is not XLX020A. We’ll get to that in a couple of paragraphs.

On the other hand, Jonathan Naylor (G4KLX) has implemented the ability for ircDDBGateway to access XLX reflectors by name. Since all XLX reflectors support DCS protocol and DCS is the most modern of the three D-Star reflector protocols, ircddbgateway defaults to DCS connections. This make perfect sense to me. And it works!

Note: In case you did not know, ircDDBGateway is part of the software suite that comprises the exceedingly popular Pi-Star distribution. May of the tools provided as part of Pi-Star were developed by G4KLX.

As an end user of a hotspot or repeater, I just want to connect. There is also the problem of amgibuity. You can have an REF123, an XRF123, a DCS123, and an XLX123. They may or may not be the same destination. But XLX123 is a specific destination, as are the other three. So the best way to connect to an XLX reflector for the end user would be to allow the end user to specify that destination.

To continue to require that XLX connection requests specify a particular protocol, when there is no specific reason to do so, would be as confusing as requiring the end user of a mobile phone to specify what network the called party is connected to. Yes, the option is there, but let’s make this simple.

I’d like to see the various hotspot platforms adopt this aproach. What do you think?

73 de K2DLS


XLX Support Updates

There are a couple of big announcements to make in terms of support for the XLX reflector world this week.

The first development is that Kenwood has released firmware version 1.09 for the popular D74A handheld transceiver. Among the improvements contained in this release is direct support for selecting XLX reflectors by name on the “Link to Reflector” menu.

The second development is that Andy Tayor <MW0MWZ>, developer of the extremely popular Pi-Star hotspot software distribution for the Raspberry Pi, has made a change that allows the radio operator to directly select an XLX reflector. Previously, you would have to make a local host table override entry for an XRF or DCS reflector in order to make this work.

06-28 Alert: After some more testing, it seems that the Pi-Star change to allow connection via the XLX name isn’t working properly. Testers experienced one way audio with the initiator of the connection not hearing the remote end.

07-11 Update: XLX Linking is now working, with some tweaks to the ircddbgateway config. See this thread on the Pi-Star Forum for more info.

XLX reflectors just got a whole lot better thanks to these updates!

73 de K2DLS

XRF020B Hamvention Connection

XRF020B is your link to Dayton Hamvention through the end of this weekend. In cooperation with VA3UV and KA8SCP, we’ve linked XRF020B and XRF038C to Dayton D-Star repeater W8RTL. So feel free to connect through the course of the weekend for updates from your fellow radio amateurs.

You can also connect via DMR to XLX020B using TG6. Key up with an initial private call to 64002.

Feel free to post any big Dayton news in the comments.

73 to everyone in Dayton and those who wish they were.

“Peanut” App Adds USA Master

David <PA7LIM>, the very talented developer of the Peanut app, has added a new master server in the USA. This ought to greatly improve voice stream quality once fully deployed. The “020 Project” has volunteered to be the first reflector to move over the the USA master, which is currently in test mode.

When the move occurs, you’ll have to change the “Master” in the Peanut app to USA-Test. Then, you’ll connect to XRF020C as before. XRF020C is the gateway to the repeaters connected to REF020A.

The move is expected to occur tomorrow, May 1. (Update: We’re already there on the afternoon of April 30.)

Happy May Day!

73 de K2DLS

The “020” Reflectors

D-Star users have long known about REF020. Reflector 20, as many call it, is one of the original D-Plus Reflectors. A number of repeaters in the New Jersey/New York/Pennsylvania region link to it, including powerhouse K3PDR in Philadelphia and NJ2DG in Martinsville, NJ. It was recently relocated to the cloud by its operator (Scott KB2EAR) when when the site where the server was housed became unavailable. Historically, the busy channel tends to be REF020A.

During the weeks that Reflector 20 was down, I started exploring D-Star smart groups as a way to get together on the air with some of the folks that I talk to regularly. Smart Group CNJHAM was created on the QuadNet array.

Smart Groups can be a bit confusing on repeaters if you don’t know what group is being used as you come into range. My friend Ray <W2RJR> is playing with a low profile Pi-Star based repeater so we decided that repeater use would be simpler if it could connect to a reflector. Then the only destination route needed is CQCQCQ. So XRF020 was born.

Initially, there were challenges getting XRF020 getting listed in the right directories. You see, there is supposed to be one XRF directory that is authoritative, but not all gateway systems seem to pull data from the same place. Pi-Star uses one list, OpenSpot another, and DV4mini yet another. OpenSpot listed XRF020 right away. DV4mini uses the XLX list and you could have an XRF and XLX using the same number, which is “interesting”. Pi-Star took weeks to list XRF020 until I went to the “top guy”. Then it was handled immediately. Once I learned that XLX reflectors self-register, XLX020 was born.

CNJHAM - Our Central New Jersey smart group conference
REF020 - The original D-Plus Reflector 20 operated by KB2EAR
XRF020 - An XRF Reflector that speaks D-Plus and DCS as well as DExtra
XLX020 - A multiprotocol reflector that bridges digital modes

Here is the lay of our digital land.

Smart Group CNJHAM is where a few of us in the Central NJ area meet up daily. It is more or less our local digital intercom, but you are welcome to stop by and say hello. You can also say hello via XRF020A and XLX020A, as well as REF020D. They are all linked. The NJ2DG-C repeater is linked to REF020D, so you can get in that way too.

         CNJHAM <==> XRF020A <==> XLX020A <==> DMR/YSF
                        |
                     REF020D

If you’re an REF020 user, then you’ll want to know that REF020A is linked fulltime to XLX020C. You can connect to the XLX side of things via DMR, D-Star, or YSF. You can also get in via PA7LIM’s Peanut.

             REF020A <==> XLX020C <==> DMR/YSF/Peanut

See you in 020 land.

73