This paper is motivated by the recent inclusion of DMR into the existing XLX reflectors, and by linking into the XRF/XLX infrastructure. XRF and XLX as used here are reflector names versus the prefixes as used in host files and linking commands. XRF reflectors are addressed with an XRF prefix. XLX reflectors are addressed with XRF, DCS, or REF prefixes.
The advantage for existing DMR users are portals into current XLX/XRF infrastructure (individual reflectors or groups of linked reflectors) either using new DMR only Talk Groups or Talk Groups with transcoding. The advantage for existing D-STAR users is the ability to access the XLX/XRF infrastructure using many high quality, low cost DMR radios.
To discuss the full potential of XLX DMR, we need to understand both XLX and XRF.
XRF started as open-source alternative to D-Plus reflectors bringing technical improvements and the ability to link. Open-source meant users did not have to register their call signs with a central authority, and reflector admins did not need permission from a central authority to stand up a reflector. To many users and administrators, this independence was very important.
XLX started as a D-STAR reflector capable of using DPlus, DExtra, and DCS protocols, all part of D-STAR. Some admins of XRF and DCS reflectors replaced their reflectors with XLX reflectors. XRF reflectors are not going away. They provide reflector linking options that provide flexibility and agility - the ability to reconfigure reflector links for nets or special events. Additionally there is a new XRF in beta that provides 26 modules, even more extensive linking options, and the ability to detect and respond to various gateway issues and careless reflector linking.
XLX and XRF reflectors can link, providing a configuration with the best of both reflector types - specifically the multiprotocol options of XLX and the linking options of XRF.
DMR is a new capability of XLX. Each XLX Version 2 can provide up to 26 channels, reachable as D-STAR modules (A-Z) and 26 DMR Talk Groups (4001-4026). Module A correspond to 4001, B to 4002, etc. Currently, any module can be accessed via D-STAR or DMR. There is no way to force a module as D-STAR only or DMR only, although a reflector admin could by enabling only certain ports to have a D-STAR-only or a DMR-only reflector.
If an XLX V 2 reflector is also associated with a separate server that includes specific hardware, then transcoding is possible between D-STAR and DMR. That server can be separate, even in a separate location from the reflector, provided there is good connectivity and reasonable latency and not too much jitter, the variation in latency. A typical situation could include a reflector running on a VM or a cloud environment connected to a transcoding server where physical access is required.
If transcoding is available, a D-STAR user connected to Module A can communicate with a DMR user connected to TG 4001, etc. The quality is excellent in both directions. In my opinion, the only differences result from differences in individual radios, not the mode.
The transcoding capacity of a reflector is determined by the transcoding hardware available to the transcoding server. The capacity could include allowing only 1 module/TG, 2, 3, 6, or additions, such as 9. Each module/ TG requires 2 hardware channels, 1 for D-STAR to DMR and 1 for DMR to D-STAR.
If 26 modules/TGs were enabled and the transcoding hardware only had capacity for 6 modules/TGs, then all modules/TGs would compete for the limited transcoding hardware channels. While each module/TG would have transcoding capability, the hardware might not have channels available. Some reflector admins might not mind this, just as some MMDVM all mode enabled repeater owners don’t mind a mode not being available at a point in time. But the near term solution for admins who do not want people to be frustrated is to only enable enough modules on a reflector consistent with the transcoding hardware available.
If an XLX is not associated with a transcoding server, all modules enabled can be used for D-STAR or DMR. This would be again similar to the MMDVM repeater with all modes enabled in that a QSO in one mode would not be heard in the other mode. One solution for this would be for the reflector admin to advise which modules should be used for D-STAR and which for DMR.
I think there will be more access control between XLX and the transcoding server in the future, but in the meantime my best suggestion for the XLX reflectors with transcoding to enable only enough modules/TGs consistent with the transcoding hardware capability.
Using DMRGateway to access XLX DMR and the other DMR systems DMRGateway enables accessing BrandMeister, DMR+, or XLX just by changing talk groups on the radio. In addition to connecting to multiple DMR masters, DMRGateway avoids TG conflicts by remapping the TGs that are programmed in the radio. There will be an example below. There is a key difference between XLX and the others. With BrandMeister or DMR+, connecting to a single master enables access to the entire system. XLX masters are independent of each other.
The current DMRGateway allows accessing DMR+, BrandMeister, and 2 XLX Masters. An upcoming DMRGateway, still in the experimental branch, allows up to 999 XLX Masters. DMRGateway can be configured many ways, but the following is based on how most software distributions are using DMRGateway.
Programming the radio for BrandMeister is not changed when using either the current or the upcoming version of DMRGateway.
Programming the radio for DMR+ is modified when using either the current or the upcoming version of DMRGateway. All commands are preceded by an 8. For example, to connect to TG 4639, the command is a private call to 84639. Switching to TG 8 is required to talk.
For XLX, the programming for the current DMRGateway for XLX Network 1 is not changed when the upcoming DMRGateway is used, but programming for XLX Network 2 is different and will not be used with the upcoming DMRGateway. Therefore, I recommend using only XLX Network 1 in the current system to keep most of the radio programming the same. One other thing - I have always used Slot 2 with XLX but I noticed some examples with versions of DMRGateway show Slot 1 being used with XLX, so my suggestion is to try both before doing a lot of programming.
For XLX Network 1 in the current DMRGateway and for all XLXs in the upcoming DMRGateway, create manual dial or channel contacts designated as Private call contacts in the 6xxxx range. The RX group should include the Group TG 6 to hear announcements.
- Disconnect 64000
- Status 65000
- Use 64001 to connect to TG 4001
- Use 64002 to connect to TG 4002
- …
- Use 64026 to connect to TG 4026
- Talk set TG 6 Group Call
The difference between the current and upcoming DMRGateway is how to set the XLX Master, using only XLX Network 1 in the current version.
In the current version in the [XLX Network 1] section of DMRGateway.ini, you need to change the Address= line to the IP or server/domain name of the master and restart DMRGateway. Not too convenient. To anticipate the upcoming DMRGateway, create channels with new commands to select a particular XLX master. They are private calls in the range 8001 to 8999, for example 8313 being XLX313. There is a host file, nominally called XLXHosts.txt that will likely be populated automatically, e.g. daily by a cron job.
A list of XLX reflectors running 2.0 that have chosen to be listed publicly here: http://xlxapi.rlx.lu/api.php?do=GetXLXDMRMaster …There is no general way to tell which of them are associated with transcoding servers. Reflector admins could customize their dashboards to indicate this, but nothing standard as of now.
Round Table discussion open system digital modes. Web site with information is at http://roundtable.tech Live listening and podcasts available.
X-Reflector Directory contains list of XRF and XLX reflectors and in many cases links to sponsoring organization web sites http://xrefl.net
73
John Fields
K6KD
9 September 2017