Topics

Is this even possible?

Jim Gifford - KD4PPG
 

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG

Corey Dean N3FE
 

I am actually doing exactly what you are doing.  I have my hblink setup with multiple connections.  8802 is also on my TS1.  I am doing this with both Motorola repeaters and a Homebrew repeater.  However I am testing a pre-release so my configs won't work for you just yet.

I do NOT use the hblink Bridge-all so I only have specific BM talkgroups coming across on my repeaters.

It will be a few days before I can send you an example of my configs, but if you want me to set you up with a connection to my HBlink so you can at least get connected and test it so that you have access to 8802 I can do that.  I will need to pull in 3151 but that won't be a problem.

Please email me off list if you are interested.

Corey  N3FE



On Fri, Nov 23, 2018 at 7:15 AM Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG

Mike KB8JNM
 

Could I make the suggestion that you post that here as well. Not just off-list.

So perhaps that may stop multiple questions of the same from appearing here.

I'm sure many may learn from it even if not doing exactly the same.

...mike/kb8jnm

On 11/23/2018 9:09 AM, Corey Dean N3FE wrote:
I am actually doing exactly what you are doing.  I have my hblink setup with multiple connections.  8802 is also on my TS1.  I am doing this with both Motorola repeaters and a Homebrew repeater.  However I am testing a pre-release so my configs won't work for you just yet.

I do NOT use the hblink Bridge-all so I only have specific BM talkgroups coming across on my repeaters.

It will be a few days before I can send you an example of my configs, but if you want me to set you up with a connection to my HBlink so you can at least get connected and test it so that you have access to 8802 I can do that.  I will need to pull in 3151 but that won't be a problem.

Please email me off list if you are interested.

Corey  N3FE



On Fri, Nov 23, 2018 at 7:15 AM Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG

Corey Dean N3FE
 

I will but I can't at this time.  I am doing some testing and my configs will not work on the current system.

Corey


On Fri, Nov 23, 2018 at 9:55 AM Mike KB8JNM <groupio@...> wrote:

Could I make the suggestion that you post that here as well. Not just off-list.

So perhaps that may stop multiple questions of the same from appearing here.

I'm sure many may learn from it even if not doing exactly the same.

...mike/kb8jnm

On 11/23/2018 9:09 AM, Corey Dean N3FE wrote:
I am actually doing exactly what you are doing.  I have my hblink setup with multiple connections.  8802 is also on my TS1.  I am doing this with both Motorola repeaters and a Homebrew repeater.  However I am testing a pre-release so my configs won't work for you just yet.

I do NOT use the hblink Bridge-all so I only have specific BM talkgroups coming across on my repeaters.

It will be a few days before I can send you an example of my configs, but if you want me to set you up with a connection to my HBlink so you can at least get connected and test it so that you have access to 8802 I can do that.  I will need to pull in 3151 but that won't be a problem.

Please email me off list if you are interested.

Corey  N3FE



On Fri, Nov 23, 2018 at 7:15 AM Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG

Jim Gifford - KD4PPG
 

I spent time today going back and forth with Corey, and he has been most helpful.  Since he’s using things not yet intended for general consumption, I’ve decided to hold off until that’s out, and instead focus my attention on simplifying the model so that I can finally get my head around how all the pieces glue together.

I’ve spent quite a lot of time today working with IPSC_Bridge and HB_Bridge, and now have the simplest possible setup I could do.  I’ve passed audio traffic through from end to end in both directions, but have some issues still.

MMDVM Repeater <-> HB_Bridge <-> IPSC_Bridge <-> K4USD cBridge

TS1: TG8802
TS2 TG3151

So far, it all looks good, but I have a few concerns.  Earlier today, I was having a QSO over 8802 via the MMDVM repeater, when it stopped making it through the pipeline all the way to K4USD.  I wasn’t able to determine where it was failing, and switched to a direct RF link to a known operational repeater to finish the QSO.

I eventually decided it must’ve been an errant talkgroup from the cBridge, and sent the list of talkgroups I’ve been receiving unsolicited to the cBridge maintainer, and he fixed that when he got home tonight.  So now I’m sitting down and testing again.

Just a couple of minutes ago, I heard a ham call out on the 8802 talkgroup via the radio connected to the known good repeater (40+ miles away), but the HT listening to the benchtop repeater had no audio output at all.  Everything else looked normal, the pi-star dashboard showed the contact, that TX was occurring, etc.  The AnyTone 878 showed the contact information, talkgroup, etc, and updated the last call info after he finished talking.

Here’s the output from IPSC_Bridge:

INFO 2018-11-23 23:54:31,694 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3121792 (3121792)
INFO 2018-11-23 23:54:34,392 Voice Transmission End 2.70 seconds loss rate: 93.33% (3/45)
INFO 2018-11-23 23:56:06,731 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3121792 (3121792)
INFO 2018-11-23 23:56:11,592 Voice Transmission End 4.86 seconds loss rate: 96.30% (3/81)
INFO 2018-11-23 23:57:41,114 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3111697 (3111697)
INFO 2018-11-23 23:57:45,252 Voice Transmission End 4.14 seconds loss rate: 95.65% (3/69)

Here’s the output from HB_Bridge:

INFO 2018-11-23 23:54:31,692 (MASTER-1) Begin AMBE encode STREAM ID: 3929710726 SUB: 3121792 (3121792) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1
INFO 2018-11-23 23:56:06,732 (MASTER-1) Begin AMBE encode STREAM ID: 725990770 SUB: 3121792 (3121792) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1
INFO 2018-11-23 23:57:41,112 (MASTER-1) Begin AMBE encode STREAM ID: 754258576 SUB: 3111697 (3111697) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1

Now that loss rate from IPSC_Bridge worried me when I first discovered it, but since I was actually passing audio both ways earlier today when it was happening, I figured it wasn’t worth worrying about, probably just mis-reporting.  Notice how it’s always 3 out of however many. Always.  But now I wonder if it’s indicative of a problem I should track down.

Any ideas what I should check next?

In terms of setting up confbridge, which is preferred to work with, the one in dmrlink or the one in hblink?  Ultimately, I want one of those to be the primary decision maker in the “center” of it all.  With the link to BM being the most number of talkgroups, I’m leaning towards the hblink one as the one to use.

Thanks,
Jim

On Nov 23, 2018, at 7:14 AM, Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG

Corey Dean N3FE
 

I have seen that same thing happen when the audio lets are not set correctly.  The 868 and 878 are pretty picky on audio levels.

Corey N3FE

On Fri, Nov 23, 2018 at 7:14 PM Jim Gifford - KD4PPG <jim@...> wrote:
I spent time today going back and forth with Corey, and he has been most helpful.  Since he’s using things not yet intended for general consumption, I’ve decided to hold off until that’s out, and instead focus my attention on simplifying the model so that I can finally get my head around how all the pieces glue together.

I’ve spent quite a lot of time today working with IPSC_Bridge and HB_Bridge, and now have the simplest possible setup I could do.  I’ve passed audio traffic through from end to end in both directions, but have some issues still.

MMDVM Repeater <-> HB_Bridge <-> IPSC_Bridge <-> K4USD cBridge

TS1: TG8802
TS2 TG3151

So far, it all looks good, but I have a few concerns.  Earlier today, I was having a QSO over 8802 via the MMDVM repeater, when it stopped making it through the pipeline all the way to K4USD.  I wasn’t able to determine where it was failing, and switched to a direct RF link to a known operational repeater to finish the QSO.

I eventually decided it must’ve been an errant talkgroup from the cBridge, and sent the list of talkgroups I’ve been receiving unsolicited to the cBridge maintainer, and he fixed that when he got home tonight.  So now I’m sitting down and testing again.

Just a couple of minutes ago, I heard a ham call out on the 8802 talkgroup via the radio connected to the known good repeater (40+ miles away), but the HT listening to the benchtop repeater had no audio output at all.  Everything else looked normal, the pi-star dashboard showed the contact, that TX was occurring, etc.  The AnyTone 878 showed the contact information, talkgroup, etc, and updated the last call info after he finished talking.

Here’s the output from IPSC_Bridge:

INFO 2018-11-23 23:54:31,694 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3121792 (3121792)
INFO 2018-11-23 23:54:34,392 Voice Transmission End 2.70 seconds loss rate: 93.33% (3/45)
INFO 2018-11-23 23:56:06,731 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3121792 (3121792)
INFO 2018-11-23 23:56:11,592 Voice Transmission End 4.86 seconds loss rate: 96.30% (3/81)
INFO 2018-11-23 23:57:41,114 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3111697 (3111697)
INFO 2018-11-23 23:57:45,252 Voice Transmission End 4.14 seconds loss rate: 95.65% (3/69)

Here’s the output from HB_Bridge:

INFO 2018-11-23 23:54:31,692 (MASTER-1) Begin AMBE encode STREAM ID: 3929710726 SUB: 3121792 (3121792) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1
INFO 2018-11-23 23:56:06,732 (MASTER-1) Begin AMBE encode STREAM ID: 725990770 SUB: 3121792 (3121792) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1
INFO 2018-11-23 23:57:41,112 (MASTER-1) Begin AMBE encode STREAM ID: 754258576 SUB: 3111697 (3111697) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1

Now that loss rate from IPSC_Bridge worried me when I first discovered it, but since I was actually passing audio both ways earlier today when it was happening, I figured it wasn’t worth worrying about, probably just mis-reporting.  Notice how it’s always 3 out of however many. Always.  But now I wonder if it’s indicative of a problem I should track down.

Any ideas what I should check next?

In terms of setting up confbridge, which is preferred to work with, the one in dmrlink or the one in hblink?  Ultimately, I want one of those to be the primary decision maker in the “center” of it all.  With the link to BM being the most number of talkgroups, I’m leaning towards the hblink one as the one to use.

Thanks,
Jim

On Nov 23, 2018, at 7:14 AM, Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG


Cort N0MJS
 

When I started this, there was DMRlink – MMDVM didn’t yet exist. After I wrote HBlink, I still developed on DMRlink first, and then ported changes to HBlink, but have kept pretty good parity between both of them.

As of now, I’d say the best determining factor would be what kind of repeaters do you have more of? Motorola or MMDVM? That’s the advice I typically give. If you’re predominantly a Motorola operation, then use DMRlink’s confbridge.py as the main hub; if MMDVM, then use hb_confbridge.py.

But this is about to change. Going forward, now that HBlink has OpenBridge support, HBlink will be what gets developed first – and at some point, I may even sunset further development on DMRlink applications (e.g. confbridge.py). Using multiple IPSC connections to a c-Bridge to pick up TGIDs (or multiple HBP connections to Brandmeister, etc.) is cumbersome. OpenBridge allows “server-to-server” type access to Brandmeister, DMR-MARC and DMR+, and that’s my reason for shifting primary development (and there’s about to be quite a bit of it) to HBlink first.

I’d like to see a few improvements in IPSC_Bridge, and hopefully can contribute to them. Even on K0USY Group’s systems, it looks like the future will be trading out our XPR series repeaters for MMDMV-based ones, or putting a “backpack” on each one (SBC running IPSC_Bridge/HB_Bridge) and converting them all to Homebrew at the repeater site. I’ll likely keep one XPR for DMRlink development, but that’s probably it.

0x49 DE N0MJS

P.S. - if anyone is in the market for lightly used (I run the power at 25W on them and NEVER burn up PAs that way) K0USY Group will soon have a number of XPR8300s and XPR8400s available for sale or trade for MTR2000s.

On Nov 23, 2018, at 6:14 PM, Jim Gifford - KD4PPG <jim@...> wrote:

In terms of setting up confbridge, which is preferred to work with, the one in dmrlink or the one in hblink?  Ultimately, I want one of those to be the primary decision maker in the “center” of it all.  With the link to BM being the most number of talkgroups, I’m leaning towards the hblink one as the one to use.

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206





Jim Gifford - KD4PPG
 

I left this running without tinkering over the weekend, and everything stayed rock solid.  The audio issue disappeared for the most part.  I even updated the MD-9600 to have the same settings for listening to the MMDVM box.  It’s worth noting that the MMDVM “repeater” in this case is a cheap duplex chinaspot that I’m running on my coordinated frequency while I finish building my real MMDVM repeater.  The chinaspot can’t be heard more than 25 feet away, and I haven’t dialed in the frequency with mmdvmcal yet.  I’m still learning how to use my service monitor.  It’s adequate to prove the concept, but not adequate to use for an extended QSO yet.

Watching the pi-star dashboard, I saw very few incidents of any packet loss, and in every case I followed up on, the same loss was reflected in the cBridge, so it was lacking in the source signal.

Even though it goes against my OCD-like nature, I’m ignoring the log files from IPSC_Bridge that say extremely high packet loss, as I suspect it’s a reporting bug, not a real bug.  Every single transmission only shows 3 received out of all the ones transmitted.  I’m assuming packets.

Example (times in UTC):
INFO 2018-11-26 12:22:16,271 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3110063 (3110063)
INFO 2018-11-26 12:22:24,371 Voice Transmission End 8.10 seconds loss rate: 97.78% (3/135)
INFO 2018-11-26 12:22:27,791 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3110037 (3110037)
INFO 2018-11-26 12:22:38,412 Voice Transmission End 10.62 seconds loss rate: 98.31% (3/177)
INFO 2018-11-26 12:22:40,691 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3110063 (3110063)
INFO 2018-11-26 12:22:54,551 Voice Transmission End 13.86 seconds loss rate: 98.70% (3/231)
INFO 2018-11-26 12:23:10,871 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3110037 (3110037)
INFO 2018-11-26 12:23:17,172 Voice Transmission End 6.30 seconds loss rate: 97.14% (3/105)
INFO 2018-11-26 12:23:19,571 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3110063 (3110063)
INFO 2018-11-26 12:23:36,671 Voice Transmission End 17.10 seconds loss rate: 98.95% (3/285)
INFO 2018-11-26 12:23:37,631 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3110037 (3110037)
INFO 2018-11-26 12:23:41,771 Voice Transmission End 4.14 seconds loss rate: 95.65% (3/69)
INFO 2018-11-26 12:26:05,230 Voice Transmission Start on TS 2 and TG 3151 (3151) from 3151152 (3151152)
INFO 2018-11-26 12:26:08,648 Voice Transmission End 3.42 seconds loss rate: 94.74% (3/57)
INFO 2018-11-26 12:51:53,708 Voice Transmission Start on TS 2 and TG 3151 (3151) from 3151584 (3151584)
INFO 2018-11-26 12:51:54,967 Voice Transmission End 1.26 seconds loss rate: 85.71% (3/21)
INFO 2018-11-26 13:07:20,770 Voice Transmission Start on TS 2 and TG 3151 (3151) from 3151406 (3151406)
INFO 2018-11-26 13:07:26,346 Voice Transmission End 5.58 seconds loss rate: 96.77% (3/93)
INFO 2018-11-26 13:26:16,994 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3120699 (3120699)
INFO 2018-11-26 13:26:20,411 Voice Transmission End 3.42 seconds loss rate: 94.74% (3/57)
INFO 2018-11-26 13:30:37,633 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3110037 (3110037)
INFO 2018-11-26 13:30:41,772 Voice Transmission End 4.14 seconds loss rate: 95.65% (3/69)
INFO 2018-11-26 13:31:53,650 Voice Transmission Start on TS 2 and TG 3151 (3151) from 3151090 (3151090)
INFO 2018-11-26 13:31:54,547 Voice Transmission End 0.90 seconds loss rate: 80.00% (3/15)

Now, since it is *always* (3/X), this must be an artifact within the code, not the signal, since I can copy the entire transmission on the radio at the endpoint.  Definitely not enough of an issue to bother tracking down at this point.

This software works great, and the CPU usage stats for my virtual server show it doesn’t even break idle.  I’m ready to start making the setup a little more complex now that I have a feel for how it all works together.

Thank you to everyone that has helped me get to this point.  Reading through the archive of topics was educational, but not as much as actually getting some piece of the system operational.  I especially want to thank Corey for his off-list assistance and helping me understand I wasn’t really ready to do what I was attempting to do, and that I needed to start smaller and work my way up.

Thanks,
Jim

On Nov 23, 2018, at 7:52 PM, Corey Dean N3FE <n3fe@...> wrote:

I have seen that same thing happen when the audio lets are not set correctly.  The 868 and 878 are pretty picky on audio levels.

Corey N3FE

On Fri, Nov 23, 2018 at 7:14 PM Jim Gifford - KD4PPG <jim@...> wrote:
I spent time today going back and forth with Corey, and he has been most helpful.  Since he’s using things not yet intended for general consumption, I’ve decided to hold off until that’s out, and instead focus my attention on simplifying the model so that I can finally get my head around how all the pieces glue together.

I’ve spent quite a lot of time today working with IPSC_Bridge and HB_Bridge, and now have the simplest possible setup I could do.  I’ve passed audio traffic through from end to end in both directions, but have some issues still.

MMDVM Repeater <-> HB_Bridge <-> IPSC_Bridge <-> K4USD cBridge

TS1: TG8802
TS2 TG3151

So far, it all looks good, but I have a few concerns.  Earlier today, I was having a QSO over 8802 via the MMDVM repeater, when it stopped making it through the pipeline all the way to K4USD.  I wasn’t able to determine where it was failing, and switched to a direct RF link to a known operational repeater to finish the QSO.

I eventually decided it must’ve been an errant talkgroup from the cBridge, and sent the list of talkgroups I’ve been receiving unsolicited to the cBridge maintainer, and he fixed that when he got home tonight.  So now I’m sitting down and testing again.

Just a couple of minutes ago, I heard a ham call out on the 8802 talkgroup via the radio connected to the known good repeater (40+ miles away), but the HT listening to the benchtop repeater had no audio output at all.  Everything else looked normal, the pi-star dashboard showed the contact, that TX was occurring, etc.  The AnyTone 878 showed the contact information, talkgroup, etc, and updated the last call info after he finished talking.

Here’s the output from IPSC_Bridge:

INFO 2018-11-23 23:54:31,694 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3121792 (3121792)
INFO 2018-11-23 23:54:34,392 Voice Transmission End 2.70 seconds loss rate: 93.33% (3/45)
INFO 2018-11-23 23:56:06,731 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3121792 (3121792)
INFO 2018-11-23 23:56:11,592 Voice Transmission End 4.86 seconds loss rate: 96.30% (3/81)
INFO 2018-11-23 23:57:41,114 Voice Transmission Start on TS 1 and TG 8802 (8802) from 3111697 (3111697)
INFO 2018-11-23 23:57:45,252 Voice Transmission End 4.14 seconds loss rate: 95.65% (3/69)

Here’s the output from HB_Bridge:

INFO 2018-11-23 23:54:31,692 (MASTER-1) Begin AMBE encode STREAM ID: 3929710726 SUB: 3121792 (3121792) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1
INFO 2018-11-23 23:56:06,732 (MASTER-1) Begin AMBE encode STREAM ID: 725990770 SUB: 3121792 (3121792) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1
INFO 2018-11-23 23:57:41,112 (MASTER-1) Begin AMBE encode STREAM ID: 754258576 SUB: 3111697 (3111697) REPEATER: 13100030 (13100030) TGID 8802 (8802), TS 1

Now that loss rate from IPSC_Bridge worried me when I first discovered it, but since I was actually passing audio both ways earlier today when it was happening, I figured it wasn’t worth worrying about, probably just mis-reporting.  Notice how it’s always 3 out of however many. Always.  But now I wonder if it’s indicative of a problem I should track down.

Any ideas what I should check next?

In terms of setting up confbridge, which is preferred to work with, the one in dmrlink or the one in hblink?  Ultimately, I want one of those to be the primary decision maker in the “center” of it all.  With the link to BM being the most number of talkgroups, I’m leaning towards the hblink one as the one to use.

Thanks,
Jim

On Nov 23, 2018, at 7:14 AM, Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG




Jim Gifford - KD4PPG
 

Cort,

Thanks for this answer.  I spent the weekend pondering your answer and the implications, and picturing in my head how I should proceed.  At this point, I’m going to stick with hb_confbridge, because of the reasoning you gave, and connect everything else over to that core component.

Thanks,
Jim


On Nov 23, 2018, at 7:53 PM, Cort N0MJS via Groups.Io <n0mjs@...> wrote:

When I started this, there was DMRlink – MMDVM didn’t yet exist. After I wrote HBlink, I still developed on DMRlink first, and then ported changes to HBlink, but have kept pretty good parity between both of them.

As of now, I’d say the best determining factor would be what kind of repeaters do you have more of? Motorola or MMDVM? That’s the advice I typically give. If you’re predominantly a Motorola operation, then use DMRlink’s confbridge.py as the main hub; if MMDVM, then use hb_confbridge.py.

But this is about to change. Going forward, now that HBlink has OpenBridge support, HBlink will be what gets developed first – and at some point, I may even sunset further development on DMRlink applications (e.g. confbridge.py). Using multiple IPSC connections to a c-Bridge to pick up TGIDs (or multiple HBP connections to Brandmeister, etc.) is cumbersome. OpenBridge allows “server-to-server” type access to Brandmeister, DMR-MARC and DMR+, and that’s my reason for shifting primary development (and there’s about to be quite a bit of it) to HBlink first.

I’d like to see a few improvements in IPSC_Bridge, and hopefully can contribute to them. Even on K0USY Group’s systems, it looks like the future will be trading out our XPR series repeaters for MMDMV-based ones, or putting a “backpack” on each one (SBC running IPSC_Bridge/HB_Bridge) and converting them all to Homebrew at the repeater site. I’ll likely keep one XPR for DMRlink development, but that’s probably it.

0x49 DE N0MJS

P.S. - if anyone is in the market for lightly used (I run the power at 25W on them and NEVER burn up PAs that way) K0USY Group will soon have a number of XPR8300s and XPR8400s available for sale or trade for MTR2000s.

On Nov 23, 2018, at 6:14 PM, Jim Gifford - KD4PPG <jim@...> wrote:

In terms of setting up confbridge, which is preferred to work with, the one in dmrlink or the one in hblink?  Ultimately, I want one of those to be the primary decision maker in the “center” of it all.  With the link to BM being the most number of talkgroups, I’m leaning towards the hblink one as the one to use.

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206





Peter M0NWI
 

Hi Cort,

Reference the below, can I ask is OpenBridge not compatible with DMRlink, or just that you've made the decision to not implement?

As you know I've always kept DMRlink as the core routing for the network, linking out using IPSCBridge / HBlink as needed to bring in the odd MMDVM box, and its served me well, as the bulk of my connections are moto IPSC.

I see OpenBridge as a super way to link networks, and would like to try this, at present I have one link per repeater upstream, and bridge the traffic, so OpenBridge would be a good win.

So I'm contemplating, do I move to HBLink as the centre, and use IPSCBridge for the motos to gain the benefits?

Regards
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 24 November 2018 00:53:38
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Is this even possible?
 
When I started this, there was DMRlink – MMDVM didn’t yet exist. After I wrote HBlink, I still developed on DMRlink first, and then ported changes to HBlink, but have kept pretty good parity between both of them.

As of now, I’d say the best determining factor would be what kind of repeaters do you have more of? Motorola or MMDVM? That’s the advice I typically give. If you’re predominantly a Motorola operation, then use DMRlink’s confbridge.py as the main hub; if MMDVM, then use hb_confbridge.py.

But this is about to change. Going forward, now that HBlink has OpenBridge support, HBlink will be what gets developed first – and at some point, I may even sunset further development on DMRlink applications (e.g. confbridge.py). Using multiple IPSC connections to a c-Bridge to pick up TGIDs (or multiple HBP connections to Brandmeister, etc.) is cumbersome. OpenBridge allows “server-to-server” type access to Brandmeister, DMR-MARC and DMR+, and that’s my reason for shifting primary development (and there’s about to be quite a bit of it) to HBlink first.

I’d like to see a few improvements in IPSC_Bridge, and hopefully can contribute to them. Even on K0USY Group’s systems, it looks like the future will be trading out our XPR series repeaters for MMDMV-based ones, or putting a “backpack” on each one (SBC running IPSC_Bridge/HB_Bridge) and converting them all to Homebrew at the repeater site. I’ll likely keep one XPR for DMRlink development, but that’s probably it.

0x49 DE N0MJS

P.S. - if anyone is in the market for lightly used (I run the power at 25W on them and NEVER burn up PAs that way) K0USY Group will soon have a number of XPR8300s and XPR8400s available for sale or trade for MTR2000s.

On Nov 23, 2018, at 6:14 PM, Jim Gifford - KD4PPG <jim@...> wrote:

In terms of setting up confbridge, which is preferred to work with, the one in dmrlink or the one in hblink?  Ultimately, I want one of those to be the primary decision maker in the “center” of it all.  With the link to BM being the most number of talkgroups, I’m leaning towards the hblink one as the one to use.

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206





Cort N0MJS
 

To make DMRlink use OpenBridge requires all of the same internals as IPSC_Bridge.py and HB_Bridge.py. OpenBridge is based on the Home-brew Repeater Protocol. It was reasonable to incorporate it into HBlink because of that.

DMRlink is probably going to be #2 now. I just did a LOT of work with HBlink… I can trickle those changes into DMRlink over time, but like all of you, I’m also running a pretty sizable repeater network too. So just remember, I’m doing that AND trying to write the software. So go easy on me guys :)


On Nov 26, 2018, at 5:32 PM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Reference the below, can I ask is OpenBridge not compatible with DMRlink, or just that you've made the decision to not implement?

As you know I've always kept DMRlink as the core routing for the network, linking out using IPSCBridge / HBlink as needed to bring in the odd MMDVM box, and its served me well, as the bulk of my connections are moto IPSC.

I see OpenBridge as a super way to link networks, and would like to try this, at present I have one link per repeater upstream, and bridge the traffic, so OpenBridge would be a good win.

So I'm contemplating, do I move to HBLink as the centre, and use IPSCBridge for the motos to gain the benefits?

Regards
Peter

Peter M0NWI
 

Hi Cort,

Fully understand, and wasn't pushing, just wondering around OpenBridge as a philosophy, but checking the code, it seems that its only implemented in the big networks on slot 1.  In the UK we do international/national on S1 and regional on S2, so it probably won't make difference to my current design.

Can I ask if you or any of the others do anything with DMR data, I've been asked about routing GPS, and although I've done some tests with a Moto into bridge.py,on DMRkink with rules for private data, it doesn't seem to route the traffic.  I maybe doing something wrong, or that its not been fully implemented. I'm trying to route this up stream to a DMR+ IPSC2, who do push on these private TG5057 messages to APRS.fi

As I understand it, your radio when configured for GPS, sends the data as a private call to 5057 on whatever routed TG your using.  Again, I'm not sure if private calls are supported either.

Any pointers, or just info as to whether its worth continuing testing would be useful.

Thanks
Peter





Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 27 November 2018 00:30:46
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Is this even possible?
 
To make DMRlink use OpenBridge requires all of the same internals as IPSC_Bridge.py and HB_Bridge.py. OpenBridge is based on the Home-brew Repeater Protocol. It was reasonable to incorporate it into HBlink because of that.

DMRlink is probably going to be #2 now. I just did a LOT of work with HBlink… I can trickle those changes into DMRlink over time, but like all of you, I’m also running a pretty sizable repeater network too. So just remember, I’m doing that AND trying to write the software. So go easy on me guys :)


On Nov 26, 2018, at 5:32 PM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Reference the below, can I ask is OpenBridge not compatible with DMRlink, or just that you've made the decision to not implement?

As you know I've always kept DMRlink as the core routing for the network, linking out using IPSCBridge / HBlink as needed to bring in the odd MMDVM box, and its served me well, as the bulk of my connections are moto IPSC.

I see OpenBridge as a super way to link networks, and would like to try this, at present I have one link per repeater upstream, and bridge the traffic, so OpenBridge would be a good win.

So I'm contemplating, do I move to HBLink as the centre, and use IPSCBridge for the motos to gain the benefits?

Regards
Peter

Cort N0MJS
 

Inline --

On Nov 29, 2018, at 4:33 PM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Fully understand, and wasn't pushing,

Great, because I didn’t think you were :)

just wondering around OpenBridge as a philosophy, but checking the code, it seems that its only implemented in the big networks on slot 1.

Not exactly. OpenBridge allows sending an arbitrary number of call streams simultaneously. There’s no concept of “timeslot” because of that, so they just clear the TS bit in the header…. A cleared TS bit just happens to correspond to TS1. That means the packets are going to look like TS1 and I have to treat them that way, i.e. re-write the TS bit if a call stream is destined for TS2.

In the UK we do international/national on S1 and regional on S2, so it probably won't make difference to my current design.

Again, think of OpenBridge as a server to server protocol that doesn’t have a timeslot.

Can I ask if you or any of the others do anything with DMR data,

So far I’ve not been able to satisfy the group voice to-do list and have enough time to work with subscriber-to subscriber voice or data.

I've been asked about routing GPS, and although I've done some tests with a Moto into bridge.py,on DMRkink with rules for private data, it doesn't seem to route the traffic.

It was never completed and shouldn’t be expected to work as it is.

I maybe doing something wrong, or that its not been fully implemented.

Correct, never even remotely fully implemented.

I'm trying to route this up stream to a DMR+ IPSC2, who do push on these private TG5057 messages to APRS.fi
As I understand it, your radio when configured for GPS, sends the data as a private call to 5057 on whatever routed TG your using.  Again, I'm not sure if private calls are supported either.
Any pointers, or just info as to whether its worth continuing testing would be useful.

Group Voice is the only thing functional.

Thanks
Peter





Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 27 November 2018 00:30:46
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Is this even possible?
 
To make DMRlink use OpenBridge requires all of the same internals as IPSC_Bridge.py and HB_Bridge.py. OpenBridge is based on the Home-brew Repeater Protocol. It was reasonable to incorporate it into HBlink because of that.

DMRlink is probably going to be #2 now. I just did a LOT of work with HBlink… I can trickle those changes into DMRlink over time, but like all of you, I’m also running a pretty sizable repeater network too. So just remember, I’m doing that AND trying to write the software. So go easy on me guys :)


On Nov 26, 2018, at 5:32 PM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Reference the below, can I ask is OpenBridge not compatible with DMRlink, or just that you've made the decision to not implement?

As you know I've always kept DMRlink as the core routing for the network, linking out using IPSCBridge / HBlink as needed to bring in the odd MMDVM box, and its served me well, as the bulk of my connections are moto IPSC.

I see OpenBridge as a super way to link networks, and would like to try this, at present I have one link per repeater upstream, and bridge the traffic, so OpenBridge would be a good win.

So I'm contemplating, do I move to HBLink as the centre, and use IPSCBridge for the motos to gain the benefits?

Regards
Peter


Cort Buffington
785-865-7206

Jim Gifford - KD4PPG
 

A lot has happened in the last few weeks.  Most critically, the OpenBridge branch merged back into the master branch, bringing with it new goodies to play with, namely ACLs!

Additionally, I've stopped trying to conflate my needs with the needs of the other repeater operator, instead treating each as a unique problem to be solved.  Since his is closer to being on the air, I'm focusing on that.  I'm hoping for OpenBridge to be the answer to my own setup in the near future.

Basic premise: new (used) repeater, VHF, XPR8400, 147.210 +, CC1,  antenna at 300' on a county tower, owner: N4TIK (Ken), trustee: W0ADD (Al).

Ken and Al would prefer their repeater have the sysop level of control provided by Brandmeister rather than being on a cBridge and having to pester the bridge operator for changes.  However, they also want to carry the DelMarVa (8802) talkgroup, primarily for coordination across the region during EmComm scenarios, which is only carried on cBridges currently.

For policy reasons, 8802 will not be carried by BM.

The repeater is operational, barring some issues with the duplexer.  It's connected to BM currently, and operating as the owner and trustee wish it to, although lacking the 8802 talkgroup.

Existing configuration:

I think that with the advent of ACLs, I can insert a DVSwitch suite in between the XPR8400 and the BM3102 server.  I can use the ACLs to deny 8802 from going to BM3102, and also to permit only 8802 on TS1 going to/from K4USD.

Proposed configuration:


In this proposal, the IPSC_Bridge <-> BM3102 link would be using the N4TIK DMR ID # 310328, so would look the same as the existing repeater.

Does anyone see anything wrong with this approach?

Yes, I know BM supports HB directly, but I don't know what's involved with changing from the current IPSC connection to an HB connection, ie will BM even care? Is it a different port?  For that matter, I don't *know* that the IPSC_Bridge <->BM3102 link will function correctly.   Any advice on this point is very welcome.

Thanks in advance,
Jim

PS, hooray for ACLs!

On Nov 23, 2018, at 7:14 AM, Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG

JJ Cummings
 

Jim, you can do what you want to do now with the use of HBLink, DMRLink, HB_Bridge and IPSC_Bridge as follows:

hb_confbridge <-> Brandmeister (for BM TGs)
hb_confbridge <-> hb_bridge <-> ipsc_bridge <-> confbridge (for CBridge interfacing and interfacing to motorola repeaters)

hb_confbridge is a single instance of hb_confbridge.py from HBLink
confbridge is a single instance of confbridge.py from DMRLink
ipsc_bridge and hb_bridge are the respective single instances of the .py files from IPSC_Bridge and HB_Bridge.

All that you have to do is configure the respective _rules.py files to determine what TGs are allowed to go to what system, simply excluding TG8802 from your Brandmeister stanza in said file will do it.

JJC
N0PKT

On Tue, Dec 4, 2018 at 1:56 PM Jim Gifford - KD4PPG <jim@...> wrote:
A lot has happened in the last few weeks.  Most critically, the OpenBridge branch merged back into the master branch, bringing with it new goodies to play with, namely ACLs!

Additionally, I've stopped trying to conflate my needs with the needs of the other repeater operator, instead treating each as a unique problem to be solved.  Since his is closer to being on the air, I'm focusing on that.  I'm hoping for OpenBridge to be the answer to my own setup in the near future.

Basic premise: new (used) repeater, VHF, XPR8400, 147.210 +, CC1,  antenna at 300' on a county tower, owner: N4TIK (Ken), trustee: W0ADD (Al).

Ken and Al would prefer their repeater have the sysop level of control provided by Brandmeister rather than being on a cBridge and having to pester the bridge operator for changes.  However, they also want to carry the DelMarVa (8802) talkgroup, primarily for coordination across the region during EmComm scenarios, which is only carried on cBridges currently.

For policy reasons, 8802 will not be carried by BM.

The repeater is operational, barring some issues with the duplexer.  It's connected to BM currently, and operating as the owner and trustee wish it to, although lacking the 8802 talkgroup.

Existing configuration:

I think that with the advent of ACLs, I can insert a DVSwitch suite in between the XPR8400 and the BM3102 server.  I can use the ACLs to deny 8802 from going to BM3102, and also to permit only 8802 on TS1 going to/from K4USD.

Proposed configuration:


In this proposal, the IPSC_Bridge <-> BM3102 link would be using the N4TIK DMR ID # 310328, so would look the same as the existing repeater.

Does anyone see anything wrong with this approach?

Yes, I know BM supports HB directly, but I don't know what's involved with changing from the current IPSC connection to an HB connection, ie will BM even care? Is it a different port?  For that matter, I don't *know* that the IPSC_Bridge <->BM3102 link will function correctly.   Any advice on this point is very welcome.

Thanks in advance,
Jim

PS, hooray for ACLs!

On Nov 23, 2018, at 7:14 AM, Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG


Corey Dean N3FE
 

Now that openbridge is released I may be able to help out some here.  I have about 15-20 talkgroups from bm 3102 feeding hblink using openbridge.  I then have a link into my cbridge carrying Delmarva 8802, then I also have a backup system of hblink with all of those coming across it.  My home brew repeaters connect directly to hblink and the 8300 repeaters use IPSec bridge / hb bridge to connect to hblink.  I have been running it this way for a few months with no trouble at all!

If I need another talkgroup from the cbridge or bm it is very easy to add.  On openbridge all I need to know is the talkgroup I’d, enter it in and you have it right away.  Think of it as a cbridge cclink with out the need for a lid.

Corey n3fe

On Tue, Dec 4, 2018 at 8:28 PM JJ Cummings <cummingsj@...> wrote:
Jim, you can do what you want to do now with the use of HBLink, DMRLink, HB_Bridge and IPSC_Bridge as follows:

hb_confbridge <-> Brandmeister (for BM TGs)
hb_confbridge <-> hb_bridge <-> ipsc_bridge <-> confbridge (for CBridge interfacing and interfacing to motorola repeaters)

hb_confbridge is a single instance of hb_confbridge.py from HBLink
confbridge is a single instance of confbridge.py from DMRLink
ipsc_bridge and hb_bridge are the respective single instances of the .py files from IPSC_Bridge and HB_Bridge.

All that you have to do is configure the respective _rules.py files to determine what TGs are allowed to go to what system, simply excluding TG8802 from your Brandmeister stanza in said file will do it.

JJC
N0PKT

On Tue, Dec 4, 2018 at 1:56 PM Jim Gifford - KD4PPG <jim@...> wrote:
A lot has happened in the last few weeks.  Most critically, the OpenBridge branch merged back into the master branch, bringing with it new goodies to play with, namely ACLs!

Additionally, I've stopped trying to conflate my needs with the needs of the other repeater operator, instead treating each as a unique problem to be solved.  Since his is closer to being on the air, I'm focusing on that.  I'm hoping for OpenBridge to be the answer to my own setup in the near future.

Basic premise: new (used) repeater, VHF, XPR8400, 147.210 +, CC1,  antenna at 300' on a county tower, owner: N4TIK (Ken), trustee: W0ADD (Al).

Ken and Al would prefer their repeater have the sysop level of control provided by Brandmeister rather than being on a cBridge and having to pester the bridge operator for changes.  However, they also want to carry the DelMarVa (8802) talkgroup, primarily for coordination across the region during EmComm scenarios, which is only carried on cBridges currently.

For policy reasons, 8802 will not be carried by BM.

The repeater is operational, barring some issues with the duplexer.  It's connected to BM currently, and operating as the owner and trustee wish it to, although lacking the 8802 talkgroup.

Existing configuration:

I think that with the advent of ACLs, I can insert a DVSwitch suite in between the XPR8400 and the BM3102 server.  I can use the ACLs to deny 8802 from going to BM3102, and also to permit only 8802 on TS1 going to/from K4USD.

Proposed configuration:


In this proposal, the IPSC_Bridge <-> BM3102 link would be using the N4TIK DMR ID # 310328, so would look the same as the existing repeater.

Does anyone see anything wrong with this approach?

Yes, I know BM supports HB directly, but I don't know what's involved with changing from the current IPSC connection to an HB connection, ie will BM even care? Is it a different port?  For that matter, I don't *know* that the IPSC_Bridge <->BM3102 link will function correctly.   Any advice on this point is very welcome.

Thanks in advance,
Jim

PS, hooray for ACLs!

On Nov 23, 2018, at 7:14 AM, Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG