Re: OhioLink YSF to DMR bridge update

Steve N4IRS

Thanks for the update. Working with the Ohio Link team was a pleasure. The back and forth helped us learn a few things and find a bug or two. I expect the changes will be incorporated in future versions. Please keep us informed about the blocking message.

Your comment about bringing up a AllStarLink (ASL) node to experiment with DVSwitch Mobile (DVM) brings up a point I would like to address. DVM can be used in two ways. One, as a client for ASL using the native ASL protocol, IAX. In this configuration ASL can be simply that, an analog node capable of connection to other analog nodes. The flow diagram would look like this:
DVM <-> ASL <-> ASL Network.

With this configuration from DVM you can connect your ASL node to any other ASL (or EchoLink) nodes. Very clean and simple. ASL will support multiple logins from DVM so users can easily share the node. If you want to ALSO be able to connect to one or more of the digital voice networks, you can add that to ASL. Your flow diagram will look like this:
DVM <-> ASL <-> Analog_Bridge <-> MMDVM_Bridge <-> digital voice network

You now have access to both the analog and digital voice networks. You can also have multiple logins and share access. This configuration can (with some expansion) can give users access to analog and digital at the same time. For example, one (or more) user on analog and one user on digital. ASL provides quite a lot of functionality if you want. Please note, the one thing you do not have in this configuration is MetaData. DVM will not show you who is talking and all DVM users will share one DMR ID.

DVM does not REQUIRE you to build a ASL node for access. DVM also supports a direct connection to Analog_Bridge (AB) In this configuration a single user can directly access all of the supported digital modes. Your flow diagram will look like this:
DVM <-> Analog_Bridge <-> MMDVM_Bridge <-> digital voice network.

We refer to this as "hot spot in the cloud" Though the hotspot does not really be in the cloud, it can be running on a RPi in your shack. DVM becomes the user interface for AB. In this configuration DVM will display MetaData from the DV network and when you transmit from DVM, your DMR ID and callsign will be correct. In subsequent messages and in the wiki I will cover this configuration in more detail.

Last but not least, I love the "the Swiss army knife of digital radio" Mike and I have been running the DVSwitch programs on the RPi (and other types) Some for testing and some for day to day use. A while ago we started referring to these Pis as Swiss army knives" since they had all the software we needed in one place to build whatever we needed. 

73, Steve N4IRS

On 6/20/2019 8:39 PM, Gary - KE8O wrote:
Just wanted to give you an update on Ohio Link. Prior to Dayton the DVSwitch team setup a demo bridge as our previous YSF to DMR solution was having some issues.  I've been running our own DVSwitch instance now locally for a week now bridging our YSF to DMR. I started out only bridging when I was around to monitor and started bridging 24/7 since last Sunday. We only had one occurrence of the BM blocked user message in that time and that was on the first day when I was running the old MB binary with the VW issue causing one way audio with WiresX.  After installing the updated binary from github its been flawless. I know that binary had nothing in to fix the minimum TX duration so whatever was causing the original issue with the BM block message is still lurking. I've now moved on to setting up an Allstar server and node to experiment with DVMobile. My server and node number are now registered so its time to install and configure the software. I'm giving a presentation in the middle of July to our local club on digital radio. I'm hoping to be able to pass around an Inrico T320 as one of the digital radio demos.
Thank you guys for such a great product. It's the Swiss army knife of digital radio!

...Gary, KE8O

Join to automatically receive all group messages.