Some questions about dvswitch.sh and Analog_Bridge


Tim Payne
 

Evening all,

I am pretty new to the MMDVM_Bridge software and was trying have a bridge from private hblink server to p25 networks. to do this i was trying HBlink ----> DMR2YSF -----> YSF2P25 -----> P25Gateway -----> P25Parrot. this method was not working. I could see traffic going one way but not back the other way.

Then I found this software and got it working. But i have a couple of questions. 
1st is about the dvswitch.sh script. I have a small python script that looks at the hblink logs and runs the dvswitch command to "tune" the correct talk group. but the only way i can make sure that it only changes the P25 instance of Analog_Bridge is to make sure the p25 instance is started after the DMR instance. is there another way?

2nd question is. I keep getting lots of info packet lines in my Analog_Bridge log files. this puts CPU usage up to 90%. Server starts up normally and nothing much in logs about it. But as soon as there is data, even just change talkgroup with dvswitch.sh, then the 2 instances of Analog_Bridge just spam each other and cpu load hits near max. This doesnt stop until I have killed one of the instances. Is this normal? or something wrong with configuration files? should I be running on a faster PC? The PC is a 1.6GHz Atom CPU and 2GB RAM with Ubuntu Server 18.04 running.

Thanks and 73's
Tim VK3FTZD


Tim Payne
 

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 -----> AB_P25 ------> MB -------> P25Gateway.

I have killed every other process for my setup and only included the 2 for AB. I have checked ports are correct and nothing looping back into itself or into another part. I have even changed the ports away from the port mappings in the example in case something else was causing this. Still scratching my head. I have uploaded my configs and logs in case anyone has the time to look and give a second opinion. 

Thanks
Cheers 73's
Tim VK3FTZD


 

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 me.
Tx begin, Tx end, callsigns etc.


Tim Payne
 

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 the problem. You say you use the logs yourself. Do you see this in your logs? Is it normal to have this happening?


 

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 forth from Analog_Bridge.
It will be the transcoding from dmr to p25 thats using the cpu not the info.


Steve N4IRS
 

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 of MB. So in MB.ini disable P25 and P25 networking.
Set the log level to 1 and capture the AB and MB logs. I would also like to see your MB.ini and dvswitch.ini.

Steve N4IRS

On 6/4/2020 5:35 AM, Tim Payne wrote:
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 the problem. You say you use the logs yourself. Do you see this in your logs? Is it normal to have this happening?


Tim Payne
 

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 the AB_P25 and then the AB_DMR along with the rest of the system and then when I ran the dvswitch command or keyed up on the radio there was no spamming of info packets. 
 
Today I though I would leave it running for a while after issuing the dvswitch tune 9999 (disconnect) running for 3 hours at 100 CPU. 

Does AB pull any setting from the DVswitch.ini file in the MB directory? 

I'll pull the Configs for those when I get to the PC tomorrow.

Thanks
Tim vk3ftzd


Mike Zingman - N4IRR
 

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 that service the network.
This is happening because the tune command sent to AB is producing an info packet (as it should).  I will see if I can suppress these if the client has not "registered" (DVSM)


Tim Payne
 

Hi All, 

I think i got it working for the most part. 

I have since done a complete reinstall of the OS using the mini ubuntu iso. basically is so cut back that it boots really quickly. 

All the configs setup from the DMR to P25 example port mappings.

export the environment variable using "export ABINFO=/tmp/ABInfo_32001.json" so DV switch only controls the P25 side of AB.

But the problem seemed to be there and only when dvswitch.sh sent an info packet.

so for the time being, I have commented out the send info packet line in dvswitch.sh. Probably not the best approach but it works and now I can change P25 talkgroups on the fly.

Next question... Is the info packet needed for talk group changing on AB?