Welcome to DVSwitch
Purpose
1) Allows “local” networking during an outage of the regional national/international network server.
2) Allows a local network operator to “blend” upstream feeds from different Networks (capital N on purpose). These Networks can’t get their act together and learn how to play nice with each other (everyone guilty as far as we are concerned). They may not like people doing this, but the solution is to grow up and work with each other, and not keep trying to force people to take sides.
3) Allows local segregation of localized traffic with more flexibility.
4) Allows experimentation with linking and how it’s done (part 97 specifies experimentation and advancement of the radio art are a core part of amateur radio).
Mission Statement/Position
WHEREAS the Networks continue to be largely islands and are not working together to create a unified network of Networks.
WHEREAS no firm reason has been given by any of the Networks why a *competent* local network operator cannot make this work effectively.
(US ONLY)
WHEREAS 47 CFR 97 (Amateur Radio Service) specifies that a core component of amateur radio is experimentation and advancement of the radio art [97.1(b)].
BE IT RESOLVED the core group of US amateur radio operators and experimenters organized around the DVSwitch project, and in the spirit of USA 47 CFR 97 and its intentions, support the *responsible* and *thoughtful* use of digital voice networking tools to create localized networks that will interconnect to the national/international Networks, and will support users of its tools in order to do this in the most effective and sustainable way possible.
Re: ASL <> DMR <> YSF inquiry?
#mmdvm_bridge
Andrew,
toggle quoted messageShow quoted text
I would suggest you wait a few days. We just updated to allow MB to bridge or connect to all like modes in a single instance of MB. We are putting a document in the next few days. It will look something like this: ASL <-> AB <-> MB <-> DMR | <--> YSF (best I can do with ASCII graphics) 73, Steve N4IRS
On 4/20/20 7:40 PM, andrew delgado via
groups.io wrote:
Hi all,
|
|
Re: ASL <> DMR <> YSF inquiry?
#mmdvm_bridge
andrew delgado
Hi all,
i was able to work successfully the both experiments ASL <> AB <> MB <> DMR using the link provided by steve n4irs, and also the YSFReflector <> MB <> DMR.. i have the idea of having a new instance but im mixing the ports or do i really need hblink3 in between? im setting this up on a single debian box. Regards, Andrew
|
|
Re: #mmdvm_bridge
#mmdvm_bridge
that is echolink. suggestion change your time on sunday to like 2 am
monday morning to reboot and that should alleviate your problem. I
run mine on a raspberry pi 4 and never rebooted unless I make a
change in the system.
toggle quoted messageShow quoted text
On 4/20/2020 3:39 PM,
john.brazel225@... wrote:
I'm not sure what openbridge is? I simply followed a guide online on how to set this up. But just to clarify, the BM side of things are working, it's just that my bridge node won't connect back to the echolink conference on a Sunday/Monday reboot.
|
|
Re: ASL <> DMR <> YSF inquiry?
#mmdvm_bridge
|
|
Re: ASL <> DMR <> YSF inquiry?
#mmdvm_bridge
lee kasen
How did you get the ASL<>DMR To work..
Hello!
|
|
Re: #mmdvm_bridge
#mmdvm_bridge
john.brazel225@...
I'm not sure what openbridge is? I simply followed a guide online on how to set this up. But just to clarify, the BM side of things are working, it's just that my bridge node won't connect back to the echolink conference on a Sunday/Monday reboot.
|
|
Re: ASL <> DMR <> YSF inquiry?
#mmdvm_bridge
Andrew,
You can create another instance of MB crossmode DMR to YSF looks like this: BMTG<->MB<->YSFreflector - point DMR to talk group of your choice and point YSF to IP or DNS ysfreflector. 73, Eric
|
|
Re: #mmdvm_bridge
#mmdvm_bridge
JJ Cummings
Are you using an openbridge connection or are you connecting to BM as a PEER? Based on what you say you are doing it as a PEER, which you should not be doing. Please create an Openbridge and go that route. JJC
On Mon, Apr 20, 2020 at 12:42 PM <john.brazel225@...> wrote: MMDVM Bridge running on raspberry pi3, i have allstar and echolink working, and connected to brandmeister with no problems and the bridge does exactly what it supposed to do and functions perfect, however, every Sunday night/Monday morning, it will not connect to anything. I have the pi set to reboot every night at midnight, and upon reboot, a macro will get my bridge connected back to an echolink conference...Ecxept for the wee hours of Monday morning and most of the day Monday. I have completely started over twice with fresh installs and keep coming up with the same issue. I'm just lost on this one. Any Ideas?
|
|
Re: Changelog
I have posted armhf, arm64, armv6l i386 and amd64 to GitHub. (The full Monty) Last update to github: 04/26/2020 07:37:00 EST
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Mike Zingman - N4IRR <mike.zingman@...>
Sent: Monday, April 20, 2020 1:26:28 PM To: main@DVSwitch.groups.io <main@DVSwitch.groups.io> Subject: [DVSwitch] Changelog [Edited Message Follows] We just posted some changes to the components, here is the. changelog. Several of these changes will require significant doc for you to use so more to come:AB:
|
|
#mmdvm_bridge
#mmdvm_bridge
john.brazel225@...
MMDVM Bridge running on raspberry pi3, i have allstar and echolink working, and connected to brandmeister with no problems and the bridge does exactly what it supposed to do and functions perfect, however, every Sunday night/Monday morning, it will not connect to anything. I have the pi set to reboot every night at midnight, and upon reboot, a macro will get my bridge connected back to an echolink conference...Ecxept for the wee hours of Monday morning and most of the day Monday. I have completely started over twice with fresh installs and keep coming up with the same issue. I'm just lost on this one. Any Ideas?
Thanks, John KK4GXP
|
|
AB macro changes
Analog_Bridge macros have been updated to 1) support variables and 2) execute an OnRegister macro when registering a client
First OnRegister. This one is simple, every time a client (DVSM or pyUC) registers with AB the OnRegister macro (if it exists) will be executed. The macro could look like this:
[MACROS]
OnRegister=$DVSWITCH menu $AB_DIR/python/macros.txt
Why would I want to do this? You could use the event to set up a mode specific menu for the client (like I did above) or you could reset the current TG to a known starting place or you could execute a message to the client with server status (uptime, cpu load, temp, etc). The possibilities are endless.
Next are the macro variables. Actually they are no different than environment variables that can be set directly in your macro section and then exported to any shell created when a macro executes. The basic syntax is:
var MACRO_NAME = value
Simple. What happens here is an environment variable is created (just like BASH). You may then use that variable in one or many other macro commands or just let it be exported to your scripts.
As a simple export, you could let it define where you have placed important files in your system. For example, if you wanted to have a single variable to define the location of your custom scripts for AB you could:
var SCRIPT_DIR = $HOME/my_dvswitch_scripts
And then:
SOME_MACRO = $SCRIPT_DIR/my_script arg1 arg2
OTHER_MACRO = $SCRIPT_DIR/other_script arg1 arg2
Two substitutions would happen here. $SCRIPT_DIR would be replaced by $HOME/my_dvswitch_scripts. And then $HOME would be replaced by the users home directory. See how you would build these things up?
A more complex example. Right from my development machine:
var DVSWITCH=$AB_DIR/python/dvswitch.sh
var DVSWITCH_INI=$MMDVM_DIR/DVSwitch.ini
var TOAST=$DVSWITCH message
VERSION=$TOAST "`$DVSWITCH version`"
UPDATE=$DVSWITCH update;$TOAST "Database files have been updated"
TIME=$TOAST "Time is `date`"
TG=$TOAST "Current Talkgroup is `$DVSWITCH tune`"
I have created three variables which will make my life easier as I use them. The first is a simple $DVSWITCH which is replacement for the full path to my dvswitch.sh script. I can then use that nasty path to define a cool command $TOAST which I use to send messages to my DVSM client. Now I know many of you are NOT BASH programmers, so I get that this a rather esoteric change to AB. But for those of us who like to create scripts, this will make our life easier.
Also, don't forget that these variables are EXPORTED to your child shells when a macro is executed. You may have noticed a change in dvswitch.sh that will take the environment variables if they exist for AB_DIR, MMDVM_DIR and NODE_DIR. This will allow you to have several different AB.ini files each with different paths if you wanted.
Mike N4iRR
|
|
Re: Changelog
Kevin - W8KHW
Wow, you guys really have had cabin fever. Thank you! Kevin W8KHW
On Apr 20, 2020, at 1:28 PM, Mike Zingman - N4IRR <mike.zingman@...> wrote:
|
|
Re: Changelog
JJ Cummings
Awesome work Mike!
On Mon, Apr 20, 2020 at 11:28 AM Mike Zingman - N4IRR <mike.zingman@...> wrote:
|
|
Changelog
We just posted some changes to the components, here is the. changelog. Several of these changes will require significant doc for you to use so more to come:
AB:
|
|
Re: ASL <> DMR <> YSF inquiry?
#mmdvm_bridge
Hi Ernie!
Thanks for the inputs, where can i find sample config file or documentation about hblink connecting or bridging to YSF and DMR? Thanks! Andrew
|
|
Re: ASL <> DMR <> YSF inquiry?
#mmdvm_bridge
Asl<>AB<>MB<>Hblink3<>MB<>YSFReflector
|
|
ASL <> DMR <> YSF inquiry?
#mmdvm_bridge
andrew delgado
Hello!
how can i do this setup? ASL <> DMR <> YSF what are the tools do i need? i was able to setup ASL <> DMR now how can i add YSF reflector to have it ASL<>DMR <> YSF? what tools to i need? Thanks! Andrew
|
|
D-Star info from G4LKX
This message contains important information that I want disseminated far and wide please.
I have been approached by the people who run aprs.fi and REF001/REF030 (not the same people) about problems being caused by hotspots. This is down to usage and I hope that people will act on this information: 1. APRS, it is important that when configuring your hotspot, that you ensure that the suffix used for accessing aprs.fi is unique. For example if you use more than one hotspot, then ensure that for every mode and for every hotspot, the aprs.fi access callsign is unique. This is usually done by specifying a unique suffix to the callsign used by the hotspot. If more than one hotspot attempts to access aprs.fi with the same callsign+suffix combination, the first one is thrown off, and the new one connects. In the meantime the original one tries to connect and throw the new one off. This can happen multiple times per second, and is causing problems for them. Please, please, please, look at your configurations and if you have a duplicate, change one of them. 2. REF001/REF030, apparently the network load on these D-Star reflectors is now very high due to the number of hotspots connecting and staying connected. Could you please consider changing your gateway configuration so that you disconnect after a certain period of inactivity (this means local RF activity) so that they aren't overloaded. I know we like to listen out for activity, but we must also realise that D-Star popular reflectors const money to run, and that includes network and processor usage. A quick look at their dashboards will reveal the problem, they're huge. Jonathan G4KLX
|
|
Re: #analog_bridge #analog_bridge
#analog_bridge
toggle quoted messageShow quoted text
On 4/19/20 7:41 AM, Philippe wrote:
Help me to make working the application tx and Rx
|
|
#analog_bridge #analog_bridge
#analog_bridge
Help me to make working the application tx and Rx
|
|