1. main@DVSwitch.groups.io
  2. Messages
   Date   
Re: Analog_Bridge remote control (TLV) commands exposed.

SP2ONG Waldek
 

Heiko,

Yes, you know that this is not a problem for me :-) but many users do not know all the DVSwitch elements so precisely and that's why I pay attention

73 Waldek
Re: Analog_Bridge remote control (TLV) commands exposed.

Steve N4IRS
 

Yes, but it's very easy for us to change dvswitch.sh and avoid the problem alltogether.

On 11/15/2019 9:51 AM, Heiko DL1BZ wrote:
It's not really a problem. The ports in hbmonitor and hblink3 can be changed simply. I'm running here 3 instances of hblink3 and 3 instaces of hbmonitor at the same server. In this case you need change the ports too.
Look in the source of hbmonitor and hblink3 and change it. I'm sure Waldek - you know how you need to do this, hi.

73 Heiko, DL1BZ

Re: Analog_Bridge remote control (TLV) commands exposed.

Heiko DL1BZ
 

It's not really a problem. The ports in hbmonitor and hblink3 can be changed simply. I'm running here 3 instances of hblink3 and 3 instaces of hbmonitor at the same server. In this case you need change the ports too.
Look in the source of hbmonitor and hblink3 and change it. I'm sure Waldek - you know how you need to do this, hi.

73 Heiko, DL1BZ
Re: Analog_Bridge remote control (TLV) commands exposed.

Steve N4IRS
 

dvswitch.sh will be able to change DMRID and callsign. Next revision (or so)

Steve N4IRS

On 11/15/2019 1:17 AM, Waldek SP2ONG wrote:
Steve

I have start with send EmCom info via USRP Ananlog_Bridge and it will be useful possible use dvswitch.sh script yo change DMR ID in "gatewayDmrId"

73 Waldek

Re: Analog_Bridge remote control (TLV) commands exposed.

Steve N4IRS
 

Yes, it could happen. HTTP is only one way to transfer files but we will move the port.

Thanks, Steve N4IRS

On 11/15/2019 2:50 AM, Waldek SP2ONG wrote:
Steve

Looking through the dvswitch.sh file I see that it uses SimpleHTTPServer on python 9000 in python. Many people use Analog_Bridge on the same computer as they have HBlink3 and HBmonitor which uses port 9000.

I may be wrong but there may be a port conflict?

73 Waldek

Re: Analog_Bridge remote control (TLV) commands exposed.

SP2ONG Waldek
 
Edited

Steve

Looking through the dvswitch.sh file I see that it uses SimpleHTTPServer on port 9000. Many people use Analog_Bridge on the same computer as they have HBlink3 and HBmonitor which uses port 9000.

I may be wrong but there may be a port conflict?

73 Waldek
Re: Analog_Bridge remote control (TLV) commands exposed.

SP2ONG Waldek
 
Edited

Steve

I have start with send EmCom info via USRP Ananlog_Bridge and it will be useful possible use dvswitch.sh script to change DMR ID in "gatewayDmrId"

73 Waldek
Re: DMR to YSF Weird Issue

Walter Holmes K5WH
 

You’re the best Steve..

 

That all works perfectly now..

 

Thanks again..

 

Walter/K5WH

 

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> On Behalf Of Steve N4IRS
Sent: Thursday, November 14, 2019 6:11 PM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMR to YSF Weird Issue

 

Walter,
The reason the  file has a extension is so that people can determine which file they need for their architecture. You can rename the file so that it matches your service.
I put the most current version on github so people can try the new program to fix bugs or add features before I publish the file in the APT repository.

Once a month, I will update the APT repository, if the most current program is over 2 weeks old (and no bugs reported)

73, Steve N4IRS

On 11/14/19 6:39 PM, Walter Holmes K5WH wrote:

Steve,

 

To have this run as a service now, should I rename the MMMDVM_Bridge.amd64 file as MMMDVM_Bridge, so I can restart the mmdvm_bridge service?

 

Or is there an easier way to have the ./MMDVM_Bridge.amd64 MMDVM_Bridge.ini launch at startup automatically?

 

Or possibly the apt-get update and apt-get upgrade if the package is updated there already?

 

Thanks,

Walter/K5WH

 

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> On Behalf Of Steve N4IRS
Sent: Tuesday, November 12, 2019 10:02 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMR to YSF Weird Issue

 

Walter,
I updated MMMDVM_Bridge.amd64 yesterday. Please get a fresh copy from github.

Steve

On 11/12/2019 10:51 AM, Walter Holmes K5WH wrote:

hmm, even as root, I get a permission denied message when trying to run that.

 

 
Re: DMR to YSF Weird Issue

Steve N4IRS
 

Walter,
The reason the  file has a extension is so that people can determine which file they need for their architecture. You can rename the file so that it matches your service.
I put the most current version on github so people can try the new program to fix bugs or add features before I publish the file in the APT repository.

Once a month, I will update the APT repository, if the most current program is over 2 weeks old (and no bugs reported)

73, Steve N4IRS

On 11/14/19 6:39 PM, Walter Holmes K5WH wrote:

Steve,

 

To have this run as a service now, should I rename the MMMDVM_Bridge.amd64 file as MMMDVM_Bridge, so I can restart the mmdvm_bridge service?

 

Or is there an easier way to have the ./MMDVM_Bridge.amd64 MMDVM_Bridge.ini launch at startup automatically?

 

Or possibly the apt-get update and apt-get upgrade if the package is updated there already?

 

Thanks,

Walter/K5WH

 

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> On Behalf Of Steve N4IRS
Sent: Tuesday, November 12, 2019 10:02 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMR to YSF Weird Issue

 

Walter,
I updated MMMDVM_Bridge.amd64 yesterday. Please get a fresh copy from github.

Steve

On 11/12/2019 10:51 AM, Walter Holmes K5WH wrote:

hmm, even as root, I get a permission denied message when trying to run that.

 
Re: DMR to YSF Weird Issue

Walter Holmes K5WH
 

Steve,

 

To have this run as a service now, should I rename the MMMDVM_Bridge.amd64 file as MMMDVM_Bridge, so I can restart the mmdvm_bridge service?

 

Or is there an easier way to have the ./MMDVM_Bridge.amd64 MMDVM_Bridge.ini launch at startup automatically?

 

Or possibly the apt-get update and apt-get upgrade if the package is updated there already?

 

Thanks,

Walter/K5WH

 

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> On Behalf Of Steve N4IRS
Sent: Tuesday, November 12, 2019 10:02 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] DMR to YSF Weird Issue

 

Walter,
I updated MMMDVM_Bridge.amd64 yesterday. Please get a fresh copy from github.

Steve

On 11/12/2019 10:51 AM, Walter Holmes K5WH wrote:

hmm, even as root, I get a permission denied message when trying to run that.

 
Re: DMR to YSF Weird Issue

Walter Holmes K5WH
 

yes, that works now Steve..

many thanks,
Re: DMR to YSF Weird Issue

Steve N4IRS
 

Walter,
I updated MMMDVM_Bridge.amd64 yesterday. Please get a fresh copy from github.

Steve

On 11/12/2019 10:51 AM, Walter Holmes K5WH wrote:
hmm, even as root, I get a permission denied message when trying to run that.

Re: DMR to YSF Weird Issue

Steve N4IRS
 

hmmm,
Try this, I don't think it will work but

chmod +x MMDVM_Bridge.amd64

try again

I'm checking here too

On 11/12/2019 10:51 AM, Walter Holmes K5WH wrote:
hmm, even as root, I get a permission denied message when trying to run that.

Re: DMR to YSF Weird Issue

Walter Holmes K5WH
 

hmm, even as root, I get a permission denied message when trying to run that.
Re: DMR to YSF Weird Issue

Steve N4IRS
 

Put MMDVM_Bridge.amd64 in /opt/MMDVM_Bridge (do not rename file)
As root:
systemctl stop mmdvm_bridge
./MMDVM_Bridge.amd64 MMDVM_Bridge.ini

Does the program run?
 

On 11/12/2019 9:54 AM, Walter Holmes K5WH wrote:
Steve,

 I tried replacing the file, but I was not able to get the service to start afterwards.
Here is what my system is.   4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64
So I used the MMDVM_Bridge.amd64 and removed the .amd64 of course, reset the machine, but the service did not deem to start properly.  I had to replace the original file for that to come back up properly.
 Any idea where I should look further into this?
many thanks, Walter/K5WH
Re: DMR to YSF Weird Issue

Walter Holmes K5WH
 

Steve,

 I tried replacing the file, but I was not able to get the service to start afterwards.
Here is what my system is.   4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64
So I used the MMDVM_Bridge.amd64 and removed the .amd64 of course, reset the machine, but the service did not deem to start properly.  I had to replace the original file for that to come back up properly.
 Any idea where I should look further into this?
many thanks, Walter/K5WH
Re: DMR to YSF Weird Issue

Carlos Minguela
 

Thanks Steve.  I had the same problem and this fix solve it.  

73
Carlos
KP4CA
Re: I have asl setup in the cloud using debian. Just want to make sure i use the right MMDVM, i think should be using the amd64 hope this is correct before I download.thank you.

Steve N4IRS
 

What is the result of uname -a
I have asl setup in the cloud using debian. Just want to make sure i use the right MMDVM, i think should be using the amd64 hope this is correct before I download.thank you.

Charles Wiant
 

Re: DMR to YSF Weird Issue

Steve N4IRS
 

<https://dvswitch.groups.io/g/main/message/5289>

On 11/11/19 5:28 PM, Dexter Harroo wrote:
What did you do to resolve the issue? I seem to be having the same problem

On Sat, Nov 9, 2019, 12:55 AM Jake Litwin <litwinjwi@...> wrote:
Actually, I think I got it Steve. The logs are back to normal. Thanks so much for the guidance. So the executable that I was running, I take it that must have been an older one?

On Fri, Nov 8, 2019 at 10:40 PM Jake Litwin via Groups.Io <litwinjwi=gmail.com@groups.io> wrote:
Thanks Steve 

All seems to be working on the mobiles now but I'm seeing this output in the logs. Is this normal?

: 2019-11-09 04:39:31.410 YSF, received network data from N7VDR/JIMI to ALL        at N7VDR     

I: 2019-11-09 04:39:31.410 YSF, Lookup call N7VDR returned id 3108345 -> 3108345

M: 2019-11-09 04:39:31.415 DMR, TX state = ON

I: 2019-11-09 04:39:31.415 DMR, Begin TX: src=3108345 rpt=0 dst=420 slot=2 cc=0 metadata=N7VDR

D: 2019-11-09 04:39:32.041 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:32.041 0000:  1D 22 62 5F 29 54 30 53 52 52                      *."b_)T0SRR*

D: 2019-11-09 04:39:32.134 V/D Mode 2 Data, DT2

D: 2019-11-09 04:39:32.134 0000:  55 71 5F 2F 6C 21 52 20 03 FA                      *Uq_/l!R ..*

D: 2019-11-09 04:39:32.833 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:32.833 0000:  1D 22 62 5F 29 54 30 53 52 52                      *."b_)T0SRR*

D: 2019-11-09 04:39:32.941 V/D Mode 2 Data, DT2

D: 2019-11-09 04:39:32.941 0000:  55 71 5F 2F 6C 21 52 20 03 FA                      *Uq_/l!R ..*

D: 2019-11-09 04:39:33.639 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:33.639 0000:  1D 22 62 5F 29 54 30 53 52 52                      *."b_)T0SRR*

D: 2019-11-09 04:39:33.736 V/D Mode 2 Data, DT2

D: 2019-11-09 04:39:33.736 0000:  55 71 5F 2F 6C 21 52 20 03 FA                      *Uq_/l!R ..*

D: 2019-11-09 04:39:34.437 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:34.437 0000:  1D 22 62 5F 29 54 30 53 52 52                      *."b_)T0SRR*

D: 2019-11-09 04:39:34.534 V/D Mode 2 Data, DT2

D: 2019-11-09 04:39:34.534 0000:  55 71 5F 2F 6C 21 52 20 03 FA                      *Uq_/l!R ..*

D: 2019-11-09 04:39:35.263 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:35.263 0000:  1D 22 62 5F 29 54 30 53 52 52                      *."b_)T0SRR*

D: 2019-11-09 04:39:35.340 V/D Mode 2 Data, DT2

D: 2019-11-09 04:39:35.340 0000:  55 71 5F 2F 6C 21 52 20 03 FA                      *Uq_/l!R ..*

D: 2019-11-09 04:39:36.032 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:36.032 0000:  1D 22 62 5F 29 54 30 53 52 52                      *."b_)T0SRR*

D: 2019-11-09 04:39:36.136 V/D Mode 2 Data, DT2

D: 2019-11-09 04:39:36.136 0000:  55 71 5F 2F 6C 21 52 20 03 FA                      *Uq_/l!R ..*

D: 2019-11-09 04:39:36.839 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:36.839 0000:  1D 22 62 5F 29 54 30 53 52 52                      *."b_)T0SRR*

M: 2019-11-09 04:39:36.932 YSF, received network end of transmission, 5.7 seconds, 0% packet loss, BER: 0.0%

M: 2019-11-09 04:39:36.937 DMR, TX state = OFF, DMR frame count was 93 frames

M: 2019-11-09 04:39:39.645 YSF, received network data from WD0HDR/DAV to ALL        at WD0HDR    

I: 2019-11-09 04:39:39.645 YSF, Lookup call WD0HDR returned id 3108613 -> 3108613

M: 2019-11-09 04:39:39.650 DMR, TX state = ON

I: 2019-11-09 04:39:39.651 DMR, Begin TX: src=3108613 rpt=0 dst=420 slot=2 cc=0 metadata=WD0HDR

D: 2019-11-09 04:39:40.343 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:40.344 0000:  2F 22 62 5F 25 54 30 52 52 59                      */"b_%T0RRY*

D: 2019-11-09 04:39:40.462 V/D Mode 2 Data, DT2

D: 2019-11-09 04:39:40.462 0000:  59 70 46 5D 6C 20 50 20 03 23                      *YpF]l P .#*

D: 2019-11-09 04:39:41.158 V/D Mode 2 Data, DT1

D: 2019-11-09 04:39:41.158 0000:  2F 22 62 5F 25 54 30 52 52 59                      */"b_%T0RRY*

D: 2019-11-09 04:39:41.246 V/D Mode 2 Data, DT2

D: 2019-11-09 04:39:41.246 0000:  59 70 46 5D 6C 20 50 20 03 23                      *YpF]l P .#*

D: 2019-11-09 04:39:41.943 V/D Mode 2 Data, DT1



On Fri, Nov 8, 2019 at 10:13 PM Steve N4IRS <szingman@...> wrote:
There is no TX offset on s bridge.

Sent via smoke signal (AT&T)

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Adrian Fewster <vk4tux@...>
Sent: Friday, November 8, 2019 11:09:34 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] DMR to YSF Weird Issue
 

Try adjusting TX offset in modem section to suit all.

On 9/11/19 1:53 pm, Jake Litwin wrote:
Just curious to see if anyone has experienced this.. I have YSF bridged to DMR with MMDVM with the instructions provided here on the DVSwitch group. Everything seems to be fine except when mobile YSF radios receive a transmission from the DMR side, there's only about a second or two of audio and then nothing. The blue light on the YSF mobile blinks. YSF handhelds like the FT-3's, FT-2's, receive DMR just fine without any issues. Not sure why my setup would be affecting the mobile YSF radios only and not the YSF handhelds.

5441 - 5460 of 10634