Is XLX:998 B a attempt to connect to "module B" (I'm not much of a XLX person) If so try Options=XLX:9982

I think I need just a little push in the proper direction. I changed my MMDVM_Bridge.ini to read what you see below however if I watch the XLX it never connects. I tried Options=XLX:998 and

Steve N4IRS, I downloaded this the other day got error "page not found". sorry I cant remember the date looks like a week ago. wget https://github.com/DVSwitch/Analog_Bridge/raw/master/dvswitch.sh 73,

MB.ini [DMR Network] Enable=0 Address=hblink.dvswitch.org Port=62031 Jitter=360 Local=62032 Password=passw0rd # for DMR+

All, we have a PI running XLX With interlinks to BM and DV3000 to DStar. I also have a ASL with analog_bridge <> mmdvm <> BM i want to connect our mmdvm_bridge directly to the XLX to reduce lag and

Scott is right when I installed DVSwitch on the arch Linux, I use Pacman. However it doesn’t sound as good as it should. I was inspired this morning and installed DVSwitch On a running allstar node

I am seeing that Buster has been renamed to Raspbian Buster, is that the one to use to start the process of setting up DVswitch? Dick W4RSS

A transcoder should NEVER receive a tune command. Use static TG info in your gateway and BM. If you MUST have the DMR or P25 side tuneable, then the TLV tune should be directed at the MB instances

Monday noticed a couple issues on my system, D-STAR wasn't passing audio both ways and other mode dashboards were not populating the call signs (had the numeric DMR ID). Running the update

XLX does not do analog. The reason those connections sound "perfect" is that they go from digital to digital. When you go to analog - in particular Allstar - higher-frequency components of the DMR

Hi Steve, I have tried running only the 2 instances of AB and it happens when I send the dvswitch tune command. The logs I included had no MB running at all. Other tests I performed were only running

Tim, You are correct, suppressing the log does no good. We need to know what is going on. Lets start with the DMR side of the bridge. Turn off AB_P25. I assume you are running one instance

Hello Tim I never look at logs. Just look at the info on the screen. Can see whats going on in real time. Also see whats gone down then just restart the software. There is always info passing back and

Ok thanks. I'll try it. I know that I tried setting to 4 - warning and I got the close to 100% CPU usage but of course the packets were suppressed. Hiding the alerts doesn't necessarily mean it fixes

In the Analog_Bridge.ini loglevel = 2 you could change it to 0 I never change it as I use this info to see whats going on. As I run in terminal windows the info from the logs act like a dashboard for

i did stop the ambe server here is the logs. same error on port 31100 will close upon sending the marco ^DMR mode I: 2020-06-04 03:23:37.362 Tune macro: *DMR will invoke

Yes Mike, Im running the stick at the same host using pi3, my problem is when i issue the DMR mode @ Dvswitch mobile client the error pertaining to port 31100 will close. and will not receive audio

Hey guys, Still plotting on with this spamming of "INFO packet sent to USRP client" in my logs. it seems to be related to the 2 instances of AB. My setup is HBlink Master2 ----> MB -----> AB_DMR

Andrew, By the error you are seeing I have to assume you are running AMBEServer on the same machine as Analog_Bridge is running on. If this is so, you can just run the DV3000 (or other stick)

HI Ernie, I only have one instance for analog and mmdvm bridge this is right after install and configuration from the pdf documentation posted here. Regards, Andrew