locked sticky Re: First draft of overall DVSwitch documentation.


Mike Zingman - N4IRR
 

José,

So because of your document, I was able to implement the DMR to YSF interconnect.
Thank you for your feedback, we are still adding information to the outline as well as creating concrete example documents (ASL <-> DMR), etc.  Your comments help us improve the doc and every question adds to the group knowledge base.  

I did, however, had to mkdir another completely separate directory and copy the contents of MMDVM_Bridge into it, because I figured the instance already running ASL<-->Echolink<---->DMR might get affected, as the DVSwitch ini needs modification to reflect the fact that I am going to use ports 35100 and 35103 for YSF and not the 31100 and 31103 for DMR and ASL.
There are several ways to segment ini files.  Each application (AB, MB, etc) takes command line arguments to help you.  Some people prefer to have separate directories, others prefer to use one directory and name the ini files unique names.  It is up to you.  You are correct, a single instance of MB can not service two bridges with a common mode (in your case ASL <-> DMR and YSFn <-> DMR).  For this to work, you need two instances of MB and two DVSwitch.ini files.  If you wanted to have them in the same directory, you would need to use the environment variable DVSWITCH to point each instance at its ini file.  If you created ini files with names to represent your intended activity, It would look like:

DVSWITCH=./DVSwitch_ASLtoDMR.ini MMDVM_Bridge ./MMDVM_Bridge_ASLtoDMR.ini
and
DVSWITCH=./DVSwitch_YSFtoDMR.ini MMDVM_Bridge ./MMDVM_Bridge_YSFtoDMR.ini

But, your method works just fine and I would not change it.
Does each Analog Bridge instance needs its own DV300U?
Yes.  In order to encode or decode in a specific mode (DMR, DSATR, etc) you must dedicate a DV3000U to that process.  However, in your case, do not forget that you also have the emulator for AMBE encodes/decodes.  Like the DV3000U you should dedicate a "process" to each AB instance, but that just means you have to launch each emulator with a unique port to communicate to AB through.

I could not make out the diagram that explains the port assignment.
Sorry!  A really need to use a real drawing program rather than ASCII art.  It main point of the diagram is that each step along the way needs to communicate with its "partner" through a common set of ports.  Transmit (TXPort) on one side is the same as RXPort on the other.  Regardless of the data type moving from one process to another, just select a complementary set of ports and you will be good.  Make sure that you do not reuse those ports someplace else in your system by using netstat -unap. 

but the audio never went out over to DMR 

This is where the ini and log files are needed to debug.  The ini files will show us the ports you assigned to each step and the log files will show us what happens when data is presented to a port.
I had the wrong audio format

Whenever you see this message you are sending the wrong audio type (TLV) to MB.  For that mode look at the RXPort.  Now go find all TXPorts in your system that match it.  Are they all the same AMBE/IMBE/DSAMBE type?  If AB is sending type A and MB is expecting type B you will see this message.  Look at the sender.

Hope this helps
Mike

Join main@DVSwitch.groups.io to automatically receive all group messages.