Date   

Re: OhioLink YSF to DMR bridge update

Steve N4IRS
 

Just the TG number

On 6/23/19 12:54 PM, Tom Corcoran wrote:
and to change TG's do I enter *3TG in DVSM or just the TG#?
--
Tom VE3NY


Re: OhioLink YSF to DMR bridge update

Tom Corcoran
 

and to change TG's do I enter *3TG in DVSM or just the TG#?
--
Tom VE3NY


Re: OhioLink YSF to DMR bridge update

Steve N4IRS
 

Correct.

On 6/23/19 11:48 AM, Tom Corcoran wrote:
So, just build cloud instance as before : ASL <-> DMR but skip setting up ASL node. Correct?
--
Tom VE3NY


Re: OhioLink YSF to DMR bridge update

Tom Corcoran
 

So, just build cloud instance as before : ASL <-> DMR but skip setting up ASL node. Correct?
--
Tom VE3NY


Re: OhioLink YSF to DMR bridge update

Steve N4IRS
 

Tom,
The quote below is from my description of using DVM connected directly to Analog_Bridge using the USRP protocol. the flow diagram would look like this:
DVSwitch Mobile <-> Analog_Bridge <-> MMDVM_Bridge <-> DMR

The ability to switch modes and talkgroups can be done within ASL also using scripting. I am working on a writeup for ASL.

Steve N4IRS

On 6/22/19 3:52 PM, Tom Corcoran wrote:
Hello Steve,
 
I have been using the package as described in your update and it works perfectly. I am running DVM on an Inrico TM-7. 

DVSwitch Mobile <-> ASL <-> Analog_Bridge <-> MMDVM_Bridge <-> DMR
Because I entered a DMR TG in Analog_Bridge, I assumed it was hardwired until I changed it. In your update, you say ...
 
"You can access any TG available on the network like you do on your DMR radio. You can choose any TG in the list and move over to the TG with a simple button press. You can dial any arbitrary TG from the keypad. The Callsign and DMRID are changeable in DVM." 
 
Does this mean I can use analog radio keypad to change TG's? If so, is it done by entering *3newTG? You refer to "any TG in the list" ... which list? All I see is a list of ASL nodes
 
Tnx for all your efforts and great support to the community. 
--
Tom VE3NY


Re: OhioLink YSF to DMR bridge update

Tom Corcoran
 

Hello Steve,

another question related to DVM ... I wasn't aware that I could connect directly DVM <-> Analog_Bridge <-> MMDVM_Bridge <-> DMR. Presumably no need for an ASL node in my cloud instance but not clear on what stanza(s) I change to enable DVM <-> Analog_Bridge connect. Advice?

-
Tnx ... Tom VE3NY


Re: OhioLink YSF to DMR bridge update

Tom Corcoran
 

Hello Steve,
 
I have been using the package as described in your update and it works perfectly. I am running DVM on an Inrico TM-7. 

DVSwitch Mobile <-> ASL <-> Analog_Bridge <-> MMDVM_Bridge <-> DMR
Because I entered a DMR TG in Analog_Bridge, I assumed it was hardwired until I changed it. In your update, you say ...
 
"You can access any TG available on the network like you do on your DMR radio. You can choose any TG in the list and move over to the TG with a simple button press. You can dial any arbitrary TG from the keypad. The Callsign and DMRID are changeable in DVM." 
 
Does this mean I can use analog radio keypad to change TG's? If so, is it done by entering *3newTG? You refer to "any TG in the list" ... which list? All I see is a list of ASL nodes
 
Tnx for all your efforts and great support to the community. 
--
Tom VE3NY


HBlink rules.py

Carlos Minguela
 

Hi, a group of friends are unifying platforms which we have. So far we have managed to unify some of the platforms but others have not. With success we have managed to see that all HBlink accepts them as peers. But when mixing them some only receive audio but do not transmit. Attached I send you how we have configured the rules in case you can identify the possible error in them:

 
BRIDGES = {
    'BRIDGES': [
            {'SYSTEM': 'MASTER',     'TS': 2, 'TGID': 4004,    'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},
            {'SYSTEM': 'XLX215-D',    'TS': 2, 'TGID': 4004,    'ACTIVE': True, 'TIMEOUT': 2,  'TO_TYPE': 'NONE', 'ON': [],     'OFF': [],         'RESET': []},
            {'SYSTEM': 'XLX215-D',    'TS': 2, 'TGID': 9,       'ACTIVE': True, 'TIMEOUT': 2,  'TO_TYPE': 'NONE', 'ON': [],     'OFF': [],         'RESET': []},
            {'SYSTEM': 'MASTER',    'TS': 2, 'TGID': 33015, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE',  'ON': [], 'OFF': [], 'RESET': []},            
            {'SYSTEM': 'TG33015',    'TS': 2, 'TGID': 33015, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE',  'ON': [], 'OFF': [], 'RESET': []},       
            {'SYSTEM': 'MASTER',     'TS': 2, 'TGID': 7225,    'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},
            {'SYSTEM': 'ARG-TGIF',    'TS': 2, 'TGID': 7225,    'ACTIVE': True, 'TIMEOUT': 2,  'TO_TYPE': 'NONE', 'ON': [],     'OFF': [],         'RESET': []},
            {'SYSTEM': 'TG7225',    'TS': 2, 'TGID': 7225,    'ACTIVE': True, 'TIMEOUT': 2,  'TO_TYPE': 'NONE', 'ON': [],     'OFF': [],         'RESET': []},           
        ]
}

These connections are fixed and we only want to use HBlink as a bridge of all the platforms. There are no connections to it from users since we only want to unify.  Thanks in advance for any help you can give us. 73 de KP4CA.


Re: setting up MMDVM_Bridge and Analog_Bridge #analog_bridge #mmdvm_bridge

Steve N4IRS
 

Yes

On 6/21/2019 3:20 PM, Dexter Harroo wrote:
DSTAR<------> <---ircDDBGateway---> <---MMDVM_Bridge------> <-----Analog_Bridge_Dstar.ini----> <----Analog_Bridge_DMR.ini----> <----MMDVM_Bridge<------>DMR

So this is the correct illustration


Re: setting up MMDVM_Bridge and Analog_Bridge #analog_bridge #mmdvm_bridge

Steve N4IRS
 

Supported? Well not really, it's from someone else. I have not built a install package for it. It can be built from source or I think someone has packages available.

On 6/21/2019 3:15 PM, Dexter Harroo wrote:
ok Thanks Steve. I guess ircDDBGateway isn't supported on here?


Re: setting up MMDVM_Bridge and Analog_Bridge #analog_bridge #mmdvm_bridge

Dexter Harroo
 

DSTAR<------> <---ircDDBGateway---> <---MMDVM_Bridge------> <-----Analog_Bridge_Dstar.ini----> <----Analog_Bridge_DMR.ini----> <----MMDVM_Bridge<------>DMR

So this is the correct illustration


Re: setting up MMDVM_Bridge and Analog_Bridge #analog_bridge #mmdvm_bridge

Dexter Harroo
 

ok Thanks Steve. I guess ircDDBGateway isn't supported on here?


Re: setting up MMDVM_Bridge and Analog_Bridge #analog_bridge #mmdvm_bridge

Steve KC1AWV
 

Depends on how you're starting the service. If you're using the systemd scripts, this is how I would do it:

Make a copy of the existing AB systemd script, make it identifiable as a different script

cd /lib/systemd/system
cp analog_bridge.service analog_bridge-dstar.service

Then, edit the copy with your editor of choice

pico analog_bridge-dstar.service

And edit the ExecStart line to load up the configuration for the instance you want. I'll assume you're doing the dstar config

ExecStart=/opt/Analog_Bridge/Analog_Bridge /opt/Analog_Bridge/Analog_Bridge_DStar.ini

Save and exit the editor. Then update the systemd files

systemctl daemon-reload

Then star the new service

systemctl start analog_bridge-dstar.service

You can do the same for the DMR instance as well, just change the names and files where needed.

Steve KC1AWV


On Fri, Jun 21, 2019 at 2:59 PM Dexter Harroo <dex.9y4c@...> wrote:

[Edited Message Follows]

Hi guys:
Its me again, This time i am assisting a friend of mines in setting up DStar to DMR link i did some reading and want to make sure i understand the instructions and doing it correctly.
this is what i have so far.
DSTAR<------>MMDVM_Bridge------> <-----Analog_Bridge_Dstar.ini----> <----Analog_Bridge_DMR.ini----> <----MMDVM_Bridge<------>DMR

Analog_Bridge_Dstar.ini
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 32103                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in xx_Bridge.cfg)
toDMRPort = 32100                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in xx_Bridge.cfg)
ambeMode = DSTAR                        ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 3740029                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 3740029                    ; ID of source repeater
txTg = 1972                                ; TG to use for all frames received from Analog_Bridge -> xx_Bridge
txTs = 1                                ; Slot to use for frames received from Analog_Bridge -> xx_Bridge
colorCode = 1                           ; Color Code to assign DMR frames

DvSwitch.ini Dstar Stanza

[DSTAR]
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 32103                  ; Port to send AMBE TLV frames to (export)
RXPort = 32100                  ; Port to listen on (import)
FallbackID = 3740029            ; In case we can not find a valid DMR id in the database, export this one
ExportTG = 1972                 ; Which TG to export
Slot = 2                                ; Export slot

Analog_Bridge_DMR.ini
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 31103                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in xx_Bridge.cfg)
toDMRPort = 31101                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in xx_Bridge.cfg)
ambeMode = DMR                          ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 0                        ; ID to use when transmitting from Analog_Bridge
repeaterID = 0                          ; ID of source repeater
txTg = 1972                             ; TG to use for all frames received from Analog_Bridge -> xx_Bridge
txTs = 2                                ; Slot to use for frames received from Analog_Bridge -> xx_Bridge
colorCode = 1                           

DvSwitch.INI DMR Stanza
[DMR]
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 31103                  ; Port to send AMBE TLV frames to (export)
RXPort = 31101                  ; Port to listen on (import)
Slot = 2                        ; Export slot


Can someone take a look and let me know if I'm on the right track or If I am Missing anything?
Question How do i go about running the 2 Instances of Analog_Bridge?



--
Steve Miller
KC1AWV


Re: setting up MMDVM_Bridge and Analog_Bridge #analog_bridge #mmdvm_bridge

Steve N4IRS
 

Looks about right. Don't forget you need ircDDBGateway between MB and D-Star reflector.

On 6/21/2019 2:57 PM, Dexter Harroo wrote:
Hi guys:
Its me again, This time i am assisting a friend of mines in setting up DStar to DMR link i did some reading and want to make sure i understand the instructions and doing it correctly.
this is what i have so far.
DSTAR<------>MMDVM_Bridge------> <-----Analog_Bridge_Dstar.ini----> <----Analog_Bridge_DMR.ini----> <----MMDVM_Bridge<------>DMR

Analog_Bridge_Dstar.ini
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 32103                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in xx_Bridge.cfg)
toDMRPort = 32100                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in xx_Bridge.cfg)
ambeMode = DSTAR                        ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 3740029                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 3740029                    ; ID of source repeater
txTg = 1972                                ; TG to use for all frames received from Analog_Bridge -> xx_Bridge
txTs = 1                                ; Slot to use for frames received from Analog_Bridge -> xx_Bridge
colorCode = 1                           ; Color Code to assign DMR frames

DvSwitch.ini Dstar Stanza

[DSTAR]
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 32103                  ; Port to send AMBE TLV frames to (export)
RXPort = 32100                  ; Port to listen on (import)
FallbackID = 3740029            ; In case we can not find a valid DMR id in the database, export this one
ExportTG = 1972                 ; Which TG to export
Slot = 2                                ; Export slot

Analog_Bridge_DMR.ini
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 31103                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in xx_Bridge.cfg)
toDMRPort = 31101                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in xx_Bridge.cfg)
ambeMode = DMR                          ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 0                        ; ID to use when transmitting from Analog_Bridge
repeaterID = 0                          ; ID of source repeater
txTg = 1972                             ; TG to use for all frames received from Analog_Bridge -> xx_Bridge
txTs = 2                                ; Slot to use for frames received from Analog_Bridge -> xx_Bridge
colorCode = 1                           

DvSwitch.INI DMR Stanza
[DMR]
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 31103                  ; Port to send AMBE TLV frames to (export)
RXPort = 31101                  ; Port to listen on (import)
Slot = 2                        ; Export slot


Can someone take a look and let me know if I'm on the right track or If I am Missing anything?


setting up MMDVM_Bridge and Analog_Bridge #analog_bridge #mmdvm_bridge

Dexter Harroo
 
Edited

Hi guys:
Its me again, This time i am assisting a friend of mines in setting up DStar to DMR link i did some reading and want to make sure i understand the instructions and doing it correctly.
this is what i have so far.
DSTAR<------>MMDVM_Bridge------> <-----Analog_Bridge_Dstar.ini----> <----Analog_Bridge_DMR.ini----> <----MMDVM_Bridge<------>DMR

Analog_Bridge_Dstar.ini
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 32103                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in xx_Bridge.cfg)
toDMRPort = 32100                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in xx_Bridge.cfg)
ambeMode = DSTAR                        ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 3740029                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 3740029                    ; ID of source repeater
txTg = 1972                                ; TG to use for all frames received from Analog_Bridge -> xx_Bridge
txTs = 1                                ; Slot to use for frames received from Analog_Bridge -> xx_Bridge
colorCode = 1                           ; Color Code to assign DMR frames

DvSwitch.ini Dstar Stanza

[DSTAR]
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 32103                  ; Port to send AMBE TLV frames to (export)
RXPort = 32100                  ; Port to listen on (import)
FallbackID = 3740029            ; In case we can not find a valid DMR id in the database, export this one
ExportTG = 1972                 ; Which TG to export
Slot = 2                                ; Export slot

Analog_Bridge_DMR.ini
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 31103                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in xx_Bridge.cfg)
toDMRPort = 31101                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in xx_Bridge.cfg)
ambeMode = DMR                          ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 0                        ; ID to use when transmitting from Analog_Bridge
repeaterID = 0                          ; ID of source repeater
txTg = 1972                             ; TG to use for all frames received from Analog_Bridge -> xx_Bridge
txTs = 2                                ; Slot to use for frames received from Analog_Bridge -> xx_Bridge
colorCode = 1                           

DvSwitch.INI DMR Stanza
[DMR]
Address = 127.0.0.1             ; Address to send AMBE TLV frames to (export)
TXPort = 31103                  ; Port to send AMBE TLV frames to (export)
RXPort = 31101                  ; Port to listen on (import)
Slot = 2                        ; Export slot


Can someone take a look and let me know if I'm on the right track or If I am Missing anything?
Question How do i go about running the 2 Instances of Analog_Bridge?


Re: OhioLink YSF to DMR bridge update

Steve N4IRS
 

Gary,
Thanks for the update. Working with the Ohio Link team was a pleasure. The back and forth helped us learn a few things and find a bug or two. I expect the changes will be incorporated in future versions. Please keep us informed about the blocking message.

Your comment about bringing up a AllStarLink (ASL) node to experiment with DVSwitch Mobile (DVM) brings up a point I would like to address. DVM can be used in two ways. One, as a client for ASL using the native ASL protocol, IAX. In this configuration ASL can be simply that, an analog node capable of connection to other analog nodes. The flow diagram would look like this:
DVM <-> ASL <-> ASL Network.

With this configuration from DVM you can connect your ASL node to any other ASL (or EchoLink) nodes. Very clean and simple. ASL will support multiple logins from DVM so users can easily share the node. If you want to ALSO be able to connect to one or more of the digital voice networks, you can add that to ASL. Your flow diagram will look like this:
DVM <-> ASL <-> Analog_Bridge <-> MMDVM_Bridge <-> digital voice network

You now have access to both the analog and digital voice networks. You can also have multiple logins and share access. This configuration can (with some expansion) can give users access to analog and digital at the same time. For example, one (or more) user on analog and one user on digital. ASL provides quite a lot of functionality if you want. Please note, the one thing you do not have in this configuration is MetaData. DVM will not show you who is talking and all DVM users will share one DMR ID.

DVM does not REQUIRE you to build a ASL node for access. DVM also supports a direct connection to Analog_Bridge (AB) In this configuration a single user can directly access all of the supported digital modes. Your flow diagram will look like this:
DVM <-> Analog_Bridge <-> MMDVM_Bridge <-> digital voice network.

We refer to this as "hot spot in the cloud" Though the hotspot does not really be in the cloud, it can be running on a RPi in your shack. DVM becomes the user interface for AB. In this configuration DVM will display MetaData from the DV network and when you transmit from DVM, your DMR ID and callsign will be correct. In subsequent messages and in the wiki I will cover this configuration in more detail.

Last but not least, I love the "the Swiss army knife of digital radio" Mike and I have been running the DVSwitch programs on the RPi (and other types) Some for testing and some for day to day use. A while ago we started referring to these Pis as Swiss army knives" since they had all the software we needed in one place to build whatever we needed. 

73, Steve N4IRS
      

On 6/20/2019 8:39 PM, Gary - KE8O wrote:
Just wanted to give you an update on Ohio Link. Prior to Dayton the DVSwitch team setup a demo bridge as our previous YSF to DMR solution was having some issues.  I've been running our own DVSwitch instance now locally for a week now bridging our YSF to DMR. I started out only bridging when I was around to monitor and started bridging 24/7 since last Sunday. We only had one occurrence of the BM blocked user message in that time and that was on the first day when I was running the old MB binary with the VW issue causing one way audio with WiresX.  After installing the updated binary from github its been flawless. I know that binary had nothing in to fix the minimum TX duration so whatever was causing the original issue with the BM block message is still lurking. I've now moved on to setting up an Allstar server and node to experiment with DVMobile. My server and node number are now registered so its time to install and configure the software. I'm giving a presentation in the middle of July to our local club on digital radio. I'm hoping to be able to pass around an Inrico T320 as one of the digital radio demos.
 
Thank you guys for such a great product. It's the Swiss army knife of digital radio!

73,
...Gary, KE8O


OhioLink YSF to DMR bridge update

Gary - KE8O <Garymackey@...>
 

Just wanted to give you an update on Ohio Link. Prior to Dayton the DVSwitch team setup a demo bridge as our previous YSF to DMR solution was having some issues.  I've been running our own DVSwitch instance now locally for a week now bridging our YSF to DMR. I started out only bridging when I was around to monitor and started bridging 24/7 since last Sunday. We only had one occurrence of the BM blocked user message in that time and that was on the first day when I was running the old MB binary with the VW issue causing one way audio with WiresX.  After installing the updated binary from github its been flawless. I know that binary had nothing in to fix the minimum TX duration so whatever was causing the original issue with the BM block message is still lurking. I've now moved on to setting up an Allstar server and node to experiment with DVMobile. My server and node number are now registered so its time to install and configure the software. I'm giving a presentation in the middle of July to our local club on digital radio. I'm hoping to be able to pass around an Inrico T320 as one of the digital radio demos.
 
Thank you guys for such a great product. It's the Swiss army knife of digital radio!

73,
...Gary, KE8O


Re: Just Moved server from Digital Ocean and now server won't run

N9UMJ
 

sounds reasonable to me, Thanks

On Thu, Jun 20, 2019 at 6:17 PM Mike KB8JNM <groupio@...> wrote:

All of that is in /usr/local/bin/ put I put my ini and .sh script there as well.

(same with NXDN)

You must correct the config to reflect that if you choose to do it as well.

See the install

https://register.ysfreflector.de/installation

Plenty of good reason for staying on the beaten path and not mine.

It's just simpler for 'me' than chasing directories down.


On 6/20/2019 6:11 PM, N9UMJ wrote:
including the installation for the ysfreflector?

On Wed, Jun 19, 2019 at 8:41 PM Mike KB8JNM <groupio@...> wrote:

/opt/

and any custom folders you create. Keep them all in /opt for multiple instances.

On 6/19/2019 8:37 PM, N9UMJ wrote:
Mike

I was confused too.

When I moved the the whole program. And it appeared to be identical to the DO
VPS , but it just wouldn't run.

So I did a new install of DV switch and the ysf reflector and it still wouldn't run?? 
That's when I tried to get some help.

I'm not sure what the difference would be?
But I couldn't start the process.

Your suggestion of having a mock image is a good idea. I' m hoping I can still pull the .ini and conf. From the DIgital Ocean server.
What are the primary folders that I need to recover for DV Switch?


Rick

On Wed, Jun 19, 2019, 8:17 PM Mike KB8JNM <groupio@...> wrote:

You had me well confused in the beginning.  I was not reading your text well.

I will speak only for myself...

I found it is much simpler and a good habit to be in to install OS and software fresh.

I keep backup copies of all conf and ini files that are custom to what I do in mock directories.

I keep other custom conf files off server that I can load and restart on the fly, change the entire character of the server for specific purposes.

 I can do a whole new install of everything in under 40 min and be right back to where I was.

But I have done it a few times, so practice makes perfect. LOL

It is the preferred method with fewer bugs.  Especially on a VPS. If you were able to just move a image from one to another, their stock(virtual) hardware may be different among other things as well as custom linux headers to match that.  No way to know for sure. If they do not let you load your own ISO, there is a higher 'probability' they use custom headers. All things you can probably work around, but why ?

But as I always say, if there are no problems, you will not learn anything. But let us know how you make out.

Share anything unique you have learned on your path. It may help others.

On 6/18/2019 9:37 PM, N9UMJ wrote:
Mike

Your one several that has suggested Vultr , Allstar maybe an option later for linking our 9 analog repeaters to the digital network, I know doug has done that on the Alabama link

I wasn't trying to be unique , Believe it or not I was trying to make it as simple as possible by moving the the files over just as they were on DO.
I have a theory for the issues with the transfer , but will require further investigation to confirm the problem, but not sure if it's worth the effort at this point?

So your thinking it's best to load DVSwitch and the ysf reflector fresh and just copy the ini files?

I'll look at Vultr tonight and Debian is fine , I run Debian on other projects for work. Ubuntu was selected because I use it on my windows 10 machine for ham and personal, not an issue to load Debian to Windows too.Prefer not to use Windows , but some things just won't run without it.

Thanks again for your help, may have more questions later..

Rick



On Tue, Jun 18, 2019 at 5:55 PM Mike KB8JNM <groupio@...> wrote:

If I might suggest using VUTR.com

Cheap reliable and no custom headers and you can load your own ISO

But I suggest you use DEBIAN especially if you are running or think you might run allstar/app_rpt

ASL  on vultr VPS http://29999.link/asl-vps.html

Try to stay on the beaten path until you know more. But I'm not suggesting that you don't try new things but wait till you understand how it all works. Easier to get help when there is nothing unique in your set-up.

On 6/18/2019 8:41 AM, N9UMJ wrote:
Thanks Steve and Mike
I'm going to wipe out Dv_Switch and all of the files completely from the new PS and try again

I've made the directories and they exist in the files,on the new VPS running is the issue??  all of the DV_Switch files and YSFReflector files are working on DO.

Something has been lost of corrupted when brought over from Digital Ocean

It's unfortunate that the snapshot image from DO cannot be moved outside of DO .

I may look at at creating a stand alone on a pi and putting it at the fiber hub for now and start building a standalone instance for the fiber hub and not use the vps. I have 4 multi channel trans coders sitting on the bench as a fall project, Time restraints in the summer is the problem.

The urgency is moving oit away from DO and having it running as it was before the DO fiasco , until the long term changes can be made


Since I'm starting over again is there a better iso option that Ubuntu 18.04

Thanks to both of you , I'll give the move another try any tips would be appreciated.

Rick n9umj


On Tue, Jun 18, 2019 at 7:39 AM Steve KC1AWV <smiller@...> wrote:
It looks to me that you're having procedural problems, and not issues with the programs themselves. You've got folders missing apparently. Here's the important part of what you've sent over:

chown: cannot access '/var/log/YSFReflector': No such file or directory

Make sure the directory exists first before changing owner. mkdir -p /var/log/YSFReflector

Also, it looks like you're already logged in as root, so no need to use sudo on those commands.

While I'm sure nobody here really minds providing help where it's needed, we're getting into support of an operating system, and programs that are not specifically part of DVSwitch. Remember, the support for the DVSwitch programs that this group is intended for are the ones that are maintained in the DVSwitch github repo. All other support is a courtesy.

Steve KC1AWV

On Tue, Jun 18, 2019 at 1:48 AM N9UMJ <n9umj2@...> wrote:
Mike

I tried to reload the YSFReflecor and can't get it to reinstall over whats already there.

Analog_Bridge  NXDNClients  P25Clients  Quantar_Bridge  YSFParrot
DMRGateway     NXDNGateway  P25Gateway  YSFClients      md380-emu
MMDVM_Bridge   NXDNParrot   P25Parrot   YSFGateway      opt
root@hwsrv-499225:/opt# sudo chown mmdvm /var/log/YSFReflector
chown: cannot access '/var/log/YSFReflector': No such file or directory
root@hwsrv-499225:/opt# cd YSFClients
root@hwsrv-499225:/opt/YSFClients# ls
LICENCE    YSFClients      YSFGateway  YSFReflector
README.md  YSFClients.sln  YSFParrot
root@hwsrv-499225:/opt/YSFClients# cd YSFReflector
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo nano YSFreflector.ini
root@hwsrv-499225:/opt/YSFClients/YSFReflector# udo nano YSFReflector.ini

root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo nano YSFReflector.ini
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo useradd mmdvm -g mmdvm -s /                                                                             sbin/nologin
useradd: user 'mmdvm' already exists
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo chown mmdvm /var/log/YSFRef                                                                             lector
chown: cannot access '/var/log/YSFReflector': No such file or directory
root@hwsrv-499225:/opt/YSFClients/YSFReflector#

What Think??

On Mon, Jun 17, 2019 at 10:52 PM Mike KB8JNM <groupio@...> wrote:

http://manpages.ubuntu.com/manpages/bionic/man1/uname.1.html

On 6/17/2019 10:28 PM, N9UMJ wrote:
Mike

I recovered uname -r with sudo apt-get --reinstall install linux-headers-`uname -r`


Now it shows 4.15.0-15 generic for uname-r 




On Sun, Jun 16, 2019, 9:04 PM Mike KB8JNM <groupio@...> wrote:

Not sure if there is anything specific to Ubuntu but Just a thought... Your packaging might be missing something needed. Someone else may be able to chime in on that.

What does it say when you type   '  uname -r   ' from cmd line ?

Not familiar with Dig Oc but

Did you use one of their stock images ?  or - Can/did you load your own iso ?


On 6/16/2019 7:40 PM, N9UMJ wrote:
Hi Mike

Ubuntu 18.04

On Sun, Jun 16, 2019 at 12:20 PM Mike KB8JNM <groupio@...> wrote:

What OS and kernel version ?

On 6/16/2019 12:03 PM, N9UMJ wrote:
I just moved all of the DvSwitch files and server configurations away from Digital Ocean to a new VPS and can't get it to run, All of the ports have been configut=red on the firewall as the working version of DO, I was wondering if someone could give me some tips on what it might be or would be will to take a look see and see if I may have missed something

Thanks
Rick n9umj


--
Steve Miller
KC1AWV


Re: Just Moved server from Digital Ocean and now server won't run

Mike KB8JNM
 

All of that is in /usr/local/bin/ put I put my ini and .sh script there as well.

(same with NXDN)

You must correct the config to reflect that if you choose to do it as well.

See the install

https://register.ysfreflector.de/installation

Plenty of good reason for staying on the beaten path and not mine.

It's just simpler for 'me' than chasing directories down.


On 6/20/2019 6:11 PM, N9UMJ wrote:
including the installation for the ysfreflector?

On Wed, Jun 19, 2019 at 8:41 PM Mike KB8JNM <groupio@...> wrote:

/opt/

and any custom folders you create. Keep them all in /opt for multiple instances.

On 6/19/2019 8:37 PM, N9UMJ wrote:
Mike

I was confused too.

When I moved the the whole program. And it appeared to be identical to the DO
VPS , but it just wouldn't run.

So I did a new install of DV switch and the ysf reflector and it still wouldn't run?? 
That's when I tried to get some help.

I'm not sure what the difference would be?
But I couldn't start the process.

Your suggestion of having a mock image is a good idea. I' m hoping I can still pull the .ini and conf. From the DIgital Ocean server.
What are the primary folders that I need to recover for DV Switch?


Rick

On Wed, Jun 19, 2019, 8:17 PM Mike KB8JNM <groupio@...> wrote:

You had me well confused in the beginning.  I was not reading your text well.

I will speak only for myself...

I found it is much simpler and a good habit to be in to install OS and software fresh.

I keep backup copies of all conf and ini files that are custom to what I do in mock directories.

I keep other custom conf files off server that I can load and restart on the fly, change the entire character of the server for specific purposes.

 I can do a whole new install of everything in under 40 min and be right back to where I was.

But I have done it a few times, so practice makes perfect. LOL

It is the preferred method with fewer bugs.  Especially on a VPS. If you were able to just move a image from one to another, their stock(virtual) hardware may be different among other things as well as custom linux headers to match that.  No way to know for sure. If they do not let you load your own ISO, there is a higher 'probability' they use custom headers. All things you can probably work around, but why ?

But as I always say, if there are no problems, you will not learn anything. But let us know how you make out.

Share anything unique you have learned on your path. It may help others.

On 6/18/2019 9:37 PM, N9UMJ wrote:
Mike

Your one several that has suggested Vultr , Allstar maybe an option later for linking our 9 analog repeaters to the digital network, I know doug has done that on the Alabama link

I wasn't trying to be unique , Believe it or not I was trying to make it as simple as possible by moving the the files over just as they were on DO.
I have a theory for the issues with the transfer , but will require further investigation to confirm the problem, but not sure if it's worth the effort at this point?

So your thinking it's best to load DVSwitch and the ysf reflector fresh and just copy the ini files?

I'll look at Vultr tonight and Debian is fine , I run Debian on other projects for work. Ubuntu was selected because I use it on my windows 10 machine for ham and personal, not an issue to load Debian to Windows too.Prefer not to use Windows , but some things just won't run without it.

Thanks again for your help, may have more questions later..

Rick



On Tue, Jun 18, 2019 at 5:55 PM Mike KB8JNM <groupio@...> wrote:

If I might suggest using VUTR.com

Cheap reliable and no custom headers and you can load your own ISO

But I suggest you use DEBIAN especially if you are running or think you might run allstar/app_rpt

ASL  on vultr VPS http://29999.link/asl-vps.html

Try to stay on the beaten path until you know more. But I'm not suggesting that you don't try new things but wait till you understand how it all works. Easier to get help when there is nothing unique in your set-up.

On 6/18/2019 8:41 AM, N9UMJ wrote:
Thanks Steve and Mike
I'm going to wipe out Dv_Switch and all of the files completely from the new PS and try again

I've made the directories and they exist in the files,on the new VPS running is the issue??  all of the DV_Switch files and YSFReflector files are working on DO.

Something has been lost of corrupted when brought over from Digital Ocean

It's unfortunate that the snapshot image from DO cannot be moved outside of DO .

I may look at at creating a stand alone on a pi and putting it at the fiber hub for now and start building a standalone instance for the fiber hub and not use the vps. I have 4 multi channel trans coders sitting on the bench as a fall project, Time restraints in the summer is the problem.

The urgency is moving oit away from DO and having it running as it was before the DO fiasco , until the long term changes can be made


Since I'm starting over again is there a better iso option that Ubuntu 18.04

Thanks to both of you , I'll give the move another try any tips would be appreciated.

Rick n9umj


On Tue, Jun 18, 2019 at 7:39 AM Steve KC1AWV <smiller@...> wrote:
It looks to me that you're having procedural problems, and not issues with the programs themselves. You've got folders missing apparently. Here's the important part of what you've sent over:

chown: cannot access '/var/log/YSFReflector': No such file or directory

Make sure the directory exists first before changing owner. mkdir -p /var/log/YSFReflector

Also, it looks like you're already logged in as root, so no need to use sudo on those commands.

While I'm sure nobody here really minds providing help where it's needed, we're getting into support of an operating system, and programs that are not specifically part of DVSwitch. Remember, the support for the DVSwitch programs that this group is intended for are the ones that are maintained in the DVSwitch github repo. All other support is a courtesy.

Steve KC1AWV

On Tue, Jun 18, 2019 at 1:48 AM N9UMJ <n9umj2@...> wrote:
Mike

I tried to reload the YSFReflecor and can't get it to reinstall over whats already there.

Analog_Bridge  NXDNClients  P25Clients  Quantar_Bridge  YSFParrot
DMRGateway     NXDNGateway  P25Gateway  YSFClients      md380-emu
MMDVM_Bridge   NXDNParrot   P25Parrot   YSFGateway      opt
root@hwsrv-499225:/opt# sudo chown mmdvm /var/log/YSFReflector
chown: cannot access '/var/log/YSFReflector': No such file or directory
root@hwsrv-499225:/opt# cd YSFClients
root@hwsrv-499225:/opt/YSFClients# ls
LICENCE    YSFClients      YSFGateway  YSFReflector
README.md  YSFClients.sln  YSFParrot
root@hwsrv-499225:/opt/YSFClients# cd YSFReflector
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo nano YSFreflector.ini
root@hwsrv-499225:/opt/YSFClients/YSFReflector# udo nano YSFReflector.ini

root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo nano YSFReflector.ini
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo useradd mmdvm -g mmdvm -s /                                                                             sbin/nologin
useradd: user 'mmdvm' already exists
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo chown mmdvm /var/log/YSFRef                                                                             lector
chown: cannot access '/var/log/YSFReflector': No such file or directory
root@hwsrv-499225:/opt/YSFClients/YSFReflector#

What Think??

On Mon, Jun 17, 2019 at 10:52 PM Mike KB8JNM <groupio@...> wrote:

http://manpages.ubuntu.com/manpages/bionic/man1/uname.1.html

On 6/17/2019 10:28 PM, N9UMJ wrote:
Mike

I recovered uname -r with sudo apt-get --reinstall install linux-headers-`uname -r`


Now it shows 4.15.0-15 generic for uname-r 




On Sun, Jun 16, 2019, 9:04 PM Mike KB8JNM <groupio@...> wrote:

Not sure if there is anything specific to Ubuntu but Just a thought... Your packaging might be missing something needed. Someone else may be able to chime in on that.

What does it say when you type   '  uname -r   ' from cmd line ?

Not familiar with Dig Oc but

Did you use one of their stock images ?  or - Can/did you load your own iso ?


On 6/16/2019 7:40 PM, N9UMJ wrote:
Hi Mike

Ubuntu 18.04

On Sun, Jun 16, 2019 at 12:20 PM Mike KB8JNM <groupio@...> wrote:

What OS and kernel version ?

On 6/16/2019 12:03 PM, N9UMJ wrote:
I just moved all of the DvSwitch files and server configurations away from Digital Ocean to a new VPS and can't get it to run, All of the ports have been configut=red on the firewall as the working version of DO, I was wondering if someone could give me some tips on what it might be or would be will to take a look see and see if I may have missed something

Thanks
Rick n9umj


--
Steve Miller
KC1AWV


Re: Just Moved server from Digital Ocean and now server won't run

N9UMJ
 

including the installation for the ysfreflector?

On Wed, Jun 19, 2019 at 8:41 PM Mike KB8JNM <groupio@...> wrote:

/opt/

and any custom folders you create. Keep them all in /opt for multiple instances.

On 6/19/2019 8:37 PM, N9UMJ wrote:
Mike

I was confused too.

When I moved the the whole program. And it appeared to be identical to the DO
VPS , but it just wouldn't run.

So I did a new install of DV switch and the ysf reflector and it still wouldn't run?? 
That's when I tried to get some help.

I'm not sure what the difference would be?
But I couldn't start the process.

Your suggestion of having a mock image is a good idea. I' m hoping I can still pull the .ini and conf. From the DIgital Ocean server.
What are the primary folders that I need to recover for DV Switch?


Rick

On Wed, Jun 19, 2019, 8:17 PM Mike KB8JNM <groupio@...> wrote:

You had me well confused in the beginning.  I was not reading your text well.

I will speak only for myself...

I found it is much simpler and a good habit to be in to install OS and software fresh.

I keep backup copies of all conf and ini files that are custom to what I do in mock directories.

I keep other custom conf files off server that I can load and restart on the fly, change the entire character of the server for specific purposes.

 I can do a whole new install of everything in under 40 min and be right back to where I was.

But I have done it a few times, so practice makes perfect. LOL

It is the preferred method with fewer bugs.  Especially on a VPS. If you were able to just move a image from one to another, their stock(virtual) hardware may be different among other things as well as custom linux headers to match that.  No way to know for sure. If they do not let you load your own ISO, there is a higher 'probability' they use custom headers. All things you can probably work around, but why ?

But as I always say, if there are no problems, you will not learn anything. But let us know how you make out.

Share anything unique you have learned on your path. It may help others.

On 6/18/2019 9:37 PM, N9UMJ wrote:
Mike

Your one several that has suggested Vultr , Allstar maybe an option later for linking our 9 analog repeaters to the digital network, I know doug has done that on the Alabama link

I wasn't trying to be unique , Believe it or not I was trying to make it as simple as possible by moving the the files over just as they were on DO.
I have a theory for the issues with the transfer , but will require further investigation to confirm the problem, but not sure if it's worth the effort at this point?

So your thinking it's best to load DVSwitch and the ysf reflector fresh and just copy the ini files?

I'll look at Vultr tonight and Debian is fine , I run Debian on other projects for work. Ubuntu was selected because I use it on my windows 10 machine for ham and personal, not an issue to load Debian to Windows too.Prefer not to use Windows , but some things just won't run without it.

Thanks again for your help, may have more questions later..

Rick



On Tue, Jun 18, 2019 at 5:55 PM Mike KB8JNM <groupio@...> wrote:

If I might suggest using VUTR.com

Cheap reliable and no custom headers and you can load your own ISO

But I suggest you use DEBIAN especially if you are running or think you might run allstar/app_rpt

ASL  on vultr VPS http://29999.link/asl-vps.html

Try to stay on the beaten path until you know more. But I'm not suggesting that you don't try new things but wait till you understand how it all works. Easier to get help when there is nothing unique in your set-up.

On 6/18/2019 8:41 AM, N9UMJ wrote:
Thanks Steve and Mike
I'm going to wipe out Dv_Switch and all of the files completely from the new PS and try again

I've made the directories and they exist in the files,on the new VPS running is the issue??  all of the DV_Switch files and YSFReflector files are working on DO.

Something has been lost of corrupted when brought over from Digital Ocean

It's unfortunate that the snapshot image from DO cannot be moved outside of DO .

I may look at at creating a stand alone on a pi and putting it at the fiber hub for now and start building a standalone instance for the fiber hub and not use the vps. I have 4 multi channel trans coders sitting on the bench as a fall project, Time restraints in the summer is the problem.

The urgency is moving oit away from DO and having it running as it was before the DO fiasco , until the long term changes can be made


Since I'm starting over again is there a better iso option that Ubuntu 18.04

Thanks to both of you , I'll give the move another try any tips would be appreciated.

Rick n9umj


On Tue, Jun 18, 2019 at 7:39 AM Steve KC1AWV <smiller@...> wrote:
It looks to me that you're having procedural problems, and not issues with the programs themselves. You've got folders missing apparently. Here's the important part of what you've sent over:

chown: cannot access '/var/log/YSFReflector': No such file or directory

Make sure the directory exists first before changing owner. mkdir -p /var/log/YSFReflector

Also, it looks like you're already logged in as root, so no need to use sudo on those commands.

While I'm sure nobody here really minds providing help where it's needed, we're getting into support of an operating system, and programs that are not specifically part of DVSwitch. Remember, the support for the DVSwitch programs that this group is intended for are the ones that are maintained in the DVSwitch github repo. All other support is a courtesy.

Steve KC1AWV

On Tue, Jun 18, 2019 at 1:48 AM N9UMJ <n9umj2@...> wrote:
Mike

I tried to reload the YSFReflecor and can't get it to reinstall over whats already there.

Analog_Bridge  NXDNClients  P25Clients  Quantar_Bridge  YSFParrot
DMRGateway     NXDNGateway  P25Gateway  YSFClients      md380-emu
MMDVM_Bridge   NXDNParrot   P25Parrot   YSFGateway      opt
root@hwsrv-499225:/opt# sudo chown mmdvm /var/log/YSFReflector
chown: cannot access '/var/log/YSFReflector': No such file or directory
root@hwsrv-499225:/opt# cd YSFClients
root@hwsrv-499225:/opt/YSFClients# ls
LICENCE    YSFClients      YSFGateway  YSFReflector
README.md  YSFClients.sln  YSFParrot
root@hwsrv-499225:/opt/YSFClients# cd YSFReflector
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo nano YSFreflector.ini
root@hwsrv-499225:/opt/YSFClients/YSFReflector# udo nano YSFReflector.ini

root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo nano YSFReflector.ini
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo useradd mmdvm -g mmdvm -s /                                                                             sbin/nologin
useradd: user 'mmdvm' already exists
root@hwsrv-499225:/opt/YSFClients/YSFReflector# sudo chown mmdvm /var/log/YSFRef                                                                             lector
chown: cannot access '/var/log/YSFReflector': No such file or directory
root@hwsrv-499225:/opt/YSFClients/YSFReflector#

What Think??

On Mon, Jun 17, 2019 at 10:52 PM Mike KB8JNM <groupio@...> wrote:

http://manpages.ubuntu.com/manpages/bionic/man1/uname.1.html

On 6/17/2019 10:28 PM, N9UMJ wrote:
Mike

I recovered uname -r with sudo apt-get --reinstall install linux-headers-`uname -r`


Now it shows 4.15.0-15 generic for uname-r 




On Sun, Jun 16, 2019, 9:04 PM Mike KB8JNM <groupio@...> wrote:

Not sure if there is anything specific to Ubuntu but Just a thought... Your packaging might be missing something needed. Someone else may be able to chime in on that.

What does it say when you type   '  uname -r   ' from cmd line ?

Not familiar with Dig Oc but

Did you use one of their stock images ?  or - Can/did you load your own iso ?


On 6/16/2019 7:40 PM, N9UMJ wrote:
Hi Mike

Ubuntu 18.04

On Sun, Jun 16, 2019 at 12:20 PM Mike KB8JNM <groupio@...> wrote:

What OS and kernel version ?

On 6/16/2019 12:03 PM, N9UMJ wrote:
I just moved all of the DvSwitch files and server configurations away from Digital Ocean to a new VPS and can't get it to run, All of the ports have been configut=red on the firewall as the working version of DO, I was wondering if someone could give me some tips on what it might be or would be will to take a look see and see if I may have missed something

Thanks
Rick n9umj


--
Steve Miller
KC1AWV

4861 - 4880 of 9074