Welcome to DVSwitch

MMDVM_Bridge (MB) does most of the heavy lifting required to build a bridge. In fact it IS the bridge. The job of MB is to connect to a foreign network and produce a data stream that can be sent to another program like Analog_Bridge or even back to MB for transmission to another foreign network. Let's consider a simple YSF to DMR bridge. YSF Reflector <-> MMDVM_Bridge <-> BrandMeister (BM) It does not get any simpler then that. MB connects to both the YSF Reflector and BM. No gateways needed, very simple. This is a singe instance of MB. What do I mean by single instance? One copy of MB is running. MB uses 2 configuration files. One file configures MB for connecting to the foreign network(s) The second file configures MB to send the data to another program or back to MB itself. Let's start with configuring MB to connect to the foreign networks. The file is MMDVM_Bridge.ini I will only show the [stanzas] that really matter and only the fields. MMDVM_Bridge.ini [DMR] Enable=1 [System Fusion] Enable=1 The above 2 stanzas simply enable the DMR and YSF modes in MB [DMR Network] Enable=1 Address=3102.repeater.net Port=62031 Password=passw0rd [System Fusion Network] Enable=1 GatewayAddress=ysfreflector.dvswitch.org GatewayPort=42166 The above 2 stanzas enable and configure the foreign network connections required for the bridge. Now let's look at DVSwitch.ini [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) [YSF] Address = 127.0.0.1 ; Address to send AMBE TLV frames to (export) TXPort = 35100 ; Port to send AMBE TLV frames to (export) RXPort = 35103 ; Port to listen on (import) In the DMR stanza above, traffic coming from the DMR network, in this case, BM is processed by MB and sent out UDP port 31100 to IP address 127.0.0.1 (local host or the machine running MB) Traffic received on UDP port 31103 is processed and sent out to the DMR network. In the YSF stanza above, traffic coming from the YSF reflector is processed by MB and sent out UDP port 35100 to IP address 127.0.0.1 Traffic received on UDP port 35103 is processed and sent out to the YSF Reflector. OK, so how do we bridge DMR to YSF? Do we need another program? Are we finished? No to all. What we want is when traffic is received from BM it is sent to YSF and vice versa. What we need to do, is send the traffic right back into MB. DVSwitch.ini [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) [YSF] Address = 127.0.0.1 ; Address to send AMBE TLV frames to (export) TXPort = 31103 ; Port to send AMBE TLV frames to (export) RXPort = 31100 ; Port to listen on (import) Again, Traffic coming in from BM is received by MB processed and sent out UDP port 31100 to IP address 127.0.0.1 (local host or the machine running MB) If you look at the TXPort for DMR it matches the RXPort for YSF. The TXPort for YSF matches the RXPort for DMR. Let me present it a different way: [DMR] YSF Address = 127.0.0.1 <---> Address = 127.0.0.1 TXPort = 31100 <--------> RXPort = 31100 RXPort = 31103 <--------> TXPort = 31103 That is all there is to it. If there is any magic, it's in what happens to the data received from the foreign network. MB takes apart the data and "normalizes" it so that another DVSwitch program can use it. That DVSwitch program can be Analog_Bridge or even MB itself. MB can process 5 foreign networks at the same time. What MB can NOT do is to process 2 of the same foreign networks at the same time. For that, you need a second instance of MB. Hope this helps. 73, Steve N4IRS

HELP !!!!!!!!!!!!!!!!!!!! No one expects you to be a "Linux Expert" but understand this, you have chosen to build a bridge. You have to use the tools available. All of the DVSwitch programs run on Linux. You should put in the effort to at least be aware of how to do things in Linux. If you are posting on the discussion board then you have access to the internet. I doubt you can not find every Linux command and how to use it somewhere on the net. Learn how to copy and paste from a window to e-mail or other program. For people to help you, they need to see the error. PLEASE don't post a screenshot or take a picture of the screen. Many people use PuTTY to login to a remote host via SSH. it is very easy to copy text from PuTTY. Simply put the mouse at the start of the text you want to copy and while holding down the right mouse button, drag the cursor across the text you want to copy. Now go to the e-mail you want to paste into. You can usually just go to the edit menu at the top of the screen and select paste. There is no way I can tell you how to paste into every program you could be running. I strongly suggest you practice this so when you need it, you know how to do it. Start with a flow diagram of what you are trying to do. For example, if you are trying to build a bridge between AllStarLink and BrandMeister DMR, your diagram will look like this: BM <-> MMDVM_Bridge <-> Analog_Bridge <-> AllStarLink. The <-> indicates traffic or data will flow in both directions. Traffic flows from BM to MMDVM_Bridge which flows to Analog_Bridge and on to AllStarLink. Traffic also flows in the opposite direction from AllStarLink to BM. If you are unsure of the programs you will need to accomplish the task, ask in the discussion area. Post what you think the flow diagram should look like. Don't just ask someone else to create one for you. While setting up and running the programs you should have root privileges. You can do this in multiple ways: sudo ./myprogram or login to the machine as root (if possible) or sudo -s This will give you root privileges as long as you are logged in. This is easier then remembering to start each program with sudo. Run the program(s) in the foreground to look for errors. Running the program in the foreground simply means starting the program from the command prompt. Example: root@myhost:/opt/MMDVM_Bridge# ./MMDVM_Host MMDVM.ini This runs the program from the prompt. Notice the ./ in front of the program name. This means run the program in this directory. Run each program in a separate session (window). Most, if not all of the DVSwitch programs are built for only one purpose. Almost any bridge you build will require multiple programs. These programs talk to each other. You can watch the data "flow" from one program to the other if you are running all of the programs in windows so you can see the output. This is your first chance to catch errors. Don't understand the error? Read from the bottom up. Look for key words like, error, can't, fail etc. In the line containing errors look for things like a directory name or file name. When asking for help you should copy and paste the error into the e-mail. PLEASE don't just post a message that "it does not work" or my personal favorite "Broke! no good!" (Yes, I get that at work all the time.) Build from the outside in. That way you can see the traffic flow. If you don't see the traffic, stop and fix the issue before going on to the next step. If the program on the outside of the flow diagram does not see the traffic from the external network, the next program in the flow diagram won't either. It's a heck of a lot easier to fix one program at a time then it is to troubleshoot 4 programs all at once. (It does not work!) Change as little as possible in a configuration file. We have tried to set the parameters to usable values. There are comments in the configuration files. Read them! If you don't understand the comment, ask. Your question may spark an idea about how we can word the comment better. Some parameters are set to what should be obvious "place holder" values.

I want to be very clear on this: We are NOT interested in working on a interface to Zello. Not now, not ever. Please stop asking for it here. I will delete any thread on this subject. I will moderate anyone bringing it up. For DVSwitch Steve N4IRS

MMDVM_Bridge updated to 1.6.8 for all platforms. STFU has been updated to 0.3.3 for all platforms.

We have created a few sub groups to better help people find the information they are looking for. Those groups are: Quantar-Bridge ( https://dvswitch.groups.io/g/Quantar-Bridge ) Discuss connecting Motorola P25 repeaters (Quantar) with the MMDVM P25 Network. AllStarLink ( https://dvswitch.groups.io/g/allstarlink ) Discuss deployment and configuration of AllStarLink as it will be used with other DVSwitch Partners for bridging to digital networks. HBlink ( https://dvswitch.groups.io/g/HBlink ) Discuss building and extending HB networks using the power of HBlink. Support ( https://dvswitch.groups.io/g/support ) Long term support discussion We are working hard to write documentation. This will be in addition to pages we are adding the the wiki(s) Steve N4IRS

We have created a set of test reflectors for people to point their bridges at for testing. These bridges are stand alone and you can pretty much do what ever you want. These reflectors are not intended for long term bridging but it will be a safe place to test your bridge without getting the whole world mad at you. Each reflector will have a dashboard so you can see your connection. I will be updating MMDVM_Bridge.ini to default to these reflectors rather then 127.0.0.1 This should make it easier to configure a bridge the first time and reduce the confusion by removing some of the multiple 127.0.0.1 entries. Reflectors: p25reflector.dvswitch.org Port = 43166 TG = 3166 ysfreflector.dvswitch.org Port = 42166 nxdnreflector.dvswitch.org Port = 41400 TG = 3166 hblink.dvswitch.org Port = 62031 password = passw0rd Dashboards: http://dvswitch.org/NXDN_DVSwitch http://dvswitch.org/P25_DVSwitch http://dvswitch.org/YSF_DVSwitch 73, Steve N4IRS

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 ( https://docs.google.com/document/d/1-Ot5pGaibmEGmmFh-l8HUq2LRyZoujiJYulr-VSga9s/edit?usp=sharing ) 73, Steve N4IRS

Thanks to Mike, KB8JNM for hosting the round table. The attendance far exceeded our expectations which caused some problems. Lesson learned. I have shared the outine and slides from net. We were unable to get a audio recording. These are still a work in progress. We hope to get a good audio recording of the presentation. (the next time) Slides Outline

I have uploaded to the git repository DVSwitch-System-Builder a method of adding the programs and scripts people will use to build and run most of the DVSwitch programs. The idea is once you have setup a base Debian (or derivative), the System Builder will add most of the DVSwitch programs, scripts and data files. It will then grab the MMDVM programs, build and install them. All of the programs are unconfigured and ready to edit. This is simply a brute force script to take the tedium out of setting up a fresh system. (Which I seem to do a lot) It does NOT configure the bridges for you. It simply puts most of what you need on the disk. One neat addition, is the start of a dashboard. I am taking the add-on Dashboard and modifying it for use with MMDVM_Bridge. It is a work in progress and if someone, anyone speaks PHP better then I do, by all means help! I have more to add (HBlink and DMRlink) and anything else I can think of or be suggested. This is a outgrowth of a System Builder I use to setup a MMDVM system since I usually do not use Pi-Star. Speaking of Pi-Star, DO NOT try to add this to Pi-Star. Please consider this a community project. 73, Steve N4IRS

I have made some changes to the DVSwitch repositories, to better align naming and distributions. The packages are: 1: Available for ARM, i386 and AMD64 2: ARM and i386 will run on Jessie and Stretch 3: AMD64 will run on Debian Stretch AMD64 and Ubuntu AMD64 3: All packages will be in the stretch repository The available packages are: dvswitch_base, Analog_Bridge, md380-emu, MMDVM_Bridge, P25Gateway, P25Parrot. The metapackages are named dvswitch and quantar. dvswitch contains: dvswitch_base, Analog_Bridge, md380-emu and MMDVM_Bridge quantar contains: dvswitch_base, MMDVM_Bridge, Quantar_Bridge P25Gateway, P25Parrot After installing the repository, you can install either dvswitch or quantar or both I hope this make sense and will make things easier for people. To install the repository: As root cd /tmp wget http://dvswitch.org/install-dvswitch-repo chmod +x install-dvswitch-repo ./install-dvswitch-repo apt-get update 73, Steve N4IRS

This was posted a few days ago by N3FE Due to issues that have been happening recently, we are going to need to start requiring users to set a hotspot security password to gain access to the US Masters. If you already have a hotspot security password set on the BM portal, you can ignore this post. We are going to start requiring this on master 3101 November 30th, 3102 will follow on December 4th, and 3103 on December 11th. This is already implemented on the RU masters, and other Master servers will follow. At this time this will just be for hotspots. The API is being worked on to allow repeater owners to make this change as well, but it is not quite ready to go. Here is a link to a post on how to set your hotspot security on the bm portal. Please configure a personalized security password for your hotspots ! What does this mean for DVSwitch users? If you have a bridge or server connecting to BrandMeister, you will need to have set your HS password. Up till now, a user could use the default password and connect to BM. With the above change, you will need to set your own password. This is one password per CallSign/DMRID. If you have 2 DMR IDs you will need to set 2 passwords. We HIGHLY suggest you set your HS passwords now. That way when the changes are applied across BM, you will not loose connectivity.

We have been talking about hUC (HTTP USRP Client) since about the time we released DVSwitch Server. So, where is it already? hUC in it's early form did not really take that long. Thought it connects to DVSwitch Server differently, It's not much different then pyUC (python USRP Client) Then we started having our usual "what if" discussions. Our wives will tell you this can go on for days. A very big issue with a web based client is security. If you expose a HTML client to the internet, people will play with it. This could be disastrous. We need security to control who can do what. I sure don't want anybody with access to a search engine to start talking on DMR TG 91 (with my call and DMR ID) So, security had to be added. Now I have this DVSwitch Server in the cloud with a web interface and at least I can control who has access. We know DVSwitch Server is single user. It sure would be nice if I can give my friends access to my server. Let's face it, I'm not using it all the time. I can share. Some friends are more responsible then others. I would like to give Jack the ability to transmit, but not move the Server to another mode or talk group (tune). I would like to give Jill the ability to listen, but no transmit and no tune. OK, we can do that. Jack and Jill can both listen to traffic on the server. Jack can transmit. I am the only one that can tune to another TG or mode. OK, this is getting good. We don't want to limit the fun to only web clients. What about DVSM and pyUC users? Yes, you can assign the same rights to DVSM and pyUC users. You can have users from all 3 clients with different rights. Everybody that can listen will hear not only the connected Steerable Bridge (SBridge) they will hear any client with transmit rights. Let me be CLEAR, This is one SBridge shared among multiple users. This is NOT DVAAS (Digital Voice as a service) We did not forget AllStar. You can have one or more AllStar nodes directly connected to the Server. AllStar users (by node) can be assigned rights. RX, TX Tune. It's up to the Server owner how these connections are controlled. Some Server users use AllStar to mix audio from multiple modes. This is usually done by bridging each mode into a seperate AllStar "private node" This give the Server operator the ability to connect and disconnect modes into the main AllStar node. He can also directly connect 2 modes together without connecting those modes to anything else. AllStar is VERY versatile that way. In the case of unlike modes DMR (AMBE) to P25 (IMBE) this works quite well.If you are connecting like modes YSFn (AMBE) to NXDN (AMBE) this leave something to be desired. This is transcoding where none is required. It's up to the Server operator to decide if this is a disadvantage. No matter if it's like modes or not, using AllStar to bridge Digital Voice modes has one downside, You loose the metadata that is transmitted along with the voice. Some people don't care, the advantages of mixing in AllStar outweighs the disadvantages. I can make a case for either choice. So, how do we give people another option. That option is called Analog_Reflector. Consider a piece of software tha t will accept multiple connections from clients (DVSM, pyUC or hUC) it will also accept connections from multiple AllStar nodes either on the same server or a remote server. (via USRP) You can have multiple bridges connected. These bridges are fixed by mode and TG (reflector). Last but not lease is a Steerable Bridge (SBridge) This is the bridge you can change modes, you can change TGs it's exactly like the bridge in DVSwitch Server now. Any client (with the proper rights) can steer the bridge. This includes The AllStar nodes. One big advantage, no more macros needed (but still supported) The command path between AllStar and the reflector is two way. We can send commands for AllStar to the reflector (and on to the SBridge) We can also receive commands from a connected client and send them to AllStar. If you want to connect your AllStar node to another AllStar node, you can do it from a connected client. AllStar becom

In this topic we will announce bugfixes. Some fixes are minor and some are more important. (Duh! Thanks Captain Obvious) We will post the issue and how to resolve. I am going to lock this thread so that only the announcements get posted. I think this will help someone looking for a answer. If this turns out to not be the case I'll try something else. Here is the first of... There is a bug in the netcheck service. The service is intended to signal to other services that the network is configured and operational. It was always reporting the net was available. It is now fixed. To fix on your bridge: apt-get update apt-get upgrade 73, Steve N4IRS

BM is implementing controls to disallow mis-configured hotspots from connecting to their network. Some of our early configurations violate this and cause a connection to not complete. Here is what you need to check: in /opt/MMDVM_Bridge/MMDVM_Bridge.ini [General] Callsign=N4IRS Id=3112138 duplex=0 [Info] RXFrequency=224940000 TXFrequency=224940000 Make sure your RX Frequency matches your TX frequency and that your callsign is correct for your DMRID+SSID restart. We have a replacement connection method in beta test now. That method, Simple Terminal Feature Update uses the connection method required by BM. By implementing Simple Terminal Feature Update we will satisfy BM now and in the future. Steve N4IRS

Jonathan, G4KLX has posted on the OpenDV group a request for support. Without his work on MMDVM related projects, we would all be a LOT worse off. If you were around pre MMDVM days you know basic things were. Here is a link to his post: A little favour to ask..... We encourage everyone using any of the MMDVM based project to consider Jonathans request.