Limits on a Multiple DMR Gateway

[kk6don]

I have just recently began exploring other DMR networks other than Brandmeister. (It's a big world out there, might as well explore)

My question is this; Pi-star uses a numeric prefix for talkgroup routing. Brandmeister is the default , and doesn't use a prefix.

Assuming I pick the number 1 as the prefix for the next network, with a 7 digit talk group id, and some are 7 digits with a starting number of 7,
my talkgroup id would be in 17,000,000 ish. range. A prefix of 4 would be in the 47,000,000 range. But the limits of radio talkgroup id's are in the 16,000,000 range.

So 7 digit talkgroups, although technically workable by pi-star, are not available in a multi- dmr setup???

[KN2TOD]

Basic question here: how do you determine when an "id" is a talkgroup (on any network) and when it's a DMR ID? Traditionally, talkgroup numbering (BM anyway) is limited to 5 digits, while DMR Id's are always 7 digits. There are some exceptions of course: for instance, Pi-Star "traps" out, intercepts select 7 digit ids to service control functions; those id's are considered invalid DMR id's anyway (look at Pi-Star Remote in the Expert section). And id's can be filtered, rewritten by rules invoked when cross-communicating networks - this can be done at the Pi-Star level and/or by various gateways, reflectors and repeaters external to Pi-Star. Typically, one sees 6 digits used for transitory, ad-hock talkgroups, not requiring rewrite rules, but that is usually limited by the particular network being utilized and by prior arrangement amongst the participants involved.

But it is possible to communicate radio-2-radio, in private mode, by treating the respective 7-digit DMR id as a "talk group". Most codeplugs can handle this construct, and BM, I know, can handle such traffic. (Don't know about other networks.) So, one can not just create an ad-hock 7-digit talkgroup and start using it without risking stepping on existing DMR id's or getting banned for using an illegal DMR id.

[kk6don]

I am not referring to talkgroup id vs an individual's id.

Here's an example. On the TGIF network, there's a talkgroup labelled "3103733 Wnc Amateur Radio" . Various Pi-star overlays assign TGIF network a prefix of 4, Bringing the number you would need to enter on your radio as 43103733. But the largest talkgroup number you can program into a radio is 167xxxxx not 431xxxxx

Since Brandmeister has only a small handful of 7 digit talkgroup id's, and tgif has 50, and think I will try and redo the gateway rules so TGIF is the default, and Brandmeister requires a prefix..

On a separate note, many gateways have a line rewriting the talkgroup to itself...Why?

[KN2TOD]

Here's an example. On the TGIF network, there's a talkgroup labelled "3103733 Wnc Amateur Radio" . Various Pi-star overlays assign TGIF network a prefix of 4, Bringing the number you would need to enter on your radio as 43103733. But the largest talkgroup number you can program into a radio is 167xxxxx not 431xxxxx

Are we talking about the limits on the number of entries (lines) in a talkgroup table or limits on the value of a particular entry in that table? I'm not aware of limits on the values in a particular row - I'll have to check to see what various codeplug editors do here.

On a separate note, many gateways have a line rewriting the talkgroup to itself...Why?

Such rules are 1) examples of what can be coded, how they are to be coded, and 2) passthru: many talkgroup numbers are the same in multiple networks - TG x in network 1 is rewritten to TG x in network 2 and not to some other TG.

[AF6VN]

Since Brandmeister has only a small handful of 7 digit talkgroup id's, and tgif has 50, and think I will try and redo the gateway rules so TGIF is the default, and Brandmeister requires a prefix..

Unless things have changed -- BM allows any individual to create an ad-hoc talkgroup by using their assigned individual unit number. The only difference between direct routing (person to person) and ad-hoc talkgroup is whether the contact is flagged as Private or Group. BM convention (as I understand it) is 7-digit = individual ID, 6-digit = repeater ID, less than 6 digits is a talkgroup (and the more digits, the narrower the focus: 3 digits nationwide, 4 digits regional, 5 digits down to statewide).

[VE3RD]

The default pi-star DMRGateway is not capable of accessing 7 digit talk groups

Check out this link for an alternative
https://tgifnetwork.createaforum.com/ne ... gateway-4/

This version uses filters to lock the selected network, such that only the selected network can access the radio. This eliminates any inherent network switching due to activity on an unselected network, which is a issue in the pi-star version.

The basics
Basic Mode uses 9001 to 9006 to select and lock in a Network, similar to the Openspot. 7 digit talkgroups can now be used on any network.
7 Digit Mode requires all Networks to use a prefix of 1 to 6 in a 7 digit string to select and lock in a network, 7 Digit talk groups will NOT work.
8 Digit Mode requires all Networks to use a prefix of 11 to 16 in an 8 digit string to select and lock in a network, 7 Digit talk groups will work with the following rule set. Assuming Net 5 which is locked with the 15 prefix
TGRewrite0=2,15000001,2,1,999999 // this ignores all tg below 15000001
TGRewrite1=2,1000001,2,1000001,5599999 //This catches 3037671
PCRewrite0=2,15000001,2,1,999999
SrcRewrite0=2,1,2,VE3RD,9999999

From Log File on startup
I: 2023-06-11 11:05:24.414 Rewrite RF: 2:TG15000001-TG15999999 -> 2:TG1-TG999999
I: 2023-06-11 11:05:24.414 Rewrite Net: 2:TG1-TG999999 -> 2:TG15000001-TG15999999
I: 2023-06-11 11:05:24.414 Rewrite RF: 2:TG1000001-TG6599999 -> 2:TG1000001-TG6599999
I: 2023-06-11 11:05:24.414 Rewrite Net: 2:TG1000001-TG6599999 -> 2:TG1000001-TG6599999
I: 2023-06-11 11:05:24.414 Rewrite RF: 2:15000001-15999999 -> 2:1-999999
I: 2023-06-11 11:05:24.414 Rewrite Net: 2:1-9999999 -> 2:TG0

Net 6 will work only up to 2^24=16777215

Locking a network filters the Gateway to only respond to the selected network.

TGIF runs numerous 7 digit talk groups. This version of DMRGateway provides two methods of accessing them