There is a very good article on HBLink3 by its author Courtney Buffington N0MJS.

What is it? What can I do with it? When do I not use it?

For a full description of what it is, go to https://github.com/HBLink-org/hblink3.

Unless you are an experienced programmer, you will not understand much of it.

If you are interested in Networks and how they work it certainly gives an insight to what occurs on DMR when a call is made.

There are specific warnings by Cort as to its use, that he is not responsible if you misuse or abuse the software. Certainly some of the misuse is due to lack of comprehension of what can happen if the software is wrongly configured.

What can I use it for? To be frank, there is no real need for it, but it has some practical application in two ways that I can envisage.

The first of these is a complete stand-alone network for an organisation performing a specific function, and for that I mean Radio Amateur Emergency Networks. It will provide a closed network over a private wire or private communication installation, provided that there are a number of repeaters that require linking together in a fashion that provides continuity and a fixed protocol. If a single repeater is envisaged then an HBLink server serves no purpose, pardon the pun.

The second of the applications I can see in my case is permitting a number of users to use the same range of talk-groups that go to different networks that will not be linked. That sounds complicated but it will become clearer. We need to understand the DMR Gateway first.

In the configuration of the MMDVM and usually administered by a Pi-Star installation, BrandMeister would normally take prime spot in the DMR-Gateway set-up, and no modifications of talk groups are necessary. It is easy to trap the the other networks due to the rigidity of the talk group structures in place there to make the DMR-Gateway an easy proposition.

I have some repeaters in France, that are already dual network – BrandMeister and IPSC2 using the DMR-Gateway. On their own these two networks do not interact. However the talk groups are similar in that both have 208 as the centre of activity, and share the same MCC arrangement of the rest of the talk groups 2080-2089, 20800-99. However they cannot be used at the same time on the same repeater, as they will not be routed correctly. However DMR-Gateway on the MMDVM protocol uses Talk Group ReWrite instructions. What this means is that BrandMeister Talk Groups in a code plug will be ‘normal’ in that they remain the same, but Talk groups for IPSC2 will be summed with 8000, 80000 and 800000 to the talk groups to be received by the second network and ignored by the BrandMeister server connection. So talk group 208 for BrandMeister remains as 208, but 208 for IPSC2 becomes 8208, 2085 becomes 82085, and 20884 becomes 820884. The TGRewrite instruction set e.g. TGRewrite0=1,8001,1,1,999 – takes any talk group transmitted on Time Slot 1 beginning with 8001, and transposes it to time slot 1 on the second network, on talk group 1 for a range of 999 talk groups.

Arranging this for a series of Talk Groups can take care of any range but because it is configured specifically for IPSC2 France it cannot be projected onto any other IPSC2 network that can carry the same ranges, such as IPSC2-Phoenix-E. This is for two reasons, the first being that IPSC2-France3 does not carry the same interlinks for the talk groups 80-84. Nor does IPSC2-Phoenix-E carry the interlinks for 2080-2089. However I would want to keep this range to minimise the number of talk group options in the code plug.

What I want to do therefore is create options that no matter what talk group I use in the IPSC2 range, goes to the correct IPSC2 server, so that 8208 (208) will end up on IPSC2-France3, and 8235 (235) and 8080-8084 (80-84) go to IPSC2-Phoenix-E. I cannot do this directly in MMDVM to two networks as I can only have one set of TGRewrite instructions. So I keep these instructions intact, but send them instead to my HBLink3 server, that can specifically target the resultant groups and sent them to the correct network.

I have already showed that 8208 becomes 208 after the instructions are invoked, and it follows that 8235 becomes 235.

In the configuration file of HBLink3, the host server becomes the “Master”, and the other networks to which I want to connect are the “Peer” and are designated “Repeater-1”, “Repeater-2”, “Repeater-3” etc. and not to be confused with true repeaters.

It is important to comply with the strictest of guidelines that as a Peer user that no networks be linked together, as this can create issues that could result in the minimum of disconnection from the networks or complete banishment if persistent behaviour is not discontinued.

These ‘Repeater” connections are the normal configuration that would apply when connecting your own radio repeater MMDVM to any network, with the IP address, Port Number, Password, User ID and coordinates.

This itself is not enough to make the “Bridge” to the networks, as it is this that has to be carefully controlled by the rules that have to be carefully adjusted.

Whereas BrandMeister is totally open in its use of talk groups, HBLink3 has to be configured down to the last talk group and slot on which it can be used, so it very restrictive. It is not a network in itself, but a bridge to possibly several networks. And it is important bearing in mind that I do not want to link 208 over two networks nor do I wish to link any other talk group to its equivalent on any server.

Because HBLink3 runs on Python, most of the work is done with the rules.py file where we make the bridges between our “Master” and “Repeaters”. Every individual talk group has to be configured together with the slot on which it will be used, its time-out value, and the configuration of its destination has to be carefully planned. I carefully avoid using two ‘Repeaters” in the same “Master” designation of a talk group.

For example:

    ‘IPSC2-860’: [

            {‘SYSTEM’: ‘MASTER-1’,    ‘TS’: 2, ‘TGID’: 860,   ‘ACTIVE’: True, ‘TIMEOUT’: 2, ‘TO_TYPE’: ‘NONE’, ‘ON’: [3,], ‘OFF’: [8,10], ‘RESET’: []},

            {‘SYSTEM’: REPEATER-2,    ‘TS’: 2, ‘TGID’: 860, ‘ACTIVE’: True, ‘TIMEOUT’: 2, ‘TO_TYPE’: ‘NONE’, ‘ON’: [4,], ‘OFF’: [7,10], ‘RESET’: []},

        ],

    ‘IPSC2-208’: [

            {‘SYSTEM’: ‘MASTER-1’,    ‘TS’: 1, ‘TGID’: 208,   ‘ACTIVE’: True, ‘TIMEOUT’: 2, ‘TO_TYPE’: ‘NONE’, ‘ON’: [3,], ‘OFF’: [8,10], ‘RESET’: []},

            {‘SYSTEM’: REPEATER-3,    ‘TS’: 1, ‘TGID’: 208, ‘ACTIVE’: True, ‘TIMEOUT’: 2, ‘TO_TYPE’: ‘NONE’, ‘ON’: [4,], ‘OFF’: [7,10], ‘RESET’: []},

        ],

Each talk group has to be specifically targeted at the proper network. The above example shows two talk groups 860 and 208, that have arrived from my MMDVM already stripped of their preceding ‘8’ by the TGRewrite. 860 is accepted by the master, and directed only to “Repeater-2” that has already been designated by the HBLink3 configuration as the IPSC2-Phoenix-F in this case. 208 however arriving from the same source to the “Master” is configured to go the “Repeater-3” designated in the configuration as the IPSC2-France3 server. I could if I was very naughty include 860 to go to “Repeater-3” to be routed to the French server, but as this talk group does not appear on the French master table there it would have no effect.

It is for this reason that HBLink3 should not be used on BrandMeister, as Groups could be irresponsibly re-directed across multiple networks. It is not that BrandMeister administrators are being difficult, it is folly to consider doing anything in this regard to jeopardise the very sturdy and already open network. Especially Do Not Connect ANY MultiNational Talk-Groups. The HBLink3 Software may be open source, but both here and on Github you have been warned.

Yes, we can now connect everything to everything, but do we want to? Just because we can, doesn’t mean we should. Be circumspect.

Leave a Reply