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 of repeater should connect to an XLX reflector. I’ve exchanged emails with some notable folks in amateur radio software development cirles (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 connections to XLX select a specific protocol, when there is no specific reason to do so, would be as confusing as requiring the end user of a mobile phone having to know 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

N5BOC Duplex Hotspot

I managed to get my hands on one of the hot items in the MMDVM world — an N5BOC Duplex Hotspot. This is really a mini-repeater which uses both timeslots on DMR and has a separate transmit and receive antenna connector. Initial results have been as expected — excellent!

My idea was to have a hotspot where I could configure XLX on TS1 and Brandmeister on TS2. With the N5BOC board and Pi-Star this was a breeze. The key is in the DMR Gateway configuration.

My XLX configuration:

[XLX Network]
Startup=020
Enabled=1
File=/usr/local/etc/XLXHosts.txt
Port=62030
Password=passw0rd
ReloadTime=60
Slot=1
TG=6
Base=64000
Relink=60
Debug=0
Id=1234567
UserControl=1
Module=A

My Brandmeister configuration:

[DMR Network 1]
Enabled=1
Address=107.191.99.14
Port=62031
TGRewrite0=2,9,2,9,1
PCRewrite0=2,94000,2,4000,1001
TypeRewrite0=2,9990,2,9990
SrcRewrite0=2,4000,2,9,1001
PassAllPC=2
PassAllTG=2
Password="passw0rd"
Debug=0
Name=BM_United_States_3101
Id=123456701

If you’re not currently using DMRGateway, make sure that you have activated it by setting the DMR Master on the configuration page to DMR Gateway. This will reveal options to help you manage Brandmeister, DMR+, and XLX, all on the same hotspot.

Setting up a STARnet Routing Group

Last month I wrote about callsign routing in a D-Star environment. I mentioned that it is possible to create your own Starnet routing group for you and your friends to chat on. If you’re running Pi-Star, here is how to do it.

On the Pi-Star Expert Editors menu, select ircDDBGateway. This component (written by G4KLX) of the Pi-Star distribution contains the Starnet server. Starnet uses callsign routing to set up a group which can be subscribed to by any valid user on the same network. In this case, we’re using the default network run the the QuadNet team (rr.openquad.net).

You’ll have to pick a name for your group. The ideal Starnet group name is not a valid call sign and is 6 characters long. This leaves room for a space and a subscribe/unsubscribe character. So it looks like this:

MYGRUP   -- Group name

MYGRUP A -- Subscribe to MYGRUP

MYGRUP T -- Unsubscribe to MYGRUP

In the ircDDBGateway config, you’ll need to change the following:

starNetBand1       A
starNetCallsign1 MYGRUP A
starNetLogoff1 MYGRUP T
starNetInfo1 What my group is about

You’ll see some other Starnet options but it is ok to keep the defaults for now. Once you know what you’re doing you can tinker further. You can even setup multiple groups. There is also an option to link your Starnet group to a reflector, but please do not do so without the permission of the reflector operator. But if you want to test this, you can try XRF020E, which I have reserved for experimentation.

Note: The address of XRF020 is not yet current in the Pi-Star file listings, so until it is updated you’ll have to manually edit /root/DExtra_Hosts.txt with the following:

XRF020        xrf020.k2dls.net L

Once you see your group listed in the QuadNet directory under Legacy STARNet groups, you can set your D-Star destination call (URCALL) to MYGRUP and chat away. Just remember that MYGRUP is an example only, and you’ll need to pick your own unique name that is not already in use.

You’ll also likely have to forward port 40000 (the ircDDB port) on your router to the internal address of your Pi-Star installation.



It may not be like having your own private repeater, but for many D-Star hams, it is the next best thing.

73

Adventures in Callsign Routing

Callsign routing has been around since the earliest days of D-Star. It has also been little used. However, with the proliferation of Pi-Star based hotpots, callsign routing and D-Star have been given new life. Your Pi-Star installation includes a piece of software called ircddbgateway. It truly is a gateway to a whole new way of looking at D-Star.

The first piece of the puzzle is to get comfortable with callsign routing. I invite you to give me a direct call on my D74A HT. To do that, you’ll need to configure your radio with a memory that is setup to use your Pi-Star as a gateway. While that is outside the scope of this article, the general idea of the D-Star configuration (using the ficticious callsign N0TME) is:

 R1: N0TME B ; For a B (70cm) module
R2: N0TME G ; To use as a gateway
MY: N0TME ; My callsign

Now for the fun part. Normally, you’d use CQCQCQ as the destination callsign. This is the standard if using a repeater or a reflector. But, you COULD put a callsign in that destination field. Put “K2DLS P” in the destination and if I’m around, I’ll answer. Note that the P identifies my portable and must be in the 8th character position of the destination (UR) field.

There are also destinations that are not individuals, but are Smart Routing Groups. Try DSTAR1, for example. That is a very active routing group operated by the folks at QuadNet and it offers a lot of multiprotocol connectivity. There is even a net where users check in from D-Star, DMR, and Fusion and everyone can hear everyone else! Be sure to disconnect when you’re done (DSTAR1 T).

You can also configure your own legacy Starnet group on your own Pi-Star for you and your friends to chat on. This can be found on the expert menu for ircddbgateway. We’ll talk more about this in a future post.

In the meantime, I’m waiting for your call.

Turn off HDMI on Pi-Star (Easier)

Here’s an even easier way to turn off HDMI on your Pi-Star image running under Raspbian. If you’re running one of the Pi-Star 4.0 release candidates, the tvservice command may already be installed. You can check by issuing the following command:

which tvservice

If it is installed, just add the HDMI off command to /etc/rc.local.

# Turn off HDMI
/usr/bin/tvservice -o

If you’re running Pi-Star 3.x, I learned that you can install tvservice from a .deb package.

sudo apt-get install libraspberrypi-bin

For some reason this did not turn up during my initial searches but was pointed out over in the Pi-Star Forums by Dennis (W1MT).

It also seems that Andy (MM0MWZ) is considering adding a button in the future which would allow turning off HDMI from the web interface.

Turn off HDMI on Pi-Star Image

It is common practice on headless Raspberry Pi computers to turn off the HDMI to save some power. Even without a monitor attached, the HDMI hardware seems to draw ~ 50 ma of current. However, in the interest of saving space in the image, Pi-Star (as distributed) lacks the necessary tvservice command to turn off the HDMI hardware.

This command is part of the Raspberry PI “userland” package, which for some reason is not packaged as a .deb. So you’ll have to grab the code off github, but it is pretty easy. Before starting, make certain that you have expanded the filesystem of your image to fill the SD card.

sudo pistar-expand
sudo reboot

After the reboot, do the following:

rpi-rw
git clone https://github.com/raspberrypi/userland
sudo apt-get install cmake -y
cd userland
./buildme

Add the libraries to the ld.so search patch by creating a file named “userland.conf” in /etc/ld.so.conf.d. In that file add the following line:

/opt/vc/lib

Next, update the ld.so search path:

sudo ldconfig -v

You can now run the tvservice command:

## Status
sudo /opt/vc/bin/tvservice -s
## Turn off HDMI
sudo /opt/vc/bin/tvservice -o

All that is left to be done is to add the HDMI off command to your /etc/rc.local file so that it will run every time the system boots.