1. main@DVSwitch.groups.io
  2. Messages
   Date   
Re: Is this even possible?

Cort N0MJS <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
Re: Is this even possible?

Corey Dean N3FE <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
Re: Is this even possible?

Jim Gifford - K9AGR
 

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
Re: Is this even possible?

Corey Dean N3FE <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
Re: Is this even possible?

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
Re: Is this even possible?

Corey Dean N3FE <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
Is this even possible?

Jim Gifford - K9AGR
 

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
Re: XLX 2 XLX Connection

david bencini ik5xmk
 

Hi Steve,
Thank you for your answer.
 
This can be a viable path. I was hoping not to use ircddbgateway, even to be able to use a single server for this function.
 
The latest version of XLX is designed to have a distributed use on all peers of the transcoding process, so it implies that all participants have appropriate on-board hardware.
 
This is the reason for the request of a simple direct connection, point to point, with the DExtra protocol only, for example, in order not to activate the transcoding process.
 
It would be necessary for MMDVM_Bridge to present itself to XLX in a pure dstar way, at least in one side.
 
Thanks, I can try to use ircddbgateway with a different protocol / port type for each side. But I have to recompile ircddbgateway in custom mode by changing some listening ports so that everything can reside on a single server
 
73, David
Re: XLX 2 XLX Connection

Steve N4IRS
 

David,
I little to nothing about XLX so I don't know how much help I can be.
I do now understand more about XLX (with transcode) <-> XLX (XLX (without transcode) If I understand your post, the peer protocol can not connect the two different modes.
If ircDDBGateway can connect to each type maybe you can do this:

XLX (with transcode) <-> idcDDBGateway(1) <-> MMDVM_Bridge(1) <-> MMDVM_Bridge(2) <-> ircDDBGateway(2) <-> XLX (without transcode)

Steve N4IRS

On 11/22/18 8:53 AM, david bencini ik5xmk wrote:
>Why re-invent the wheel ??

Why maybe I started working on XLX from the first version and I know good things and faults?
 
If you have an XLX with transcoding and an XLX WITHOUT transcoding, how do you connect them together? The peer system works great if all XLXs have the same technical characteristics. There are many realities in the world and not everyone uses a single XLX for the whole country.
 
What we need is simply a "collector" with dstar protocol and not mmdvm. I understand that MMDVM_Bridge, DVSwitch, etc. etc. they can not do this. OK.
 
Unfortunately, XRF no longer had any development, but as a "collector" it could be fine, but it has no control and causes loops with ease.
 
There is YSF2DMR, we hope will also be implemented DCS2DPLUS for the dstar, or similar.
 
Thanks anyway, 73
Re: XLX 2 XLX Connection

david bencini ik5xmk
 

>Why re-invent the wheel ??

Why maybe I started working on XLX from the first version and I know good things and faults?
 
If you have an XLX with transcoding and an XLX WITHOUT transcoding, how do you connect them together? The peer system works great if all XLXs have the same technical characteristics. There are many realities in the world and not everyone uses a single XLX for the whole country.
 
What we need is simply a "collector" with dstar protocol and not mmdvm. I understand that MMDVM_Bridge, DVSwitch, etc. etc. they can not do this. OK.
 
Unfortunately, XRF no longer had any development, but as a "collector" it could be fine, but it has no control and causes loops with ease.
 
There is YSF2DMR, we hope will also be implemented DCS2DPLUS for the dstar, or similar.
 
Thanks anyway, 73
Re: NXDN to YSF

f0dei
 

Hello Steve,

Bruno F1PTL send you an e-mail about this problem. 
Audio from NXDN radio to YSF start in DN then switch to VW

Please, check e-mail from Bruno (more info with log).

Regards
Toufik
Re: NXDN to YSF

Steve N4IRS
 

I believe this is related to the Fusion radio (Yaesu) I have a test bridge running on dvswitch.org My test radio is a FT1D.

YSF Reflector address and port: dvswitch.org  42166
NXDN reflector address and port: dvswitch.org 41400

Using TG 3166

YSF reflector dashboard: http://dvswitch.org/YSF_DVSwitch/
NXDN reflector dashboard: http://dvswitch.org/NXDN_DVSwitch/

Steve N4IRS
Bridge (Crosslink-Transcoding) between XLX reflector and DMR TG BrandMeister #brandmeister

Al Mesa
 

Good morning:
I am looking for assistance with the following questions:

1. With the following scheme, can I make a bridge (crosslink or transcondig) between my xlx reflector and a BrandMeister TG?:

                               

 D-Star <---> ircDDBGateway <---> MMDVM_Bridge <---> Analog_Bridge_DSTAR <---> Analog_Bridge_DMR <---> MMDVM_Bridge <---> DMR.

                               

 2. If the answer is yes, may I install everything in the same ubuntu pc and also install my two ThumDV to be able to complete the transcoding process?

                               

Thank you.

Alberto M.
W4RAM
Re: How to link between a Quantar on P25 to BM DMR?

Juan Carlos Pérez <km4nno@...>
 

Hi Steve,

So I think I set must of the system, but I am missing some port links that I can find the propper file to set them. Here are my settings for the diffrent files (Data that did not changed or is not relevant is not posted). The intention for testing is to use TG 5995 on a Quantar repeater using Quantra_Bridge and pass it to BrandMeister TG 334105. Everything is set on the same Raspberry Pi.

Quantar Bridge --> ???
             34103 --> 34103
             34100 <-- 34100

P25Reflector
41000

    P25Gtw      -->   MMDVMBr  -->   An_Br_P25   -->  An_Br_DMR -->   MMDVMBr   --> BrandMeister
42010 42020 --> 42020 30100 --> 30100 32001 --> 32001 30103 --> 30103 36100 --> 31100 62031
41000 32010 <-- 32010 30103 <-- 30103 34001 <-- 34001 30100 <-- 30100 36103 <-- 31103 62032


Quantar_Bridge.ini

[QUANTAR]
logFilePath = /var/log/Quantar_Bridge.log
logLevel = 2                    ; Show messages and above 0=No logging, 1=Debug, 2=Message, 3=Info,$debug = 0                       ; Debug 0 = off, 1 = on (adds lots of additional messages)
Address = 0.0.0.0               ; Address to send AMBE TLV frames to (export)
TXPort = 34103                  ; Port to send AMBE TLV frames to (export)
RXPort = 34100                  ; Port to listen on (import)
quantarPort = 1994              ; HDLC frames To/From the Quantar repeater


 P25Reflector.ini

[Network]
Port=41000
Debug=0


 P25Gateway.ini

[General]
Callsign=XE1F
RptAddress=127.0.0.1
RptPort=32010
LocalPort=42020
Announcements=1
Daemon=0
[Network]
Port=42010
HostsFile1=./P25Hosts.txt
HostsFile2=./Private_P25Hosts.txt
ReloadTime=60
ParrotAddress=127.0.0.1
ParrotPort=42011
# Startup=10100
Startup=5995
InactivityTimeout=0
Debug=0


P25Hosts.txt

# 5995 XE1F Test TG
5995    172.0.0.1       41000


DVSwitch.ini

[QUANTAR]
logFilePath = /var/log/Quantar_Bridge.log
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 34103                  ; Port to send AMBE TLV frames to (export)
RXPort = 34100                  ; Port to listen on (import)
quantarPort = 1994              ; HDLC frames To/From the Quantar repeater
logLevel = 2                    ; Show messages and above 0=No logging, 1=Debug, 2=Message, 3=Info,$
debug = 0                       ; Debug 0 = off, 1 = on (adds lots of additional messages)

; Configure the DMR Partner
; Audio format is AMBE 72 bit
[DMR]
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 31100                  ; Port to send AMBE TLV frames to (export)
RXPort = 31103                  ; Port to listen on (import)
Slot = 2                        ; Export slot

; Configure the P25 Partner
; Audio format is IMBE 88 bit
[P25]
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 34100                  ; Port to send AMBE TLV frames to (export)
RXPort = 34103                  ; Port to listen on (import)
Slot = 2                        ; Export slot

MMDVM_Bridge.ini

[General]
Callsign=XE1F
Id=334118
Timeout=120
Duplex=0

[Info]
RXFrequency=147390000
TXFrequency=147990000
Power=25
Latitude=19.3834
Longitude=-99.1446
Height=25
Location=Benito Juarez, CMX
Description=MMDVM_Bridge
URL=https://groups.io/g/DVSwitch

[DMR]
Enable=1
ColorCode=1
EmbeddedLCOnly=1
DumpTAData=0

[P25]
Enable=1
NAC=293

[DMR Network]
Enable=1
Address=hblink.dvswitch.org
Port=62031
Jitter=360
Local=62032
Password=passw0rd
Slot1=0
Slot2=1
Debug=1

[P25 Network]
Enable=1
GatewayAddress=127.0.0.1
GatewayPort=42020
LocalPort=32010
Debug=1


Analog_Bridge_P25ini

[GENERAL]
logLevel = 2                            ; Show messages and above 0=No logging, 1=Debug, 2=Message,$
; Metadata management
exportMetadata = true                   ; Export metadata to USRP partner (transcode setups require$subscriberFile = /var/lib/dvswitch/subscriber_ids.csv   ; DMR ID to callsign lookup data

; General vocoder setup information
decoderFallBack = false                 ; Allow software AMBE decoding if a hardware decoder is not$
useEmulator = false                     ; Use the MD380 AMBE emulator for AMBE72 (DMR/YSFN/NXDN)
emulatorAddress = 127.0.0.1:2470        ; IP address and port of the server

; Audio devices are normally not needed when in gateway service.  These devices should
; only be set when local monitor or dongle modes are required.
outputAudioDevice = /dev/null           ; Audio device /dev/null, /dev/dsp1, portaudio, etc
inputAudioDevice = /dev/null            ; Only used for dongle mode

; Below values are for using this as a local DMR dongle (no ASL needed)
useMicrophone = false                   ; Use app as just a fancy dongle for DMR
useVox = false                          ; If using dongle mode (useMicrophone), enable VOX
voxDecay = 2                            ; Hang time in seconds
voxTrigger = 200                        ; Value to trip PTT (0-32767)

; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC)
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 34000                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" $
toDMRPort = 34003                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort$
ambeMode = P25                          ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 334118                   ; ID to use when transmitting from Analog_Bridge
repeaterID = 334118                     ; ID of source repeater
txTg = 5995                             ; TG to use for all frames received from Analog_Bridge -> x$
txTs = 2                                ; Slot to use for frames received from Analog_Bridge -> xx_$
colorCode = 1                           ; Color Code to assign DMR frames

; Information for USRP channel driver.  This interface uses PCM to transfer audio information
; There are two typical configurations, ASL and Transcode.  ASL (AllstarLink) is for analog clients$; to a digital network.  Transcode is when Analog_Bridge actually points its PCM interfaces back at$; causing a TLV <-- (pcm <--> pcm) --> TLV type of architecture.
;   When using ASL, this matches the rpt.conf ASL file with a setting like:
;   rxchannel = usrp/127.0.0.1:34001:32001
;   When Transcoding, make toASLPort equal to the other instance fromASLPort (crossover)
[USRP]
server = 127.0.0.1                      ; IP address of Allstar/Asterisk
toASLPort = 32001                       ; Analog_Bridge <-- ASL
fromASLPort = 34001                     ; Analog_Bridge --> ASL
aslAudio = AUDIO_UNITY                  ; Audio to ASL (AUDIO_UNITY, AUDIO_USE_AGC, AUDIO_USE_GAIN)
agcGain = -20                           ; Gain (in db) of the AGC filter
dmrAudio = AUDIO_UNITY                  ; Audio from ASL (AUDIO_UNITY, AUDIO_USE_GAIN, AUDIO_BPF)
dmrGain = 0.35                          ; Gain factor of audio from ASL (0.0-1.0)

; Information for DV3000 hardware decoder
;   There are two configuration modes: IP (AMBEServer) and serial (direct connect hardware)
;   Use top server and port if using AMBEServer
;   Use bottom server/port and serial = true if using the DV3000u (thumbdv)
;   Did you run AMBETest4.py before using this?
[DV3000]
server = 127.0.0.1                      ; IP address of AMBEServer
port = 2460                             ; Port of AMBEServer
; server = /dev/ttyUSB0                 ; Device of DV3000U on this machine
; port = 460800                         ; Baud rate of the dongle
; serial = true                         ; Use serial (DV3000U) or IP


Analog_Bridge_DMR.ini 

; General vocoder setup information
decoderFallBack = false                 ; Allow software AMBE decoding if a hardware decoder is not$
useEmulator = true                      ; Use the MD380 AMBE emulator for AMBE72 (DMR/YSFN/NXDN)
emulatorAddress = 127.0.0.1:2470        ; IP address and port of the server

; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC)
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 31000                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" $
toDMRPort = 31003                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort$
ambeMode = DMR                          ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 334118                   ; ID to use when transmitting from Analog_Bridge
repeaterID = 334118                     ; ID of source repeater
txTg = 334105                           ; TG to use for all frames received from Analog_Bridge -> x$
txTs = 2                                ; Slot to use for frames received from Analog_Bridge -> xx_$colorCode = 1                           ; Color Code to assign DMR frames

[USRP]
server = 127.0.0.1                      ; IP address of Allstar/Asterisk
toASLPort = 34001                       ; Analog_Bridge <-- ASL
fromASLPort = 32001                     ; Analog_Bridge --> ASL
aslAudio = AUDIO_UNITY                  ; Audio to ASL (AUDIO_UNITY, AUDIO_USE_AGC, AUDIO_USE_GAIN)
agcGain = -20                           ; Gain (in db) of the AGC filter
dmrAudio = AUDIO_UNITY                  ; Audio from ASL (AUDIO_UNITY, AUDIO_USE_GAIN, AUDIO_BPF)
dmrGain = 0.35                          ; Gain factor of audio from ASL (0.0-1.0)

Thank you so much for your help.


On Sunday, November 18, 2018 6:19 PM, Juan Carlos Pérez via Groups.Io <km4nno@...> wrote:


Dear Steve,

Thank you, that is exactly what I was looking for.

Juan Carlos,
XE1F


On Sunday, November 18, 2018 5:52 PM, Steve N4IRS <szingman@...> wrote:


Juan,
I'll answer the bridge between P25 and DMR here and recommend you join the Quantar Bridge subgroup at https://dvswitch.groups.io/g/Quantar-Bridge for your Quantar question.

To build a bridge between DMR and P25 you will need to transcode P25 <-> DMR. A transcoder requires 2 instances of Analog_Bridge. The system will look like this:

P25Reflector <-> P25Gateway <-> MMDVM_Bridge <-> Analog_Bridge <-> Analog_Bridge <-> MMDVM_Bridge <-> BrandMeister.

The P25Reflector is TG 334015
MMDVM_Bridge can do DMR and P25 at the same time so uyou will need only one instance
The easiest way to run 2 instances of Analog_Bridge is to have 2 .ini files. Copy the default Analog_Bridge.ini to Analog_Bridge_P25.ini and Analog_Bridge_DMR.ini
Edit each copy to configure for the mode and run the program with the name of the config file. ./Analog_Bridge Analog_Bridge_DMR.ini

These are very broad strokes. I suggest you build from the outside in.

Hope this helps,
Steve N4IRS
 

On 11/18/18 6:30 PM, Juan Carlos Pérez via Groups.Io wrote:
Hi everybody, I am really new to DV-Bridge, so I have a lot of questions after reading DVSwitch documentation.

So, I had successfully setup a Quantar repeater to connect with a Cisco 1841 and to a RaspberryPi running QuantarBridge and connecting it to MMDVM P25 talk groups.
1.- Is it possible to set an especific Talk Group to auto connect to a reflector (i.e. 10200) after lets say 10 minues that the repeater has been idle (like a reflector auto reconnect), unless a different Talk Group is selected by a PPT on that different Talk Group?

2.- It is possible to link a P25 local Talk Group (i.e. 334105) to a DMR Talk Group on BrandMeister (i.e. 334105)? In this case the TG 334105 on the BM network is the TG for my DMR repeater.

If any answer is yes, could you point me in the right direction to build that setup. 
Thank you,

Juan Carlos
NXDN to YSF

f0dei
 

Hello,

Does anyone know why a transmission from NXDN to YSF is received as VW instead DN on Fusion side ?

Configure the Yaesu Fusion Partner
; Audio format is AMBE 72 bit
; Audio format is IMBE 88 bit
[YSF]
Address = 127.0.0.1 ; Address to send AMBE TLV frames to (export)
TXPort = 33103 ; Port to send AMBE TLV frames to (export)
RXPort = 33100 ; Port to listen on (import)
FallbackID = 12345678 ; In case we can not find a valid DMR id in the da-
tabase, export this one
ExportTG = 20811; Which TG to export
Slot = 2 ; Export slot

 Configure the NXDN Partner
; Audio format is AMBE 72 bit
[NXDN]
Address = 127.0.0.1 ; Address to send AMBE TLV frames to (export)
TXPort = 33100 ; Port to send AMBE TLV frames to (export)
RXPort = 33103 ; Port to listen on (import)
FallbackID = 12345678 ; In case we can not find a valid DMR id in the da-
tabase, export this one
NXDNFallbackID = 123456 ; Use this ID when the input DMR ID is not 
found in the database
Translate = 65208=20811 ; Translate NXDN TG < -- > DMR TG (bidirec-
tional)
Slot = 2

73
Toufik
Re: How to link between a Quantar on P25 to BM DMR?

Juan Carlos Pérez <km4nno@...>
 

Dear Steve,

Thank you, that is exactly what I was looking for.

Juan Carlos,
XE1F


On Sunday, November 18, 2018 5:52 PM, Steve N4IRS <szingman@...> wrote:


Juan,
I'll answer the bridge between P25 and DMR here and recommend you join the Quantar Bridge subgroup at https://dvswitch.groups.io/g/Quantar-Bridge for your Quantar question.

To build a bridge between DMR and P25 you will need to transcode P25 <-> DMR. A transcoder requires 2 instances of Analog_Bridge. The system will look like this:

P25Reflector <-> P25Gateway <-> MMDVM_Bridge <-> Analog_Bridge <-> Analog_Bridge <-> MMDVM_Bridge <-> BrandMeister.

The P25Reflector is TG 334015
MMDVM_Bridge can do DMR and P25 at the same time so uyou will need only one instance
The easiest way to run 2 instances of Analog_Bridge is to have 2 .ini files. Copy the default Analog_Bridge.ini to Analog_Bridge_P25.ini and Analog_Bridge_DMR.ini
Edit each copy to configure for the mode and run the program with the name of the config file. ./Analog_Bridge Analog_Bridge_DMR.ini

These are very broad strokes. I suggest you build from the outside in.

Hope this helps,
Steve N4IRS
 

On 11/18/18 6:30 PM, Juan Carlos Pérez via Groups.Io wrote:
Hi everybody, I am really new to DV-Bridge, so I have a lot of questions after reading DVSwitch documentation.

So, I had successfully setup a Quantar repeater to connect with a Cisco 1841 and to a RaspberryPi running QuantarBridge and connecting it to MMDVM P25 talk groups.
1.- Is it possible to set an especific Talk Group to auto connect to a reflector (i.e. 10200) after lets say 10 minues that the repeater has been idle (like a reflector auto reconnect), unless a different Talk Group is selected by a PPT on that different Talk Group?

2.- It is possible to link a P25 local Talk Group (i.e. 334105) to a DMR Talk Group on BrandMeister (i.e. 334105)? In this case the TG 334105 on the BM network is the TG for my DMR repeater.

If any answer is yes, could you point me in the right direction to build that setup. 
Thank you,

Juan Carlos
Re: ASL to DMR Bridge...audiuo quality

Steve N4IRS
 

I assume you mean group call. Try TG 31000 for parrot.

On 11/18/18 6:00 PM, Neil k8it wrote:
how do I set the dmr tg to the parrot like 9990 private call
seems like the  analog bridge defsults to general
 
 
Thanks
73 Neil Sablatzky  K8IT
Allstar Node 41838 KITLINK
Allstar Node 42087 KITLINK HUB
IRLP Node exp0068
Echolink K8IT-L
WIRES-X K8IT 11479 Room 21479

Sent: Friday, November 16, 2018 4:59 PM
Subject: Re: [DVSwitch] ASL to DMR Bridge...audiuo quality

Have toy listened to the analog audio on another analog node or IAXRPT etc?
You can control the audio levels in Analog_bridge.ini In the [USRP] stanza,setting aslAudio and dmrAudio to AUDIO_UNITY will keep provide no gain or reduction.

If you need to adjust the DMR -> ASL audio, change:
aslAudio = AUDIO_USE_GAIN

agcGain = 1.0
This should be the same level as AUDIO_UNITY

agcGain = 2.0
This should be twice as loud as AUDIO_UNITY

agcGain = 0.5
This should be half as loud as AUDIO_UNITY  
=========================================

If you need to adjust the ASL -> DMR audio, change:
dmrAudio = AUDIO_USE_GAIN

dmrGain = 1.0
This should be the same level as AUDIO_UNITY

dmrGain = 2.0
This should be twice as loud as AUDIO_UNITY

dmrGain = 0.5
This should be half as loud as AUDIO_UNITY


On 11/16/18 4:42 PM, Neil k8it wrote:
running half duplex no emphasis using default settings for node 1999 but I have tunned my private  node which I can make public if needed.. I also can provide ssh login if needed off list
what audio params should I play with, and is the best way to do it.
currently on t/g 3126
 
Thanks
73 Neil Sablatzky  K8IT
Allstar Node 41838 KITLINK
Sent: Friday, November 16, 2018 4:09 PM
Subject: Re: [DVSwitch] ASL to DMR Bridge...audiuo quality

How are you connected to the receiver? Pre-emphasised or de-emphasised? Are you running simplex or duplex? If duplex how does the audio sound out the analog transmitter? If simplex, is it a public node that can connect to another node for a audio report?
If all that is good, look at your audio levels from analog to digital.

Steve N4IRS

On 11/16/18 4:02 PM, Neil k8it wrote:
I got the analog bridge to work now. I am now trying to improve the audio quality of the audio sent to DMR.
I correctly am using USBRADIO for my private Allstar node with audio that sounds very compressed.
Would I be better off to switch to SIMPLEUSB?
Is there any tricks to getting more audio bandwidth?
 
 
 
 
 
Thanks
73 Neil Sablatzky  K8IT
Allstar Node 41838 KITLINK
Re: How to link between a Quantar on P25 to BM DMR?

Steve N4IRS
 

Juan,
I'll answer the bridge between P25 and DMR here and recommend you join the Quantar Bridge subgroup at https://dvswitch.groups.io/g/Quantar-Bridge for your Quantar question.

To build a bridge between DMR and P25 you will need to transcode P25 <-> DMR. A transcoder requires 2 instances of Analog_Bridge. The system will look like this:

P25Reflector <-> P25Gateway <-> MMDVM_Bridge <-> Analog_Bridge <-> Analog_Bridge <-> MMDVM_Bridge <-> BrandMeister.

The P25Reflector is TG 334015
MMDVM_Bridge can do DMR and P25 at the same time so uyou will need only one instance
The easiest way to run 2 instances of Analog_Bridge is to have 2 .ini files. Copy the default Analog_Bridge.ini to Analog_Bridge_P25.ini and Analog_Bridge_DMR.ini
Edit each copy to configure for the mode and run the program with the name of the config file. ./Analog_Bridge Analog_Bridge_DMR.ini

These are very broad strokes. I suggest you build from the outside in.

Hope this helps,
Steve N4IRS
 

On 11/18/18 6:30 PM, Juan Carlos Pérez via Groups.Io wrote:
Hi everybody, I am really new to DV-Bridge, so I have a lot of questions after reading DVSwitch documentation.

So, I had successfully setup a Quantar repeater to connect with a Cisco 1841 and to a RaspberryPi running QuantarBridge and connecting it to MMDVM P25 talk groups.
1.- Is it possible to set an especific Talk Group to auto connect to a reflector (i.e. 10200) after lets say 10 minues that the repeater has been idle (like a reflector auto reconnect), unless a different Talk Group is selected by a PPT on that different Talk Group?

2.- It is possible to link a P25 local Talk Group (i.e. 334105) to a DMR Talk Group on BrandMeister (i.e. 334105)? In this case the TG 334105 on the BM network is the TG for my DMR repeater.

If any answer is yes, could you point me in the right direction to build that setup. 
Thank you,

Juan Carlos
How to link between a Quantar on P25 to BM DMR?

Juan Carlos Pérez <km4nno@...>
 

Hi everybody, I am really new to DV-Bridge, so I have a lot of questions after reading DVSwitch documentation.

So, I had successfully setup a Quantar repeater to connect with a Cisco 1841 and to a RaspberryPi running QuantarBridge and connecting it to MMDVM P25 talk groups.
1.- Is it possible to set an especific Talk Group to auto connect to a reflector (i.e. 10200) after lets say 10 minues that the repeater has been idle (like a reflector auto reconnect), unless a different Talk Group is selected by a PPT on that different Talk Group?

2.- It is possible to link a P25 local Talk Group (i.e. 334105) to a DMR Talk Group on BrandMeister (i.e. 334105)? In this case the TG 334105 on the BM network is the TG for my DMR repeater.

If any answer is yes, could you point me in the right direction to build that setup. 
Thank you,

Juan Carlos
Re: ASL to DMR Bridge...audiuo quality

Neil k8it
 

how do I set the dmr tg to the parrot like 9990 private call
seems like the  analog bridge defsults to general
 
 
Thanks
73 Neil Sablatzky  K8IT
Allstar Node 41838 KITLINK
Allstar Node 42087 KITLINK HUB
IRLP Node exp0068
Echolink K8IT-L
WIRES-X K8IT 11479 Room 21479

Sent: Friday, November 16, 2018 4:59 PM
Subject: Re: [DVSwitch] ASL to DMR Bridge...audiuo quality

Have toy listened to the analog audio on another analog node or IAXRPT etc?
You can control the audio levels in Analog_bridge.ini In the [USRP] stanza,setting aslAudio and dmrAudio to AUDIO_UNITY will keep provide no gain or reduction.

If you need to adjust the DMR -> ASL audio, change:
aslAudio = AUDIO_USE_GAIN

agcGain = 1.0
This should be the same level as AUDIO_UNITY

agcGain = 2.0
This should be twice as loud as AUDIO_UNITY

agcGain = 0.5
This should be half as loud as AUDIO_UNITY  
=========================================

If you need to adjust the ASL -> DMR audio, change:
dmrAudio = AUDIO_USE_GAIN

dmrGain = 1.0
This should be the same level as AUDIO_UNITY

dmrGain = 2.0
This should be twice as loud as AUDIO_UNITY

dmrGain = 0.5
This should be half as loud as AUDIO_UNITY


On 11/16/18 4:42 PM, Neil k8it wrote:
running half duplex no emphasis using default settings for node 1999 but I have tunned my private  node which I can make public if needed.. I also can provide ssh login if needed off list
what audio params should I play with, and is the best way to do it.
currently on t/g 3126
 
Thanks
73 Neil Sablatzky  K8IT
Allstar Node 41838 KITLINK
Sent: Friday, November 16, 2018 4:09 PM
Subject: Re: [DVSwitch] ASL to DMR Bridge...audiuo quality

How are you connected to the receiver? Pre-emphasised or de-emphasised? Are you running simplex or duplex? If duplex how does the audio sound out the analog transmitter? If simplex, is it a public node that can connect to another node for a audio report?
If all that is good, look at your audio levels from analog to digital.

Steve N4IRS

On 11/16/18 4:02 PM, Neil k8it wrote:
I got the analog bridge to work now. I am now trying to improve the audio quality of the audio sent to DMR.
I correctly am using USBRADIO for my private Allstar node with audio that sounds very compressed.
Would I be better off to switch to SIMPLEUSB?
Is there any tricks to getting more audio bandwidth?
 
 
 
 
 
Thanks
73 Neil Sablatzky  K8IT
Allstar Node 41838 KITLINK
8181 - 8200 of 10634