Date   

Re: AllStarLink/ASL-Install

Steve KC1AWV
 

I assume that with the graphical interface being used, you installed ASL on top of an existing Linux install? If I recall correctly, the ASL image is based on ALArm, not Debian/Raspbian. 

When running the asl-menu script, are you elevating to superuser by using sudo asl-menu?


Re: AllStarLink/ASL-Install

Manuel Díaz
 




so I have it and it gives me the error 5




Re: AllStarLink/ASL-Install

Steve KC1AWV
 

Long story short, if running the command asterisk -rvvv on the terminal works, this is the reason why.

The asl-menu script looks for the asterisk executable in /usr/sbin. If your instance of asterisk is installed or located elsewhere, you will need to change line 68 in the asl-menu script to reflect the correct location of the executable. So, for instance, if it's located in /usr/local/sbin the line should be changed to ASTERISK=/usr/local/sbin/asterisk. To find where the executable is, you can run which asterisk on the terminal to show where the file is located in your PATH.

Of course, flashing the maintained image for the RPi onto your card would work too, and I've had no issues running a mobile ASL node from it.

- Steve KC1AWV


Re: AllStarLink/ASL-Install

Steve KC1AWV
 

If you exit back to the terminal and run asterisk -rvvv does the asterisk cli come up?

- Steve KC1AWV


AllStarLink/ASL-Install

Manuel Díaz
 

Hi.
Who knows why I get this error when I give option 5 of the asl-menu?
I have the system installed in a raspberry pi 3B





Re: Problem with hb_parrot.py with actual github version of hblink...

Heiko DL1BZ
 

Great work Cort. Thanks a lot for the very fast fixing.

73 Heiko, DL1BZ


Re: Problem with hb_parrot.py with actual github version of hblink...

Cort N0MJS <n0mjs@...>
 

I fixed parrot. Stupid typo. Thanks, Heiko for finding my mistake!

On Dec 11, 2018, at 8:35 AM, Heiko DL1BZ <dg2dra@...> wrote:

If I use the master branch of hblink (with openbridge now) the included hb_parrot.py don't work anymore. I don't see no connect from hb_confbridge. BUT, if I use the old hb_parrot.py as an own instance, the hb_parrot works - it connects and playback all correctly. The newer in actual master branch do nothing. I'm running a master instance of hb_confbridge und an instance of hb_parrot, all is bridged (here with a talkgroup 79990).

What was changed between old and new ?

73 Heiko, DL1BZ

Cort Buffington
785-865-7206


Problem with hb_parrot.py with actual github version of hblink...

Heiko DL1BZ
 

If I use the master branch of hblink (with openbridge now) the included hb_parrot.py don't work anymore. I don't see no connect from hb_confbridge. BUT, if I use the old hb_parrot.py as an own instance, the hb_parrot works - it connects and playback all correctly. The newer in actual master branch do nothing. I'm running a master instance of hb_confbridge und an instance of hb_parrot, all is bridged (here with a talkgroup 79990).

What was changed between old and new ?

73 Heiko, DL1BZ


Re: ASL <-> XLX No analog audio?

Steve KC1AWV
 

Unfortunately, not yet. I am using the md380 software codec right now, and I would like to test a hardware AMBE dongle. I will have to purchase another pair and send the audio over to the transcoding server, as the ASL and XLX servers are housed in a colo data center that I do not have physical access to. I intended to do this anyway, to see if I can get DStar, DMR and YSF all on one module talking to each other.

Please let me know if you make any progress. I do want to keep this topic open to see if anyone else has input, as well as providing my own status updates with this project.

If there are people interested in testing the system I have in place, please do. The inbound connections available are:

ASL node 46550
Echolink KC1AWV-L
XLX740 Module B (Transcoding)

Thanks!
-Steve KC1AWV

On Sat, Dec 8, 2018, 8:39 PM adshar64 via Groups.Io <adshar64=yahoo.com@groups.io wrote:
Steve, Did you find a fix for this issue, i have the same here ?

Murray.


Re: Link DMR <==> FCSXXX

Bruno
 

Hi,

Super thank you very much for the developments. Congratulations for your work.

73's

F1PTL Bruno


Le ven. 7 déc. 2018 à 15:03, Steve N4IRS <szingman@...> a écrit :
We have identified a bug. It is being worked on now. I will post when you can update.

Steve N4IRS

On 12/4/2018 4:41 PM, Bruno wrote:
Starting logging, please wait...
M: 2018-12-04 21:39:55.381 YSF, network watchdog has expired, 152.4 seconds, 0% packet loss, BER: 0.0%
M: 2018-12-04 21:39:58.946 YSF, received network data from N4IRR to ALL at FCS001-33 


Re: Link DMR <==> FCSXXX

Steve N4IRS
 

We have identified a bug. It is being worked on now. I will post when you can update.

Steve N4IRS

On 12/4/2018 4:41 PM, Bruno wrote:
Starting logging, please wait...
M: 2018-12-04 21:39:55.381 YSF, network watchdog has expired, 152.4 seconds, 0% packet loss, BER: 0.0%
M: 2018-12-04 21:39:58.946 YSF, received network data from N4IRR to ALL at FCS001-33 


Re: NXDN to YSF

Steve N4IRS
 

In testing another issue with YSF we have identified a bug. It is being looked at to resolve both problems.  I'll post when it is resolved and you can do a update.

Steve N4IRS

On 12/7/2018 8:39 AM, andrew_12ph via Groups.Io wrote:
I have similar issues the DN switch to VW using my yaesu ftm100 but it seems to be okay when im using my portable ft2d.
any suggestions to fix this?


Re: NXDN to YSF

andrew delgado
 

I have similar issues the DN switch to VW using my yaesu ftm100 but it seems to be okay when im using my portable ft2d.
any suggestions to fix this?


Re: ASL playback and morse distorted when bridge is running

Corey Dean N3FE <n3fe@...>
 

I pulled the email address you used to register with in bm and sent the email from my personal address.

Corey


On Dec 5, 2018, at 8:33 PM, va3dxv <va3dxv@...> wrote:

Corey, could you please tell me what email address you used and where you got it? I'm concerned that I didn't receive the email. If there's an incorrect address published somewhere I'd like to rectify it so that i can be contacted in the event something is malfunctioning.

My apologies for the noise and annoyance, I disconnected from all TG's when I saw what was happening. After returning to that device just a few minutes ago, I've found out what caused it (https://dvswitch.groups.io/g/allstarlink/topic/dmr_on_the_fly_shell_script/28137868)


Re: ASL playback and morse distorted when bridge is running

va3dxv
 

Corey, could you please tell me what email address you used and where you got it? I'm concerned that I didn't receive the email. If there's an incorrect address published somewhere I'd like to rectify it so that i can be contacted in the event something is malfunctioning.

My apologies for the noise and annoyance, I disconnected from all TG's when I saw what was happening. After returning to that device just a few minutes ago, I've found out what caused it (https://dvswitch.groups.io/g/allstarlink/topic/dmr_on_the_fly_shell_script/28137868)


Re: Link DMR <==> FCSXXX

Steve N4IRS
 

I need to see the log from MMDVM_Bridge during a transmission from DMR I have a hotspot at home and I'm listening to FCS001 33

On 12/5/2018 2:13 PM, Bruno wrote:
Hi,

Here are the files used to set up this configuration.
YSFGateway Local that connects FCS001 33
MMDVM_Bridge making DMR connection BM <=> YSF
Port 35100 and 35103
The MMDVM logs are good with the good indicative
This is found at the PI-Star interface which is connected to the FCS001 33 on the receiving OM that arrives from the DMR BM.
 
73's
F1PTL Bruno


Re: Link DMR <==> FCSXXX

Bruno
 

Hi,

Here are the files used to set up this configuration.
YSFGateway Local that connects FCS001 33
MMDVM_Bridge making DMR connection BM <=> YSF
Port 35100 and 35103
The MMDVM logs are good with the good indicative
This is found at the PI-Star interface which is connected to the FCS001 33 on the receiving OM that arrives from the DMR BM.
 
73's
F1PTL Bruno


Re: Is this even possible?

Corey Dean N3FE <n3fe@...>
 

Now that openbridge is released I may be able to help out some here.  I have about 15-20 talkgroups from bm 3102 feeding hblink using openbridge.  I then have a link into my cbridge carrying Delmarva 8802, then I also have a backup system of hblink with all of those coming across it.  My home brew repeaters connect directly to hblink and the 8300 repeaters use IPSec bridge / hb bridge to connect to hblink.  I have been running it this way for a few months with no trouble at all!

If I need another talkgroup from the cbridge or bm it is very easy to add.  On openbridge all I need to know is the talkgroup I’d, enter it in and you have it right away.  Think of it as a cbridge cclink with out the need for a lid.

Corey n3fe

On Tue, Dec 4, 2018 at 8:28 PM JJ Cummings <cummingsj@...> wrote:
Jim, you can do what you want to do now with the use of HBLink, DMRLink, HB_Bridge and IPSC_Bridge as follows:

hb_confbridge <-> Brandmeister (for BM TGs)
hb_confbridge <-> hb_bridge <-> ipsc_bridge <-> confbridge (for CBridge interfacing and interfacing to motorola repeaters)

hb_confbridge is a single instance of hb_confbridge.py from HBLink
confbridge is a single instance of confbridge.py from DMRLink
ipsc_bridge and hb_bridge are the respective single instances of the .py files from IPSC_Bridge and HB_Bridge.

All that you have to do is configure the respective _rules.py files to determine what TGs are allowed to go to what system, simply excluding TG8802 from your Brandmeister stanza in said file will do it.

JJC
N0PKT

On Tue, Dec 4, 2018 at 1:56 PM Jim Gifford - KD4PPG <jim@...> wrote:
A lot has happened in the last few weeks.  Most critically, the OpenBridge branch merged back into the master branch, bringing with it new goodies to play with, namely ACLs!

Additionally, I've stopped trying to conflate my needs with the needs of the other repeater operator, instead treating each as a unique problem to be solved.  Since his is closer to being on the air, I'm focusing on that.  I'm hoping for OpenBridge to be the answer to my own setup in the near future.

Basic premise: new (used) repeater, VHF, XPR8400, 147.210 +, CC1,  antenna at 300' on a county tower, owner: N4TIK (Ken), trustee: W0ADD (Al).

Ken and Al would prefer their repeater have the sysop level of control provided by Brandmeister rather than being on a cBridge and having to pester the bridge operator for changes.  However, they also want to carry the DelMarVa (8802) talkgroup, primarily for coordination across the region during EmComm scenarios, which is only carried on cBridges currently.

For policy reasons, 8802 will not be carried by BM.

The repeater is operational, barring some issues with the duplexer.  It's connected to BM currently, and operating as the owner and trustee wish it to, although lacking the 8802 talkgroup.

Existing configuration:

I think that with the advent of ACLs, I can insert a DVSwitch suite in between the XPR8400 and the BM3102 server.  I can use the ACLs to deny 8802 from going to BM3102, and also to permit only 8802 on TS1 going to/from K4USD.

Proposed configuration:


In this proposal, the IPSC_Bridge <-> BM3102 link would be using the N4TIK DMR ID # 310328, so would look the same as the existing repeater.

Does anyone see anything wrong with this approach?

Yes, I know BM supports HB directly, but I don't know what's involved with changing from the current IPSC connection to an HB connection, ie will BM even care? Is it a different port?  For that matter, I don't *know* that the IPSC_Bridge <->BM3102 link will function correctly.   Any advice on this point is very welcome.

Thanks in advance,
Jim

PS, hooray for ACLs!

On Nov 23, 2018, at 7:14 AM, Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG



Re: Is this even possible?

JJ Cummings
 

Jim, you can do what you want to do now with the use of HBLink, DMRLink, HB_Bridge and IPSC_Bridge as follows:

hb_confbridge <-> Brandmeister (for BM TGs)
hb_confbridge <-> hb_bridge <-> ipsc_bridge <-> confbridge (for CBridge interfacing and interfacing to motorola repeaters)

hb_confbridge is a single instance of hb_confbridge.py from HBLink
confbridge is a single instance of confbridge.py from DMRLink
ipsc_bridge and hb_bridge are the respective single instances of the .py files from IPSC_Bridge and HB_Bridge.

All that you have to do is configure the respective _rules.py files to determine what TGs are allowed to go to what system, simply excluding TG8802 from your Brandmeister stanza in said file will do it.

JJC
N0PKT

On Tue, Dec 4, 2018 at 1:56 PM Jim Gifford - KD4PPG <jim@...> wrote:
A lot has happened in the last few weeks.  Most critically, the OpenBridge branch merged back into the master branch, bringing with it new goodies to play with, namely ACLs!

Additionally, I've stopped trying to conflate my needs with the needs of the other repeater operator, instead treating each as a unique problem to be solved.  Since his is closer to being on the air, I'm focusing on that.  I'm hoping for OpenBridge to be the answer to my own setup in the near future.

Basic premise: new (used) repeater, VHF, XPR8400, 147.210 +, CC1,  antenna at 300' on a county tower, owner: N4TIK (Ken), trustee: W0ADD (Al).

Ken and Al would prefer their repeater have the sysop level of control provided by Brandmeister rather than being on a cBridge and having to pester the bridge operator for changes.  However, they also want to carry the DelMarVa (8802) talkgroup, primarily for coordination across the region during EmComm scenarios, which is only carried on cBridges currently.

For policy reasons, 8802 will not be carried by BM.

The repeater is operational, barring some issues with the duplexer.  It's connected to BM currently, and operating as the owner and trustee wish it to, although lacking the 8802 talkgroup.

Existing configuration:

I think that with the advent of ACLs, I can insert a DVSwitch suite in between the XPR8400 and the BM3102 server.  I can use the ACLs to deny 8802 from going to BM3102, and also to permit only 8802 on TS1 going to/from K4USD.

Proposed configuration:


In this proposal, the IPSC_Bridge <-> BM3102 link would be using the N4TIK DMR ID # 310328, so would look the same as the existing repeater.

Does anyone see anything wrong with this approach?

Yes, I know BM supports HB directly, but I don't know what's involved with changing from the current IPSC connection to an HB connection, ie will BM even care? Is it a different port?  For that matter, I don't *know* that the IPSC_Bridge <->BM3102 link will function correctly.   Any advice on this point is very welcome.

Thanks in advance,
Jim

PS, hooray for ACLs!

On Nov 23, 2018, at 7:14 AM, Jim Gifford - KD4PPG <jim@...> wrote:

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG



Re: Link DMR <==> FCSXXX

Steve N4IRS
 

Bruno,
We need to see your MMDVM_Bridge.ini and DVSwitch.ini It would also help to see the log when MMDVM_Bridge is running and the transmission occurs.

Steve N4IRS

On 12/4/18 4:37 PM, Bruno wrote:
Hi,
it works between the FCS001 33 and the DMR BM. On the other hand at the level of the PI-Star or OpenSpot2 the callback that goes back to the level of traffic and still N4IRR ???
I do not know why ??
 
73's
F1PTL Bruno

7361 - 7380 of 9891