Date   

Re: Analog_Bridge stops bridging

Patrick Perdue
 

The power supply is 4A. Temperature is hanging out around 35 degrees C with active cooling.


On 11/15/2019 4:44 PM, Ernie Gm7kbk wrote:
Check your power supply it needs to be 2 amps or greater. Also Pi do not like the heat. Use cooling fan and heatsinks.


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: Friday, November 15, 2019 8:43:09 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: [DVSwitch] Analog_Bridge stops bridging
 
Hi:

I have Analog_Bridge and MMDVM_Bridge running on a Debian Stretch VPS.
Analog_Bridge is connected to a remote DV3000 dongle hosted on a
Raspberry Pi at my house. Pings between my house and the

server average 3 ms, with higher spikes. The worst I see is 19 ms, but
that's not at all typical.

Sometimes, after Analog_Bridge has been running for some time, traffic
appears to stop bridging. There is no activity in the log indicating
that it is receiving or transmitting between MMDVM_Bridge and USRP. It
just stops, requiring a restart of A_B, which makes everything work again.

Sometimes, it can run like this for a day or two. Other times, it can
fall over in less than an hour.

I haven't figured out a pattern in the logs. At first, I thought it
might be short keys from Allstar, but it often just drops in the middle
of transmission, and it doesn't seem to matter what side of the bridge
is transmitting at the time. I have tried running it in the console and
as a daemon with the same result. Note: I'm using the version of
Analog_Bridge from the repository. Is this a known, fixed issue in the
latest build from github?

This didn't happen when I was using the md380-emu vocoder, as far as I
can remember. I had Analog_Bridge running solidly with no restarts for a
week.

For a while, I had Analog_Bridge restart four times a day on a Cron, but
that wasn't ideal, as it would sometimes break QSOs, and often, it fell
over between restarts, leaving large gaps of time when the bridge didn't
work if I didn't happen to be around. I haven't yet implemented a macro
so anyone can restart the bridge.

Has anyone else experienced this while using a remotely connected
DV3000? Would it be safer to run DVSwitch and the DV3000 locally, and
have it connect to USRP across the internet rather than having
Analog_Bridge connect to my DV3000 that way?





Re: Analog_Bridge stops bridging

 

Check your power supply it needs to be 2 amps or greater. Also Pi do not like the heat. Use cooling fan and heatsinks.


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: Friday, November 15, 2019 8:43:09 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: [DVSwitch] Analog_Bridge stops bridging
 
Hi:

I have Analog_Bridge and MMDVM_Bridge running on a Debian Stretch VPS.
Analog_Bridge is connected to a remote DV3000 dongle hosted on a
Raspberry Pi at my house. Pings between my house and the

server average 3 ms, with higher spikes. The worst I see is 19 ms, but
that's not at all typical.

Sometimes, after Analog_Bridge has been running for some time, traffic
appears to stop bridging. There is no activity in the log indicating
that it is receiving or transmitting between MMDVM_Bridge and USRP. It
just stops, requiring a restart of A_B, which makes everything work again.

Sometimes, it can run like this for a day or two. Other times, it can
fall over in less than an hour.

I haven't figured out a pattern in the logs. At first, I thought it
might be short keys from Allstar, but it often just drops in the middle
of transmission, and it doesn't seem to matter what side of the bridge
is transmitting at the time. I have tried running it in the console and
as a daemon with the same result. Note: I'm using the version of
Analog_Bridge from the repository. Is this a known, fixed issue in the
latest build from github?

This didn't happen when I was using the md380-emu vocoder, as far as I
can remember. I had Analog_Bridge running solidly with no restarts for a
week.

For a while, I had Analog_Bridge restart four times a day on a Cron, but
that wasn't ideal, as it would sometimes break QSOs, and often, it fell
over between restarts, leaving large gaps of time when the bridge didn't
work if I didn't happen to be around. I haven't yet implemented a macro
so anyone can restart the bridge.

Has anyone else experienced this while using a remotely connected
DV3000? Would it be safer to run DVSwitch and the DV3000 locally, and
have it connect to USRP across the internet rather than having
Analog_Bridge connect to my DV3000 that way?





Re: Trying to get HBlink to connect to Brandmeister without success: #hblink

Carlos Minguela
 

Hi Corey

Thanks for the information. I see the reason now. First of all, I requested an openbridge on 25-Jul-19. The request was canceled and then I made another request on 01-Nov-19 with the number BMN-1863.  To date it has not been answered just like the previous one that was canceled due to lack of attention.   I'll just wait until someone take my case then.

Thanks again for the clarification.

Carlos
KP4CA


Re: Trying to get HBlink to connect to Brandmeister without success: #hblink

Jay Spaulding
 

Well there you have it. I put my request in weeks ago.

Thanks for the clarification Corey.


On Fri, Nov 15, 2019 at 2:34 PM Corey Dean N3FE <n3fe@...> wrote:
You arent connecting because I blocked you and two others.  I am requesting you request a openbridge connection Using the bm support email support@.... 

Having 20 plus connections as a user from hblink to bm is not how it was intended to be used.  That is what openbridge was implemented for!





On Fri, Nov 15, 2019 at 2:27 PM Jay Spaulding <Jay@...> wrote:
Can try another server.
Here is what mine top looks like little different from yours.

[BrandMeister]
MODE: PEER
ENABLED: True
LOOSE: True
EXPORT_AMBE: False
IP:
PORT: 42031
MASTER_IP: 64.94.238.196
MASTER_PORT: 62031
PASSPHRASE: passw0rd

On Fri, Nov 15, 2019 at 1:50 PM Carlos Minguela via Groups.Io <minguela=yahoo.com@groups.io> wrote:

Hello, for a week now my HBlink has not been able to connect with BM. No changes have been made to the system. This is the log and configuration. Have any of you had a similar situation? Thanks for your help.

Carlos
KP4CA

Log:

WARNING 2019-11-15 18:48:46,712 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:48:51,643 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:48:51,676 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:48:51,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:48:56,644 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:48:56,676 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:48:56,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:49:01,643 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:49:01,675 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:49:01,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:49:06,643 (TG33015) Sending login request to master 74.91.114.19:62031
 

hblink.cfg

[TG33015]
MODE: PEER
ENABLED: True
LOOSE: False
EXPORT_AMBE: False
IP: 
PORT: 54002
MASTER_IP: 74.91.114.19
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: KP4CA
RADIO_ID: 330500410
RX_FREQ: 440750000
TX_FREQ: 445750000
TX_POWER: 25
COLORCODE: 1
SLOTS: 2
LATITUDE: 18.296409
LONGITUDE: -067.161799
HEIGHT: 75
LOCATION: Anasco, PR
DESCRIPTION: HBlink Master
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS:
USE_ACL: True
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
 



--



--


Analog_Bridge stops bridging

Patrick Perdue
 

Hi:

I have Analog_Bridge and MMDVM_Bridge running on a Debian Stretch VPS. Analog_Bridge is connected to a remote DV3000 dongle hosted on a Raspberry Pi at my house. Pings between my house and the

server average 3 ms, with higher spikes. The worst I see is 19 ms, but that's not at all typical.

Sometimes, after Analog_Bridge has been running for some time, traffic appears to stop bridging. There is no activity in the log indicating that it is receiving or transmitting between MMDVM_Bridge and USRP. It just stops, requiring a restart of A_B, which makes everything work again.

Sometimes, it can run like this for a day or two. Other times, it can fall over in less than an hour.

I haven't figured out a pattern in the logs. At first, I thought it might be short keys from Allstar, but it often just drops in the middle of transmission, and it doesn't seem to matter what side of the bridge is transmitting at the time. I have tried running it in the console and as a daemon with the same result. Note: I'm using the version of Analog_Bridge from the repository. Is this a known, fixed issue in the latest build from github?

This didn't happen when I was using the md380-emu vocoder, as far as I can remember. I had Analog_Bridge running solidly with no restarts for a week.

For a while, I had Analog_Bridge restart four times a day on a Cron, but that wasn't ideal, as it would sometimes break QSOs, and often, it fell over between restarts, leaving large gaps of time when the bridge didn't work if I didn't happen to be around. I haven't yet implemented a macro so anyone can restart the bridge.

Has anyone else experienced this while using a remotely connected DV3000? Would it be safer to run DVSwitch and the DV3000 locally, and have it connect to USRP across the internet rather than having Analog_Bridge connect to my DV3000 that way?


Re: Trying to get HBlink to connect to Brandmeister without success: #hblink

Corey Dean N3FE <n3fe@...>
 

You arent connecting because I blocked you and two others.  I am requesting you request a openbridge connection Using the bm support email support@.... 

Having 20 plus connections as a user from hblink to bm is not how it was intended to be used.  That is what openbridge was implemented for!





On Fri, Nov 15, 2019 at 2:27 PM Jay Spaulding <Jay@...> wrote:
Can try another server.
Here is what mine top looks like little different from yours.

[BrandMeister]
MODE: PEER
ENABLED: True
LOOSE: True
EXPORT_AMBE: False
IP:
PORT: 42031
MASTER_IP: 64.94.238.196
MASTER_PORT: 62031
PASSPHRASE: passw0rd

On Fri, Nov 15, 2019 at 1:50 PM Carlos Minguela via Groups.Io <minguela=yahoo.com@groups.io> wrote:

Hello, for a week now my HBlink has not been able to connect with BM. No changes have been made to the system. This is the log and configuration. Have any of you had a similar situation? Thanks for your help.

Carlos
KP4CA

Log:

WARNING 2019-11-15 18:48:46,712 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:48:51,643 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:48:51,676 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:48:51,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:48:56,644 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:48:56,676 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:48:56,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:49:01,643 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:49:01,675 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:49:01,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:49:06,643 (TG33015) Sending login request to master 74.91.114.19:62031
 

hblink.cfg

[TG33015]
MODE: PEER
ENABLED: True
LOOSE: False
EXPORT_AMBE: False
IP: 
PORT: 54002
MASTER_IP: 74.91.114.19
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: KP4CA
RADIO_ID: 330500410
RX_FREQ: 440750000
TX_FREQ: 445750000
TX_POWER: 25
COLORCODE: 1
SLOTS: 2
LATITUDE: 18.296409
LONGITUDE: -067.161799
HEIGHT: 75
LOCATION: Anasco, PR
DESCRIPTION: HBlink Master
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS:
USE_ACL: True
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
 



--


Re: Trying to get HBlink to connect to Brandmeister without success: #hblink

Jay Spaulding
 

Can try another server.
Here is what mine top looks like little different from yours.

[BrandMeister]
MODE: PEER
ENABLED: True
LOOSE: True
EXPORT_AMBE: False
IP:
PORT: 42031
MASTER_IP: 64.94.238.196
MASTER_PORT: 62031
PASSPHRASE: passw0rd

On Fri, Nov 15, 2019 at 1:50 PM Carlos Minguela via Groups.Io <minguela=yahoo.com@groups.io> wrote:

Hello, for a week now my HBlink has not been able to connect with BM. No changes have been made to the system. This is the log and configuration. Have any of you had a similar situation? Thanks for your help.

Carlos
KP4CA

Log:

WARNING 2019-11-15 18:48:46,712 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:48:51,643 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:48:51,676 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:48:51,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:48:56,644 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:48:56,676 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:48:56,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:49:01,643 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:49:01,675 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:49:01,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:49:06,643 (TG33015) Sending login request to master 74.91.114.19:62031
 

hblink.cfg

[TG33015]
MODE: PEER
ENABLED: True
LOOSE: False
EXPORT_AMBE: False
IP: 
PORT: 54002
MASTER_IP: 74.91.114.19
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: KP4CA
RADIO_ID: 330500410
RX_FREQ: 440750000
TX_FREQ: 445750000
TX_POWER: 25
COLORCODE: 1
SLOTS: 2
LATITUDE: 18.296409
LONGITUDE: -067.161799
HEIGHT: 75
LOCATION: Anasco, PR
DESCRIPTION: HBlink Master
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS:
USE_ACL: True
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
 



--


Trying to get HBlink to connect to Brandmeister without success: #hblink

Carlos Minguela
 


Hello, for a week now my HBlink has not been able to connect with BM. No changes have been made to the system. This is the log and configuration. Have any of you had a similar situation? Thanks for your help.

Carlos
KP4CA

Log:

WARNING 2019-11-15 18:48:46,712 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:48:51,643 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:48:51,676 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:48:51,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:48:56,644 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:48:56,676 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:48:56,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:49:01,643 (TG33015) Sending login request to master 74.91.114.19:62031
INFO 2019-11-15 18:49:01,675 (TG33015) Repeater Login ACK Received with 32bit ID: 1751451459
WARNING 2019-11-15 18:49:01,710 (TG33015) MSTNAK Received. Resetting connection to the Master.
INFO 2019-11-15 18:49:06,643 (TG33015) Sending login request to master 74.91.114.19:62031
 

hblink.cfg

[TG33015]
MODE: PEER
ENABLED: True
LOOSE: False
EXPORT_AMBE: False
IP: 
PORT: 54002
MASTER_IP: 74.91.114.19
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: KP4CA
RADIO_ID: 330500410
RX_FREQ: 440750000
TX_FREQ: 445750000
TX_POWER: 25
COLORCODE: 1
SLOTS: 2
LATITUDE: 18.296409
LONGITUDE: -067.161799
HEIGHT: 75
LOCATION: Anasco, PR
DESCRIPTION: HBlink Master
URL: https://www.qrz.com/db/KP4CA
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS:
USE_ACL: True
SUB_ACL: DENY:1
TGID_TS1_ACL: PERMIT:ALL
TGID_TS2_ACL: PERMIT:ALL
 


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.

4681 - 4700 of 9882