Picking apart the MMDVM DMR Gateway .INI file

So, I’ve been having a LOT of trouble getting my MMDVM to cooperate and pass Brandmeister traffic…I could connect to the TGIF network, and got green lights on the Pi-star dashboard, but it was really difficult to figure out what was going on. I could NOT connect to any Brandmeister Talkgroups.

On a whim, I turned EVERYTHING off, and started slowly turning options and networks back on, and testing through the parrot private call (private call 310997)

Somehow, turning DMR+ off seemed to be the ticket.

I’ll admit, I’m still figuring out what XLX and HBLink are…and why I would, or would not, want them on… but that’s not important right now.

I couldn’t, for the life of me, figure out what made DMR+ interfere with the brandmeister settings – I was trying to connect to a 313xxx talkgroup, so it SHOULDN’T have been re-routing anywhere.

The hard part was completely understanding the context behind all the rewrite commands…. I mean, it’s not HARD, but the github page doesn’t explain what the “range” variable is. I had to really read into the rules to understand them.  When someone gives a set of variable definitions (like in excel VBA documentation) I would normally expect to see descriptions of the variables as they are used.  

Re-write is defined here: https://github.com/g4klx/DMRGateway/wiki/Rewrite-Rules

the system description of the rewrite is:”TGRewrite=fromSlot,fromTG,toSlot,toTG,range”

think about the context this way….   the from/to fields are all the START of the range you want to route.  the “range” is the number of talkgroups to route.
Using this example:   TGRewrite=1,4009990,1,9990,5  

would route an RF call on 4009990 to 9990 on the network that the rewrite rule is included on.  so my portable, programmed to make a call on 4009990 would then be connecting to TG 9990 on (TGIF, presumably – see below).
Similarly 4009991, 4009992, 4009993, 4009994  would be routed, because i said a range of 5.  if i had said a range of 10, talkgroups up to 4009999 would be routed.

Now after poking through the .ini file, I am left wondering hy there’s several instances of rewriting something on a 1 to 1 basis (slot 2, TG 9990 -> slot 2, TG 9990)

Sooo… here’s my .ini file, along with some commentary on what’s going on (denoted using the “//” markings, like in C++)

[General]

(no changes here)



[Log]

(no changes here)



[Voice]

Enabled=1

Language=en_US

//changed this from en_GB to en_US just because the accent was a bit weird the way it was digitized

Directory=/usr/local/etc/DMR_Audio



[Info]

(no changes here)



[XLX Network]

(no changes here, and no routing involved)



[DMR Network 1]

//Brandmeister…  by default

Enabled=1

Address=74.91.114.19

Port=62031



TGRewrite0=2,9,2,9,1

//rewrite slot 2 to slot 2, talkgroup 9 to talkgroup 9… why?



PCRewrite0=2,94000,2,4000,1001

//  rewrite private calls – 

//  slot 2 to slot 2

//  94000 to 4000 through 95000 to 5000



TypeRewrite0=2,9990,2,9990

//rewrite slot 2 to slot 2, talkgroup 9990 to talkgroup 9990… why?



SrcRewrite0=2,4000,2,9,1001

//Source Rewrite…. 

//Slot 2 to slot 2.  

// inbound 4000 will come out as TG 9, up to 5000 coming out as 1010



PassAllPC0=1

//pass all private calls on timeslot 1

PassAllTG0=1

//pass all other talkgroups on timeslot 1

PassAllPC1=2

//pass all private calls on timeslot 2

PassAllTG1=2

//pass all other talkgroups on timeslot 2



Password=”********”

Debug=0

Id=********01

Name=BM_United_States_3102



[DMR Network 2]

Enabled=0

Address=168.235.109.210

Port=55555



TGRewrite0=2,8,2,9,1

//rewrite slot 2 to slot 2, talkgroup 8 to talkgroup 9



TGRewrite1=2,80505,2,505,1

//rewrite slot 2 to slot 2, talkgroup 80505 to talkgroup 505



TGRewrite2=2,80800,2,800,100

//rewrite slot 2 to slot 2, talkgroup 80800 to talkgroup 800 through 80899 to 899



TGRewrite3=2,83801,2,3801,8

//rewrite slot 2 to slot 2, talkgroup 83801 to talkgroup 3801 through 83807 to 3807



TGRewrite4=2,89990,2,9990,1

//rewrite slot 2 to slot 2, talkgroup 89990 to talkgroup 9990



TGRewrite5=2,80001,1,1,9999

//rewrite slot 2 to slot 1, talkgroup 80001 to talkgroup 1 through 90000 to 9999



TGRewrite6=2,80001,2,1,9999

//rewrite slot 2 to slot 2, talkgroup 80001 to talkgroup 1 through 90000 to 9999



PCRewrite0=2,84000,2,4000,1001

//  rewrite private calls – 

//  slot 2 to slot 2

//  84000 to 4000 through 85000 to 5000





Password="********"

Debug=0

Id=********02

Name=DMR+_IPSC2-QUADNET



 

[DMR Network 3]

Enabled=0

Name=HBLink

Address=1.2.3.4

Port=5555

TGRewrite=2,11,2,11,1

//rewrite slot 2 to slot 2, talkgroup 11 to talkgroup 11



Password=*********

Location=0

Debug=0

TGRewrite0=2,11,2,11,1

//rewrite slot 2 to slot 2, talkgroup 11 to talkgroup 11



 

[DMR Network 4]

Enabled=1

Name=TGIF_Network

PCRewrite1=1,4009990,1,9990,1

PCRewrite2=2,4009990,2,9990,1

// for timeslots 1 and 2, keep the same TS

// route private call network 4009990 to 9990



TypeRewrite1=1,4009990,1,9990

TypeRewrite2=2,4009990,2,9990

// for timeslots 1 and 2, keep the same TS

// route talkgroup network 4009990 to 9990





TGRewrite1=1,4000001,1,1,999999

TGRewrite2=2,4000001,2,1,999999

// for timeslots 1 and 2, keep the same TS

// route 4000001 to 1 through 4999999 to 999999



SrcRewrite1=1,9990,1,4009990,1

SrcRewrite2=2,9990,2,4009990,1

// for timeslots 1 and 2, keep the same TS

// route network 9990 to 4009990



SrcRewrite3=1,1,1,4000001,999999

SrcRewrite4=2,1,2,4000001,999999

//for both timeslots

//Route network 1 to 4000001 through 999999 to 4999999 (add 4,000,000)



Address=tgif.network

Password=*********

Port=62031

Location=0

Debug=0

Id=*********

so to boil it all down, here’s a routing table….

Note: All unlisted talkgroups will be passed through to Network 1 (BM, in this case)

The real kicker here? 313xxx should route straight through to Brandmeister with no routing errors – and DMR+ rewriting/routing has NOTHING in that range. So far, this investigation has solved NOTHING… though turning DMR+ off does fix my issue for the time being.

On a related note, there is an “overlay” of talkgroups, which serves to translate the various network talkgroup IDs to the proper RF channel values to allow proper connection on the IP side – this is discussed and posted here:

https://forum.pistar.uk/viewtopic.php?f=5&t=2730