Date   

Re: DVSwitch Server Raspberry Pi Image

Jay
 

Steve, and All

Thanks so much for doing this.  I have been building Pi Images for DVSwitch from the beginning and I cannot count the number of times I have built images from scratch.  I realize that I could get to a certain point and save the image, but i am always worried that I do not the latest of something, especially INI files.  This is a huge step forward in my mind.

That does bring up a question.  The binaries are quite easy to keep up to date.  Is there a method to keep  INI files current without losing existing entries.  I have never found one but over time the "stanzas" have changed and some keywords.

I enjoyed the video and keep them coming.  This is what Ham Radio is all about.

--

jb   N4NQY


Re: 2 ysf2ysf mmdvm_bridge issue with dmr2ysf

Steve N4IRS
 

To troubleshoot this, you will need to run MB in the foreground. You will capture the live data when the crash happens.

Steve N4IRS

On 10/27/20 10:19 PM, Sylvain ve2tbu wrote:
hi All. im running 2 mbridge to link 2 different ysf reflector.working with fusion working good dn and vw without issue, i try with my dmr with openspot.. openspot dmr to ysf. it working only in 1 side. the mb1 working in my own refl is ok but accross the mb1 to mb2 the  mb2 crash and restart.I try many thing  tg change for tg 9 dmr id nothing change. i seen in my log the error message and i can see from mb1 dmr id 3022260 mb2 show 302226 so they miss something.
hers the log issue and i try to connect from dmr2ysf from ysfref1 mb2 crash i connect to ysfref2 mb1 crash so its the same issue on both side .

This software is for use on amateur radio networks only,
I: 2020-10-28 01:56:47.010 it is to be used for educational purposes only. Its use on
I: 2020-10-28 01:56:47.010 commercial networks is strictly prohibited.
I: 2020-10-28 01:56:47.010 Copyright(C) 2015-2018 by Jonathan Naylor, G4KLX and others
M: 2020-10-28 01:56:47.010 MMDVM_Bridge-20200727_V1.5.9 is starting
M: 2020-10-28 01:56:47.010 Built 16:22:31 Oct 23 2020 (GitID #0ea07ac)
I: 2020-10-28 01:56:47.010 General Parameters
I: 2020-10-28 01:56:47.010     Callsign: VA2TB
I: 2020-10-28 01:56:47.010     Id: 302252
I: 2020-10-28 01:56:47.010     Duplex: no
I: 2020-10-28 01:56:47.010     Timeout: 180s
I: 2020-10-28 01:56:47.010     D-Star: disabled
I: 2020-10-28 01:56:47.010     DMR: disabled
I: 2020-10-28 01:56:47.010     YSF: enabled
I: 2020-10-28 01:56:47.010     P25: disabled
I: 2020-10-28 01:56:47.010     NXDN: disabled
I: 2020-10-28 01:56:47.010 Modem Parameters
I: 2020-10-28 01:56:47.010     Port: /dev/null
I: 2020-10-28 01:56:47.010     RX Invert: no
I: 2020-10-28 01:56:47.010     TX Invert: no
I: 2020-10-28 01:56:47.010     PTT Invert: no
I: 2020-10-28 01:56:47.010     TX Delay: 100ms
I: 2020-10-28 01:56:47.010     RX Offset: 0Hz
I: 2020-10-28 01:56:47.010     TX Offset: 0Hz
I: 2020-10-28 01:56:47.010     RX DC Offset: 0
I: 2020-10-28 01:56:47.010     TX DC Offset: 0
I: 2020-10-28 01:56:47.010     RF Level: 100.0%
I: 2020-10-28 01:56:47.010     DMR Delay: 0 (0.0ms)
I: 2020-10-28 01:56:47.010     RX Level: 50.0%
I: 2020-10-28 01:56:47.010     CW Id TX Level: 50.0%
I: 2020-10-28 01:56:47.010     D-Star TX Level: 50.0%
I: 2020-10-28 01:56:47.010     DMR TX Level: 50.0%
I: 2020-10-28 01:56:47.010     YSF TX Level: 50.0%
I: 2020-10-28 01:56:47.010     P25 TX Level: 50.0%
I: 2020-10-28 01:56:47.010     NXDN TX Level: 50.0%
I: 2020-10-28 01:56:47.010     RX Frequency: 0Hz (0Hz)
I: 2020-10-28 01:56:47.010     TX Frequency: 0Hz (0Hz)
M: 2020-10-28 01:56:47.010 Opening the MMDVM
I: 2020-10-28 01:56:47.010 Display Parameters
I: 2020-10-28 01:56:47.010     Type:
I: 2020-10-28 01:56:47.010 System Fusion Network Parameters
I: 2020-10-28 01:56:47.010     Local Address: 0
I: 2020-10-28 01:56:47.010     Local Port: 42200
I: 2020-10-28 01:56:47.010     Gateway Address: 151.80.143.185
I: 2020-10-28 01:56:47.010     Gateway Port: 42002
I: 2020-10-28 01:56:47.010     Mode Hang: 3s
M: 2020-10-28 01:56:47.010 Opening YSF network connection
I: 2020-10-28 01:56:47.014 RSSI
I: 2020-10-28 01:56:47.014     Mapping File: /dev/null
I: 2020-10-28 01:56:47.014 Loaded 0 RSSI data mapping points from /dev/null
I: 2020-10-28 01:56:47.014 DMR Id Lookups
I: 2020-10-28 01:56:47.014     File: /opt/DMRIds.dat
I: 2020-10-28 01:56:47.014     Reload: 24 hours
I: 2020-10-28 01:56:47.142 Loaded 89800 Ids to the DMR callsign lookup table
I: 2020-10-28 01:56:47.145 YSF RF Parameters
I: 2020-10-28 01:56:47.145     Low Deviation: no
I: 2020-10-28 01:56:47.145     Remote Gateway: no
I: 2020-10-28 01:56:47.145     Self Only: no
I: 2020-10-28 01:56:47.145     DSQ: no
I: 2020-10-28 01:56:47.145     Mode Hang: 10s
M: 2020-10-28 01:56:47.145 YSF, Opening INI file: DVSwitch.ini
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] address -> 127.0.0.1
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] txPort -> 42500
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] rxPort -> 43500
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] txWidePort -> 42500
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] fallbackID -> 1234567
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] exportTG -> 9
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] slot -> 2
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] RemotePort -> 6073
M: 2020-10-28 01:56:47.145 YSF, Transmitting on 127.0.0.1:42500, and listening on port 43500.  Result = 1
M: 2020-10-28 01:56:47.145 MMDVM_Bridge-20200727_V1.5.9 is running
I: 2020-10-28 01:56:47.145 Started the DMR Id lookup reload thread
M: 2020-10-28 01:56:58.969 YSF, TX state = ON
I: 2020-10-28 01:56:58.969 YSF, Begin TX: src=1234567 rpt=0 dst=9 slot=2 cc=0 metadata=302226
M: 2020-10-28 01:56:58.969 YSF, No call or id found, using ini value: VA2TB     HH&
I: 2020-10-28 01:56:59.326 YSF, Narrow transmit (72 bit)
I: 2020-10-28 01:57:02.865 MMDVM_Bridge:
I: 2020-10-28 01:57:02.865 Portions Copyright (C) 2018, 2019, 2020 DVSwitch, INAD.
I: 2020-10-28 01:57:02.865 Hacks by Mike N4IRR and Steve N4IRS
I: 2020-10-28 01:57:02.865 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


2 ysf2ysf mmdvm_bridge issue with dmr2ysf

 

hi All. im running 2 mbridge to link 2 different ysf reflector.working with fusion working good dn and vw without issue, i try with my dmr with openspot.. openspot dmr to ysf. it working only in 1 side. the mb1 working in my own refl is ok but accross the mb1 to mb2 the  mb2 crash and restart.I try many thing  tg change for tg 9 dmr id nothing change. i seen in my log the error message and i can see from mb1 dmr id 3022260 mb2 show 302226 so they miss something.
hers the log issue and i try to connect from dmr2ysf from ysfref1 mb2 crash i connect to ysfref2 mb1 crash so its the same issue on both side .

This software is for use on amateur radio networks only,
I: 2020-10-28 01:56:47.010 it is to be used for educational purposes only. Its use on
I: 2020-10-28 01:56:47.010 commercial networks is strictly prohibited.
I: 2020-10-28 01:56:47.010 Copyright(C) 2015-2018 by Jonathan Naylor, G4KLX and others
M: 2020-10-28 01:56:47.010 MMDVM_Bridge-20200727_V1.5.9 is starting
M: 2020-10-28 01:56:47.010 Built 16:22:31 Oct 23 2020 (GitID #0ea07ac)
I: 2020-10-28 01:56:47.010 General Parameters
I: 2020-10-28 01:56:47.010     Callsign: VA2TB
I: 2020-10-28 01:56:47.010     Id: 302252
I: 2020-10-28 01:56:47.010     Duplex: no
I: 2020-10-28 01:56:47.010     Timeout: 180s
I: 2020-10-28 01:56:47.010     D-Star: disabled
I: 2020-10-28 01:56:47.010     DMR: disabled
I: 2020-10-28 01:56:47.010     YSF: enabled
I: 2020-10-28 01:56:47.010     P25: disabled
I: 2020-10-28 01:56:47.010     NXDN: disabled
I: 2020-10-28 01:56:47.010 Modem Parameters
I: 2020-10-28 01:56:47.010     Port: /dev/null
I: 2020-10-28 01:56:47.010     RX Invert: no
I: 2020-10-28 01:56:47.010     TX Invert: no
I: 2020-10-28 01:56:47.010     PTT Invert: no
I: 2020-10-28 01:56:47.010     TX Delay: 100ms
I: 2020-10-28 01:56:47.010     RX Offset: 0Hz
I: 2020-10-28 01:56:47.010     TX Offset: 0Hz
I: 2020-10-28 01:56:47.010     RX DC Offset: 0
I: 2020-10-28 01:56:47.010     TX DC Offset: 0
I: 2020-10-28 01:56:47.010     RF Level: 100.0%
I: 2020-10-28 01:56:47.010     DMR Delay: 0 (0.0ms)
I: 2020-10-28 01:56:47.010     RX Level: 50.0%
I: 2020-10-28 01:56:47.010     CW Id TX Level: 50.0%
I: 2020-10-28 01:56:47.010     D-Star TX Level: 50.0%
I: 2020-10-28 01:56:47.010     DMR TX Level: 50.0%
I: 2020-10-28 01:56:47.010     YSF TX Level: 50.0%
I: 2020-10-28 01:56:47.010     P25 TX Level: 50.0%
I: 2020-10-28 01:56:47.010     NXDN TX Level: 50.0%
I: 2020-10-28 01:56:47.010     RX Frequency: 0Hz (0Hz)
I: 2020-10-28 01:56:47.010     TX Frequency: 0Hz (0Hz)
M: 2020-10-28 01:56:47.010 Opening the MMDVM
I: 2020-10-28 01:56:47.010 Display Parameters
I: 2020-10-28 01:56:47.010     Type:
I: 2020-10-28 01:56:47.010 System Fusion Network Parameters
I: 2020-10-28 01:56:47.010     Local Address: 0
I: 2020-10-28 01:56:47.010     Local Port: 42200
I: 2020-10-28 01:56:47.010     Gateway Address: 151.80.143.185
I: 2020-10-28 01:56:47.010     Gateway Port: 42002
I: 2020-10-28 01:56:47.010     Mode Hang: 3s
M: 2020-10-28 01:56:47.010 Opening YSF network connection
I: 2020-10-28 01:56:47.014 RSSI
I: 2020-10-28 01:56:47.014     Mapping File: /dev/null
I: 2020-10-28 01:56:47.014 Loaded 0 RSSI data mapping points from /dev/null
I: 2020-10-28 01:56:47.014 DMR Id Lookups
I: 2020-10-28 01:56:47.014     File: /opt/DMRIds.dat
I: 2020-10-28 01:56:47.014     Reload: 24 hours
I: 2020-10-28 01:56:47.142 Loaded 89800 Ids to the DMR callsign lookup table
I: 2020-10-28 01:56:47.145 YSF RF Parameters
I: 2020-10-28 01:56:47.145     Low Deviation: no
I: 2020-10-28 01:56:47.145     Remote Gateway: no
I: 2020-10-28 01:56:47.145     Self Only: no
I: 2020-10-28 01:56:47.145     DSQ: no
I: 2020-10-28 01:56:47.145     Mode Hang: 10s
M: 2020-10-28 01:56:47.145 YSF, Opening INI file: DVSwitch.ini
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] address -> 127.0.0.1
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] txPort -> 42500
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] rxPort -> 43500
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] txWidePort -> 42500
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] fallbackID -> 1234567
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] exportTG -> 9
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] slot -> 2
M: 2020-10-28 01:56:47.145 YSF, Setting [YSF] RemotePort -> 6073
M: 2020-10-28 01:56:47.145 YSF, Transmitting on 127.0.0.1:42500, and listening on port 43500.  Result = 1
M: 2020-10-28 01:56:47.145 MMDVM_Bridge-20200727_V1.5.9 is running
I: 2020-10-28 01:56:47.145 Started the DMR Id lookup reload thread
M: 2020-10-28 01:56:58.969 YSF, TX state = ON
I: 2020-10-28 01:56:58.969 YSF, Begin TX: src=1234567 rpt=0 dst=9 slot=2 cc=0 metadata=302226
M: 2020-10-28 01:56:58.969 YSF, No call or id found, using ini value: VA2TB     HH&
I: 2020-10-28 01:56:59.326 YSF, Narrow transmit (72 bit)
I: 2020-10-28 01:57:02.865 MMDVM_Bridge:
I: 2020-10-28 01:57:02.865 Portions Copyright (C) 2018, 2019, 2020 DVSwitch, INAD.
I: 2020-10-28 01:57:02.865 Hacks by Mike N4IRR and Steve N4IRS
I: 2020-10-28 01:57:02.865 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


Re: YSF > ASL using XLXd reflector

k7wby@...
 

Steve, thanks for the repsonse. My first attempt was without the gateway using only MB, which as you say, works. I wasn't able to do YSF Passthrough but I knew G4KLX's YSFGateway could do it. I've managed to get that up and running now and all is good.  This is all an experiment to see what I might do if my back haul failed. I needed a fail over that I can bring up remotely via ssh. This will get the job done. DVSwitch is quite versatile and I thank you for streamlining it for us.


Re: One TG in Analog Bridge

Steve N4IRS
 

dvswitch.sh tune 9

On 10/27/20 7:23 PM, Aaron Groover wrote:

Is there a way to just set a basic TG for example “9” and be able to talk on what static TG we are on either on the BM or TGIF selfcare dash? Or do we have to constantly change it and restart analog bridge?

 

 

 

--

 

Thank You,

 

Aaron Groover

(610) 379 6148

K3ALG@...

agroover@...

 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

 



One TG in Analog Bridge

Aaron Groover
 

Is there a way to just set a basic TG for example “9” and be able to talk on what static TG we are on either on the BM or TGIF selfcare dash? Or do we have to constantly change it and restart analog bridge?

 

 

 

--

 

Thank You,

 

Aaron Groover

(610) 379 6148

K3ALG@...

agroover@...

 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

 


Re: YSF > ASL using XLXd reflector

Steve N4IRS
 

Are you connecting to a DMR or YSF XLX connection? MB can connect directly to a YSF reflector without need for YSFGateway or to a XLX DMR reflector.

On 10/27/20 4:41 PM, k7wby@... wrote:
Hi folks, so I have MB > XLXd and the xlx dashboard shows the connection as a Repeater/Node of K7wBY B and the channel is blank. I tried adding Options=XLX:4008 to see if it would come up on Channel H but that didn't seem to work. I suspect that I'm going to need to run YSFGateway and then point MB to the gateway.


YSF > ASL using XLXd reflector

k7wby@...
 

Hi folks, so I have MB > XLXd and the xlx dashboard shows the connection as a Repeater/Node of K7wBY B and the channel is blank. I tried adding Options=XLX:4008 to see if it would come up on Channel H but that didn't seem to work. I suspect that I'm going to need to run YSFGateway and then point MB to the gateway.


Re: Some basic dv switch questions, hoping you can help

Steve N4IRS
 

Huh?

On 10/26/2020 2:47 PM, lee kasen wrote:
Get a pi i use the pi3b and an mmdvm hat (Google it) then www. pi-star. Co. Uk.(no spaces)  youtube or ham radio concepts (seting up a mmdvm) and have fun. You may want to get a dmr radio tyt md 380 is the one i have. (learn how to work code plug) hope that gets you started 

On Sat, Oct 24, 2020, 17:12 Jed Barton <jedbarton@...> wrote:
Hey guys,

Jed.n1jbc here.  So, i'm brand new to this dvswitch thing, and
honestly it seems pretty cool.
So, the furthest i've gotten with it, is hooking it up to my allstar
node, using a network radio.  I'm using an Inrico t-320 network radio,
and have dvswitch installed on it, and am connecting it to my allstar
node.  It works great.
Now it's time to expand it further.  I've been told that i can run
dmr, and other digital modes if i put a pi together.  So i'm at that
point where i want to go to that next step.  What do i need to do?
I'm going to have a lot of questions here.

Cheers,

Jed







Re: Some basic dv switch questions, hoping you can help

lee kasen
 

Get a pi i use the pi3b and an mmdvm hat (Google it) then www. pi-star. Co. Uk.(no spaces)  youtube or ham radio concepts (seting up a mmdvm) and have fun. You may want to get a dmr radio tyt md 380 is the one i have. (learn how to work code plug) hope that gets you started 


On Sat, Oct 24, 2020, 17:12 Jed Barton <jedbarton@...> wrote:
Hey guys,

Jed.n1jbc here.  So, i'm brand new to this dvswitch thing, and
honestly it seems pretty cool.
So, the furthest i've gotten with it, is hooking it up to my allstar
node, using a network radio.  I'm using an Inrico t-320 network radio,
and have dvswitch installed on it, and am connecting it to my allstar
node.  It works great.
Now it's time to expand it further.  I've been told that i can run
dmr, and other digital modes if i put a pi together.  So i'm at that
point where i want to go to that next step.  What do i need to do?
I'm going to have a lot of questions here.

Cheers,

Jed






Re: M17 Support #mmdvm_bridge

Steve N4IRS
 

Thanks.
Mike and I talked about supporting CW, but maybe not MCW. ;)

Steve

On 10/26/2020 10:54 AM, k7wby@... wrote:
Good plan Steve, with over 75 digital modes currently available it would be an insane project to try to accommodate them all. 


Re: M17 Support #mmdvm_bridge

k7wby@...
 

Good plan Steve, with over 75 digital modes currently available it would be an insane project to try to accommodate them all. 


Re: M17 Support #mmdvm_bridge

Steve N4IRS
 

Maybe in the future. We will see if it really gets any use.

On 10/26/2020 8:49 AM, Roby IV3JDV wrote:

Hi Steve, are you planning to support the new M17 protocol?


Roby IV3JDV



M17 Support #mmdvm_bridge

Roby IV3JDV
 

Hi Steve, are you planning to support the new M17 protocol?


Roby IV3JDV


Re: Some basic dv switch questions, hoping you can help

Steve N4IRS
 

Jed,
Welcome. Glad you are enjoying using DVSwitch Mobile (DVSM) with Allstar. For what you are asking, you have a couple of choices:

1: Setup a separate Pi for you to use the Digital modes with DVSM.
2: Add the digital modes to your existing AllStar node.

No matter what you choose, I'm going to tell you to wait at least a week to do anything other the gather hardware.
1: is the best option If you have a spare Pi.
2: give you the best overall flexibility but may be more complex to setup depending on how you want things to work.

We are one week away from release of DVSwitch Server. The server image runs on a Raspberry Pi and allows you to setup a server with very little trouble.
We have not tested adding DVSwitch Server to an existing AllStar node. It SHOULD work, but we need to test before recommending.

That having been said, we have 2 subgroups you should consider joining.
1: <https://dvswitch.groups.io/g/allstarlink> Discussion of bridging AllStar to the digital world
2: <https://dvswitch.groups.io/g/Mobile> Discussion of all things DVSM

73, Steve N4IRS

On 10/24/20 10:39 AM, Jed Barton wrote:
Hey guys,

Jed.n1jbc here. So, i'm brand new to this dvswitch thing, and
honestly it seems pretty cool.
So, the furthest i've gotten with it, is hooking it up to my allstar
node, using a network radio. I'm using an Inrico t-320 network radio,
and have dvswitch installed on it, and am connecting it to my allstar
node. It works great.
Now it's time to expand it further. I've been told that i can run
dmr, and other digital modes if i put a pi together. So i'm at that
point where i want to go to that next step. What do i need to do?
I'm going to have a lot of questions here.

Cheers,

Jed




Some basic dv switch questions, hoping you can help

Jed Barton <jedbarton@...>
 

Hey guys,

Jed.n1jbc here. So, i'm brand new to this dvswitch thing, and
honestly it seems pretty cool.
So, the furthest i've gotten with it, is hooking it up to my allstar
node, using a network radio. I'm using an Inrico t-320 network radio,
and have dvswitch installed on it, and am connecting it to my allstar
node. It works great.
Now it's time to expand it further. I've been told that i can run
dmr, and other digital modes if i put a pi together. So i'm at that
point where i want to go to that next step. What do i need to do?
I'm going to have a lot of questions here.

Cheers,

Jed


Re: P25Gateway Inactivity Timeout Behavior

Steve N4IRS
 

Happy Halloween....

On 10/23/2020 2:08 PM, Greg WB6ZSU wrote:
Thanks Steve. I’ll wait for the new image. As you said, it will be “Just two weeks”. 😀


Greg
WB6ZSU


On Oct 23, 2020, at 10:50 AM, Steve N4IRS <szingman@...> wrote:

When the new image is released and you have access to the site, then yes I suggest you install the new image. If nothing else it will allow safer updates.

On 10/23/2020 1:47 PM, Greg WB6ZSU wrote:
Steve,

I tried restarting both Pi’s and this seems to have corrected the issue.

Do you think it is still a good idea to update the files to the latest version, or is there really no big advantage?  One of the installs is on a mountaintop, and I’m a little hesitant to do a remote upgrade. I’m using this strictly for P25, utilizing Quantar Bridge.


Greg
WB6ZSU
 
On Oct 23, 2020, at 7:59 AM, Steve N4IRS <szingman@...> wrote:

I see no reason it would change. It's just that I tested with the current version as shown in the included logs so I know it's working. As far as I know it always worked that way.

On 10/23/2020 10:58 AM, Greg WB6ZSU wrote:
Steve,

I will try doing this later.

Can you think of why this would have changed all the sudden?  I have two installations which are now behaving this way.

I only realized this because the past few days I was noticing there hasn’t been much chatter on the TG. Also, when I keyed my radio, I would get the “Pacific” annunciation which was an indication that the talkgroup had changed. That’s when I started doing some digging.

Greg
WB6ZSU


On Oct 23, 2020, at 7:49 AM, Steve N4IRS <szingman@...> wrote:

Greg,
You might just get away with replacing the binary.

systemctl stop p25gateway
cd /opt/P25Gateway
mv P25Gateway P25Gateway.old
 wget https://github.com/DVSwitch/P25Gateway/raw/master/bin/P25Gateway.armhf
mv P25Gateway.armhf P25Gateway
chmod +x P25Gateway
systemctl start p25gateway

To go "all the way" you will want to replace the binary, the ini and the audio directory from this: <https://github.com/DVSwitch/P25Gateway/archive/master.zip>


Steve N4IRS

On 10/23/2020 10:41 AM, Greg WB6ZSU wrote:
Steve,

Here are my results (you can see this is a pretty old install):


root@raspberrypi:/home/pi# uname -a
Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
root@raspberrypi:/home/pi# dpkg --print-architecture
armhf
root@raspberrypi:/home/pi# /opt/P25Gateway/P25Gateway -v
P25Gateway version 20180409
root@raspberrypi:/home/pi#


Greg
WB6ZSU



On Oct 23, 2020, at 2:47 AM, Steve N4IRS <szingman@...> wrote:

Greg,
Please run the following as root:
uname -a
dpkg --print-architecture
/opt/P25Gateway/P25Gateway -v

Steve N4IRS



On 10/23/20 3:17 AM, Greg WB6ZSU wrote:
Over the past few days I’ve noticed a change in the way the Inactivity timeout works.  I have my system configured with a Startup TG of 10400 and an Inactivity Timer of 10 minutes.  The way I’m accustomed to this working is that if I changed talk groups to something other than 10400 (Startup) and there was inactivity on this new TG for more than 10 minutes, the system would revert back to 10400. This is not the way it is behaving today. I’m not exactly sure what TG is now used as the “Revert” TG.

I’ve looked at the P25Gateway log file and verified that even when operating on 10400, if there is more than 10 minutes of inactivity, I will be unlinked from 10400.

Is this a known current behavior, and if so, what does happen after the inactivity timer expires?


Thanks and 73,
Greg
WB6ZSU


















Re: P25Gateway Inactivity Timeout Behavior

Greg WB6ZSU
 

Thanks Steve. I’ll wait for the new image. As you said, it will be “Just two weeks”. 😀


Greg
WB6ZSU


On Oct 23, 2020, at 10:50 AM, Steve N4IRS <szingman@...> wrote:

When the new image is released and you have access to the site, then yes I suggest you install the new image. If nothing else it will allow safer updates.

On 10/23/2020 1:47 PM, Greg WB6ZSU wrote:
Steve,

I tried restarting both Pi’s and this seems to have corrected the issue.

Do you think it is still a good idea to update the files to the latest version, or is there really no big advantage?  One of the installs is on a mountaintop, and I’m a little hesitant to do a remote upgrade. I’m using this strictly for P25, utilizing Quantar Bridge.


Greg
WB6ZSU
 
On Oct 23, 2020, at 7:59 AM, Steve N4IRS <szingman@...> wrote:

I see no reason it would change. It's just that I tested with the current version as shown in the included logs so I know it's working. As far as I know it always worked that way.

On 10/23/2020 10:58 AM, Greg WB6ZSU wrote:
Steve,

I will try doing this later.

Can you think of why this would have changed all the sudden?  I have two installations which are now behaving this way.

I only realized this because the past few days I was noticing there hasn’t been much chatter on the TG. Also, when I keyed my radio, I would get the “Pacific” annunciation which was an indication that the talkgroup had changed. That’s when I started doing some digging.

Greg
WB6ZSU


On Oct 23, 2020, at 7:49 AM, Steve N4IRS <szingman@...> wrote:

Greg,
You might just get away with replacing the binary.

systemctl stop p25gateway
cd /opt/P25Gateway
mv P25Gateway P25Gateway.old
 wget https://github.com/DVSwitch/P25Gateway/raw/master/bin/P25Gateway.armhf
mv P25Gateway.armhf P25Gateway
chmod +x P25Gateway
systemctl start p25gateway

To go "all the way" you will want to replace the binary, the ini and the audio directory from this: <https://github.com/DVSwitch/P25Gateway/archive/master.zip>


Steve N4IRS

On 10/23/2020 10:41 AM, Greg WB6ZSU wrote:
Steve,

Here are my results (you can see this is a pretty old install):


root@raspberrypi:/home/pi# uname -a
Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
root@raspberrypi:/home/pi# dpkg --print-architecture
armhf
root@raspberrypi:/home/pi# /opt/P25Gateway/P25Gateway -v
P25Gateway version 20180409
root@raspberrypi:/home/pi#


Greg
WB6ZSU



On Oct 23, 2020, at 2:47 AM, Steve N4IRS <szingman@...> wrote:

Greg,
Please run the following as root:
uname -a
dpkg --print-architecture
/opt/P25Gateway/P25Gateway -v

Steve N4IRS



On 10/23/20 3:17 AM, Greg WB6ZSU wrote:
Over the past few days I’ve noticed a change in the way the Inactivity timeout works.  I have my system configured with a Startup TG of 10400 and an Inactivity Timer of 10 minutes.  The way I’m accustomed to this working is that if I changed talk groups to something other than 10400 (Startup) and there was inactivity on this new TG for more than 10 minutes, the system would revert back to 10400. This is not the way it is behaving today. I’m not exactly sure what TG is now used as the “Revert” TG.

I’ve looked at the P25Gateway log file and verified that even when operating on 10400, if there is more than 10 minutes of inactivity, I will be unlinked from 10400.

Is this a known current behavior, and if so, what does happen after the inactivity timer expires?


Thanks and 73,
Greg
WB6ZSU

















Re: P25Gateway Inactivity Timeout Behavior

Steve N4IRS
 

When the new image is released and you have access to the site, then yes I suggest you install the new image. If nothing else it will allow safer updates.

On 10/23/2020 1:47 PM, Greg WB6ZSU wrote:
Steve,

I tried restarting both Pi’s and this seems to have corrected the issue.

Do you think it is still a good idea to update the files to the latest version, or is there really no big advantage?  One of the installs is on a mountaintop, and I’m a little hesitant to do a remote upgrade. I’m using this strictly for P25, utilizing Quantar Bridge.


Greg
WB6ZSU
 
On Oct 23, 2020, at 7:59 AM, Steve N4IRS <szingman@...> wrote:

I see no reason it would change. It's just that I tested with the current version as shown in the included logs so I know it's working. As far as I know it always worked that way.

On 10/23/2020 10:58 AM, Greg WB6ZSU wrote:
Steve,

I will try doing this later.

Can you think of why this would have changed all the sudden?  I have two installations which are now behaving this way.

I only realized this because the past few days I was noticing there hasn’t been much chatter on the TG. Also, when I keyed my radio, I would get the “Pacific” annunciation which was an indication that the talkgroup had changed. That’s when I started doing some digging.

Greg
WB6ZSU


On Oct 23, 2020, at 7:49 AM, Steve N4IRS <szingman@...> wrote:

Greg,
You might just get away with replacing the binary.

systemctl stop p25gateway
cd /opt/P25Gateway
mv P25Gateway P25Gateway.old
 wget https://github.com/DVSwitch/P25Gateway/raw/master/bin/P25Gateway.armhf
mv P25Gateway.armhf P25Gateway
chmod +x P25Gateway
systemctl start p25gateway

To go "all the way" you will want to replace the binary, the ini and the audio directory from this: <https://github.com/DVSwitch/P25Gateway/archive/master.zip>


Steve N4IRS

On 10/23/2020 10:41 AM, Greg WB6ZSU wrote:
Steve,

Here are my results (you can see this is a pretty old install):


root@raspberrypi:/home/pi# uname -a
Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
root@raspberrypi:/home/pi# dpkg --print-architecture
armhf
root@raspberrypi:/home/pi# /opt/P25Gateway/P25Gateway -v
P25Gateway version 20180409
root@raspberrypi:/home/pi#


Greg
WB6ZSU



On Oct 23, 2020, at 2:47 AM, Steve N4IRS <szingman@...> wrote:

Greg,
Please run the following as root:
uname -a
dpkg --print-architecture
/opt/P25Gateway/P25Gateway -v

Steve N4IRS



On 10/23/20 3:17 AM, Greg WB6ZSU wrote:
Over the past few days I’ve noticed a change in the way the Inactivity timeout works.  I have my system configured with a Startup TG of 10400 and an Inactivity Timer of 10 minutes.  The way I’m accustomed to this working is that if I changed talk groups to something other than 10400 (Startup) and there was inactivity on this new TG for more than 10 minutes, the system would revert back to 10400. This is not the way it is behaving today. I’m not exactly sure what TG is now used as the “Revert” TG.

I’ve looked at the P25Gateway log file and verified that even when operating on 10400, if there is more than 10 minutes of inactivity, I will be unlinked from 10400.

Is this a known current behavior, and if so, what does happen after the inactivity timer expires?


Thanks and 73,
Greg
WB6ZSU
















Re: P25Gateway Inactivity Timeout Behavior

Steve N4IRS
 

If it works don't fix it.

On 10/23/2020 1:47 PM, Greg WB6ZSU wrote:
Steve,

I tried restarting both Pi’s and this seems to have corrected the issue.

Do you think it is still a good idea to update the files to the latest version, or is there really no big advantage?  One of the installs is on a mountaintop, and I’m a little hesitant to do a remote upgrade. I’m using this strictly for P25, utilizing Quantar Bridge.


Greg
WB6ZSU
 
On Oct 23, 2020, at 7:59 AM, Steve N4IRS <szingman@...> wrote:

I see no reason it would change. It's just that I tested with the current version as shown in the included logs so I know it's working. As far as I know it always worked that way.

On 10/23/2020 10:58 AM, Greg WB6ZSU wrote:
Steve,

I will try doing this later.

Can you think of why this would have changed all the sudden?  I have two installations which are now behaving this way.

I only realized this because the past few days I was noticing there hasn’t been much chatter on the TG. Also, when I keyed my radio, I would get the “Pacific” annunciation which was an indication that the talkgroup had changed. That’s when I started doing some digging.

Greg
WB6ZSU


On Oct 23, 2020, at 7:49 AM, Steve N4IRS <szingman@...> wrote:

Greg,
You might just get away with replacing the binary.

systemctl stop p25gateway
cd /opt/P25Gateway
mv P25Gateway P25Gateway.old
 wget https://github.com/DVSwitch/P25Gateway/raw/master/bin/P25Gateway.armhf
mv P25Gateway.armhf P25Gateway
chmod +x P25Gateway
systemctl start p25gateway

To go "all the way" you will want to replace the binary, the ini and the audio directory from this: <https://github.com/DVSwitch/P25Gateway/archive/master.zip>


Steve N4IRS

On 10/23/2020 10:41 AM, Greg WB6ZSU wrote:
Steve,

Here are my results (you can see this is a pretty old install):


root@raspberrypi:/home/pi# uname -a
Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
root@raspberrypi:/home/pi# dpkg --print-architecture
armhf
root@raspberrypi:/home/pi# /opt/P25Gateway/P25Gateway -v
P25Gateway version 20180409
root@raspberrypi:/home/pi#


Greg
WB6ZSU



On Oct 23, 2020, at 2:47 AM, Steve N4IRS <szingman@...> wrote:

Greg,
Please run the following as root:
uname -a
dpkg --print-architecture
/opt/P25Gateway/P25Gateway -v

Steve N4IRS



On 10/23/20 3:17 AM, Greg WB6ZSU wrote:
Over the past few days I’ve noticed a change in the way the Inactivity timeout works.  I have my system configured with a Startup TG of 10400 and an Inactivity Timer of 10 minutes.  The way I’m accustomed to this working is that if I changed talk groups to something other than 10400 (Startup) and there was inactivity on this new TG for more than 10 minutes, the system would revert back to 10400. This is not the way it is behaving today. I’m not exactly sure what TG is now used as the “Revert” TG.

I’ve looked at the P25Gateway log file and verified that even when operating on 10400, if there is more than 10 minutes of inactivity, I will be unlinked from 10400.

Is this a known current behavior, and if so, what does happen after the inactivity timer expires?


Thanks and 73,
Greg
WB6ZSU















2501 - 2520 of 9795