Date   

Re: Let us say I am a NOOB (newbie)...

Fred Hillhouse
 

Hi David,

 

Yes it is weekly.

 

Also, when referring to something posting a while back that you are referring to, it is useful to have it in your email so others don’t have to search to understand context.

 

Best regards,

Fred N7FMH

 

 

From: main@DVSwitch.groups.io [mailto:main@DVSwitch.groups.io] On Behalf Of David Bodman
Sent: Wednesday, April 24, 2019 11:44 PM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Let us say I am a NOOB (newbie)...

 

So is this net every Saturday night? or Second Saturday of the month?


Virus-free. www.avast.com


Re: Let us say I am a NOOB (newbie)...

David Bodman
 

So is this net every Saturday night? or Second Saturday of the month?


Re: Audio stream of DMR talkgroup.

Mike Zingman - N4IRR
 
Edited

I would modify USRP_Audio to print the PCM values to either stdout or a named pipe and then you should be able to use the Lame encoder just as ASL does.


Re: Audio stream of DMR talkgroup.

Alexander DC5AJ
 

I would like to try it without ASL, something like: MMDVM_Bridge -> Analog_Bridge -> USRP_Audio ->Lame ->Ezstream . Can't figgure out a working solution, what is the best way to feed the audio from USRP_Audio into lame or oggenc ?

Alex
DC5AJ


Re: Audio stream of DMR talkgroup.

K3CHB
 

thanks guys!

On Mon, Apr 22, 2019 at 1:08 PM Jeff Lehman, KC8QCH <kc8qch@...> wrote:
You wouldn't even need to setup a public node if you didn't want to to use ASL. Set it up as a private node on your server and then viola.....no one could connect to the ASL node, but you would than have a dedicated audio stream and wouldn't even need to try to reconfigure AB or MMDVM to make it happen.

On Mon, Apr 22, 2019 at 12:47 PM Steve N4IRS <szingman@...> wrote:
See:
https://wiki.allstarlink.org/wiki/Broadcastify



--
Jeff Lehman, KC8QCH
E-mail: kc8qch@...
Hamshack Hotline: 4218

Webmaster
Hamilton County ARPSC
http://www.hamcoarpsc.org
E-mail: hamcoarpsc@...
Phone: 513-452-6480

Multimode System Administrator
World Wide Amateur Radio Guild
https://hamradiohub.com/
E-Mail: kc8qch@...


Re: Audio stream of DMR talkgroup.

Jeff Lehman, N8ACL
 

You wouldn't even need to setup a public node if you didn't want to to use ASL. Set it up as a private node on your server and then viola.....no one could connect to the ASL node, but you would than have a dedicated audio stream and wouldn't even need to try to reconfigure AB or MMDVM to make it happen.


On Mon, Apr 22, 2019 at 12:47 PM Steve N4IRS <szingman@...> wrote:
See:
https://wiki.allstarlink.org/wiki/Broadcastify



--
Jeff Lehman, KC8QCH
E-mail: kc8qch@...
Hamshack Hotline: 4218

Webmaster
Hamilton County ARPSC
http://www.hamcoarpsc.org
E-mail: hamcoarpsc@...
Phone: 513-452-6480

Multimode System Administrator
World Wide Amateur Radio Guild
https://hamradiohub.com/
E-Mail: kc8qch@...


Re: Audio stream of DMR talkgroup.

Steve N4IRS
 


Re: Audio stream of DMR talkgroup.

Steve N4IRS
 

Jimmy,
I do it with MMDVM_Bridge -> Analog_Bridge -> AllStar -> broadcastify.

I don't see why it could not be done with MMDVM_Bridge -> Analog_Bridge -> USRP_Audio -> Broadcastify.
It would be a matter of understanding how the analog audio is process in ASL to send it to Broadcastify:
outstreamcmd = /bin/sh,-c,/usr/bin/lame --preset cbr 16 -r -m m -s 8 --bitwidth 16 - - | /usr/bin/ezstream -qvc /etc/ezstream.xml
it is like this:
MMDVM_Bridge -> Analog_Bridge -> USRP_Audio -> lame -> ezstream -> Broadcastify.

Hope this helps,
73, Steve N4IRS

On 4/22/2019 11:59 AM, Jimmy Capizzi wrote:
Hello, I am trying to set up an audio stream of our DMR talk group for the internet, does anyone have any information on this? 

I am thinking this can be done with Analog_Bridge.

Thanks alot

Jimmy 
K3CHB


Audio stream of DMR talkgroup.

K3CHB
 

Hello, I am trying to set up an audio stream of our DMR talk group for the internet, does anyone have any information on this? 

I am thinking this can be done with Analog_Bridge.

Thanks alot

Jimmy 
K3CHB


Re: OpenBridge Server?

KB5PBM
 

Use iptables to trigger of a source port and route to a destination ip and port.  


Re: OpenBridge Server?

Cort N0MJS <n0mjs@...>
 

OBP does not have any concept of master or peer. Both ends are the same. There’s no difference.

On Apr 21, 2019, at 10:49 AM, Ted Freitas (KE6YJC) via Groups.Io <ted.freitas@...> wrote:

Hi Everyone,

Been using dmrlink, hblink to establish our own standalone system like we used to have when we were on the c-Bridge. I have to say since we got everything setup we are quite happy and it's been fun learning the new scripts / software to make this all possible. I do have a question though. In light of what has happened with the BM DDoS attack's we are trying to break our system apart into public / private services. Our setup consists of a c-Bridge for all our DMR MARC feeds, a IPSC Gateway running HB_Bridge / IPSC_Bridge and a routing gateway that ties the IPSC Network and HBP (MMDVM) networks together. I have been reading in the form how the OBP can pull feeds in from the BM network and see that its function is to push/pull feeds from a server. I was wondering if HBlink can be setup as an OBP master to allow me push our internet network feeds from our routing gateway over to a secondary routing gateway that would only be used for public hotspots?

I know this can be done with multiple HBlink instances but i was looking for a solution to route everything accross and not need to manage a 2nd rules file or another set of config files.

Thanks,
Ted/KE6YJC <msedge_f8VQfKTT0w.jpg>

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






OpenBridge Server?

 

Hi Everyone,

Been using dmrlink, hblink to establish our own standalone system like we used to have when we were on the c-Bridge. I have to say since we got everything setup we are quite happy and it's been fun learning the new scripts / software to make this all possible. I do have a question though. In light of what has happened with the BM DDoS attack's we are trying to break our system apart into public / private services. Our setup consists of a c-Bridge for all our DMR MARC feeds, a IPSC Gateway running HB_Bridge / IPSC_Bridge and a routing gateway that ties the IPSC Network and HBP (MMDVM) networks together. I have been reading in the form how the OBP can pull feeds in from the BM network and see that its function is to push/pull feeds from a server. I was wondering if HBlink can be setup as an OBP master to allow me push our internet network feeds from our routing gateway over to a secondary routing gateway that would only be used for public hotspots?

I know this can be done with multiple HBlink instances but i was looking for a solution to route everything accross and not need to manage a 2nd rules file or another set of config files.

Thanks,
Ted/KE6YJC


Re: DV Switch Mobile

Phil, G7OEA
 

Hi Mark,

I am running a raspberry pi 3 and the app together. The rpi3 connects to other hubs to access the all-star network. 

If you want help setting up a rpi3 with the app them you can email me. I am listed on QRZ.com

I also run MB7ILV and MB7ALV in the northwest..

73, phil


Re: Bridging a P25Reflector and a YSFReflector?

Steve N4IRS
 

Correct,
One MB and two AB (Transcoder) We are going forward with the change. No timeline yet but since MB is being worked on now it will be added.

Steve N4IRS


Re: The digital side of DVSwitch Mobile

N9UMJ
 

Steve

That sounds like a fantastic platform,  With work and travel I haven't been able to follow the progress of forums, This is something I'm very interested in learning more..Especially with my analog to digital project that I hope to start as soon as I wrap up a few other non-ham projects..Congratulations to you and the DV-Switch team on the progress and all of the time and hard work involved....Now for the important question?

What kind of beer?

Best Regards

Rick n9umj


On Fri, Apr 19, 2019 at 4:06 PM Steve N4IRS <szingman@...> wrote:

So, I am sure you think that we have gone dark on Mobile, but nothing is
further from the truth.  (We are actually on the beach drinking beer
spending the billions of dollars we made on the app so far.) While
development of the Allstar side has not stopped, we are spending quite a
lot of time on the digital side of Mobile.  The best way to think of
Mobile is as a full featured client for all of the DVSwitch portfolio of
applications.  Its job is to let you take DVSwitch with you wherever you
go.  Besides giving you access to the analog side by using Allstar,
Mobile now gives you access to all amateur digital voice modes (DMR,
D-Star, Yaesu Fusion narrow and wide, P25 and NXDN).  By leveraging the
capabilities of Analog_Bridge and MMDVM_Bridge you can roam wherever you
want and have all of your modes with you. The beauty of this is YOU
control the server. YOU setup the modes you want to use. It's YOUR
server. It is easier to list the features in bullet point format, so
here goes:

         •    Digital capabilities
         ⁃    All digital modes are supported for both receive and transmit
         ⁃    Digital Info
         ⁃    Metadata for each mode is displayed on the main “dialer”
screen
         ⁃    Each digital mode is color coded
         ⁃    Mode, TG/Reflector
         ⁃    Callsign and ID
         ⁃    TX/RX elapsed time
         ⁃    Talk group selection with incremental search
         ⁃    Full list of TG/Reflectors are available on the macro menu
         ⁃    Shortcuts to the first 10 are available for press and hold
on dialpad
         ⁃    Shortcut for mode on ‘A’ key
         ⁃    Shortcut for TGs on the ‘B’ key
         ⁃    Last heard list displays the last 50 stations heard
         ⁃    Personalized for your call sign and DMR/CCS7 ID
         •    General
         ⁃    Callsign lookup is done on the server side
         ⁃    Bluetooth and hardware PTT buttons supported (reported
working)
         ⁃    Network radio PTT Android intents (Inrico, Sonim, Hytera,
Senhaix, Radio-Tone, AOC)
         ⁃    Dedicated Bluetooth Microphones (iTalkie ZMIC)
         ⁃    Bluetooth LE (Pryme PTT-Z)
         ⁃    Macros may be invoked from the Mobile client and executed
on the server
         ⁃    Macros can change digital modes
         ⁃    Macros can invoke system functions
         ⁃    Nodes can be set up in the cloud or at your QTH which
includes NAT traversal capabilities for UDP
         ⁃    Bandwidth sipping codecs make it inexpensive to run all
the time
         ⁃    Rodger beep available on EOT
         ⁃    Backup and restore of user settings (soon)
         ⁃    The server has the capabilities to upload a new database
to the client when requested (soon)
         ⁃    Support for phones, tablets and network radio form factors

What do you need to make this cool stuff work?  Steve and I have been
playing with “hotspot builds” both on Intel and ARM and virtual and
physical hardware.  The components we run in these builds are
Analog_Bridge, MMDVM_Bridge, P25Gateway, NXDNGateway and IRCDDBGateway
(DMR and YSF do not need gateways).  In addition, md380-emu or a ThumbDV
is needed. If you go with the md380-emu, D-Star performance will be
severely degraded.  With these components in place, you can then use
DVSwitch Mobile to connect to any digital mode and steer that mode to
any talkgroup or reflector.

The magic happens because of two types of commands that are sent from
Mobile to the server.  First is a mode select command.  This command is
a macro which is interpreted by Analog_Bridge and used to enable the
proper settings within Analog_Bridge and MMDVM_Bridge. The macro
capabilities of Analog_Bridge let you run any script you want, and in
this case we have a script that is executed to change the mode to DMR,
DSTAR, YSF, P25 and NXDN.

The second type of command that Mobile sends is a Dial/Tune command. 
Analog_Bridge will take the command and forward it on to the
MMDVM_Bridge instance that is servicing the digital stream. Each mode
has a unique syntax for tuning.  For example DMR, P25 and NXDN use talk
group numbers to navigate, D-Star uses reflector names and YSF uses
reflector addresses and ports.  Mobile has a database for each mode with
the name of the talk group/reflector and the mode specific syntax to use.

To configure DVSwitch Mobile for digital access you just have to add a
new account to your app.  The account details are as follows:
     •    Protocol - USRP
     •    Hostname - IP address or host where Analog_Bridge is running
     •    Port - port number that matches Analog_Bridge.ini [USRP] TXPort
     •    TX Port - port number that matches Analog_Bridge.ini [USRP] RXPort
     •    Callsign - A valid ham radio callsign
     •    DMR ID - a valid DMR/CCS7 ID
     •    Autoload Node - does not need to be checked
     •    Transmit Level - We suggest you set this to no greater than
50% to start.  Use a Parrot to fine tune
     •    Receive Level - 100% is fine, adjust to taste
     •    Codec Types - Begin with Server Selected (unless on a very
limited network then use ADPCM)

The only setting that warrants additional information is the Port/TX
Port.  For best operation these ports should be equal.  When
Analog_Bridge sees equal port values it transitions into UDP traversal
mode.  This will allow you to set up your “node in the cloud” to be
behind a NAT router.  If behind a NAT, make sure to port forward the
selected port to your host running Analog_Bridge. Analog_Bridge and
Mobile will negotiate the session and keep it alive.






The digital side of DVSwitch Mobile

Steve N4IRS
 

So, I am sure you think that we have gone dark on Mobile, but nothing is further from the truth.  (We are actually on the beach drinking beer spending the billions of dollars we made on the app so far.) While development of the Allstar side has not stopped, we are spending quite a lot of time on the digital side of Mobile.  The best way to think of Mobile is as a full featured client for all of the DVSwitch portfolio of applications.  Its job is to let you take DVSwitch with you wherever you go.  Besides giving you access to the analog side by using Allstar, Mobile now gives you access to all amateur digital voice modes (DMR, D-Star, Yaesu Fusion narrow and wide, P25 and NXDN).  By leveraging the capabilities of Analog_Bridge and MMDVM_Bridge you can roam wherever you want and have all of your modes with you. The beauty of this is YOU control the server. YOU setup the modes you want to use. It's YOUR server. It is easier to list the features in bullet point format, so here goes:

        •    Digital capabilities
        ⁃    All digital modes are supported for both receive and transmit
        ⁃    Digital Info
        ⁃    Metadata for each mode is displayed on the main “dialer” screen
        ⁃    Each digital mode is color coded
        ⁃    Mode, TG/Reflector
        ⁃    Callsign and ID
        ⁃    TX/RX elapsed time
        ⁃    Talk group selection with incremental search
        ⁃    Full list of TG/Reflectors are available on the macro menu
        ⁃    Shortcuts to the first 10 are available for press and hold on dialpad
        ⁃    Shortcut for mode on ‘A’ key
        ⁃    Shortcut for TGs on the ‘B’ key
        ⁃    Last heard list displays the last 50 stations heard
        ⁃    Personalized for your call sign and DMR/CCS7 ID
        •    General
        ⁃    Callsign lookup is done on the server side
        ⁃    Bluetooth and hardware PTT buttons supported (reported working)
        ⁃    Network radio PTT Android intents (Inrico, Sonim, Hytera, Senhaix, Radio-Tone, AOC)
        ⁃    Dedicated Bluetooth Microphones (iTalkie ZMIC)
        ⁃    Bluetooth LE (Pryme PTT-Z)
        ⁃    Macros may be invoked from the Mobile client and executed on the server
        ⁃    Macros can change digital modes
        ⁃    Macros can invoke system functions
        ⁃    Nodes can be set up in the cloud or at your QTH which includes NAT traversal capabilities for UDP
        ⁃    Bandwidth sipping codecs make it inexpensive to run all the time
        ⁃    Rodger beep available on EOT
        ⁃    Backup and restore of user settings (soon)
        ⁃    The server has the capabilities to upload a new database to the client when requested (soon)
        ⁃    Support for phones, tablets and network radio form factors

What do you need to make this cool stuff work?  Steve and I have been playing with “hotspot builds” both on Intel and ARM and virtual and physical hardware.  The components we run in these builds are Analog_Bridge, MMDVM_Bridge, P25Gateway, NXDNGateway and IRCDDBGateway (DMR and YSF do not need gateways).  In addition, md380-emu or a ThumbDV is needed. If you go with the md380-emu, D-Star performance will be severely degraded.  With these components in place, you can then use DVSwitch Mobile to connect to any digital mode and steer that mode to any talkgroup or reflector.

The magic happens because of two types of commands that are sent from Mobile to the server.  First is a mode select command.  This command is a macro which is interpreted by Analog_Bridge and used to enable the proper settings within Analog_Bridge and MMDVM_Bridge. The macro capabilities of Analog_Bridge let you run any script you want, and in this case we have a script that is executed to change the mode to DMR, DSTAR, YSF, P25 and NXDN.

The second type of command that Mobile sends is a Dial/Tune command.  Analog_Bridge will take the command and forward it on to the MMDVM_Bridge instance that is servicing the digital stream. Each mode has a unique syntax for tuning.  For example DMR, P25 and NXDN use talk group numbers to navigate, D-Star uses reflector names and YSF uses reflector addresses and ports.  Mobile has a database for each mode with the name of the talk group/reflector and the mode specific syntax to use.

To configure DVSwitch Mobile for digital access you just have to add a new account to your app.  The account details are as follows:
    •    Protocol - USRP
    •    Hostname - IP address or host where Analog_Bridge is running
    •    Port - port number that matches Analog_Bridge.ini [USRP] TXPort
    •    TX Port - port number that matches Analog_Bridge.ini [USRP] RXPort
    •    Callsign - A valid ham radio callsign
    •    DMR ID - a valid DMR/CCS7 ID
    •    Autoload Node - does not need to be checked
    •    Transmit Level - We suggest you set this to no greater than 50% to start.  Use a Parrot to fine tune
    •    Receive Level - 100% is fine, adjust to taste
    •    Codec Types - Begin with Server Selected (unless on a very limited network then use ADPCM)

The only setting that warrants additional information is the Port/TX Port.  For best operation these ports should be equal.  When Analog_Bridge sees equal port values it transitions into UDP traversal mode.  This will allow you to set up your “node in the cloud” to be behind a NAT router.  If behind a NAT, make sure to port forward the selected port to your host running Analog_Bridge. Analog_Bridge and Mobile will negotiate the session and keep it alive.


Re: Bridging a P25Reflector and a YSFReflector?

2E0ISK
 

This sounds like a great solution. I am assuming this would mean only one instance of MB would be required (as with straight VW) but it would also handle YSFN pipe it via the transcoder and back in?


Re: Amazon Web Services (AWS) usage for reflectors

Tim Porter
 

Mike I would like too. 
Let's get in touch
74 de k4kwq tim

On Thu, Apr 18, 2019, 1:12 PM Mike, KI0IK <stupidfatkid@...> wrote:
John,

Have you considered hosting your reflector(s) in the Azure cloud?  I'm running a small Ubuntu VM in Azure (1 CPU, 1 GB RAM).  It's hosting a P25Reflector and a YSFReflector (they're bridged together with an instance of MMDVM_Bridge).  It's working well.  

Mike


Re: Amazon Web Services (AWS) usage for reflectors

leighton782@...
 

Thanks

However I am a complete Digital Virgin and all seems to be quite complex for an old man like me

Regards

Steve

On 18/04/2019 18:12, Mike, KI0IK wrote:
John,

Have you considered hosting your reflector(s) in the Azure cloud?  I'm running a small Ubuntu VM in Azure (1 CPU, 1 GB RAM).  It's hosting a P25Reflector and a YSFReflector (they're bridged together with an instance of MMDVM_Bridge).  It's working well.  

Mike


Re: Amazon Web Services (AWS) usage for reflectors

Mike, KI0IK
 

John,

Have you considered hosting your reflector(s) in the Azure cloud?  I'm running a small Ubuntu VM in Azure (1 CPU, 1 GB RAM).  It's hosting a P25Reflector and a YSFReflector (they're bridged together with an instance of MMDVM_Bridge).  It's working well.  

Mike

5321 - 5340 of 9096