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

So because of your document, I was able to implement the DMR to YSF interconnect. The explanation helped me very much. 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. Many thanks, and my appreciation to Corey Dean N3FE for giving me a link for YSFReflector Guatemala all this time. I am now able to do this by means of the DVSwitch program. I only had to run one instance of MMDVM_Bridge to accomplish the link from BrandMeister to the YSFReflector, I did not interpret your drawing this way, however. The drawing I take it to be two instances of MMDVM_Bridge running, one for the BM side and the other for the YSFn. I do reiterate that without this document I would not have been able to accomplish this and I thank you very much.

Now, I do have questions regarding the transcoding process from BrandMeister over to DSTAR:

1. Does each Analog Bridge instance needs its own DV300U? I do have two and ran Analog Bridge AB1.ini bound to /dev/ttyUSB0 and Analog Bridge AB2.ini bound to /dev/ttyUSB1 However, each one does its thing but it does not pass data on to the other side, as if PCM stays there but does not get exported on to the other network. AB1.ini is on the DSTAR side and I used the DSTAR recommended ports (32100 32103) and does light up when TXing on DSTAR HT. Same thing on AB2.ini, DMR gets in and the ThumbDV lights up, but no audio goes through on to DSTAR. Also, AB1 has DSTAR on ambeMode and AB2.ini has DMR on the ambeMode setting.
2. I could not make out the diagram that explains the port assignment. I gave it the last try by assigning the 31100 and 31103 ports on the AMBE AUDIO section of AB1.ini(DSTAR AB) but same results.
3. I also tried running one instance of MMDVM_Bridge enabling DMR and DSTAR, both networks get logged in, I am able to switch reflector modules with ircddbgateway and also assign a static talk group with BrandMeister Selfcare.
4. XLX502 already has four transcoding channels available, and as I keyed up on DSTAR the transcoders lit up as well as the ThumbDV on AB1, but the audio never went out over to DMR, at least the DMR radio never lit up.

Before doing all this, I was able to use the YSFn instance of MMDVM_Bridge with DSTAR enabled and was able to link up to the reflector but the output said that I had the wrong audio format (I do not recall the exact long line but said something like expecting AMBE and got DSAMBE or something similar, sorry, not wanting to paste a long log here)

Thanks Steve and hopefully I did not make you fall asleep with my sad story here hi.

73 

--
José Roberto Ruíz García Salas
TG9AOR

Great Job Steve

73 Pablo - EA4FVB

Excellent, Many Thx.
Joaquin Madrid
EA5GVK.

Excellent! Many thanks. Will go and read now.
--
José Roberto Ruíz García Salas
TG9AOR

We have created the first overall document covering all of the new DVSwitch programs. This started as an outline and grew. It is in Google Docs so that people always have access to the latest and greatest. We are putting the first howto together for a simple bridge and will expand after that. Neither Mike or I are document writers so please bare with us. 

DVSwitch Documentation

73, Steve N4IRS