> Steve, I wonder why you call the module id's TG's > I do recognise XLX and openspot accept link id's as group contact protocol, whereas usually they would be private call. You answered your own ques

#mmdvm_bridge

XLX modules use TGs in the 4000 range. 4001 for module A, 4002 for module B ... 4026 for module Z if you want to change it on the fly from a radio. The other option is for MMDVM_Bridge to take the Mod

#mmdvm_bridge

I like these kinds of projects, ones that make me think! If I take a step back and take a higher level look, these are my thoughts. If we don't want to fiddle with the Asterisk code, then we have two

I don't see why not. Though you may want to play with the analog audio while it's in ASL before it goes to AB. Generally speaking, if it can be done in asterisk, it can also be done in ASL.

> However, it occurs to me as an audio guy that just connecting ASL directly to DMR with the current bridge as it is wouldn't be the best sounding option, as calls to and from DSTAR would be transcode

You know as I'm thinking about it, ASL has macros for controlling a base station built into app_rpt already. So, using DVSwitch Mobile will give you the ability to tune and such the remote base as if

DVSwitch Mobile is the Android/iPhone client used in lieu of needing a hotspot and digital radio, and it used to be called Android IAXRPT. Using DVSwitch Mobile, you can connect to ASL, DMR, DStar, YS

Is there a specific need for the DMR hotspot? If you're using ASL already, you could use DVSwitch Mobile direct to ASL and not have to worry about converting to DMR. Remote Base <-> ASL <-> DVSwitch M

The DVSwitch suite is software, it does not interact with an RPi's GPIO. So unless you have something unrelated to DVSwitch attached to your RPi, the answer is yes. Steve KC1AWV

A DV3000 device is required when transcoding between two modulation modes, such as AMBE2+ and IMBE. Simply put, if you have DStar anywhere in the mix, you'll need a DV3000 stick to transcode it to som

Snide remarks to an accepted answer by a knowledgeable person isn't very friendly, either. That's the reason I locked the topic. Just my two cents. Steve KC1AWV

Locking topic, this is starting to get out of hand.

If I am reading this right, I think what Neil is describing is a way for a DMR radio to talk with a Fusion radio, without needing to go to a reflector or other network. It's an interesting thought exp

I'm continuing work on HBmonitor3 - a Python 3 port of the original N0MJS HBmonitor. The last bit that I worked on and seems to be hanging me up is dict.iteritems() is no longer in Python 3. According

New PR on github to fix a typo I overlooked on line 213. Also removed a \t at the end of the same line. Also, porting from python 2 to 3 is breaking. Twisted gives a 500 response, Request did not retu

Thanks, I forgot about that indentation! I'll update in a few.

PR submitted. https://github.com/n0mjs710/HBmonitor/pull/4 Since my car will be at the mechanic this weekend, I'll have some time to take a stab at porting HBmonitor to python 3. Steve KC1AWV

If nobody else jumps on making the PR, I can do that today. I'm also going to look at a python 3 rewrite if anyone is interested. Steve KC1AWV

Expedient connection to BM if you don't have an OB link set up. Sometimes users just want to connect on demand, or they're testing. There's more than one way to skin a cat. Steve KC1AWV

As many as you have configurations for and your CPU can handle. But, it's not really about instances, technically you could run tens of thousands of instances before you'd see any significant impact.