Date   

DMR to the Bridge Echolink conference server

bagdala@...
 

The bridge is an iLink/EchoLink compatible conference bridge and we have been using it to host our Echolink conference server. I was wondering if anyone tried using DVSwitch to link DMR and TBD ?
And if not, what would you recommend for linking DMR and Echolink only ( non allstar node )


Re: OpenBridge issue both bm&ipsc2

Cort N0MJS <n0mjs@...>
 

Yep, that’s expected and known. IPSC2 servers send one additional packet at the end of a data stream that is outside of the protocol spec defined by DMR+ and Brandmeister. It does not affect usability. To date I have had no luck finding out what it is, though Artem at Brandmeister was going to try and look into it. BM has made the protocol open to all, DMR+ considers it their IP and is not interested in publication.

+1 Brandmeister
-1 DMR+

You can ignore it. It is not causing problems.

Which brings up something in general for everyone – just because something might look “bad” to you in a log doesn’t mean something is failing. I log a LOT OF STUFF. Please assume that, unless something in practice is failing, many log messages that look ominous are not.

On Jan 15, 2019, at 10:14 AM, Themis Floros SV4QXF <xsystemgr@...> wrote:

Hello guys , i have a setup with hblink for mmdvm and a newer hblink with a openbridge config . The last days i try to connect to ipsc2 server and to bm server and take this message

OpenBridge HMAC failed, packet discarded - OPCODE: DMRD DATA: 'DMRD\xb50\x0c=\x00\x00[\x00\x00\x07\xe5\x04\xbe\xab|Y\xc48\x91B5kt\x15\x9e\x93\n)\xa6QR\x89P\x9cPp\x8f\x17Ol\xe8\x99\xa4\x12/\xb7e\xe6\xcd'

Thanks

Cort Buffington
785-865-7206


OpenBridge issue both bm&ipsc2

Themis Floros SV4QXF
 

Hello guys , i have a setup with hblink for mmdvm and a newer hblink with a openbridge config . The last days i try to connect to ipsc2 server and to bm server and take this message

OpenBridge HMAC failed, packet discarded - OPCODE: DMRD DATA: 'DMRD\xb50\x0c=\x00\x00[\x00\x00\x07\xe5\x04\xbe\xab|Y\xc48\x91B5kt\x15\x9e\x93\n)\xa6QR\x89P\x9cPp\x8f\x17Ol\xe8\x99\xa4\x12/\xb7e\xe6\xcd'

Thanks


Re: Is this even possible?

Jim Gifford - K9AGR
 

I've been sick the last 6 weeks or so, but I'm finally getting back on my feet.

During my convalescence, I didn't have much energy to work on this project.  But now, I'm ready to get back to it, and make this all work.

Corey, for setting up an openbridge feed from BM, should I coordinate directly with you, or should I contact the dmr-admins (at) repeater.net address?  Do I need to pre-choose the talkgroups I want fed to me via the openbridge, or is it more like the self-serve features of the normal BM console?

I already have a working feed of 8802 from K4USD that I'm happy with.  It has been rock solid, and I'd like to just keep using that feed since it's already functional.

Thank you again for all the assistance,
Jim

On Dec 4, 2018, at 9:05 PM, Corey Dean N3FE <n3fe@...> wrote:

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






Re: ASL to XLX in DSTAR mode ? Lost audio -> Solved

Santu OTTAVI (TK1BI)
 



Le 14/01/2019 à 22:39, Ken KE2N via Groups.Io a écrit :
D: 2019-01-14 19:48:03.324 D-Star, lost audio for 300ms filling in, elapsed: 1211ms, expected: 60, received: 43
M: 2019-01-14 19:48:03.616 D-Star, network watchdog has expired, 1.2 seconds,  98% packet loss, BER: 0.0%

In case anybody else encounters that "D-Star lost audio" error :
According to Murphy's Law, the cause was completely external to Analog_Bridge / MMDVM_Bridge setup :

xlx ambed daemon had a malfunction. Errors were present in XLX log. Strangely, it scrambled all XLX traffic, including traffic that did not require XLX transcoding. This also affected Analog_bridge traffic.

Restarting ambed solved that problem.


Re: ASL to XLX in DSTAR mode ? MMDVM_Bridge transmitting DMR-ID instead of callsign

Santu OTTAVI (TK1BI)
 

Hi,

Le 14/01/2019 à 22:39, Ken KE2N via Groups.Io a écrit :

My setup is probably not what you want.  The ASL link is to a DMR talk group:

Asterisk <-> chan_USRP <-> Analog_Bridge <-> MMDVM_Bridge <-> DMR TG


Thank you for your answer. Here, the XLX is the central part of the system. It has internal transcoding, and all other stuff (including Asterisk hub) will connect to it. What I'm trying to do is :
Asterisk Hub <-> chan_USRP <-> Analog_Bridge <-> MMDVM_Bridge <-> ircddbgatewayd <-> XLX
Here's the current status :
- From XLX to Asterisk : it works perfectly
- From Asterisk to XLX : <nothing>

On the XLX log, I can see packets arriving from my Asterisk node, but it's as if they are not interpreted as a connection request by XLX :
Jan 14 22:51:01 xlx xlxd: DCS packet (100) from 10.44.0.3
Looking at MMDVM_Bridge, I can see D-Star outgoing packets :
M: 2019-01-15 09:38:53.337 D-Star link status set to "Connected to DCS755 K "
M: 2019-01-15 09:39:41.514 D-Star, TX state = ON
I: 2019-01-15 09:39:41.514 D-Star, Begin TX: src=6693310 rpt=2080199 dst=6 slot=2 cc=1 metadata=208019902
D: 2019-01-15 09:39:41.514 D-Star Network Header Sent
D: 2019-01-15 09:39:41.514 0000:  44 53 52 50 20 4C CE 00 40 00 00 54 4B 35 4B 50    *DSRP L..@..TK5KP*
D: 2019-01-15 09:39:41.514 0010:  20 20 47 54 4B 35 4B 50 20 20 47 43 51 43 51 43    *  GTK5KP  GCQCQC*
D: 2019-01-15 09:39:41.514 0020:  51 20 20 32 30 38 30 31 39 39 30 44 56 53 57 E7    *Q  20801990DVSW.*
Something seems to be wrong here :
- TK5KP is the callsign of my gateway
- 2080199 is the DMR-ID of TK5KP. This field is the source caller ID. I would expect it to contain a D-Star callsign, not a CCS7 ID.

Problem :
It seems MMDVM_Bridge is sending a D-Star connection frame with a DMR-ID instead of a D-Star callsign, which makes XLX ignore it.

Additional question :
Can I use the same callsign (TK5KP) for ircddb gateway callsign, MMDVM_bridge "repeater" callsign, and source callsign (which will appear on D-Star network for data originating from Asterisk) ?

Thank you in advance for your help.

73 de TK1BI



Re: Help linking P25 to DMR

mike@...
 

Thanks Steve. I'll grab those components and start experimenting! 

I have an existing P25Reflector that connects a couple of MMDVM repeaters (primarily P25 users) and wish to bridge a talk group with one on Brandmeister.

I'm going to try this on a R-pi 3b+; do you think that's going to be robust enough to run everything? 

73,
Mike - N6MIK

On Mon, Jan 14, 2019 at 7:58 PM Steve N4IRS <szingman@...> wrote:
Mike,
Yes you will need those things also. here is a basic diagram:
P25Reflector <-> P25Gateway <-> MMDVM_Bridge <-> Analog_Bridge <-> Analog_Bridge <-> MMDVM_Bridge <-> DMR Master (BM, HB etc)
You will need 2 instances of Analog_Bridge
The 2 MMDVM_Bridges can be done as one instance.

The question is, what exactly are you trying to bridge? That will tell us more about the ends of the bridge.

73, Steve N4IRS

On 1/14/19 10:51 PM, mike@... wrote:
Hey all, 

I'm brand new to the group, but have been experimenting with DMR and P25 for a while. I am looking to build a bridge between P25 and DMR, and have found just enough to confuse me on the 'web. :) 

It looks like I'll need MMDVM_Bridge for sure - but I am unclear what other components I need. I have also seen a post (possibly outdated) that talks about needing gateways, reflectors and a couple of analog bridges... but something is telling me that may not be the case. 

Am I on the right track? Any pointers are appreciated!

Thanks and 73, 
Mike - N6MIK


Re: Help linking P25 to DMR

Steve N4IRS
 

Mike,
Yes you will need those things also. here is a basic diagram:
P25Reflector <-> P25Gateway <-> MMDVM_Bridge <-> Analog_Bridge <-> Analog_Bridge <-> MMDVM_Bridge <-> DMR Master (BM, HB etc)
You will need 2 instances of Analog_Bridge
The 2 MMDVM_Bridges can be done as one instance.

The question is, what exactly are you trying to bridge? That will tell us more about the ends of the bridge.

73, Steve N4IRS

On 1/14/19 10:51 PM, mike@... wrote:
Hey all, 

I'm brand new to the group, but have been experimenting with DMR and P25 for a while. I am looking to build a bridge between P25 and DMR, and have found just enough to confuse me on the 'web. :) 

It looks like I'll need MMDVM_Bridge for sure - but I am unclear what other components I need. I have also seen a post (possibly outdated) that talks about needing gateways, reflectors and a couple of analog bridges... but something is telling me that may not be the case. 

Am I on the right track? Any pointers are appreciated!

Thanks and 73, 
Mike - N6MIK


Help linking P25 to DMR

mike@...
 

Hey all, 

I'm brand new to the group, but have been experimenting with DMR and P25 for a while. I am looking to build a bridge between P25 and DMR, and have found just enough to confuse me on the 'web. :) 

It looks like I'll need MMDVM_Bridge for sure - but I am unclear what other components I need. I have also seen a post (possibly outdated) that talks about needing gateways, reflectors and a couple of analog bridges... but something is telling me that may not be the case. 

Am I on the right track? Any pointers are appreciated!

Thanks and 73, 
Mike - N6MIK


Re: DMR vs DSTAR

Pierre Martel
 

Brain fart! Sorry! 


Le lun. 14 janv. 2019 à 17:26, Steve N4IRS <szingman@...> a écrit :
Uh, no P25 is IMBE

Sent via smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Pierre Martel <petem001@...>
Sent: Monday, January 14, 2019 4:44:54 PM
To: main@dvswitch.groups.io
Subject: Re: [DVSwitch] DMR vs DSTAR
 
Yes dmr is AMBE while Dstar is IMBE

Le lun. 14 janv. 2019 à 16:37, Vincenzo Salamone <it9cdu@...> a écrit :
Ok, so I need necessarily some hardware for transcode DMR--->Dstar and viceversa?

Il giorno lun 14 gen 2019 alle ore 22:33 Steve KC1AWV <smiller@...> ha scritto:
In my case, I run ambed on a server at home, separate from my XLX server that's in a data center. The ambed service (included with xlxd) runs the transcoding for D-Star <-> DMR for the XLX server. In order to achieve transcoding, some DV3000 dongles are attached to the ambed server.

This setup is a bit more advanced/customized, since I have services running on separate servers. Also, we're talking more along the lines of xlxd now, which is out of scope for the DVSwitch group.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:04 PM Vincenzo Salamone <it9cdu@...> wrote:
OK Steve,
now all the connections seems to work, but, no audio pass from dstar to dmr .... the transmission is MUTE. Maybe I need some AMBE codec to install ?

Il giorno lun 14 gen 2019 alle ore 19:58 Steve KC1AWV <smiller@...> ha scritto:
The connection between MMDVM_Bridge to DMRGateway here is like this:

---
MMDVM_Bridge.ini

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

---
DMRGateway.ini

[General]
Timeout=10
# RFTimeout=10
# NetTimeout=7
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

I assume you're running both programs on the same machine, so all addresses will be loopback.

Steve KC1AWV

On Mon, Jan 14, 2019 at 1:49 PM Vincenzo Salamone <it9cdu@...> wrote:
Thank's Steve,
XLX connection is ok now. Can you give me an example how to "Set MMDVM_Bridge to send its audio to DMRGateway" ?

tnx

Il giorno lun 14 gen 2019 alle ore 19:03 Steve KC1AWV <smiller@...> ha scritto:
If you are connecting to XLX, I used DMRGateway as well as MMDVM_Bridge. In DMRGateway.ini, you can set the XLX Network stanza similar to this:

[XLX Network]
Enabled=1
File=/var/lib/mmdvm/XLXHosts.txt
Port=62030
Password=passw0rd
ReloadTime=60
Slot=2
TG=6
Base=64000
Startup=740
Relink=60
Debug=0
Id=
UserControl=1
Module=B

Of course, use your own DMR ID on the Id= line. Set MMDVM_Bridge to send its audio to DMRGateway.

Steve KC1AWV

On Mon, Jan 14, 2019 at 12:57 PM Vincenzo Salamone <it9cdu@...> wrote:
Hi,
I want to bridge DMR to an XLX module, I understand that I can use the DVSwitch tools and MMDVM_Bridge. I have to create 2 instances of MMDVM_Bridge but I don't understand how connect to a specific module of XLX one instance of MMDVM_Bridge.
Anyone ca help me to better understand?
thank's

73 de IT9CDU



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV


Re: DMR vs DSTAR

Steve N4IRS
 

My 1841 is here <https://dvswitch.groups.io/g/Quantar-Bridge/topic/router_config/23325590?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,23325590>
There are also a couple in the wiki in the Quantar_Bridge sub group

On 1/14/19 7:29 PM, Mike Clay wrote:
Speaking of P25, does anyone have a Cisco router configuration file for networking a Quantar repeater?
Thanks

Mike AC5XV


Re: DMR vs DSTAR

Mike Clay <Mclay2005@...>
 

Speaking of P25, does anyone have a Cisco router configuration file for networking a Quantar repeater?
Thanks

Mike AC5XV


Re: If you use HBlink OR dmr_utils, you need to read this

Cort N0MJS <n0mjs@...>
 

A bit more now the I’m on a real computer. The way those streams get processed on the TX side, I’ve not found a really efficient way to terminate them with the call end. The efficient place would be right before the stream metadata is used for forwarding, necessitating another check fo the same condition again after forwarding… I’m trying to find a better way, but letting them timeout isn’t a problem. It just keeps entries in a list a few seconds longer.

On Jan 14, 2019, at 4:26 PM, Cort N0MJS via Groups.Io <n0mjs@...> wrote:

Not an error. TX streams have to time out for not. There’s no explicit end for OBP TX streams yet


On Jan 14, 2019, at 2:41 PM, JJ Cummings <cummingsj@...> wrote:

Cort - great stuff I just switched over so the stack now looks like this (for those that care)

DMRLink <-> IPSC_Bridge <-> HB_Bridge <-> hblink3(bridge) <-> Analog_Bridge <-> ASL

On a separate note, I noted a an error in the log specifically related  to openbridge (outbound only connections) looks like it's not registering that the END event has occurred when it happens and thusly it times out?.  Posting here but hopefully I can post a pull request if ever I get time to debug at all.

INFO 2019-01-14 14:16:30,526 (ANALOG_BRIDGE) *CALL END*   STREAM ID: 2752969323 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.02
INFO 2019-01-14 14:16:35,780 (OBP-3103) *TIME OUT*   STREAM ID: 2752969323 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.02
INFO 2019-01-14 14:19:21,827 (ANALOG_BRIDGE) *CALL START* STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1
INFO 2019-01-14 14:19:21,878 (ANALOG_BRIDGE) Conference Bridge: 310815, Call Bridged to OBP System: OBP-3103 TS: 1, TGID: 310815
INFO 2019-01-14 14:19:24,859 (ANALOG_BRIDGE) *CALL END*   STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.03
INFO 2019-01-14 14:19:30,780 (OBP-3103) *TIME OUT*   STREAM ID: 205043449 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.03

On Fri, Jan 11, 2019 at 11:04 AM Cort N0MJS via Groups.Io <n0mjs=me.com@groups.io> wrote:
Folks,

PYTHON2 BASED VERSIONS OF HBLINK AND DMR_UTILS ARE NOW SUNSET – ONLY BUG FIXES WILL BE OFFERED.



If you go looking at my repos on GitHub, you’ll see a couple of new things:

HBlink3 and dmr_utils3

These are Python3 versions of HBlink and dmr_utils. Currently, dmr_utils3 does not include ambe_bridge.py and HBlink3 does not include parrot or bridge_all – effectively leaving it as the base stack and the conference bridge application… there have also been some things renamed. I removed “hb_” from the beginning of all of the files, and I also renamed hb_confbridge.py to bridge.py. Likewise I renamed hb_confbridge_rules.py to rules.py. The main goal with the name changes is to make the first character or few unique. I’m a shitty typist to begin with, so being able to type b(tab) and get bridge.py is a lot easier than having to type out hb_confbridge.py all of the time… and I have to type those things a lot when I’m in full-on coding mode :)

As for the future of the other HBlink programs – some of that is going to be dependent on community support. I would love to see someone step up and port all_bridge.py and parrot.py to Python3. I will eventually get to them, but not soon because….

The master branch of HBlink3 is stable and has been running on the K0USY Group’s “KS-DMR” network all week. On our particular system, with the things we have configured, just moving to Python3 (ok, a few bits of refactoring as well) has given us a 15-20% performance boost (measured in time between packet ingress and processing completion). You will also notice another branch of HBlink3 called uvloop. With this branch I’m swapping out the venerable Twisted module for Python3’s built-in Asyncio module, and a “drop in replacement” for portions of it called uvLoop, an ultra-fast drop-in replacement for parts of Asyncio… just moving to Python3 gave us a nice bump. My hope is that the move to uvloop makes HBlink work much faster – potentially rivaling statically compiled to machine-code software.

I’ve already moved off of the master branch to work on the uvloop branch. This development will be rapid – because the goal is to have hblink.py and bridge.py working on uvloop ASAP. Once that is completed, I will go back and start filling in the gaps as well as adding features. I do not intend to back-port new features to the Python2 versions.

The HBlink3 master branch will support the existing python2 hbmonitor software. The uvloop branch will not. I intend to “burn down” the reporting “stuff” and start over with HBlink3 on uvloop. I am looking for javascript (and related browser code) developers to help with this. Hbmonitor is a bandwidth HOG. It renders the entirety of the HTML tables on the server for every incremental change, and pushes all of that HTML out to the browser. A busy system on HBmonitor can use close to 1Mbps of bandwidth for a single browser connected. The goal is to send much less information to the browser, and let the browser build the tables… but I don’t have a clue about programming that stuff. Co-developers welcome!!!

0x49 DE N0MJS



Cort Buffington
785-865-7206





Cort Buffington
785-865-7206


Re: DMR vs DSTAR

Matt Ames
 

Actually, DMR is AMBE2+ while DSTAR is AMBE.

The only protocol that uses IMBE is P25 Phase 1.


On Tue, 15 Jan 2019 at 08:45, Pierre Martel <petem001@...> wrote:
Yes dmr is AMBE while Dstar is IMBE

Le lun. 14 janv. 2019 à 16:37, Vincenzo Salamone <it9cdu@...> a écrit :
Ok, so I need necessarily some hardware for transcode DMR--->Dstar and viceversa?

Il giorno lun 14 gen 2019 alle ore 22:33 Steve KC1AWV <smiller@...> ha scritto:
In my case, I run ambed on a server at home, separate from my XLX server that's in a data center. The ambed service (included with xlxd) runs the transcoding for D-Star <-> DMR for the XLX server. In order to achieve transcoding, some DV3000 dongles are attached to the ambed server.

This setup is a bit more advanced/customized, since I have services running on separate servers. Also, we're talking more along the lines of xlxd now, which is out of scope for the DVSwitch group.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:04 PM Vincenzo Salamone <it9cdu@...> wrote:
OK Steve,
now all the connections seems to work, but, no audio pass from dstar to dmr .... the transmission is MUTE. Maybe I need some AMBE codec to install ?

Il giorno lun 14 gen 2019 alle ore 19:58 Steve KC1AWV <smiller@...> ha scritto:
The connection between MMDVM_Bridge to DMRGateway here is like this:

---
MMDVM_Bridge.ini

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

---
DMRGateway.ini

[General]
Timeout=10
# RFTimeout=10
# NetTimeout=7
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

I assume you're running both programs on the same machine, so all addresses will be loopback.

Steve KC1AWV

On Mon, Jan 14, 2019 at 1:49 PM Vincenzo Salamone <it9cdu@...> wrote:
Thank's Steve,
XLX connection is ok now. Can you give me an example how to "Set MMDVM_Bridge to send its audio to DMRGateway" ?

tnx

Il giorno lun 14 gen 2019 alle ore 19:03 Steve KC1AWV <smiller@...> ha scritto:
If you are connecting to XLX, I used DMRGateway as well as MMDVM_Bridge. In DMRGateway.ini, you can set the XLX Network stanza similar to this:

[XLX Network]
Enabled=1
File=/var/lib/mmdvm/XLXHosts.txt
Port=62030
Password=passw0rd
ReloadTime=60
Slot=2
TG=6
Base=64000
Startup=740
Relink=60
Debug=0
Id=
UserControl=1
Module=B

Of course, use your own DMR ID on the Id= line. Set MMDVM_Bridge to send its audio to DMRGateway.

Steve KC1AWV

On Mon, Jan 14, 2019 at 12:57 PM Vincenzo Salamone <it9cdu@...> wrote:
Hi,
I want to bridge DMR to an XLX module, I understand that I can use the DVSwitch tools and MMDVM_Bridge. I have to create 2 instances of MMDVM_Bridge but I don't understand how connect to a specific module of XLX one instance of MMDVM_Bridge.
Anyone ca help me to better understand?
thank's

73 de IT9CDU



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV


Re: If you use HBlink OR dmr_utils, you need to read this

Cort N0MJS <n0mjs@...>
 

Not an error. TX streams have to time out for not. There’s no explicit end for OBP TX streams yet


On Jan 14, 2019, at 2:41 PM, JJ Cummings <cummingsj@...> wrote:

Cort - great stuff I just switched over so the stack now looks like this (for those that care)

DMRLink <-> IPSC_Bridge <-> HB_Bridge <-> hblink3(bridge) <-> Analog_Bridge <-> ASL

On a separate note, I noted a an error in the log specifically related  to openbridge (outbound only connections) looks like it's not registering that the END event has occurred when it happens and thusly it times out?.  Posting here but hopefully I can post a pull request if ever I get time to debug at all.

INFO 2019-01-14 14:16:30,526 (ANALOG_BRIDGE) *CALL END*   STREAM ID: 2752969323 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.02
INFO 2019-01-14 14:16:35,780 (OBP-3103) *TIME OUT*   STREAM ID: 2752969323 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.02
INFO 2019-01-14 14:19:21,827 (ANALOG_BRIDGE) *CALL START* STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1
INFO 2019-01-14 14:19:21,878 (ANALOG_BRIDGE) Conference Bridge: 310815, Call Bridged to OBP System: OBP-3103 TS: 1, TGID: 310815
INFO 2019-01-14 14:19:24,859 (ANALOG_BRIDGE) *CALL END*   STREAM ID: 205043449 SUB: 1108389 (1108389) PEER: 310857 (310857) TGID 310815 (310815), TS 1, Duration: 3.03
INFO 2019-01-14 14:19:30,780 (OBP-3103) *TIME OUT*   STREAM ID: 205043449 SUB: 1108389 PEER: 310885350 TGID: 310815 TS 1 Duration: 3.03

On Fri, Jan 11, 2019 at 11:04 AM Cort N0MJS via Groups.Io <n0mjs=me.com@groups.io> wrote:
Folks,

PYTHON2 BASED VERSIONS OF HBLINK AND DMR_UTILS ARE NOW SUNSET – ONLY BUG FIXES WILL BE OFFERED.



If you go looking at my repos on GitHub, you’ll see a couple of new things:

HBlink3 and dmr_utils3

These are Python3 versions of HBlink and dmr_utils. Currently, dmr_utils3 does not include ambe_bridge.py and HBlink3 does not include parrot or bridge_all – effectively leaving it as the base stack and the conference bridge application… there have also been some things renamed. I removed “hb_” from the beginning of all of the files, and I also renamed hb_confbridge.py to bridge.py. Likewise I renamed hb_confbridge_rules.py to rules.py. The main goal with the name changes is to make the first character or few unique. I’m a shitty typist to begin with, so being able to type b(tab) and get bridge.py is a lot easier than having to type out hb_confbridge.py all of the time… and I have to type those things a lot when I’m in full-on coding mode :)

As for the future of the other HBlink programs – some of that is going to be dependent on community support. I would love to see someone step up and port all_bridge.py and parrot.py to Python3. I will eventually get to them, but not soon because….

The master branch of HBlink3 is stable and has been running on the K0USY Group’s “KS-DMR” network all week. On our particular system, with the things we have configured, just moving to Python3 (ok, a few bits of refactoring as well) has given us a 15-20% performance boost (measured in time between packet ingress and processing completion). You will also notice another branch of HBlink3 called uvloop. With this branch I’m swapping out the venerable Twisted module for Python3’s built-in Asyncio module, and a “drop in replacement” for portions of it called uvLoop, an ultra-fast drop-in replacement for parts of Asyncio… just moving to Python3 gave us a nice bump. My hope is that the move to uvloop makes HBlink work much faster – potentially rivaling statically compiled to machine-code software.

I’ve already moved off of the master branch to work on the uvloop branch. This development will be rapid – because the goal is to have hblink.py and bridge.py working on uvloop ASAP. Once that is completed, I will go back and start filling in the gaps as well as adding features. I do not intend to back-port new features to the Python2 versions.

The HBlink3 master branch will support the existing python2 hbmonitor software. The uvloop branch will not. I intend to “burn down” the reporting “stuff” and start over with HBlink3 on uvloop. I am looking for javascript (and related browser code) developers to help with this. Hbmonitor is a bandwidth HOG. It renders the entirety of the HTML tables on the server for every incremental change, and pushes all of that HTML out to the browser. A busy system on HBmonitor can use close to 1Mbps of bandwidth for a single browser connected. The goal is to send much less information to the browser, and let the browser build the tables… but I don’t have a clue about programming that stuff. Co-developers welcome!!!

0x49 DE N0MJS



Cort Buffington
785-865-7206





Re: DMR vs DSTAR

Steve N4IRS
 

Uh, no P25 is IMBE

Sent via smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Pierre Martel <petem001@...>
Sent: Monday, January 14, 2019 4:44:54 PM
To: main@dvswitch.groups.io
Subject: Re: [DVSwitch] DMR vs DSTAR
 
Yes dmr is AMBE while Dstar is IMBE

Le lun. 14 janv. 2019 à 16:37, Vincenzo Salamone <it9cdu@...> a écrit :
Ok, so I need necessarily some hardware for transcode DMR--->Dstar and viceversa?

Il giorno lun 14 gen 2019 alle ore 22:33 Steve KC1AWV <smiller@...> ha scritto:
In my case, I run ambed on a server at home, separate from my XLX server that's in a data center. The ambed service (included with xlxd) runs the transcoding for D-Star <-> DMR for the XLX server. In order to achieve transcoding, some DV3000 dongles are attached to the ambed server.

This setup is a bit more advanced/customized, since I have services running on separate servers. Also, we're talking more along the lines of xlxd now, which is out of scope for the DVSwitch group.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:04 PM Vincenzo Salamone <it9cdu@...> wrote:
OK Steve,
now all the connections seems to work, but, no audio pass from dstar to dmr .... the transmission is MUTE. Maybe I need some AMBE codec to install ?

Il giorno lun 14 gen 2019 alle ore 19:58 Steve KC1AWV <smiller@...> ha scritto:
The connection between MMDVM_Bridge to DMRGateway here is like this:

---
MMDVM_Bridge.ini

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

---
DMRGateway.ini

[General]
Timeout=10
# RFTimeout=10
# NetTimeout=7
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

I assume you're running both programs on the same machine, so all addresses will be loopback.

Steve KC1AWV

On Mon, Jan 14, 2019 at 1:49 PM Vincenzo Salamone <it9cdu@...> wrote:
Thank's Steve,
XLX connection is ok now. Can you give me an example how to "Set MMDVM_Bridge to send its audio to DMRGateway" ?

tnx

Il giorno lun 14 gen 2019 alle ore 19:03 Steve KC1AWV <smiller@...> ha scritto:
If you are connecting to XLX, I used DMRGateway as well as MMDVM_Bridge. In DMRGateway.ini, you can set the XLX Network stanza similar to this:

[XLX Network]
Enabled=1
File=/var/lib/mmdvm/XLXHosts.txt
Port=62030
Password=passw0rd
ReloadTime=60
Slot=2
TG=6
Base=64000
Startup=740
Relink=60
Debug=0
Id=
UserControl=1
Module=B

Of course, use your own DMR ID on the Id= line. Set MMDVM_Bridge to send its audio to DMRGateway.

Steve KC1AWV

On Mon, Jan 14, 2019 at 12:57 PM Vincenzo Salamone <it9cdu@...> wrote:
Hi,
I want to bridge DMR to an XLX module, I understand that I can use the DVSwitch tools and MMDVM_Bridge. I have to create 2 instances of MMDVM_Bridge but I don't understand how connect to a specific module of XLX one instance of MMDVM_Bridge.
Anyone ca help me to better understand?
thank's

73 de IT9CDU



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV


Re: DMR vs DSTAR

philippe st-cyr
 

I look that tonight 


Le lun. 14 janv. 2019 5:03 p.m., JJ Cummings <cummingsj@...> a écrit :
You are correct, I think that you have to use the DV3000... too many transcode projects right now and I mixed them up lol... though to be fair I have not tried it with md380emu

On Mon, Jan 14, 2019 at 2:58 PM Steve KC1AWV <smiller@...> wrote:
JJ -
I've tried doing something similar on xlxd with md380-emu, but the issue I ran into was that ambed looks for a hardware device(s) for transcoding, and the startup for xlxd looks for an ambed service running to perform transcoding. I was unable to fit md380-emu in there.

Unless there's another path or setup that I'm overlooking that ignores ambed, which I would be really interested in.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:50 PM JJ Cummings <cummingsj@...> wrote:
I think that md380-emu, as I noted before, (included in the DVSwitch package install) will do this, that's what we are using...

On Mon, Jan 14, 2019 at 2:48 PM Steve KC1AWV <smiller@...> wrote:
Correct. The reason is that there does not exist a good open software codec to transcode D-Star (AMBE) and DMR (AMBE2+) as far as I know. So, some sort of AMBE hardware chip, like the DV3000, is used instead.

For example, I run two NW Digital ThumbDV dongles in my ambed server to transcode D-Star <-> DMR. I haven't used YSF (AMBE2+) or P25 (IMBE) but the idea may be the same, just would need more dongles to transcode more streams on the same module.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:37 PM Vincenzo Salamone <it9cdu@...> wrote:
Ok, so I need necessarily some hardware for transcode DMR--->Dstar and viceversa?

Il giorno lun 14 gen 2019 alle ore 22:33 Steve KC1AWV <smiller@...> ha scritto:
In my case, I run ambed on a server at home, separate from my XLX server that's in a data center. The ambed service (included with xlxd) runs the transcoding for D-Star <-> DMR for the XLX server. In order to achieve transcoding, some DV3000 dongles are attached to the ambed server.

This setup is a bit more advanced/customized, since I have services running on separate servers. Also, we're talking more along the lines of xlxd now, which is out of scope for the DVSwitch group.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:04 PM Vincenzo Salamone <it9cdu@...> wrote:
OK Steve,
now all the connections seems to work, but, no audio pass from dstar to dmr .... the transmission is MUTE. Maybe I need some AMBE codec to install ?

Il giorno lun 14 gen 2019 alle ore 19:58 Steve KC1AWV <smiller@...> ha scritto:
The connection between MMDVM_Bridge to DMRGateway here is like this:

---
MMDVM_Bridge.ini

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

---
DMRGateway.ini

[General]
Timeout=10
# RFTimeout=10
# NetTimeout=7
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

I assume you're running both programs on the same machine, so all addresses will be loopback.

Steve KC1AWV

On Mon, Jan 14, 2019 at 1:49 PM Vincenzo Salamone <it9cdu@...> wrote:
Thank's Steve,
XLX connection is ok now. Can you give me an example how to "Set MMDVM_Bridge to send its audio to DMRGateway" ?

tnx

Il giorno lun 14 gen 2019 alle ore 19:03 Steve KC1AWV <smiller@...> ha scritto:
If you are connecting to XLX, I used DMRGateway as well as MMDVM_Bridge. In DMRGateway.ini, you can set the XLX Network stanza similar to this:

[XLX Network]
Enabled=1
File=/var/lib/mmdvm/XLXHosts.txt
Port=62030
Password=passw0rd
ReloadTime=60
Slot=2
TG=6
Base=64000
Startup=740
Relink=60
Debug=0
Id=
UserControl=1
Module=B

Of course, use your own DMR ID on the Id= line. Set MMDVM_Bridge to send its audio to DMRGateway.

Steve KC1AWV

On Mon, Jan 14, 2019 at 12:57 PM Vincenzo Salamone <it9cdu@...> wrote:
Hi,
I want to bridge DMR to an XLX module, I understand that I can use the DVSwitch tools and MMDVM_Bridge. I have to create 2 instances of MMDVM_Bridge but I don't understand how connect to a specific module of XLX one instance of MMDVM_Bridge.
Anyone ca help me to better understand?
thank's

73 de IT9CDU



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV


Re: DMR vs DSTAR

Steve KC1AWV
 

No worries, but you did give me an idea! I'll whip up a couple tests and see what I can think of to try and transcode sans-DV3000.

Steve KC1AWV


On Mon, Jan 14, 2019 at 5:03 PM JJ Cummings <cummingsj@...> wrote:
You are correct, I think that you have to use the DV3000... too many transcode projects right now and I mixed them up lol... though to be fair I have not tried it with md380emu

On Mon, Jan 14, 2019 at 2:58 PM Steve KC1AWV <smiller@...> wrote:
JJ -
I've tried doing something similar on xlxd with md380-emu, but the issue I ran into was that ambed looks for a hardware device(s) for transcoding, and the startup for xlxd looks for an ambed service running to perform transcoding. I was unable to fit md380-emu in there.

Unless there's another path or setup that I'm overlooking that ignores ambed, which I would be really interested in.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:50 PM JJ Cummings <cummingsj@...> wrote:
I think that md380-emu, as I noted before, (included in the DVSwitch package install) will do this, that's what we are using...

On Mon, Jan 14, 2019 at 2:48 PM Steve KC1AWV <smiller@...> wrote:
Correct. The reason is that there does not exist a good open software codec to transcode D-Star (AMBE) and DMR (AMBE2+) as far as I know. So, some sort of AMBE hardware chip, like the DV3000, is used instead.

For example, I run two NW Digital ThumbDV dongles in my ambed server to transcode D-Star <-> DMR. I haven't used YSF (AMBE2+) or P25 (IMBE) but the idea may be the same, just would need more dongles to transcode more streams on the same module.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:37 PM Vincenzo Salamone <it9cdu@...> wrote:
Ok, so I need necessarily some hardware for transcode DMR--->Dstar and viceversa?

Il giorno lun 14 gen 2019 alle ore 22:33 Steve KC1AWV <smiller@...> ha scritto:
In my case, I run ambed on a server at home, separate from my XLX server that's in a data center. The ambed service (included with xlxd) runs the transcoding for D-Star <-> DMR for the XLX server. In order to achieve transcoding, some DV3000 dongles are attached to the ambed server.

This setup is a bit more advanced/customized, since I have services running on separate servers. Also, we're talking more along the lines of xlxd now, which is out of scope for the DVSwitch group.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:04 PM Vincenzo Salamone <it9cdu@...> wrote:
OK Steve,
now all the connections seems to work, but, no audio pass from dstar to dmr .... the transmission is MUTE. Maybe I need some AMBE codec to install ?

Il giorno lun 14 gen 2019 alle ore 19:58 Steve KC1AWV <smiller@...> ha scritto:
The connection between MMDVM_Bridge to DMRGateway here is like this:

---
MMDVM_Bridge.ini

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

---
DMRGateway.ini

[General]
Timeout=10
# RFTimeout=10
# NetTimeout=7
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

I assume you're running both programs on the same machine, so all addresses will be loopback.

Steve KC1AWV

On Mon, Jan 14, 2019 at 1:49 PM Vincenzo Salamone <it9cdu@...> wrote:
Thank's Steve,
XLX connection is ok now. Can you give me an example how to "Set MMDVM_Bridge to send its audio to DMRGateway" ?

tnx

Il giorno lun 14 gen 2019 alle ore 19:03 Steve KC1AWV <smiller@...> ha scritto:
If you are connecting to XLX, I used DMRGateway as well as MMDVM_Bridge. In DMRGateway.ini, you can set the XLX Network stanza similar to this:

[XLX Network]
Enabled=1
File=/var/lib/mmdvm/XLXHosts.txt
Port=62030
Password=passw0rd
ReloadTime=60
Slot=2
TG=6
Base=64000
Startup=740
Relink=60
Debug=0
Id=
UserControl=1
Module=B

Of course, use your own DMR ID on the Id= line. Set MMDVM_Bridge to send its audio to DMRGateway.

Steve KC1AWV

On Mon, Jan 14, 2019 at 12:57 PM Vincenzo Salamone <it9cdu@...> wrote:
Hi,
I want to bridge DMR to an XLX module, I understand that I can use the DVSwitch tools and MMDVM_Bridge. I have to create 2 instances of MMDVM_Bridge but I don't understand how connect to a specific module of XLX one instance of MMDVM_Bridge.
Anyone ca help me to better understand?
thank's

73 de IT9CDU



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV


Re: DMR vs DSTAR

JJ Cummings
 

You are correct, I think that you have to use the DV3000... too many transcode projects right now and I mixed them up lol... though to be fair I have not tried it with md380emu


On Mon, Jan 14, 2019 at 2:58 PM Steve KC1AWV <smiller@...> wrote:
JJ -
I've tried doing something similar on xlxd with md380-emu, but the issue I ran into was that ambed looks for a hardware device(s) for transcoding, and the startup for xlxd looks for an ambed service running to perform transcoding. I was unable to fit md380-emu in there.

Unless there's another path or setup that I'm overlooking that ignores ambed, which I would be really interested in.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:50 PM JJ Cummings <cummingsj@...> wrote:
I think that md380-emu, as I noted before, (included in the DVSwitch package install) will do this, that's what we are using...

On Mon, Jan 14, 2019 at 2:48 PM Steve KC1AWV <smiller@...> wrote:
Correct. The reason is that there does not exist a good open software codec to transcode D-Star (AMBE) and DMR (AMBE2+) as far as I know. So, some sort of AMBE hardware chip, like the DV3000, is used instead.

For example, I run two NW Digital ThumbDV dongles in my ambed server to transcode D-Star <-> DMR. I haven't used YSF (AMBE2+) or P25 (IMBE) but the idea may be the same, just would need more dongles to transcode more streams on the same module.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:37 PM Vincenzo Salamone <it9cdu@...> wrote:
Ok, so I need necessarily some hardware for transcode DMR--->Dstar and viceversa?

Il giorno lun 14 gen 2019 alle ore 22:33 Steve KC1AWV <smiller@...> ha scritto:
In my case, I run ambed on a server at home, separate from my XLX server that's in a data center. The ambed service (included with xlxd) runs the transcoding for D-Star <-> DMR for the XLX server. In order to achieve transcoding, some DV3000 dongles are attached to the ambed server.

This setup is a bit more advanced/customized, since I have services running on separate servers. Also, we're talking more along the lines of xlxd now, which is out of scope for the DVSwitch group.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:04 PM Vincenzo Salamone <it9cdu@...> wrote:
OK Steve,
now all the connections seems to work, but, no audio pass from dstar to dmr .... the transmission is MUTE. Maybe I need some AMBE codec to install ?

Il giorno lun 14 gen 2019 alle ore 19:58 Steve KC1AWV <smiller@...> ha scritto:
The connection between MMDVM_Bridge to DMRGateway here is like this:

---
MMDVM_Bridge.ini

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

---
DMRGateway.ini

[General]
Timeout=10
# RFTimeout=10
# NetTimeout=7
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

I assume you're running both programs on the same machine, so all addresses will be loopback.

Steve KC1AWV

On Mon, Jan 14, 2019 at 1:49 PM Vincenzo Salamone <it9cdu@...> wrote:
Thank's Steve,
XLX connection is ok now. Can you give me an example how to "Set MMDVM_Bridge to send its audio to DMRGateway" ?

tnx

Il giorno lun 14 gen 2019 alle ore 19:03 Steve KC1AWV <smiller@...> ha scritto:
If you are connecting to XLX, I used DMRGateway as well as MMDVM_Bridge. In DMRGateway.ini, you can set the XLX Network stanza similar to this:

[XLX Network]
Enabled=1
File=/var/lib/mmdvm/XLXHosts.txt
Port=62030
Password=passw0rd
ReloadTime=60
Slot=2
TG=6
Base=64000
Startup=740
Relink=60
Debug=0
Id=
UserControl=1
Module=B

Of course, use your own DMR ID on the Id= line. Set MMDVM_Bridge to send its audio to DMRGateway.

Steve KC1AWV

On Mon, Jan 14, 2019 at 12:57 PM Vincenzo Salamone <it9cdu@...> wrote:
Hi,
I want to bridge DMR to an XLX module, I understand that I can use the DVSwitch tools and MMDVM_Bridge. I have to create 2 instances of MMDVM_Bridge but I don't understand how connect to a specific module of XLX one instance of MMDVM_Bridge.
Anyone ca help me to better understand?
thank's

73 de IT9CDU



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV


Re: DMR vs DSTAR

Steve KC1AWV
 

JJ -
I've tried doing something similar on xlxd with md380-emu, but the issue I ran into was that ambed looks for a hardware device(s) for transcoding, and the startup for xlxd looks for an ambed service running to perform transcoding. I was unable to fit md380-emu in there.

Unless there's another path or setup that I'm overlooking that ignores ambed, which I would be really interested in.

Steve KC1AWV


On Mon, Jan 14, 2019 at 4:50 PM JJ Cummings <cummingsj@...> wrote:
I think that md380-emu, as I noted before, (included in the DVSwitch package install) will do this, that's what we are using...

On Mon, Jan 14, 2019 at 2:48 PM Steve KC1AWV <smiller@...> wrote:
Correct. The reason is that there does not exist a good open software codec to transcode D-Star (AMBE) and DMR (AMBE2+) as far as I know. So, some sort of AMBE hardware chip, like the DV3000, is used instead.

For example, I run two NW Digital ThumbDV dongles in my ambed server to transcode D-Star <-> DMR. I haven't used YSF (AMBE2+) or P25 (IMBE) but the idea may be the same, just would need more dongles to transcode more streams on the same module.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:37 PM Vincenzo Salamone <it9cdu@...> wrote:
Ok, so I need necessarily some hardware for transcode DMR--->Dstar and viceversa?

Il giorno lun 14 gen 2019 alle ore 22:33 Steve KC1AWV <smiller@...> ha scritto:
In my case, I run ambed on a server at home, separate from my XLX server that's in a data center. The ambed service (included with xlxd) runs the transcoding for D-Star <-> DMR for the XLX server. In order to achieve transcoding, some DV3000 dongles are attached to the ambed server.

This setup is a bit more advanced/customized, since I have services running on separate servers. Also, we're talking more along the lines of xlxd now, which is out of scope for the DVSwitch group.

Steve KC1AWV

On Mon, Jan 14, 2019 at 4:04 PM Vincenzo Salamone <it9cdu@...> wrote:
OK Steve,
now all the connections seems to work, but, no audio pass from dstar to dmr .... the transmission is MUTE. Maybe I need some AMBE codec to install ?

Il giorno lun 14 gen 2019 alle ore 19:58 Steve KC1AWV <smiller@...> ha scritto:
The connection between MMDVM_Bridge to DMRGateway here is like this:

---
MMDVM_Bridge.ini

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

---
DMRGateway.ini

[General]
Timeout=10
# RFTimeout=10
# NetTimeout=7
RptAddress=127.0.0.1
RptPort=62032
LocalAddress=127.0.0.1
LocalPort=62031
RuleTrace=0
Daemon=0
Debug=0

I assume you're running both programs on the same machine, so all addresses will be loopback.

Steve KC1AWV

On Mon, Jan 14, 2019 at 1:49 PM Vincenzo Salamone <it9cdu@...> wrote:
Thank's Steve,
XLX connection is ok now. Can you give me an example how to "Set MMDVM_Bridge to send its audio to DMRGateway" ?

tnx

Il giorno lun 14 gen 2019 alle ore 19:03 Steve KC1AWV <smiller@...> ha scritto:
If you are connecting to XLX, I used DMRGateway as well as MMDVM_Bridge. In DMRGateway.ini, you can set the XLX Network stanza similar to this:

[XLX Network]
Enabled=1
File=/var/lib/mmdvm/XLXHosts.txt
Port=62030
Password=passw0rd
ReloadTime=60
Slot=2
TG=6
Base=64000
Startup=740
Relink=60
Debug=0
Id=
UserControl=1
Module=B

Of course, use your own DMR ID on the Id= line. Set MMDVM_Bridge to send its audio to DMRGateway.

Steve KC1AWV

On Mon, Jan 14, 2019 at 12:57 PM Vincenzo Salamone <it9cdu@...> wrote:
Hi,
I want to bridge DMR to an XLX module, I understand that I can use the DVSwitch tools and MMDVM_Bridge. I have to create 2 instances of MMDVM_Bridge but I don't understand how connect to a specific module of XLX one instance of MMDVM_Bridge.
Anyone ca help me to better understand?
thank's

73 de IT9CDU



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV



--
Steve Miller
KC1AWV

6361 - 6380 of 9203