I have been active on this mode for the last two years and feel that I have acquired sufficient knowledge to form an opinion. I am not an expert in the precise technology, but I am well versed in human interaction to see where some are going wrong. some have it right, and some are in the middle and need a bit of guidance.
This information will serve primarily the repeater keeper/sysop, but give rise to questions by the users of the sysops as to how best to use their local repeater. My experiences relate to MMDVM-Type repeaters of which I manage two and help out with a third.
In examining worldwide usage of slots there appears to be a consensus that Slot 1 on a repeater is used for World Wide Talkgroups, and Language based Talkgroups.
Slot 2 on repeaters appears to be used in the majority for National, Regional, as well as local use. Talkgroup 9 is local use on Slot 1 and Slot 2.
Fixed (static) or Dynamic talkgroups?
Fixed talkgroups do not as a rule have a time-out, that is to say they remain permanently ON Bi-Directionally. Dynamic Talkgroups remain available from the repeater side by PTT, and stay Bi-Directional for 10 minutes until they time-out from the server. Fixed (static) talkgroups are made so in self-care by the sysop or on Pi-Star. Available static* talkgroups on the servers also have to be equally available in the repeater. (See next paragraph). *I really do not like the use of this term as it implies an elevation to high voltage.
I have recently moved one repeater F5ZLR from an Ubuntu based MMDVMHost to Pi-Star without any changes to the operation of the repeater, other than the improvement of the addition of the Dashboard – http://f5zgm.f8kfz.org:19389 will show the live operation.
Whitelisting and Blacklisting.
In my view there is no need to whitelist or blacklist any talkgroups as BrandMeister and MMDVM control everything for you.
In an MMDVM repeater all talkgroups are available as dynamic on either slot. This is a very wide selection, meaning that two users of the repeater can program their radios to use the same talkgroup but on different slots. NOT a good move. I have seen this on one repeater I have been observing.
The Pi-Star software is not a fix-all although some control is maintained over some talkgroups, through the use of the BrandMeister API in expert settings.
Talkgroups or Reflectors.
Repeaters should function entirely on talkgroups, but the facility exists on TG9 slot 2 to open a reflector to another talkgroup not already available on the repeater.
Most sysops have almost completely dis-opted talkgroup activity on a repeater and made it function entirely on reflectors. This is situation limiting by far, but at the same time provides a little experimentation for the users. However I have noticed that it also shows selfishness by some operators who prevent others from accessing the repeater or change the reflectors without consideration to others. While a repeater is open to a reflector the issue of a 5000 private call can elucidate the current connection, and a private call of 4000 can disconnect the current connection.
Simplistically, all one needs on a repeater are TG9 on both slots, but this makes for slight complications when changing reflectors. Having a range of talkgroups programmed in to the CPS is far simpler by turning a knob.
I find it very frustrating that some repeater users disconnect their routing on a repeater to the network, thus preventing me from contacting users subsequently within that repeater’s coverage.
HotSpot users have little option but to use Reflectors, unless they have recourse to Reflector 4999 and/or extended Talkgroups, as I do when I use a DV4Mini.
Special Note: If Talkgroup 2350 is available on the repeater and in the users codeplug, then it is absolutely pointless for that user to issue a 4400 private call on talkgroup 9 to connect to the reflector that corresponds to the 2350 talkgroup. It means effectively that Slot 2 has two pathways open to the same server talkgroup via two talkgroups on the repeater.
Too many Fixed Talkgroups available?
It depends on how useful you want your repeater to be. If you have no fixed talkgroups then no one from outside the repeater area can access it after the time-out on the available talkgroups has expired. If you have two, one on each slot, it begins to have an impact. Let us for example fix 91 on Slot 1 so that it is connected to the available world wide network, and fix 2350 (England) on Slot 2, then there will be lots to hear and invite a lot of interaction worldwide and locally (relatively), but the repeater will have a high duty cycle. If you make 235 (National UK) fixed on Slot 1, and 2350 (England) on Slot 2 then this duty cycle will drop considerably.
I run a repeater on soak-test at the moment with several fixed talkgroups on each slot, but as these fixed talkgroups are relatively inactive, there is very little chance that the slot will be blocked by other transmissions. I do not use reflectors. I see no need. I can have a contact on 2350 and QSY to 2352 without issue.
It is very clear to me that that some users do not look at the services provided at the repeater by the sysop. They make calls on non-existent talkgroups, They call up reflectors when there is no need, and they don’t take advantage of all that is available. Most of this is generally lack of knowledge, but I have found the stuff, why not them?
Code Plugs and Hot Spots.
So many time I have heard people on the air bemoaning the lack of knowledge or experience of this mode. This is a learning hobby – get over it and learn! There is a simple aid in these blogs, read it in conjunction with you CPS and make your own code plugs. If you have a hotspot, you need only TG9 and the frequency of the device at the very least. If you want to add more then do your own research and don’t rely on others, as you may be picking up bad advice.
A Final note to Sysops. Think about adding a Talkgroup with the repeaters ID number in one or both slots. Then if users have this in their codeplugs, and scan this talkgroup, users of the repeater can still call into the network when not within the repeaters coverage.
A final note to everyone, never ever consider DMR in its current state as a supplement to an emergency network. If there is an true emergency, the infrastructure may be the first to suffer. Use analogue communications or HF. If you come across a local emergency whilst mobile necessitating attendance of the emergency services, use a telephone or someone truly local to you. To pass information pertinent to any emergency requires local knowledge. Someone on a DMR network NOT in your locale cannot provide this as a service.