Date   

Re: Connect Fusion repeater to DMR

Paul Nannery KC2VRJ
 

The nice thing with the dr 1x is it is easy to keep analog with the digital modes. But yes it is a dumb repeater


On Sun, Jun 10, 2018, 12:02 PM Chris via Groups.Io <chood73=yahoo.com@groups.io> wrote:
I finally figured it out. The DR1X is just ridiculously dumb and can't connect to anything. You have to use their Yaesu box to even connect to the WiresX rooms and then it's only over RF.

I see what you were saying, you basically install an MMDVM modem on the repeater and let it do the C4FM work. Essentially using the DR1X as a pair of radios. At that point why even use a DR1X? It's a garbage "repeater" anyway.

I am going to talk to the club and see if they just want to put a real repeater up there in place of that thing, since we will need to use a MMDVM modem anyway. At least then, it will have a real front-end on it.

That or they can just let it sit there and talk to itself. lol

Chris
WB4ULK


Turn on logging and view logs ASL

Chris WB4ULK
 

Could someone point me in the right direction as to turning on all the logging that I can in ASL and where to view those logs.
I have a weird little issue cropping up in my DMR to ASL bridge and would like to be able to chase it down.

Chris
WB4ULK


Re: Connect Fusion repeater to DMR

Chris WB4ULK
 

I finally figured it out. The DR1X is just ridiculously dumb and can't connect to anything. You have to use their Yaesu box to even connect to the WiresX rooms and then it's only over RF.

I see what you were saying, you basically install an MMDVM modem on the repeater and let it do the C4FM work. Essentially using the DR1X as a pair of radios. At that point why even use a DR1X? It's a garbage "repeater" anyway.

I am going to talk to the club and see if they just want to put a real repeater up there in place of that thing, since we will need to use a MMDVM modem anyway. At least then, it will have a real front-end on it.

That or they can just let it sit there and talk to itself. lol

Chris
WB4ULK


Re: How to configure a ASL server

Steve N4IRS
 

José,
The point I'm trying to make is that in AllStarLink each node has a node stanza. Within that stanza there is a rxchannel. Each node can have only one rxchannel. At the top of the sample rpt.conf you have a list of the more common ones.

; rxchannel = dahdi/pseudo                        ; No radio (hub)
; rxchannel = SimpleUSB/usb_1999        ; SimpleUSB 
; rxchannel = Pi/1                                           ; Raspberry Pi PiTA 
; rxchannel = Radio/usb_1999       ; USBRadio (DSP) 
; rxchannel = Dahdi/1               ; PCI Quad card 
; rxchannel = Beagle/1                      ; BeagleBoard 
; rxchannel = USRP/127.0.0.1:34001:32001; GNU Radio interface USRP

An ASL server can host more then one node. In the case of Echolink it does not have a rxchannel of it's own. Echolink connects or attaches to a existing node. this is done with the "astnode = 1999" in echolink.cfg
You can build a ASL server with multiple types of nodes. But Echolink can only attach to one node. The node it connects to can be connected to other nodes.

There really is no right way or wrong way to build this other then one node can only have one rxchannel.

The way I build my servers is to assign a node to each type of node. That can be a hub, echolink, usrp etc. By separating everything, I can control how things are connected. for example:
2100 = a hub
1999 = echolink
1998 = DMR
1997 = P25

Nodes 2100 and 1999 use the dahdi/pseudo channel driver
Nodes 1998 and 1997 use the USRP channel driver

Since 2100 is a public node, any AllStarLink node can connect to it You can connect any or all of the other nodes to 2100. You could also decide to connect P25 to Echolink, connect DMR to ASL.
Again, there is no right way and wrong way to build this other then the one rxchannel per node rule.

Hope this helps

Steve

  
 


Re: How to configure a ASL server

TG9AOR
 

Steve:


Here is my echolink.conf
[el0]
call = TG9AOR                           ; Change this!
pwd = 5up3rt1tt4                        ; Change this!
name = BM DMR TG70406                   ; Change this!
qth = Guatemala                         ; Change this!
email = qrz@...                  ; Change this!
node = 540574                           ; Change this!
; Data for EchoLink Status Page
lat = 14.528                            ; Latitude in decimal degrees
lon = -90.454                           ; Longitude in decimal degrees
freq = 0.0                              ; not mandatory Frequency in MHz
tone = 0.0                              ; not mandatory CTCSS Tone (0 for none)
power = 0                               ; 0=0W, 1=1W, 2=4W, 3=9W, 4=16W, 5=25W, 6=36W, 7=49W, 8=64W, 9=81W (Power in Watts)
height = 0                              ; 0=10 1=20 2=40 3=80 4=160 5=320 6=640 7=1280 8=2560 9=5120 (AMSL in Feet)
gain = 0                                ; Gain in db (0-9)
dir = 0                                 ; 0=omni 1=45deg 2=90deg 3=135deg 4=180deg 5=225deg 6=270deg 7=315deg 8=360deg (Direction)
maxstns = 2                             ; Max Stations
rtcptimeout = 10                        ; Max number of missed heartbeats from EL
recfile = /tmp/echolink_recorded.gsm    ;
astnode = 48270                         ; Change this!
context = radio-secure                  ; Default in code is echolink-in
; Max 3 servers
server1 = nasouth.echolink.org
server2 = naeast.echolink.org
server3 = server3.echolink.org
; To deny w6xxx you would add the statement: deny = w6xxx
; To prohibit computer-based connections you would write: permit = *-*
; To allow access to only a select group of callsigns: permit = w6abc,w6def,...
permit = KB2YMD-L,TG9AOR-L,KB2YMD                               ; comma delimited list of callsign, type (-r)
; deny

; Remote text commands thru netcat:
; o.conip <IPaddress>    (request a connect)  ===============>I have tried this by issuing nc -u 127.0.0.1 32767 and then at the prompt issuing the o.conip xxx.xxx.xx.xxx but I do not get a reply or NAK and Echolink does not connect to the IP requested. What is the proper command syntax for this? Thanks.
; o.dconip <IPaddress>   (request a disconnect)
; o.rec                  (turn on/off recording)
ipaddr = 127.0.0.1
port = 32767
#includeifexists custom/echolink.conf

--
José Roberto Ruíz García Salas
TG9AOR


Re: "Blocked" Message on Brandmeister

Steve N4IRS
 

Well,
Then I don't know what to tell ya.

On 06/09/2018 07:33 PM, Mike Swiatkowski via Groups.Io wrote:
Not that I know of....


Re: "Blocked" Message on Brandmeister

Mike, AA9VI
 

Not that I know of....


ASL (or DMR) to YSF #brandmeister

Jon KM8V
 

Hi there. The DMR <-> ASL gateway is running great.

I'm reading https://dvswitch.groups.io/g/main/wiki/Bridge-DMR-to-YSF-Narrow and wondering if it's possible to easily add a connection from ASL -> a YSF reflector, and if so, does it require a dongle or can it be done completely in software?

Thanks & 73 de KM8V


Re: How to configure a ASL server

TG9AOR
 

On Fri, Jun 8, 2018 at 07:48 pm, Steve N4IRS wrote:
José, The 1999 stanza is the private node that us used to connect Analog_Bridge to AllStarLink. It does not have to be 1999, nor for that matter does it have to be a private node. If for example you have a public node [2222] rxchannel = Radio/usb0 ; Assuming a radio connected via a USB radio interface
I requested and used my node for the echolink connection (48270), it works, it connects immediately upon starting the asterisk service.
And you have a echolink connection (echolink.conf) [el0] node = 3215555 ; The EL node number astnode = 2222 ; Connect EL to node 2222 When someone on EL connects to 3215555 they are on ASL 2222
My node is 540570(EL). Does my ASL Node accept connections from other ASL nodes? Will they in turn go out on my EL connection?

Now you want to ADD a node for Analog_Bridge. [1999] rxchannel = USRP/127.0.0.1:34001:32001; GNU Radio interface USRP
This is under 48270(the [1999] rxchannel = USRP, and it is using the USRP channel driver. I set up 48270 as a hub(no radio)
Make sense?
I interpreted the 1999 is the ON/OFF switch that will allow DMR to enter the Allstar network or viceversa, and you activate it with the AllStar CLI.

Thanks.

 

This is the first draft of the ASL <-> DMR how to document.
<https://docs.google.com/document/d/1eN50Csr29eAprBu7eKA0Bfa2XUcsXw5iktY1Ey-Qjkg/edit?usp=sharing>

73, Steve N4IRS


On 06/08/2018 10:06 PM, TG9AOR wrote:
Excellent document. Thank you so much. As you may or may not recall, I followed Kv4S's how to guide, it in turn made reference to another how to guide on setting up the allstar node. It differs somewhat when looking into the manual setup section.Now, considering that I have echolink connected on that allstar node, do I still need to insert the 1999 stanza into de rpt.conf? 

73
--
José Roberto Ruíz García Salas
TG9AOR

 On Fri, Jun 8, 2018 at 07:48 pm, Steve N4IRS wrote:
José,
The 1999 stanza is the private node that us used to connect Analog_Bridge to AllStarLink. It does not have to be 1999, nor for that matter does it have to be a private node.
If for example you have a public node
[2222]
rxchannel = Radio/usb0 ; Assuming a radio connected via a USB radio interface

And you have a echolink connection (echolink.conf)
[el0]
node = 3215555 ; The EL node number
astnode = 2222 ; Connect EL to node 2222

When someone on EL connects to 3215555 they are on ASL 2222

Now you want to ADD a node for Analog_Bridge.
[1999]
rxchannel = USRP/127.0.0.1:34001:32001; GNU Radio interface USRP

Make sense?

This is the first draft of the ASL <-> DMR how to document.
<https://docs.google.com/document/d/1eN50Csr29eAprBu7eKA0Bfa2XUcsXw5iktY1Ey-Qjkg/edit?usp=sharing>

73, Steve N4IRS


On 06/08/2018 10:06 PM, TG9AOR wrote:
Excellent document. Thank you so much. As you may or may not recall, I followed Kv4S's how to guide, it in turn made reference to another how to guide on setting up the allstar node. It differs somewhat when looking into the manual setup section.Now, considering that I have echolink connected on that allstar node, do I still need to insert the 1999 stanza into de rpt.conf? 

73
--
José Roberto Ruíz García Salas
TG9AOR

 
--
José Roberto Ruíz García Salas
TG9AOR


Re: Repeater ID can not be the same as subscriber ID

Chris Andrist, KC7WSU
 

Looks like I forgot to tell Analog_Bridge which ini to look at. All is working now.

Regards,

Chris Andrist, KC7WSU
DMR-UTAH

On Jun 8, 2018, at 9:19 PM, Steve N4IRS <szingman@...> wrote:

Chris,
I just pasted your AMBE_AUDIO stanza into a test Analog_Bridge.ini I did not get the error. Could you please post the complete startup from Analog_bridge.

Thanks, Steve

On 06/08/2018 11:08 PM, Chris Andrist, KC7WSU wrote:

I: 2018-06-09 03:08:10.164 Analog Bridge Version 1.1 Wed May 30 09:44:39 EDT 2018
I: 2018-06-09 03:08:10.164 Copyright (C) 2018 DVSwitch, INAD.
I: 2018-06-09 03:08:10.164 Created by Mike N4IRR and Steve N4IRS
I: 2018-06-09 03:08:10.164 Analog Bridge comes with ABSOLUTELY NO WARRANTY
I: 2018-06-09 03:08:10.164
I: 2018-06-09 03:08:10.164 This software is for use on amateur radio networks only,
I: 2018-06-09 03:08:10.164 it is to be used for educational purposes only. Its use on
I: 2018-06-09 03:08:10.164 commercial networks is strictly prohibited.
I: 2018-06-09 03:08:10.164
I: 2018-06-09 03:08:10.164 Analog Bridge is starting
F: 2018-06-09 03:08:10.165 Repeater ID can not be the same as subscriber ID




Here is the info from my Analog_Bridge.ini

; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC)
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 31000                     ; AMBE frames from xx_Bridge (should match "toGatewayPor$
toDMRPort = 31003                       ; AMBE frames from xx_Bridge (should match "fromGatewayP$
ambeMode = DMR                          ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 3149010                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 314905                     ; ID of source repeater
txTg = 31490                            ; TG to use for all frames received from Analog_Bridge -$
txTs = 1                                ; Slot to use for frames received from Analog_Bridge -> $
colorCode = 1                           ; Color Code to assign DMR frames


gatewayDmrId and repeaterID are not the same, not sure why I am getting this.

Regards,

Chris Andrist, KC7WSU
DMR-UTAH


Re: Repeater ID can not be the same as subscriber ID

Steve N4IRS
 

Chris,
I just pasted your AMBE_AUDIO stanza into a test Analog_Bridge.ini I did not get the error. Could you please post the complete startup from Analog_bridge.

Thanks, Steve

On 06/08/2018 11:08 PM, Chris Andrist, KC7WSU wrote:

I: 2018-06-09 03:08:10.164 Analog Bridge Version 1.1 Wed May 30 09:44:39 EDT 2018
I: 2018-06-09 03:08:10.164 Copyright (C) 2018 DVSwitch, INAD.
I: 2018-06-09 03:08:10.164 Created by Mike N4IRR and Steve N4IRS
I: 2018-06-09 03:08:10.164 Analog Bridge comes with ABSOLUTELY NO WARRANTY
I: 2018-06-09 03:08:10.164
I: 2018-06-09 03:08:10.164 This software is for use on amateur radio networks only,
I: 2018-06-09 03:08:10.164 it is to be used for educational purposes only. Its use on
I: 2018-06-09 03:08:10.164 commercial networks is strictly prohibited.
I: 2018-06-09 03:08:10.164
I: 2018-06-09 03:08:10.164 Analog Bridge is starting
F: 2018-06-09 03:08:10.165 Repeater ID can not be the same as subscriber ID




Here is the info from my Analog_Bridge.ini

; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC)
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 31000                     ; AMBE frames from xx_Bridge (should match "toGatewayPor$
toDMRPort = 31003                       ; AMBE frames from xx_Bridge (should match "fromGatewayP$
ambeMode = DMR                          ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 3149010                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 314905                     ; ID of source repeater
txTg = 31490                            ; TG to use for all frames received from Analog_Bridge -$
txTs = 1                                ; Slot to use for frames received from Analog_Bridge -> $
colorCode = 1                           ; Color Code to assign DMR frames


gatewayDmrId and repeaterID are not the same, not sure why I am getting this.

Regards,

Chris Andrist, KC7WSU
DMR-UTAH


Repeater ID can not be the same as subscriber ID

Chris Andrist, KC7WSU
 


I: 2018-06-09 03:08:10.164 Analog Bridge Version 1.1 Wed May 30 09:44:39 EDT 2018
I: 2018-06-09 03:08:10.164 Copyright (C) 2018 DVSwitch, INAD.
I: 2018-06-09 03:08:10.164 Created by Mike N4IRR and Steve N4IRS
I: 2018-06-09 03:08:10.164 Analog Bridge comes with ABSOLUTELY NO WARRANTY
I: 2018-06-09 03:08:10.164
I: 2018-06-09 03:08:10.164 This software is for use on amateur radio networks only,
I: 2018-06-09 03:08:10.164 it is to be used for educational purposes only. Its use on
I: 2018-06-09 03:08:10.164 commercial networks is strictly prohibited.
I: 2018-06-09 03:08:10.164
I: 2018-06-09 03:08:10.164 Analog Bridge is starting
F: 2018-06-09 03:08:10.165 Repeater ID can not be the same as subscriber ID




Here is the info from my Analog_Bridge.ini

; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC)
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 31000                     ; AMBE frames from xx_Bridge (should match "toGatewayPor$
toDMRPort = 31003                       ; AMBE frames from xx_Bridge (should match "fromGatewayP$
ambeMode = DMR                          ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 3149010                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 314905                     ; ID of source repeater
txTg = 31490                            ; TG to use for all frames received from Analog_Bridge -$
txTs = 1                                ; Slot to use for frames received from Analog_Bridge -> $
colorCode = 1                           ; Color Code to assign DMR frames


gatewayDmrId and repeaterID are not the same, not sure why I am getting this.

Regards,

Chris Andrist, KC7WSU
DMR-UTAH


Re: How to configure a ASL server

Steve N4IRS
 

José,
The 1999 stanza is the private node that us used to connect Analog_Bridge to AllStarLink. It does not have to be 1999, nor for that matter does it have to be a private node.
If for example you have a public node
[2222]
rxchannel = Radio/usb0 ; Assuming a radio connected via a USB radio interface

And you have a echolink connection (echolink.conf)
[el0]
node = 3215555 ; The EL node number
astnode = 2222 ; Connect EL to node 2222

When someone on EL connects to 3215555 they are on ASL 2222

Now you want to ADD a node for Analog_Bridge.
[1999]
rxchannel = USRP/127.0.0.1:34001:32001; GNU Radio interface USRP

Make sense?

This is the first draft of the ASL <-> DMR how to document.
<https://docs.google.com/document/d/1eN50Csr29eAprBu7eKA0Bfa2XUcsXw5iktY1Ey-Qjkg/edit?usp=sharing>

73, Steve N4IRS


On 06/08/2018 10:06 PM, TG9AOR wrote:
Excellent document. Thank you so much. As you may or may not recall, I followed Kv4S's how to guide, it in turn made reference to another how to guide on setting up the allstar node. It differs somewhat when looking into the manual setup section.Now, considering that I have echolink connected on that allstar node, do I still need to insert the 1999 stanza into de rpt.conf? 

73
--
José Roberto Ruíz García Salas
TG9AOR


Re: How to configure a ASL server

TG9AOR
 

I am able to see more detailed explanation on the section "Transcode one digital format to another", I believe you are referring to this? It is very helpful. 
--
José Roberto Ruíz García Salas
TG9AOR


How to configure a ASL server

TG9AOR
 

Excellent document. Thank you so much. As you may or may not recall, I followed Kv4S's how to guide, it in turn made reference to another how to guide on setting up the allstar node. It differs somewhat when looking into the manual setup section.Now, considering that I have echolink connected on that allstar node, do I still need to insert the 1999 stanza into de rpt.conf? 

73
--
José Roberto Ruíz García Salas
TG9AOR


Network Watchdog cutting off feed to YSFReflector

TG9AOR
 

I noticed that sporadically my DMR transmissions on TG704 would not make it 100% into YSFreflector. Log output below:

I: 2018-06-09 00:36:31.144 YSF, Narrow transmit (72 bit)
M: 2018-06-09 00:37:16.444 DMR Slot 2, received network end of voice transmission, 45.5 seconds, 0% packet loss, BER: 0.0%
M: 2018-06-09 00:37:16.444 YSF, TX state = OFF
M: 2018-06-09 00:37:20.323 DMR Slot 2, received network voice header from HK4CZE to TG 704
M: 2018-06-09 00:37:20.323 YSF, TX state = ON
I: 2018-06-09 00:37:20.324 YSF, Begin TX: src=7320002 rpt=0 dst=704 slot=2 cc=0 metadata=HK4CZE

I: 2018-06-09 00:37:20.690 YSF, Narrow transmit (72 bit)
M: 2018-06-09 00:37:22.237 DMR Slot 2, network watchdog has expired, 1.3 seconds, 81% packet loss, BER: 0.0%
E: 2018-06-09 00:38:11.082 DMR, Connection to the master has timed out, retrying connection
M: 2018-06-09 00:38:11.082 DMR, Closing DMR Network
M: 2018-06-09 00:38:11.082 DMR, Opening DMR Network
M: 2018-06-09 00:38:21.334 DMR, Logged into the master successfully
M: 2018-06-09 00:38:30.490 DMR Slot 2, received network voice header from HK4CZE to TG 704
M: 2018-06-09 00:38:30.490 YSF, TX state = ON
I: 2018-06-09 00:38:30.490 YSF, Begin TX: src=7320002 rpt=0 dst=704 slot=2 cc=0 metadata=HK4CZE

I: 2018-06-09 00:38:30.786 YSF, Narrow transmit (72 bit)
M: 2018-06-09 00:38:31.246 DMR Talker Alias (Data Format 1, Received 6/8 char): 'HK4CZE'
M: 2018-06-09 00:38:31.835 DMR Talker Alias (Data Format 1, Received 8/8 char): 'HK4CZE  '
M: 2018-06-09 00:39:32.360 DMR Slot 2, network watchdog has expired, 61.7 seconds, 1% packet loss, BER: 0.0%
M: 2018-06-09 00:39:32.402 YSF, received network data from TG0AA      to ALL        at TG0AA
I: 2018-06-09 00:39:32.402 YSF, Lookup call TG0AA returned id 7040018 -> 7040018
M: 2018-06-09 00:39:32.407 DMR, TX state = ON
I: 2018-06-09 00:39:32.407 DMR, Begin TX: src=7040018 rpt=0 dst=704 slot=2 cc=0 metadata=TG0AA
M: 2018-06-09 00:39:35.605 YSF, network watchdog has expired, 1.8 seconds, 0% packet loss, BER: 7.9%
M: 2018-06-09 00:39:35.605 DMR, TX state = OFF
E: 2018-06-09 00:40:21.427 DMR, Connection to the master has timed out, retrying connection
M: 2018-06-09 00:40:21.427 DMR, Closing DMR Network
M: 2018-06-09 00:40:21.427 DMR, Opening DMR Network
M: 2018-06-09 00:40:31.687 DMR, Logged into the master successfully
 
 
Data center is located in Seattle, WA. xlxd interlink to XLX502 does not have any issues, XLX502 located in Guatemala.
 
How do I get Mr. watchdog in control?
 
 
73 de TG9AOR

--
José Roberto Ruíz García Salas
TG9AOR


Re: New member, few questions regarding hblink/hb_bridge/hb_confbridge

Corey Dean N3FE <n3fe@...>
 

If you have each client have a different connection setup you could use conf bridge and manage this quite easily.


On Jun 8, 2018, at 3:14 PM, Colby Ross W1BSB <colbypr@...> wrote:

That's what I thought. Thanks Steve. So at this time if repeat were off there would be no way to define a list of talk groups that would be repeated to other clients which was kind of what I thought. 

Colby

On Fri, Jun 8, 2018, 15:12 Steve N4IRS <szingman@...> wrote:
If two clients are connected to the same Master and repeat is turned on, all traffic will pass between the two clients.
If two clients are connected to different Master and repeat is turned on, only the TGs defined in hb_confbridge will pass between the two clients.




On 6/8/2018 2:28 PM, Colby Ross W1BSB wrote:
There is not. I didn't want every talk group being repeated, only ones that were defined.

Colby


Re: "Blocked" Message on Brandmeister

Steve N4IRS
 

I: 2018-06-08 19:08:24.977 DMR Network Parameters
I: 2018-06-08 19:08:24.977     Address: 104.236.174.109
I: 2018-06-08 19:08:24.977     Port: 55555
I: 2018-06-08 19:08:24.977     Local: 62032
I: 2018-06-08 19:08:24.977     Jitter: 360ms
I: 2018-06-08 19:08:24.977     Slot 1: disabled
I: 2018-06-08 19:08:24.977     Slot 2: enabled
I: 2018-06-08 19:08:24.977     Mode Hang: 3s
I: 2018-06-08 19:08:24.977     Options: StartRef=4649;RelinkTime=0;UserLink=1
I: 2018-06-08 19:08:24.977 Info Parameters
I: 2018-06-08 19:08:24.978     Callsign: N4IRS
I: 2018-06-08 19:08:24.978     RX Frequency: 222340000Hz
I: 2018-06-08 19:08:24.978     TX Frequency: 224940000Hz
I: 2018-06-08 19:08:24.978     Power: 1W
I: 2018-06-08 19:08:24.978     Latitude: 41.733299deg N
I: 2018-06-08 19:08:24.978     Longitude: -50.399899deg E
I: 2018-06-08 19:08:24.978     Height: 0m
I: 2018-06-08 19:08:24.978     Location: "Iceberg, North Atlantic"
I: 2018-06-08 19:08:24.978     Description: "MMDVM_Bridge"
I: 2018-06-08 19:08:24.978     URL: "https://groups.io/g/DVSwitch"
M: 2018-06-08 19:08:24.978 DMR, Opening DMR Network
I: 2018-06-08 19:08:24.978 RSSI
I: 2018-06-08 19:08:24.978     Mapping File: RSSI.dat
W: 2018-06-08 19:08:24.978 Cannot open the RSSI data file - RSSI.dat
I: 2018-06-08 19:08:24.978 DMR Id Lookups
I: 2018-06-08 19:08:24.978     File: /var/lib/mmdvm/DMRIds.dat
I: 2018-06-08 19:08:24.978     Reload: 24 hours
I: 2018-06-08 19:08:25.062 Loaded 57133 Ids to the DMR callsign lookup table
I: 2018-06-08 19:08:25.062 DMR RF Parameters
I: 2018-06-08 19:08:25.062 Started the DMR Id lookup reload thread
I: 2018-06-08 19:08:25.062     Id: 3112138
I: 2018-06-08 19:08:25.062     Color Code: 1
I: 2018-06-08 19:08:25.062     Self Only: no
I: 2018-06-08 19:08:25.062     Embedded LC Only: yes
I: 2018-06-08 19:08:25.062     Dump Talker Alias Data: no
I: 2018-06-08 19:08:25.062     Prefixes: 0
I: 2018-06-08 19:08:25.062     Call Hang: 3s
I: 2018-06-08 19:08:25.063     TX Hang: 3s
I: 2018-06-08 19:08:25.063     Mode Hang: 10s
M: 2018-06-08 19:08:25.063 DMR, Opening INI file: DVSwitch.ini
M: 2018-06-08 19:08:25.063 DMR, Setting [DMR] Address -> 127.0.0.1
M: 2018-06-08 19:08:25.063 DMR, Setting [DMR] TXPort -> 31100
M: 2018-06-08 19:08:25.063 DMR, Setting [DMR] RXPort -> 31103
M: 2018-06-08 19:08:25.063 DMR, Setting [DMR] Slot -> 1
M: 2018-06-08 19:08:25.063 DMR, Transmitting on 127.0.0.1:31100 and listening on port 31103.  Result = 1
M: 2018-06-08 19:08:25.063 MMDVM_Bridge-20180526 is running
D: 2018-06-08 19:08:35.153 DMR, Sending authorisation
D: 2018-06-08 19:08:35.245 DMR, Sending configuration
D: 2018-06-08 19:08:35.337 DMR, Sending options
M: 2018-06-08 19:08:35.429 DMR, Logged into the master successfully
M: 2018-06-08 19:09:26.536 DMR Slot 2, received network voice header from 4649 to TG 9
M: 2018-06-08 19:09:33.274 DMR Slot 2, received network end of voice transmission, 6.6 seconds, 0% packet loss, BER: 0.0%
M: 2018-06-08 19:23:50.143 DMR Slot 2, received network late entry from WB9PZM to TG 9
D: 2018-06-08 19:23:51.145 DMR Slot 2, lost audio for 408ms filling in
D: 2018-06-08 19:23:51.553 DMR Slot 2, lost audio for 408ms filling in
D: 2018-06-08 19:23:51.962 DMR Slot 2, lost audio for 409ms filling in
M: 2018-06-08 19:23:52.237 DMR Slot 2, network watchdog has expired, 2.2 seconds, 50% packet loss, BER: 0.0%

As you can see, I connected to the Master at 19:08Z and the last traffic I saw was at 19:23Z As of right now, (19:51Z) I'm still connected. I think there may be a keep alive being missed. Are there any firewall rules involved?

73, Steve N4IRS

On 6/8/2018 3:03 PM, Mike Swiatkowski via Groups.Io wrote:
attached...


Re: New member, few questions regarding hblink/hb_bridge/hb_confbridge

Colby Ross W1BSB <colbypr@...>
 

In my testing with repeat off even if using the bridged talkgroup the other clients on the same master don't hear it which is what I was looking for. Thanks again for the help. 

Cokby

On Fri, Jun 8, 2018, 15:16 Steve N4IRS <szingman@...> wrote:
repeat only controls traffic passing within a Master. It does not effect traffic passing through the conf_bridge. At least I think so.

On 6/8/2018 3:14 PM, Colby Ross W1BSB wrote:
That's what I thought. Thanks Steve. So at this time if repeat were off there would be no way to define a list of talk groups that would be repeated to other clients which was kind of what I thought. 

Colby

On Fri, Jun 8, 2018, 15:12 Steve N4IRS <szingman@...> wrote:
If two clients are connected to the same Master and repeat is turned on, all traffic will pass between the two clients.
If two clients are connected to different Master and repeat is turned on, only the TGs defined in hb_confbridge will pass between the two clients.




On 6/8/2018 2:28 PM, Colby Ross W1BSB wrote:
There is not. I didn't want every talk group being repeated, only ones that were defined.

Colby



Re: New member, few questions regarding hblink/hb_bridge/hb_confbridge

Steve N4IRS
 

repeat only controls traffic passing within a Master. It does not effect traffic passing through the conf_bridge. At least I think so.

On 6/8/2018 3:14 PM, Colby Ross W1BSB wrote:
That's what I thought. Thanks Steve. So at this time if repeat were off there would be no way to define a list of talk groups that would be repeated to other clients which was kind of what I thought. 

Colby

On Fri, Jun 8, 2018, 15:12 Steve N4IRS <szingman@...> wrote:
If two clients are connected to the same Master and repeat is turned on, all traffic will pass between the two clients.
If two clients are connected to different Master and repeat is turned on, only the TGs defined in hb_confbridge will pass between the two clients.




On 6/8/2018 2:28 PM, Colby Ross W1BSB wrote:
There is not. I didn't want every talk group being repeated, only ones that were defined.

Colby


8221 - 8240 of 9795