Date   

Re: MMDVM_BRIDGE Not Starting

fabio damiani
 

root@raspberrypi:/opt/MMDVM_Bridge# ./MMDVM_Bridge MMDVM_Bridge.ini
./MMDVM_Bridge: line 1: !DOCTYPE: No such file or directory
./MMDVM_Bridge: line 2: html: No such file or directory
./MMDVM_Bridge: line 3: head: No such file or directory
./MMDVM_Bridge: line 4: meta: No such file or directory
./MMDVM_Bridge: line 5: meta: No such file or directory
./MMDVM_Bridge: line 6: meta: No such file or directory
./MMDVM_Bridge: line 7: !--: No such file or directory
./MMDVM_Bridge: line 8: meta: No such file or directory
./MMDVM_Bridge: line 9: $'\r': command not found
./MMDVM_Bridge: line 10: meta: No such file or directory
./MMDVM_Bridge: line 11: meta: No such file or directory
./MMDVM_Bridge: line 12: meta: No such file or directory
./MMDVM_Bridge: line 13: $'\r': command not found
./MMDVM_Bridge: line 14: base: No such file or directory
./MMDVM_Bridge: line 15: syntax error near unexpected token `<'
'/MMDVM_Bridge: line 15: `        <!--[if lt IE 10]><script type="text/javascript">
root@raspberrypi:/opt/MMDVM_Bridge#
 


Re: MMDVM_BRIDGE Not Starting

Steve N4IRS
 

Try this as root:
cd /opt/MMDVM_Bridge
,/MMDVM_Bridge MMDVM_Bridge.ini

Please report the results.

Sent by smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of fabio damiani <iz2bks@...>
Sent: Tuesday, November 5, 2019 5:17:43 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: [DVSwitch] MMDVM_BRIDGE Not Starting
 
Hi everyone, I need a favor, I installed on raspberry DV-Switch, but the MMDVM_BRIDGE does not start and gives me this error.

mmdvm_bridge.service - MMDVM_Bridge Service
   Loaded: loaded (/lib/systemd/system/mmdvm_bridge.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-11-05 22:11:44 GMT; 18s ago
  Process: 551 ExecStart=/opt/MMDVM_Bridge/MMDVM_Bridge /opt/MMDVM_Bridge/MMDVM_Bridge.ini (code=exited, status=203/EXEC)
 Main PID: 551 (code=exited, status=203/EXEC)
 
Nov 05 22:11:44 raspberrypi systemd[1]: Started MMDVM_Bridge Service.
Nov 05 22:11:44 raspberrypi systemd[1]: mmdvm_bridge.service: Main process exited, code=exited, status=203/EXEC
Nov 05 22:11:44 raspberrypi systemd[1]: mmdvm_bridge.service: Unit entered failed state.
Nov 05 22:11:44 raspberrypi systemd[1]: mmdvm_bridge.service: Failed with result 'exit-code'.
root@raspberrypi:~#
Thanks for help


MMDVM_BRIDGE Not Starting

fabio damiani
 

Hi everyone, I need a favor, I installed on raspberry DV-Switch, but the MMDVM_BRIDGE does not start and gives me this error.

mmdvm_bridge.service - MMDVM_Bridge Service
   Loaded: loaded (/lib/systemd/system/mmdvm_bridge.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-11-05 22:11:44 GMT; 18s ago
  Process: 551 ExecStart=/opt/MMDVM_Bridge/MMDVM_Bridge /opt/MMDVM_Bridge/MMDVM_Bridge.ini (code=exited, status=203/EXEC)
 Main PID: 551 (code=exited, status=203/EXEC)
 
Nov 05 22:11:44 raspberrypi systemd[1]: Started MMDVM_Bridge Service.
Nov 05 22:11:44 raspberrypi systemd[1]: mmdvm_bridge.service: Main process exited, code=exited, status=203/EXEC
Nov 05 22:11:44 raspberrypi systemd[1]: mmdvm_bridge.service: Unit entered failed state.
Nov 05 22:11:44 raspberrypi systemd[1]: mmdvm_bridge.service: Failed with result 'exit-code'.
root@raspberrypi:~#
Thanks for help


Re: Analog_Bridge remote control (TLV) commands exposed.

Steve N4IRS
 

I have received a few direct questions about this topic. I would prefer questions be asked here so all can learn from the question / answer but I'll try to cover the subject here.

Some people are under the impression that the changes to Analog_Bridge and the addition of dvswitch.sh are for DVSwitch Mobile(DVSM) and USRP Client(UC). This could not be further from the truth. The first version of Analog_Bridge was built to provide a method of bridging AllStarLink(ASL) to the DMR networks. Analog_Bridge has it's roots in ASL and we always consider the impact of any change.

I believe most of the ASL to Digital bridges in use today are single mode. I expect mostly DMR but I'm sure there are other modes in use. To build a multi-mode ASL bridge required some script  jiu jitsu to change modes. The same method I used for the example multi-mode DVSM was used to change modes in a ASL to Digital bridge.
Create 5 copies of Analog_Bridge.ini (DMR.ini, YSF.ini, NXDN.ini, P25INI and DSTAR.ini
Edit each mode ini file to reflect the mode. Don't forget to set the TX and RX ports to match those defined in DVSwitch.ini.
Create 5 macros for ASL that copies the proper .ini file over Analog_Bridge.ini and restart Analog_Bridge.
Not elegant, but it works. I'll say it again, don't forget to set the proper TX and RX ports! 

Now let's do the same thing with dvswitch.sh:
Create 5 macros in ASL, each with a a single command and a parameter. dvswitch.sh mode DMR or dvswitch.sh mode YSF. You get the idea.
That's it. dvswitch.sh will read DVSwitch.ini then find the desired mode. dvswitch.sh will tell Analog_Bridge to change mode and ports to match the running instance of MMDVM_Bridge. That's it, you are now on a new mode.
So, you want to change to a different Talk Group or Reflector? Create a macro for ASL with the command dvswitch.sh tune 3112138 or dvswitch.sh tune ysfreflector.net:42000 and you are on the new Talk Group or Reflector.

Now let's get cute. I want ASL to tell me what mode and TG it's currently pointed at. dvswitch.sh is your friend here too. I won't build the whole script but in pseudo code:
ask dvswitch the current mode with dvswitch.sh mode (no parameter)
ask dvswitch.sh the current Talk Group with dvswitch.sh tune (no parameter)
take the results of those 2 commands and ask ASL to say "tuned to Talk Group $tg on mode $mode"

You get the idea. 

As we move forward with the fork of AllStarLink, we will expand the ability of AllStarLink to interact with Analog_Bridge. The first project will be to expand chan_usrp. The channel driver is simple and perfect to communicate more to Analog_Bridge. Some scripting will always be required but USRP has a lot of room to expand. If you have some ideas for what you would like to see join us in the subgroup for the fork <https://dvswitch.groups.io/g/DVSwitch-ASL>. Your ideas are welcome.


Re: AMBEserver on rPI for Analog_Bridge

Patrick Perdue
 

I did all the same stuff again a few hours later, with the ThumbDV connected to the Pi, and it works without break-ups this time. Don't know what changed. Oh well.

On 11/4/2019 9:27 PM, Steve N4IRS wrote:
I can tell you that both Mike and I have run a DV3000 on a remote Pi. Though only on a LAN on the same segment.

On 11/4/19 9:25 PM, Patrick Perdue wrote:
I did, and it was.

FWIW, I also tried the dongle on another x86 machine running Debian with the same results. I have not yet tried everything locally on that machine.


On 11/4/2019 9:23 PM, Steve N4IRS wrote:
Can I assume you verified on the machine with the DV3000, operation with AMBEtest4.py and the latency is 1?

Steve N4IRS

On 11/4/19 8:51 PM, Patrick Perdue wrote:
Got it working, but audio is extremely jittery (pretty much useless) between the remote AMBEserver and the Analog_Bridge. Latency is a very solid 3 MS across the internet between the box in my apartment and the server running DVSwitch. If I used BlueDV locally for DMR and D-STAR, all seems fine. I even tried it from my iPhone's hotspot, and it was good there, too.

I guess I can run DVSwitch locally, but was trying to avoid doing that.



On 11/3/2019 8:00 PM, Steve N4IRS wrote:
Patrick,
I would not suggest you use a powered hub. Plug the ThumbDV directly into the Pi.
The ThumbDV is very sensitive to power dips.
See this: <https://dvswitch.groups.io/g/main/message/315?p=,,,20,0,0,0::relevance,,DV3000U,20,2,0,5521534>

Fore USB latency:
As root:
cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
I expect it will return 16

Try this:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

If that works, add:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
to /etc/rc.local before the last line (exit 0)

73, Steve N4IRS

On 11/3/19 7:47 PM, Patrick Perdue wrote:
Hi:

A while back, I saw something on this group to the affect of changing timing to make the ThumbDV+AMBEserver combo work better on a Raspberry Pi, but I can't find it now after searching the archives for an hour.

Note that I haven't set this up yet -- still waiting for dongles to arrive. They should be here tomorrow.

I have DVSwitch and ASL running in the cloud, and want to use AMBEserver on a remote Raspberry Pi 4 2GB instead of md380-emu. I'm using a 3.5A power supply on the Pi 4. I'd like to host two dongles for two different, completely unrelated connection points, each with it's own AMBEserver, of course. This is just a dongle host, and won't be running DVSwitch itself.

The Pi is running stock Raspbian.

What should be done in order to optimize things with this setup? Should I still use a powered USB hub, as some have suggested? What about timing?

Thanks and 73

KE4DYI











Re: AMBEserver on rPI for Analog_Bridge

Steve N4IRS
 

I can tell you that both Mike and I have run a DV3000 on a remote Pi. Though only on a LAN on the same segment.

On 11/4/19 9:25 PM, Patrick Perdue wrote:
I did, and it was.

FWIW, I also tried the dongle on another x86 machine running Debian with the same results. I have not yet tried everything locally on that machine.


On 11/4/2019 9:23 PM, Steve N4IRS wrote:
Can I assume you verified on the machine with the DV3000, operation with AMBEtest4.py and the latency is 1?

Steve N4IRS

On 11/4/19 8:51 PM, Patrick Perdue wrote:
Got it working, but audio is extremely jittery (pretty much useless) between the remote AMBEserver and the Analog_Bridge. Latency is a very solid 3 MS across the internet between the box in my apartment and the server running DVSwitch. If I used BlueDV locally for DMR and D-STAR, all seems fine. I even tried it from my iPhone's hotspot, and it was good there, too.

I guess I can run DVSwitch locally, but was trying to avoid doing that.



On 11/3/2019 8:00 PM, Steve N4IRS wrote:
Patrick,
I would not suggest you use a powered hub. Plug the ThumbDV directly into the Pi.
The ThumbDV is very sensitive to power dips.
See this: <https://dvswitch.groups.io/g/main/message/315?p=,,,20,0,0,0::relevance,,DV3000U,20,2,0,5521534>

Fore USB latency:
As root:
cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
I expect it will return 16

Try this:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

If that works, add:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
to /etc/rc.local before the last line (exit 0)

73, Steve N4IRS

On 11/3/19 7:47 PM, Patrick Perdue wrote:
Hi:

A while back, I saw something on this group to the affect of changing timing to make the ThumbDV+AMBEserver combo work better on a Raspberry Pi, but I can't find it now after searching the archives for an hour.

Note that I haven't set this up yet -- still waiting for dongles to arrive. They should be here tomorrow.

I have DVSwitch and ASL running in the cloud, and want to use AMBEserver on a remote Raspberry Pi 4 2GB instead of md380-emu. I'm using a 3.5A power supply on the Pi 4. I'd like to host two dongles for two different, completely unrelated connection points, each with it's own AMBEserver, of course. This is just a dongle host, and won't be running DVSwitch itself.

The Pi is running stock Raspbian.

What should be done in order to optimize things with this setup? Should I still use a powered USB hub, as some have suggested? What about timing?

Thanks and 73

KE4DYI









Re: AMBEserver on rPI for Analog_Bridge

Patrick Perdue
 

I did, and it was.

FWIW, I also tried the dongle on another x86 machine running Debian with the same results. I have not yet tried everything locally on that machine.

On 11/4/2019 9:23 PM, Steve N4IRS wrote:
Can I assume you verified on the machine with the DV3000, operation with AMBEtest4.py and the latency is 1?

Steve N4IRS

On 11/4/19 8:51 PM, Patrick Perdue wrote:
Got it working, but audio is extremely jittery (pretty much useless) between the remote AMBEserver and the Analog_Bridge. Latency is a very solid 3 MS across the internet between the box in my apartment and the server running DVSwitch. If I used BlueDV locally for DMR and D-STAR, all seems fine. I even tried it from my iPhone's hotspot, and it was good there, too.

I guess I can run DVSwitch locally, but was trying to avoid doing that.



On 11/3/2019 8:00 PM, Steve N4IRS wrote:
Patrick,
I would not suggest you use a powered hub. Plug the ThumbDV directly into the Pi.
The ThumbDV is very sensitive to power dips.
See this: <https://dvswitch.groups.io/g/main/message/315?p=,,,20,0,0,0::relevance,,DV3000U,20,2,0,5521534>

Fore USB latency:
As root:
cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
I expect it will return 16

Try this:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

If that works, add:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
to /etc/rc.local before the last line (exit 0)

73, Steve N4IRS

On 11/3/19 7:47 PM, Patrick Perdue wrote:
Hi:

A while back, I saw something on this group to the affect of changing timing to make the ThumbDV+AMBEserver combo work better on a Raspberry Pi, but I can't find it now after searching the archives for an hour.

Note that I haven't set this up yet -- still waiting for dongles to arrive. They should be here tomorrow.

I have DVSwitch and ASL running in the cloud, and want to use AMBEserver on a remote Raspberry Pi 4 2GB instead of md380-emu. I'm using a 3.5A power supply on the Pi 4. I'd like to host two dongles for two different, completely unrelated connection points, each with it's own AMBEserver, of course. This is just a dongle host, and won't be running DVSwitch itself.

The Pi is running stock Raspbian.

What should be done in order to optimize things with this setup? Should I still use a powered USB hub, as some have suggested? What about timing?

Thanks and 73

KE4DYI








Re: AMBEserver on rPI for Analog_Bridge

Steve N4IRS
 

Can I assume you verified on the machine with the DV3000, operation with AMBEtest4.py and the latency is 1?

Steve N4IRS

On 11/4/19 8:51 PM, Patrick Perdue wrote:
Got it working, but audio is extremely jittery (pretty much useless) between the remote AMBEserver and the Analog_Bridge. Latency is a very solid 3 MS across the internet between the box in my apartment and the server running DVSwitch. If I used BlueDV locally for DMR and D-STAR, all seems fine. I even tried it from my iPhone's hotspot, and it was good there, too.

I guess I can run DVSwitch locally, but was trying to avoid doing that.



On 11/3/2019 8:00 PM, Steve N4IRS wrote:
Patrick,
I would not suggest you use a powered hub. Plug the ThumbDV directly into the Pi.
The ThumbDV is very sensitive to power dips.
See this: <https://dvswitch.groups.io/g/main/message/315?p=,,,20,0,0,0::relevance,,DV3000U,20,2,0,5521534>

Fore USB latency:
As root:
cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
I expect it will return 16

Try this:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

If that works, add:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
to /etc/rc.local before the last line (exit 0)

73, Steve N4IRS

On 11/3/19 7:47 PM, Patrick Perdue wrote:
Hi:

A while back, I saw something on this group to the affect of changing timing to make the ThumbDV+AMBEserver combo work better on a Raspberry Pi, but I can't find it now after searching the archives for an hour.

Note that I haven't set this up yet -- still waiting for dongles to arrive. They should be here tomorrow.

I have DVSwitch and ASL running in the cloud, and want to use AMBEserver on a remote Raspberry Pi 4 2GB instead of md380-emu. I'm using a 3.5A power supply on the Pi 4. I'd like to host two dongles for two different, completely unrelated connection points, each with it's own AMBEserver, of course. This is just a dongle host, and won't be running DVSwitch itself.

The Pi is running stock Raspbian.

What should be done in order to optimize things with this setup? Should I still use a powered USB hub, as some have suggested? What about timing?

Thanks and 73

KE4DYI






Re: AMBEserver on rPI for Analog_Bridge

Patrick Perdue
 

Got it working, but audio is extremely jittery (pretty much useless) between the remote AMBEserver and the Analog_Bridge. Latency is a very solid 3 MS across the internet between the box in my apartment and the server running DVSwitch. If I used BlueDV locally for DMR and D-STAR, all seems fine. I even tried it from my iPhone's hotspot, and it was good there, too.

I guess I can run DVSwitch locally, but was trying to avoid doing that.

On 11/3/2019 8:00 PM, Steve N4IRS wrote:
Patrick,
I would not suggest you use a powered hub. Plug the ThumbDV directly into the Pi.
The ThumbDV is very sensitive to power dips.
See this: <https://dvswitch.groups.io/g/main/message/315?p=,,,20,0,0,0::relevance,,DV3000U,20,2,0,5521534>

Fore USB latency:
As root:
cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
I expect it will return 16

Try this:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

If that works, add:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
to /etc/rc.local before the last line (exit 0)

73, Steve N4IRS

On 11/3/19 7:47 PM, Patrick Perdue wrote:
Hi:

A while back, I saw something on this group to the affect of changing timing to make the ThumbDV+AMBEserver combo work better on a Raspberry Pi, but I can't find it now after searching the archives for an hour.

Note that I haven't set this up yet -- still waiting for dongles to arrive. They should be here tomorrow.

I have DVSwitch and ASL running in the cloud, and want to use AMBEserver on a remote Raspberry Pi 4 2GB instead of md380-emu. I'm using a 3.5A power supply on the Pi 4. I'd like to host two dongles for two different, completely unrelated connection points, each with it's own AMBEserver, of course. This is just a dongle host, and won't be running DVSwitch itself.

The Pi is running stock Raspbian.

What should be done in order to optimize things with this setup? Should I still use a powered USB hub, as some have suggested? What about timing?

Thanks and 73

KE4DYI





Analog_Bridge remote control (TLV) commands exposed.

Steve N4IRS
 

Mike and I have been working on a utility to help people manage or control Analog_Bridge "on the fly" There are a number of reasons people would want to do this:

1: Change Talk Groups / Reflectors on the fly (tune)
2: Change to Digital Voice mode Analog_Bridge is in (mode)
3: Change audio levels (tlvAudio, usrpAudio)
4: Mute audio from Analog_Bridge (mute)
5: Notify DVSM/UC of the current configuration of Analog_Bridge
6: Display a message on the DVSM/UC screen

Commands can help you query current configuration and other troubleshooting.
Push updated data files (TG / Reflector lists) to DVSM/UC

These commands expand the capabilities of systems using Analog_Bridge.
In a ASL to DMR bridge, you can change talk groups without restarting Analog_Bridge.
With a DVSM system, you can change modes without having to restart Analog_Bridge.

Most commands take a parameter, for example mode:
mode {DMR|NXDN|P25|YSF|DSTAR}
The mode command without a parameter returns the current mode. This can be used in scripts as a variable. For example:

# Ask Analog_Bridge what is the current mode
mode=`./dvswitch.sh mode`
# Send a message (toast) to DVSM
./dvswitch.sh message "Changing to parrot $mode"

Below is the current list of commands.
root@omv:/opt/Analog_Bridge# ./dvswitch.sh

Usage:
./dvswitch.sh
         { mode | tune | ambesize | ambemode | slot | update | tlvAudio | usrpAudio | tlvPorts |
           info | show | lookup | mute | message |
           pushfile | collectProcessDataFiles | collectProcessPushDataFiles | pushurl | collectProcessPushDataFilesHTTP }
         tune {tg|reflector}                             Tune to specific TG/Reflector
         ambesize {72|88|49}                             Set number of bits for ambe data
         ambemode {DMR|NXDN|P25|YSFN|YSFW|DSTAR}         Set AMBE mode
         slot {1|2}                                      Set DMR slot to transmit on
         mode {DMR|NXDN|P25|YSF|DSTAR}                   Set Analog_Bridge digital mode
         update                                          Update callsign databases
         tlvAudio gain                                   Set AMBE audio gain
         usrpAudio gain                                  Set PCM audio gain
         tlvPorts rxport txport                          Set Analog_Bridge receive and transmit ports
         mute {OFF|USRP|TLV|BOTH}                        Cause Aanlog_Bridge to mute a stream
         info                                            Update ABInfo and send to DVSM/UC
         show                                            Pretty print the ABInfo json file
         lookup                                          Lookup a DMR ID/call in the local database
         message msg                                     Send a text message to DVSM/UC
         pushfile file                                   Push file to DVSM
         pushurl url                                     Push URL to DVSM
         collectProcessDataFiles                         Collect and prepare DVSM data files
         collectProcessPushDataFiles                     Collect, prepare and upload DVSM data files
         collectProcessPushDataFilesHTTP                 Collect, prepare and upload DVSM data files over http


Connect MMDVM_Bridge to XLX?

Florian Wolters
 

Morning folks,

ist it possible to hook up MMDVM_Bridge to an XLX Reflector directly?

vy73 de Florian DF2ET


Re: AMBEserver on rPI for Analog_Bridge

Steve N4IRS
 

Patrick,
I would not suggest you use a powered hub. Plug the ThumbDV directly into the Pi.
The ThumbDV is very sensitive to power dips.
See this: <https://dvswitch.groups.io/g/main/message/315?p=,,,20,0,0,0::relevance,,DV3000U,20,2,0,5521534>

Fore USB latency:
As root:
cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
I expect it will return 16

Try this:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer

If that works, add:
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
to /etc/rc.local before the last line (exit 0)

73, Steve N4IRS

On 11/3/19 7:47 PM, Patrick Perdue wrote:
Hi:

A while back, I saw something on this group to the affect of changing timing to make the ThumbDV+AMBEserver combo work better on a Raspberry Pi, but I can't find it now after searching the archives for an hour.

Note that I haven't set this up yet -- still waiting for dongles to arrive. They should be here tomorrow.

I have DVSwitch and ASL running in the cloud, and want to use AMBEserver on a remote Raspberry Pi 4 2GB instead of md380-emu. I'm using a 3.5A power supply on the Pi 4. I'd like to host two dongles for two different, completely unrelated connection points, each with it's own AMBEserver, of course. This is just a dongle host, and won't be running DVSwitch itself.

The Pi is running stock Raspbian.

What should be done in order to optimize things with this setup? Should I still use a powered USB hub, as some have suggested? What about timing?

Thanks and 73

KE4DYI



DV Switch and CDMA transcoding

N9UMJ
 

Has there been any experimentation using CDMA <> NXDN or TDMA attemps?
Ive been working with some equipment that uses CDMA and looking for any information of it being used in the amateur world?

Rick
N9umj


AMBEserver on rPI for Analog_Bridge

Patrick Perdue
 

Hi:

A while back, I saw something on this group to the affect of changing timing to make the ThumbDV+AMBEserver combo work better on a Raspberry Pi, but I can't find it now after searching the archives for an hour.

Note that I haven't set this up yet -- still waiting for dongles to arrive. They should be here tomorrow.

I have DVSwitch and ASL running in the cloud, and want to use AMBEserver on a remote Raspberry Pi 4 2GB instead of md380-emu. I'm using a 3.5A power supply on the Pi 4. I'd like to host two dongles for two different, completely unrelated connection points, each with it's own AMBEserver, of course. This is just a dongle host, and won't be running DVSwitch itself.

The Pi is running stock Raspbian.

What should be done in order to optimize things with this setup? Should I still use a powered USB hub, as some have suggested? What about timing?

Thanks and 73

KE4DYI


Re: Analog_Bridge and audio processing

Patrick Perdue
 

Steve:

I understand the concept of the shin. That's a bit beyond my skill set at the moment, but something like that which could host LADSPA plugins would be really cool.

Thanks for the tips on dynamically changing parameters with DVSwitch.


On 11/1/2019 10:34 AM, Steve N4IRS wrote:
Patrick,
The band pass filter is not configurable. I believe it's 300 to 3000 Hz. If you want to insert audio processing between Analog_Bridge and Asterisk, (The USRP channel driver) you might want to create a "shim" the shim would extract the PCM audio from the USRP data stream, make your adjustments and then rebuild the USRP data before sending on to ASL or Analog_Bridge in the other direction. This is a broad stroke of a idea and could be fleshed out.

I have seen your post on the HAMVIOP list and as Steve said, you can "steer" Analog_Bridge and MMDVM_Bridge via a external interface. The example he pointed you to is simple and we are putting the finishing touches on a script that would give users a simple commandline interface to changing parameters on the fly. Below is a partial list of comands.

Usage:
./dvswitch.sh   {mode | tune | ambesize | ambemode | update | tlvAudio | usrpAudio | tlvPorts | info | mute | message |
        pushfile | collectProcessDataFiles | collectProcessPushDataFiles | pushurl | collectProcessPushDataFilesHTTP}
         tune tg                                         tune to specific TG/Reflector
         ambesize
         ambemode {DMR|NXDN|P25|YSFN|YSFW|DSTAR}         Set AMBE mode
         mode {DMR|NXDN|P25|YSF|DSTAR}                   Set Analog_Bridge mode
         update                                          Update callsign databases
         tlvAudio gain                                   Set AMBE audio gain
         usrpAudio gain                                  Set PCM audio gain
         tlvPorts rxport txport                          Set Analog_Bridge receive and transmit ports
         mute {OFF|USRP|TLV|BOTH}                        Cause Aanlog_Bridge to mute a stream
         info                                            Update ABInfo and send to DVSM/UC
         message msg                                     Send a text message to DVSM/UC
         pushfile file                                   Push file to DVSM
         pushurl url                                     Push URL to DVSM
         collectProcessDataFiles                         Collect and prepare DVSM data files
         collectProcessPushDataFiles                     Collect, prepare and upload DVSM data files
         collectProcessPushDataFilesHTTP                 Collect, prepare and upload DVSM data files over http

We are adding more commands as we "expose" the TLV commands available. 

73, Steve N4IRS

On 10/29/2019 12:56 PM, Patrick Perdue wrote:
Hi all:

Yesterday, I configured a bridge between ASL and DMR using md380-emu. Everything is working great, but I'm wondering if I can improve audio quality on the ASL to DMR side other than just changing levels. I don't really like the sound of decoded audio from DMR on ASL, but I expect most of this is due to md380-emu. I have ordered more ThumbDV dongles, so that will probably help some in and of itself. Some is probably due to the entire stack working at 8 kHz. I haven't done any testing, but anecdotally, it seems that, on a real DMR radio, the vocoder is perhaps running at a higher sampling rate, though the audio itself is 8 kHz.

I noticed an Analog_Bridge option called USE_AUDIO_BPF, but couldn't find any info on it. I assume this is a band pass filter. Is it configurable, or fixed frequencies? If there are arguments, what does the syntax for this look like?

I'd ultimately like to use LADSPA effects to do things like downward expansion from ASL to DMR to clean up some low level noise before it hits the vocoder, maybe put a slight EQ or multi-band dynamics processing to fill out some of the low-end from analog radios. My thought, though I'm not sure how this would actually be done, is to pipe Analog_Bridge to SoX for real time processing, then back to another Analog_Bridge instance for the node. I'm just not sure of a good way to pipe raw PCM audio from A_B to stdin, so that SoX can process the audio, then pipe raw PCM audio post-processing to, I assume, a second A_B configured to send to the node

, or if this is even possible without a bunch of latency and a huge mess. Has anyone tried anything like this before?





Re: Analog_Bridge and audio processing

Steve N4IRS
 

Patrick,
The band pass filter is not configurable. I believe it's 300 to 3000 Hz. If you want to insert audio processing between Analog_Bridge and Asterisk, (The USRP channel driver) you might want to create a "shim" the shim would extract the PCM audio from the USRP data stream, make your adjustments and then rebuild the USRP data before sending on to ASL or Analog_Bridge in the other direction. This is a broad stroke of a idea and could be fleshed out.

I have seen your post on the HAMVIOP list and as Steve said, you can "steer" Analog_Bridge and MMDVM_Bridge via a external interface. The example he pointed you to is simple and we are putting the finishing touches on a script that would give users a simple commandline interface to changing parameters on the fly. Below is a partial list of comands.

Usage:
./dvswitch.sh   {mode | tune | ambesize | ambemode | update | tlvAudio | usrpAudio | tlvPorts | info | mute | message |
        pushfile | collectProcessDataFiles | collectProcessPushDataFiles | pushurl | collectProcessPushDataFilesHTTP}
         tune tg                                         tune to specific TG/Reflector
         ambesize
         ambemode {DMR|NXDN|P25|YSFN|YSFW|DSTAR}         Set AMBE mode
         mode {DMR|NXDN|P25|YSF|DSTAR}                   Set Analog_Bridge mode
         update                                          Update callsign databases
         tlvAudio gain                                   Set AMBE audio gain
         usrpAudio gain                                  Set PCM audio gain
         tlvPorts rxport txport                          Set Analog_Bridge receive and transmit ports
         mute {OFF|USRP|TLV|BOTH}                        Cause Aanlog_Bridge to mute a stream
         info                                            Update ABInfo and send to DVSM/UC
         message msg                                     Send a text message to DVSM/UC
         pushfile file                                   Push file to DVSM
         pushurl url                                     Push URL to DVSM
         collectProcessDataFiles                         Collect and prepare DVSM data files
         collectProcessPushDataFiles                     Collect, prepare and upload DVSM data files
         collectProcessPushDataFilesHTTP                 Collect, prepare and upload DVSM data files over http

We are adding more commands as we "expose" the TLV commands available. 

73, Steve N4IRS

On 10/29/2019 12:56 PM, Patrick Perdue wrote:
Hi all:

Yesterday, I configured a bridge between ASL and DMR using md380-emu. Everything is working great, but I'm wondering if I can improve audio quality on the ASL to DMR side other than just changing levels. I don't really like the sound of decoded audio from DMR on ASL, but I expect most of this is due to md380-emu. I have ordered more ThumbDV dongles, so that will probably help some in and of itself. Some is probably due to the entire stack working at 8 kHz. I haven't done any testing, but anecdotally, it seems that, on a real DMR radio, the vocoder is perhaps running at a higher sampling rate, though the audio itself is 8 kHz.

I noticed an Analog_Bridge option called USE_AUDIO_BPF, but couldn't find any info on it. I assume this is a band pass filter. Is it configurable, or fixed frequencies? If there are arguments, what does the syntax for this look like?

I'd ultimately like to use LADSPA effects to do things like downward expansion from ASL to DMR to clean up some low level noise before it hits the vocoder, maybe put a slight EQ or multi-band dynamics processing to fill out some of the low-end from analog radios. My thought, though I'm not sure how this would actually be done, is to pipe Analog_Bridge to SoX for real time processing, then back to another Analog_Bridge instance for the node. I'm just not sure of a good way to pipe raw PCM audio from A_B to stdin, so that SoX can process the audio, then pipe raw PCM audio post-processing to, I assume, a second A_B configured to send to the node

, or if this is even possible without a bunch of latency and a huge mess. Has anyone tried anything like this before?





Re: P25<>NXDN bridge

Steve N4IRS
 

Yes,
NXDN does require NXDN_Gateway. A single MMDVM_Bridge can do all of the modes at once. Just not 2 of the same mode.

Steve

On 10/31/19 4:03 PM, Russell, KV4S wrote:
Ahh that might be easier....
if they are both ambe could you set it like this ysf guide?

or do you need the 2 mmdvm bridges? 

On Thu, Oct 31, 2019 at 2:40 PM Steve N4IRS <szingman@...> wrote:
No,
Both DMR and NXDN are AMBE. No transcoder needed.

DMR Master <-> MMDVM_Bridge_a  <-> MMDVM_Bridge_b <-> NXDNGateway <-> NXDNReflector


On 10/31/2019 3:38 PM, Russell, KV4S wrote:
follow up question/direction would a NXDN to DMR bridge pretty much the same setup as that?

On Thu, Oct 31, 2019 at 2:28 PM Steve N4IRS <szingman@...> wrote:
It's going to require a transcoder.

P25Reflector <-> P25Gateway <-> MMDVM_Bridge_a <-> Analog_Bridge_P25 <-> Analog_Bridge_NXDN <-> MMDVM_Bridge_b <-> NXDNGateway <-> NXDNReflector

P25Reflector and NXDNReflector are external to the bridge. Consider them endpoints.
MMDVM_Bridge_a and MMDVM_Bridge_b are a single instance of MMDVM_Bridge.
Analog_Bridge_P25 and Analog_Bridge_NXDN are each a single instance.

Steve N4IRS

On 10/31/2019 3:04 PM, Russell, KV4S wrote:
Has anyone done a P25<>NXDN bridge? If so I'm looking for some guidance/instructions on how.

Thanks, 
Russell, KV4S




Re: Is there a way to do a dstar to analog bridge. If so could you give me an example to how that would look like. Thank you WV8CW

Steve N4IRS
 

idcddbgateway <-> MMDVM_Bridge <-> Analog_Bridge

On 10/31/19 4:39 PM, Charles Wiant via Groups.Io wrote:


Is there a way to do a dstar to analog bridge. If so could you give me an example to how that would look like. Thank you WV8CW

Charles Wiant
 


Re: P25<>NXDN bridge

 

Ahh that might be easier....
if they are both ambe could you set it like this ysf guide?

or do you need the 2 mmdvm bridges? 


On Thu, Oct 31, 2019 at 2:40 PM Steve N4IRS <szingman@...> wrote:
No,
Both DMR and NXDN are AMBE. No transcoder needed.

DMR Master <-> MMDVM_Bridge_a  <-> MMDVM_Bridge_b <-> NXDNGateway <-> NXDNReflector


On 10/31/2019 3:38 PM, Russell, KV4S wrote:
follow up question/direction would a NXDN to DMR bridge pretty much the same setup as that?

On Thu, Oct 31, 2019 at 2:28 PM Steve N4IRS <szingman@...> wrote:
It's going to require a transcoder.

P25Reflector <-> P25Gateway <-> MMDVM_Bridge_a <-> Analog_Bridge_P25 <-> Analog_Bridge_NXDN <-> MMDVM_Bridge_b <-> NXDNGateway <-> NXDNReflector

P25Reflector and NXDNReflector are external to the bridge. Consider them endpoints.
MMDVM_Bridge_a and MMDVM_Bridge_b are a single instance of MMDVM_Bridge.
Analog_Bridge_P25 and Analog_Bridge_NXDN are each a single instance.

Steve N4IRS

On 10/31/2019 3:04 PM, Russell, KV4S wrote:
Has anyone done a P25<>NXDN bridge? If so I'm looking for some guidance/instructions on how.

Thanks, 
Russell, KV4S


4001 - 4020 of 9087