This document is intended for the following persons.
Those persons concerned with BrandMeister MMDVM DMR Repeaters, that is to say owners, sysops and users committees.
MMDVM is an open system and as such can be configured to individual needs. When connected to a server it has multimode capabilities, but in this document the only mode under discussion is DMR BrandMeister.
It is understood that there is sufficient material available to describe the operation of DMR tier II, so there is no need to include it here.
This is a discussion document intended for opening minds to the possibilities of DMR-BrandMeister that have not been fully tested.
I will introduce a concept of a common framework, a system of conventions that are largely already in place but not couched in such terms, within the recognised policies of the BrandMeister protocol.
I will invite the concept of Talkgroups rather than Reflectors.
I will try to open your minds to the further development of Repeater ID based Talkgroups, an extension of private calls.
The MMDVM repeater construct in BrandMeister.
An MMDVM repeater, when in two slot duplex operation and fully connected to a BrandMeister server, is open to ALL talkgroups on EITHER slot in Dynamic * mode from the RF path only.
There are four important activities for which to watch and consider in an observable MMDVM DMR repeater, illustrated by snapshots from a PiStar dashboard:
TX DMR slot # – There is ongoing activity on the slot # originating on the network path, opening a fixed * talkgroup on the current repeater.
RX DMR – There is ongoing activity on the repeater originating on the RF input path, opening a talkgroup as dynamic *. A fixed * talkgroup also becomes dynamic * at this point.
Listening DMR – The recent activity has just ceased on the repeater with the possibility it may continue on the same now-dynamic talkgroup / reflector. The open dynamic * talkgroup remains available for about 15 seconds until….
Listening – All activity has ceased, and the repeater is in standby. Dynamic * talkgroups may now be superseded by another, or simply drop out of use at the observed repeater. They are removed from the Dynamic TGs box after 10 minutes but remain in the DMR Repeater Box lower left as enabled on the slot for a long time until another talkgroup is called up on the repeater, supplanting it. All RF dynamic groups can remain in the administration box for their individual 10 minute period, but only the last used on RF will show as enabled in the DMR Repeater box.
Some Local talkgroups like TG9, TG10 and TG99 are not relayed onto a server but must remain purely local. TG9 use will depend entirely on the availability of the slots. TG9 and TG10 activations only appear as RF gateway activity on a Pi-Star Dashboard, but TG99 transmissions appear as dynamic talkgroups in the administration in addition to the gateway activity. Reflector connections on TG9 do not appear in the administration, only in the gateway activity.
Talkgroups are registered according to their international function or their locality and function by numerical code commencing with their country code. See this table (click to view).
When programming a code plug, the “group calls” are of the foremost importance, and these are the talkgroups in sequence, the talkgroup number being the most important, but the talkgroup name is by personal preference. Without a talkgroup table in the code plug, no further progress can be achieved.
Conventions: In repeater design it is important to consider a convention, whereby all repeaters would resemble each other to some degree so that the users can program their radios with some degree of conformity, and can recognise the connectivity when moving between repeaters. The first part of the convention would be to define the use of the 2 slots. Loosely speaking this has already become the norm in that slot 1 is largely international/national/language based, and slot 2 is largely regional/local/reflector based. For example it would seem natural for England that talkgroup 2350 should always be on slot 2 on repeaters and 235 will be on slot 1. It would seem to be outside of the convention should neighbouring repeaters adopt different slots. This may not necessarily be the case in other countries. The second convention would be to accept that the repeater system operates on a first come – first served basis on each of the two slots. If the slot is busy, it is occupied for the duration of the talkgroup or reflector activity, until that activity ceases, and the repeater returns from “TX DMR Slot#” or “RX DMR” to “listening” and not just “listening DMR”, which is the intermediate stage. Remember the 15 second duration before the talkgroup drops out entirely. The third convention would be to accept that the sysop / managers / users committee’s decision of an individual repeater’s configuration is final, subject to the first and second convention.
Fixed * or Dynamic *?
All talkgroups on MMDVM with BrandMeister are dynamic on set-up, that is to say they are inactive and unconnected to the wider network until they are activated at the repeater by someone transmitting to the repeater on that talkgroup. The talkgroup immediately relays all the following data to the server system, assuming that all the servers are in sync. This communication will not appear anywhere else other than on the transmitter of that repeater in use unless one of the following three scenarios is in operation.
1. The same talkgroup is simultaneously activated on another repeater, thus permitting communication only between those two repeaters. Should another repeater be activated on the same talkgroup during the same brief period then it too becomes synced and party to the communication.
2. The same talkgroup has been fixed, or pre-programmed on one or more repeaters, thus permitting full and uninterrupted communication on that repeater or repeaters.
3. The talkgroup is being linked on another repeater by a permanent connection to a reflector via talkgroup 9 slot 2 on the distant repeater.
The term “Static” has been used to describe fixed talkgroups, but that does not accurately describe this function as they are not being raised to a high potential voltage.
In Pi-Star, use of the BrandMeister Application Programming Interface (API) or in other MMDVM control systems, the use of self-care in the BrandMeister.Network, give full control to the sysop over the Talkgroups and the slots that he/she wants active on the repeater bi-directionally without users needing to open the talkgroup by pressing the PTT. These actions also can govern the active reflector.
There are two ways to determine the state of a talkgroup, one of which is called “whitelisting”, the other by use of the BrandMeister API or BrandMeister Self-care as indicated above.
“Whitelisting” or forcing a talkgroup to a slot has major drawbacks, in that it restricts the MMDVM to only the talkgroups in the whitelist. It means that anyone attempting to use a talkgroup on the affected repeater will be refused if the talkgroup is not on the list for the slot. This method is not conducive to full use of the MMDVM host nor to the effective and proper use of the BrandMeister Network and should not be implimented. I see no reason for it whatsoever. “Blacklisting” is very frowned upon.
Anyone using a non-standard talkgroup that creates interference contrary to the efficient and good running of a repeater should be discouraged from his activity and educated where possible. I refer for example to the persistant blipping-up of TG91 on slot 1 and not commiting to a full contact. It wakes the repeater for a long period unnecessarily.
When deciding the status of talkgroups, we need to consider all three conventions. The first convention may govern the choice of talkgroups on slots. But then the second convention must apply as ongoing activity cannot be overridden. Then by applying the third convention, Talkgroup 9 on either slot should never be fixed as it is always intended that this slot is local in use, therefore dynamic and PTT operated.
How many talkgroups can be fixed?
There is no restriction but the application of common sense. For example:
a: If a sysop wants to create a talkgroup for local users and affiliates * * of a repeater, then it would make sense to select a slot less active, if he has already fixed TG2350 on slot 2. User A an affiliate outside the area calls User B in the area of the repeater on TG2350 on slot 2 of the repeater, they then agree to QSY to a created talkgroup – fixed TG236186. It would make sense that this group would be on slot 1, so that future calls on fixed TG2350 will not interfere should TG235186 have been on slot 2.
b: If a user A on fixed TG2350 makes contact with user B on another repeater on fixed TG2350, and want to QSY, and want to select TG 2351 they can do so in two scenarios. i. The TG2351 can be Dynamic at either end, as it will not matter on their respective repeaters, with the proviso that as it is dynamic then the users must operate their PTTs to open the talkgroup. No other users will hear the conversation anywhere that does not have a Fixed TG2351 or a reflector open to this talkgroup. ii. This is effectively point to point communication using only two repeaters on the network.
Locally at the repeater(s), it does not matter that there is a user on TG2351, as the second convention applies. Until this user has finished, and the repeater has dropped from “listening DMR” mode to “Listening” mode, any other user cannot use the same slot, no matter what talkgroup he is on, except TG2351 and tailgating the other user. You have only to watch a Pi-Star dashboard for long enough to see how BrandMeister governs the traffic on a talkgroup and therefore a repeater’s operation.
It is technically possible to have several fixed and frequently used Talkgroups on a repeater, within a reasonable limit. For example on a southern repeater it could be sensible to have TG2350, TG23510 (south east UK) fixed on slot 2, and TG235, TG235186 fixed on slot 1. Access to International and other regional groups and chat groups could be dynamic and called upon according to local requirement. The dynamic Talkgroups drop out of use at “Listening”, and would not impinge upon the fixed groups. Any fixed talkgroup activated at the repeater becomes the active dynamic talkgroup for the duration of the contact until it ceases, and “Listening” is achieved.
Remember that even a fixed Talkgroup becomes dynamic at the repeater when it is activated. So after 15 seconds has elapsed at the end of the activity and the repeater is now “listening”, any other talkgroup can be activated on the RF input provided that another fixed talkgroup isn’t activated on the network side ahead of the attempt. The good thing here is that even though the local repeater is still active for that 15 second period “listening DMR”, the user can activate another talkgroup locally ahead of time overriding the former dynamic talkgroup, assuring a good QSY to continue the contact on another fixed or dynamic talkgroup.
Another thought occurs to me, do repeater users want or need a national hailing talkgroup? In my opinion – yes, but does it need to be TG 2350 on slot 2, or perhaps 235 on slot 1. The French system does just that, with a hailing talkgroup 208 fixed on slot 1, and chat channel talkgroups 2080-2089 dynamic on slot 2. That makes the concept of point to point communication more valid, with other repeaters not being party to a chat except on two repeaters on which the users are situated. Perhaps we are too entrenched in our ways to change.
With the advent of the Pi-Star MMDVM front end by Andrew Taylor and other people in the original web based dashboard, full control has been established of the MMDVM host, enabling wider and extensive use of the MMDVM, over and above that of merely a pilot of a reflector based system. Most but not all of the UK repeaters appears to have reflector 4400 on TG9 slot 2, which works after a fashion, but it is debatable if this is really the most effective use of the technology.
Connection by reflector is the most simple method of connectivity for a new user as he can only program one talkgroup in his one zone on his one repeater channel, and by using his private call function on transmit he can steer his way round the reflectors accessible from TG9 in his radio. On a reflector based repeater that has only slot 2 Talkgroup 9 active, this is not perhaps the best use of a repeater for three reasons. 1. Any other listener on this repeater is subjected to the wiles of a user making his choice of reflector and not shutting it down when he has finished (Yes – of course there is the automatic disconnection and reset.) 2. Outside users wanting to make contact with a known user of that repeater will be for the time being be unable to do so due to a change of reflector from the normal (4400 – TG2350). 3. Users taking advantage of the MMDVM on that repeater can use TG2350 as Dynamic but this doubles up the fixed reflector 4400 on TG9 if it is for the time being not in use.
Already I hear a clamour of dissent, “there would be blocking of the slot by continued occupancy of the other talkgroup of the slot!!!!!!”
Yes, there is one positive point to a reflector based repeater, in that the user of that repeater can interrogate the TG9 slot 2 by private call to 5000 to solicit which reflector is active if at all. The user will always hear the activity thereon, and know that that the repeater slot is occupied. On the contrary a user trying TG2350 on a talkgroup based repeater finding himself refused, has no knowledge of other activity on other talkgroups without checking a dashboard or switching around the other talkgroups to see why.
However I refer you to the second convention.
Again to reiterate, the reflector based repeater is also a first come-first served system, but lacks finesse, and the slot on the repeater would be blocked for all other local users in any case. It also forces the user to make manipulations of his radio, operations of the keypad etc. that in a talkgroup based repeater would be a click-rotate of one knob in a more sophisticated and more efficient code plug. Incidentally 4000 does not unlink talkgroups.
With MMDVM repeaters, reflector use is largely superfluous. If the user knows the reflectors destination talkgroup, he can define it in his code plug as a talkgroup.
With an MD380 or similar, programmed with Tools, talkgroup selection can also be made from the menus. This doesn’t mean that reflectors cannot be used, as a reflector can sit alongside fixed talkgroups. However it would be pretty pointless to maintain a reflector connected to a talkgroup that is already available in the MMDVM either as fixed or dynamic.
Even a DV4Mini user does not need to use reflectors other than reflector 4999 that gives the user access to extended talkgroup functions through BrandMeister Self-care. The latest Hot Spots are also unrestricted by Reflectors and can use all the talkgroups on two slots.
There is one thing of note in a fixed talkgroup based repeater, in that the duty cycle would probably increase, as any fixed talkgroup could be activated during the quiet times of others.
Whilst some repeaters sysops have opted for regional grouping by subscribing to fixed regional talkgroups, not many have opted for other routings. * * For example each repeater has a DMR ID, which in itself can be used as a talkgroup recommendly in slot 1 for local priority. With code plugs suitably and similarly programmed, a local user can remain in local touch with his group from outside his repeater area, through an MMDVM repeater elsewhere, provided the slot 1 is unoccupied, without any intervention of the second repeater’s sysop.
Basically any DMR ID active on the network can become a Talkgroup. This is the basis of personal calls on DMR.
I have looked at the whole concept of DMR:BrandMeister as a tool and it performs as an excellent medium for communication over internet.
I have looked at what exists as a standard, and already there is the basis for the three conventions.
Having already built two MMDVM DMR-BrandMeister repeaters F5ZLR & F5ZLW, I have carried out extensive tests in order to see how the talkgroups work, both as Dynamic and Fixed (Static). Both are on Pi-Star although of different designs. I have made an extensive study of the activity on their Pi-Star dashboards that has enabled me to come to these conclusions.
I have also discussed the DMR-ID talkgroups with other Repeater keepers, and my suggestions have been accepted and are in constant use.
As a hot spot user for several years, I have been a user of reflectors, and can see the advantages of Talkgroups over the restrictions of Reflectors.
I invite debate and commentary: Be aware that I have a professional communications and computer background. I have been a communicator longer than I have been an amateur. I manage the two DMR repeaters, (and I am party to two others,) and manage a further network of several analogue repeaters all based on the Raspberry Pi in all its flavours.
Chris JACKSON F5VMR G4NAB