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

Mike Zingman - N4IRR
 

Set the environment variable ABINFO to the filename of the AB you want to control. Each ABINFO file is in /tmp and named based on the port. 
ABINFO=/tmp/xxxx.xxx ./dvswitch.sx Foo
 
Re: Analog_Bridge remote control (TLV) commands exposed.

SP2ONG Waldek
 

Steve

One more question

I use three Analog_Bridge on my server. How to choose Analog_Bridge to use dvswitch.sh on the selected AB, for example, I would like to change tvlAudio gain

73 Waldek
New file uploaded to main@DVSwitch.groups.io

main@DVSwitch.groups.io Notification <main+notification@...>
 

Hello,

This email message is a notification to let you know that the following files have been uploaded to the Files area of the main@DVSwitch.groups.io group.

Uploaded By: Steve N4IRS <szingman@...>

Description:
USRP_Parrot listens on a UDP port for USRP packets. After end of transmission, USRP_Parrot sends those USRP packets out to a UDP port.

Cheers,
The Groups.io Team
Re: Analog_Bridge stops bridging

Steve N4IRS
 

ASL configures the USRP connection in rpt.conf:
In the node stanza

rxchannel = USRP/127.0.0.1:34001:32001; GNU Radio interface USRP



On 11/16/19 3:02 AM, Patrick Perdue wrote:

I have installed/configured DVSwitch on my Raspberry Pi 4 and pointed it at the local AMBEserver and remote USRP, but it seems that traffic isn't passing. Does ASL's USRP driver only listen on localhost by default? If so, where can I change this in ASL?

Otherwise, what did I break?


On 11/15/2019 5:47 PM, Patrick Perdue via Groups.Io wrote:

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

Patrick Perdue
 

Here is a full log. There are no entries when transmissions occur from either side of the bridge.

I could use the IP address rather than DNS for the remote machine, but I know from experience that DNS works, as I am currently using it to connect Analog_Bridge from the VPS to my remote AMBEserver in a somewhat working configuration.


I: 2019-11-16 10:03:22.605 Analog Bridge Version 1.4.1 Mon Nov 11 19:06:12 UTC 2019
I: 2019-11-16 10:03:22.605 Copyright (C) 2018 DVSwitch, INAD.
I: 2019-11-16 10:03:22.605 Created by Mike N4IRR and Steve N4IRS
I: 2019-11-16 10:03:22.605 Analog Bridge comes with ABSOLUTELY NO WARRANTY
I: 2019-11-16 10:03:22.605
I: 2019-11-16 10:03:22.605 This software is for use on amateur radio networks only,
I: 2019-11-16 10:03:22.605 it is to be used for educational purposes only. Its use on
I: 2019-11-16 10:03:22.605 commercial networks is strictly prohibited.
I: 2019-11-16 10:03:22.605
I: 2019-11-16 10:03:22.606 Analog Bridge is starting
M: 2019-11-16 10:03:22.606 Setting [GENERAL] logLevel -> 2
M: 2019-11-16 10:03:22.606 Setting [GENERAL] subscriberFile -> /var/lib/dvswitch/subscriber_ids.csv
M: 2019-11-16 10:03:22.606 Setting [GENERAL] exportMetadata -> true
M: 2019-11-16 10:03:22.606 Setting [GENERAL] decoderFallBack -> true
M: 2019-11-16 10:03:22.606 Setting [GENERAL] useEmulator -> false
M: 2019-11-16 10:03:22.606 Setting [GENERAL] emulatorAddress -> 127.0.0.1:2470
M: 2019-11-16 10:03:22.606 Setting [AMBE_AUDIO] address -> xlx.borris.me
M: 2019-11-16 10:03:22.606 Setting [AMBE_AUDIO] txPort -> 31103
M: 2019-11-16 10:03:22.606 Setting [AMBE_AUDIO] rxPort -> 31100
M: 2019-11-16 10:03:22.606 Setting [AMBE_AUDIO] ambeMode -> DMR
M: 2019-11-16 10:03:22.607 Setting [AMBE_AUDIO] minTxTimeMS -> 2500
M: 2019-11-16 10:03:22.607 Setting [AMBE_AUDIO] gatewayDmrId -> 3138495
M: 2019-11-16 10:03:22.607 Setting [AMBE_AUDIO] repeaterID -> 3154444
M: 2019-11-16 10:03:22.607 Setting [AMBE_AUDIO] txTg -> 31679
M: 2019-11-16 10:03:22.607 Setting [AMBE_AUDIO] txTs -> 2
M: 2019-11-16 10:03:22.607 Setting [AMBE_AUDIO] colorCode -> 1
M: 2019-11-16 10:03:22.607 Setting [USRP] address -> xlx.borris.me
M: 2019-11-16 10:03:22.607 Setting [USRP] txPort -> 32001
M: 2019-11-16 10:03:22.607 Setting [USRP] rxPort -> 34001
M: 2019-11-16 10:03:22.607 Setting [USRP] usrpAudio -> AUDIO_UNITY
M: 2019-11-16 10:03:22.607 Setting [USRP] usrpGain -> 1.10
M: 2019-11-16 10:03:22.607 Setting [USRP] tlvAudio -> AUDIO_USE_BPF
M: 2019-11-16 10:03:22.607 Setting [USRP] tlvGain -> 0.20
M: 2019-11-16 10:03:22.607 Setting [DV3000] address -> 127.0.0.1
M: 2019-11-16 10:03:22.607 Setting [DV3000] rxPort -> 2460
I: 2019-11-16 10:03:22.607 Open UDP listener on xlx.borris.me:31100
I: 2019-11-16 10:03:22.607 Open USRP on xlx.borris.me:32001
M: 2019-11-16 10:03:22.608 Connecting to DV3000 hardware......
M: 2019-11-16 10:03:22.628 Begin DV3000 decode
I: 2019-11-16 10:03:22.981 Subscriber IDs loaded: 146118
I: 2019-11-16 10:03:22.981 Default extended metadata <KE4DYI>
I: 2019-11-16 10:03:22.981 Using hardware AMBE vocoder
I: 2019-11-16 10:03:22.983 Connected to USRP xlx.borris.me:32001
I: 2019-11-16 10:03:22.984 Starting USRP --> Analog_Bridge (encoder) -> TLV thread
I: 2019-11-16 10:03:22.984 Starting TLV --> Analog_Bridge (decoder) --> USRP thread
I: 2019-11-16 10:03:28.692 Signal 2 received, exiting Analog_Bridge

11/16/2019 3:44 AM, Peter M0NWI wrote:

Patrick,

You'll need to give people a little more to go on.  Can you post your config text files, and the output log from when you are trying to transmit?

Most of these type of issues seem to be around IP addresses or ports not being lined up through the pipeline of voice bridges, and packets dropping off the end.

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: 16 November 2019 08:02:52
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Analog_Bridge stops bridging
 

I have installed/configured DVSwitch on my Raspberry Pi 4 and pointed it at the local AMBEserver and remote USRP, but it seems that traffic isn't passing. Does ASL's USRP driver only listen on localhost by default? If so, where can I change this in ASL?

Otherwise, what did I break?


On 11/15/2019 5:47 PM, Patrick Perdue via Groups.Io wrote:

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: Trying to get HBlink to connect to Brandmeister without success: #hblink

Peter M0NWI
 

Bang in Corey,

And the fact that all this is volunteer labour and their personal money.
People have work, life and family issues which must come first!

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Corey Dean N3FE <n3fe@...>
Sent: 16 November 2019 00:07:36
To: main@dvswitch.groups.io <main@dvswitch.groups.io>
Subject: Re: [DVSwitch] Trying to get HBlink to connect to Brandmeister without success: #hblink
 
I will see if I can get someone to look into this for you.  I must apologize I haven’t been active for a few months now and have not been adding connections to 3102.  I will see if I can get someone to look into adding these for you on another bm master.

On another note... there seems to be some people that monitor this group just so they can bash people on another network.  If you don’t understand how things work, take the time to learn and knock of the bashing.  It may help you to understand how things really work.



On Fri, Nov 15, 2019 at 4:03 PM Carlos Minguela via Groups.Io <minguela=yahoo.com@groups.io> wrote:
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: Analog_Bridge stops bridging

Peter M0NWI
 

Patrick,

You'll need to give people a little more to go on.  Can you post your config text files, and the output log from when you are trying to transmit?

Most of these type of issues seem to be around IP addresses or ports not being lined up through the pipeline of voice bridges, and packets dropping off the end.

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Patrick Perdue <patrick@...>
Sent: 16 November 2019 08:02:52
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] Analog_Bridge stops bridging
 

I have installed/configured DVSwitch on my Raspberry Pi 4 and pointed it at the local AMBEserver and remote USRP, but it seems that traffic isn't passing. Does ASL's USRP driver only listen on localhost by default? If so, where can I change this in ASL?

Otherwise, what did I break?


On 11/15/2019 5:47 PM, Patrick Perdue via Groups.Io wrote:

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

Patrick Perdue
 

I have installed/configured DVSwitch on my Raspberry Pi 4 and pointed it at the local AMBEserver and remote USRP, but it seems that traffic isn't passing. Does ASL's USRP driver only listen on localhost by default? If so, where can I change this in ASL?

Otherwise, what did I break?


On 11/15/2019 5:47 PM, Patrick Perdue via Groups.Io wrote:

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: Trying to get HBlink to connect to Brandmeister without success: #hblink

Carlos Minguela
 

Thanks Corey.

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

Corey Dean N3FE <n3fe@...>
 

I will see if I can get someone to look into this for you.  I must apologize I haven’t been active for a few months now and have not been adding connections to 3102.  I will see if I can get someone to look into adding these for you on another bm master.

On another note... there seems to be some people that monitor this group just so they can bash people on another network.  If you don’t understand how things work, take the time to learn and knock of the bashing.  It may help you to understand how things really work.



On Fri, Nov 15, 2019 at 4:03 PM Carlos Minguela via Groups.Io <minguela=yahoo.com@groups.io> wrote:
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: 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

Ernie Gm7kbk
 

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

3861 - 3880 of 9072