The more I listen to DMR, the more I hear the confusion in numbers of users, apparent in the lack of understanding of how and why it works, mainly due to the uncommon propagation of terminology and the wrong context. So I hope the following discourse may help. Other modes are available but I am sticking with DMR for this article.
We start this program by understanding repeaters first of all. Some of this understanding is primarily BrandMeister related, but it can apply equally to other networks as the technology is the same.
Normally a repeater has two available SLOTS where the repeater manager has allowed them. The repeater manager can block use of these in the repeater firmware or mmdvmhost, thus SLOT 1 or SLOT 2 or Both can be closed off to users, although the repeater would be pretty useless without an active SLOT.
The next thing to understand is that a talkgroup is NOT a reflector.
Talkgroups are data routings within the system of servers. For reflectors see the specific paragraph below.
I am now going to restrict the next part of this discourse specifically to mmdvmhost repeaters, which are largely homebrew, although some of information may well apply to other commercial repeaters.
A repeater manager or sysop can Whitelist talkgroups within the repeater thus permitting controlled dynamic use, which means some transmissions may be refused on unwhitelisted talkgroups. I have noted this in the mmdvm repeaters that I have built. A log entry will show that an unauthorised talkgroup has been refused. However by omitting a whitelist command, a repeater can be dynamically open to all talkgroups anywhere, which can lead to anarchy.
A standard DMR repeater will have Talkgroup 9 as standard and active on Slot 1 and Slot 2, which give local communication only over the repeater. Any transmission on these talkgroups will never pass over the network. In technical terms these two talkgroups are Dynamic and PTT activated, however they can be made locally fixed or static by whitelisting them.
The repeater manager can also whitelist other talkgroups on the repeater by allocating them to a specific slot. So for example in the UK Talkgroup 2350 the national centre of activity is normally allocated to Slot 2, however on the 5B4CY repeater in Limassol it (2350) is on Slot 1. Having them whitelisted permits them to be Dynamic Talkgroups, but until permission is granted at the server, they can not be Static or Fixed talkgroups, that is to say fully active. Once this is so, all transmissions on the talkgroup can pass over ALL systems similarly configured without the need to blip the PTT to the repeater to open the link to the talkgroup.
On BrandMeister the method of fixed talkgroups is done through Self-Care by the sysop (repeater manager). A Dynamic talkgroup generally resets to off at the repeater output after a period of time, usually 10 minutes if unactivated at the repeater input. Fixed talkgroups remain on line, so that whenever there is activity, all systems with the same fixed talkgroups will open simultaneously.
I make a comment here that there is such a thing as repeater overload. A repeater keeper can put too many Static or fixed talkgroups on a repeater, I know as I did it in the beginning. If these Static groups are particularly busy and are on the same slot then this activity can render the repeater useless for 100% communication. This can occur even if the local activity around the repeater is light, as outside transmissions would block the channels. It would be better that these talkgroups would be Dynamic and available for local users by PTT activation as and when they were required.
Clusters are groups of repeaters that have agreed to participate in a joining by talkgroup, that has no wider propagation other than those in the agreement. This cluster can be local in nature as in the South West Cluster in the UK, or wider due to an interest in shared technology. Generally there will be no connection unless requested from outside the grouping.
For anyone setting up a repeater, there are two considerations. 1. the needs of the local users, 2, the need for interconnectivity to the wider world.
Looking across the network as a whole, slot 1 seems best used as an international medium with double and triple digit talkgroups, and slot 2 as a local/national medium with access to four or five digit talkgroups. There would be no need to fix a reflector as standard as these can be programmed by the users on demand, and subject to a reasonable timeout. 4400 would be superfluous as talkgroup 2350 would be the first choice of dynamic or fixed talkgroup, likewise 4401, 4402 etc. as 2351 and 2352 would become the dynamic equivalent talkgroups.
So far I have covered simple Talkgroup Connections that are channelled by connections through the server through the Talkgroups database. A repeater can be connected firstly and most simply by Talkgroups, or secondly and more dynamically through Reflectors.
Reflectors have a relational connection to a corresponding talkgroup, although not all talkgroups have a corresponding reflector. Reflectors have a two-fold purpose, in that primarily they provide a bridge out from a repeater to a wider context, or secondarily a bridge in permitting a whole new group of people on Hot Spots to access the available talkgroups via the reflector connections. Some reflectors are bridges to other modes, and other systems on other bands.
With a repeater on Talkgroup 2350, we find that it is accessible by anyone who can achieve a connection to reflector 4400, via the server system. Likewise a HotSpot user on reflector 4400 can communicate with all repeaters having a static talkgroup of 2350. Notice here that the talkgroup has to be static or fixed for the communication to be heard on each repeater, or if dynamic to be heard has to have been opened within the previous five minutes by PTT at the repeater concerned.
The repeater manager can set up a default reflector on the repeater by asking permission from the server, by self-care in BrandMeister as sysop, setting a timeout as 0 seconds for a Static connection or can set a timeout (e.g. 900 Secs) for the connection, thus making it Dynamic. This may permit a repeater to have an out-of-area reflector or an overriding connection to Talkgroup 9 on slot 2. To ascertain if a reflector is currently connected to a repeater in use, we make a private call to 5000, when the announcement on the repeater will indicate a connection or otherwise.
A repeater user can force a connection to another reflector by addressing the repeater on talkgroup 9 slot 2 by transceiver with a private call of the selected reflector, or disconnect the current connection by addressing it with a private call to 4000. The server then makes the changes to the repeater linking, subject to the rules in force on the self-care or other repeater control system in place.
To find out how to change reflectors, we can read some instructions elsewhere.
However we have to give a little advice here; whenever a hotspot user has declared that he wishes to QSY to another reflector, he must be given the opportunity to issue the private call to the new reflector, for if the channel becomes immediately occupied, he will be unable to do so.
So that wraps it up for repeaters, their slots and talkgroups and how they intersect with other repeaters via the server system.
Hotspots are systems that are in fact simplex repeaters that provide access to the world of DMR and other modes via Reflectors. Hotspots such as the DV-Mega, Open Spot, Blue DV, and the DV4Mini require the owner to address them correctly with their own DMR-ID with or without a two digit supplementary. (The DV4Mini cannot be added to in this way.) The software that interfaces the devices needs a connection to a master server either by a fixed internet or in many cases a mobile phone 3G or 4G otherwise communication over the selected network is impossible.
A user has a couple of ways to use the hotspot, but primarily needs the hotspot to have a simplex frequency programmed in the interface, and a radio similarly programmed in the CPS. My DV4Mini accepts 438.65 calls. Read further on for MMDVM Devices.
Now I have recently discovered a new way to use the DV4Mini so I will describe that secondly but firstly I will describe the easy method.
I use the DV4Mini Control Panel as adopted by K2DLS, and the firmware version 1.77 in the DV4Mini device. I will not describe how to set it up, but in my case I have to select DMR+ on the front page and a BM master server in expert setting.
Once running I can do one of three things.
I can use the group call key on the side of the MD380 / RT3 and call the reflector I require. The DV4Mini (usually) changes to the reflector. That is the easy way.
The second way is to talk directly to the software through VNC and select the reflector on the desktop application and connect. That is also an easy way but means that I have to carry around the radio and the tablet.
That was the easy method.
The more difficult method means creating further channels in the radio codeplug for the DV4Mini frequency but allocating a talkgroup to each channel. So I would have multiple channels with multiple talkgroups. I then have to set the DV4Mini to reflector 4999 – for extended talkgroups. Built into the K2DLS image is a python program, with some tables in /etc/bmxtg named buttons.conf talkgroups.conf and masters.conf. By careful study these files can be changed to contain information relevant to your region and requirements. By running the bmxtg from the desktop, you change the talkgroup accessible by the device, and you select the relevant channel in the radio with which to communicate.
The third method is to select 4999 on the DV4mini desktop, and then select selfcare on the Brandmeister pages, and select extended routing in the services menu. In the available boxes, select the DV4mini device and enter the selected talkgroup.
That is the difficult method. As I wrote, I favour the KISS principle, so this method is not simple, but proves the point of Murphy’s Rule….if someone can, someone will.
MMDVM hotspots are becoming more in vogue as the software develops. The software Pi-Star developed by Andy Taylor MW0MWZ is phenomenal. Full control over an MMDVM device by web interface is terrific. I will not go into detail on the software as it will take a whole new chapter. But I use the software for repeater control on F5ZLW that runs on a ZUM-Radio Pi-Hat. The older MMDVM repeater F5ZLR runs on an arduino system with a Pi 2 in series is controlled by SSH, which for me is very KISS.
Essential tools for DMR particularly BrandMeister include hoseline and self-care. Similar tools exist for other networks although the philosophies remain separate.
Any terms of use such as TAC, Chat, Group are purely local and may mean something completely different to users unfamiliar with their usage so be judicious in their use. You may think it makes you sound clever, but it’s not. Until a term is in general use put it to one side and make yourself clearly understood.
By all means if you have a code between friends use it but don’t expect it to be understood by everyone.
