Welcome to DVSwitch
DVSwitch is a set of tools and programs related to provisioning and operating Amateur Radio digital voice networks.
Purpose
The purpose of DVSwitch is as follows:
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).
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
Our stated position is:
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.
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: Troubleshooting ThumbDV HW AMBE chip with Analog_Bridge
David Ranch
Hello Steve,
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer I'm happy to report that this resolved my issue and the audio quality issue is resolved! If I can make a recommendation, on page 16 of https://docs.google.com/document/d/1eN50Csr29eAprBu7eKA0Bfa2XUcsXw5iktY1Ey-Qjkg/edit , consider adding tothe "Insert vocoder discussion here" section. Something like: - Enable the "Project 25 IMBE Encoder/Decoder Fixed-Point implementation" codec This is the default setting and generally has good audio quality Analog_Bridge.ini [GENERAL] decoderFallBack = true useEmulator = false [DV3000] ;server = /dev/ttyUSB0 ; Device of DV3000U on this machine ;port = 460800 ; Baud rate of the dongle ;serial = true ; Use serial (DV3000U) or IP - Enable the md380-emu codec This has good audio quality (possibly better than the IMBE software vocoder): Document how the md380-emu process will be started Analog_Bridge.ini [GENERAL] decoderFallBack = false useEmulator = true [DV3000] ;server = /dev/ttyUSB0 ; Device of DV3000U on this machine ;port = 460800 ; Baud rate of the dongle ;serial = true ; Use serial (DV3000U) or IP - Enable HW AMBE codec This is the default setting and generally has good audio quality (possibly better than the IMBE software vocoder): - Connect the HW device directly to your computer (no USB hubs if possible) - Edit the Analog_Bridge.ini [GENERAL] decoderFallBack = false useEmulator = false [DV3000] server = /dev/ttyUSB0 ; Device of DV3000U on this machine port = 460800 ; Baud rate of the dongle serial = true ; Use serial (DV3000U) or IP - If used with a Raspberry Pi and you experience audio issues: - When connected to the Raspberry Pi, run the "dmesg" command and confirm which serial port it's beeing seen as. The default is /dev/ttyUSB0 unless that device is already in use - Make sure that the serial RX/TX LEDs are lighting up on the USB device when receiving / transmitting signals - You might need to change your USB latency with: echo 1 | sudo tee /sys/bus/usb-serial/devices/ttyUSB0/latency_timer - Use a proper power supply for your Rpi as the AMBE chips are reknown for being very sensitive to voltage sags --David KI6ZHD
|
|
|
|
Re: Troubleshooting ThumbDV HW AMBE chip with Analog_Bridge
David Ranch
Hello Steve, Thanks for the reply. There are typically 2 issues with the ThumbDV on a RPi: Yes.. I saw that post. This is currently being driven by a 5.1v @ 2.5A supply which should be good but I'll try others. 2: FTDI latency, as root: Ok, I have the following: -- cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer 16 -- I'll change that down to 1 as recommended and I'll see what that does. Beyond that, I assume the versions I'm running, the Analog_Bridge config and log output looks good? --David KI6ZHD
|
|
|
|
Re: Troubleshooting ThumbDV HW AMBE chip with Analog_Bridge
David,
toggle quoted messageShow quoted text
There are typically 2 issues with the ThumbDV on a RPi: 1: Power, The ThumbDV is very sensitive to power drops See <https://dvswitch.groups.io/g/main/message/315?p=,,,20,0,0,0::relevance,,DV3000u,20,2,0,5521534> 2: FTDI latency, as root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer If the result is greater then 1 echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer 73, Steve N4IRS
On 9/6/19 12:32 AM, David Ranch wrote:
|
|
|
|
Troubleshooting ThumbDV HW AMBE chip with Analog_Bridge
David Ranch
Hello Everyone, I have a working DMR TG to Analog DVSwitch setup working here using the included "Project 25 IMBE Encoder/Decoder Fixed-Point implementation" SW emulation on an Rpi3B+. It was recommended to go with a hardware AMBE solution for the best audio quality so I bought a NWDigital ThumbDV. It seems things the new hardware is functioning: - ThumbDV seen as /dev/ttyUSB0 - ThumbDV LEDs light up when people are talking on the DMR talk group - No errors in dmesg - No errors shown from the Analog_Bridge output from STDOUT - Load on the Rpi is around 0.35 Yet the resulting analog audio is segmented up. When I say segmented up, I mean the audio is coming through but I'm hearing gaps in the analog audio every 300ms or so (a guess) and it seems to be substantially slowed down compared to the audio I hear on a DMR HT. What's especially interesting that at the end of a long transmission, the Rpi can be 15-20 seconds delayed though the pitch of the voice is still correct! That's some SERIOUS buffering that is not experienced when using the SW vocoder. I did some various research on the web and found the AMBEtest4.py script at: https://raw.githubusercontent.com/DVSwitch/Analog_Bridge/master/scripts/AMBEtest4.py but it seems this is a Python2 script but my Rpi only has Python3. I did install all the required Python modules and did port the various print statements to by Python3 compatible but I started getting into some difficult errors that I couldn't get past. Does anyone have a version of this that's Python3 compatible? Any other thoughts on why this might be happening? If I switch back to the SW IMBE vocoder, the analog audio is smooth with a average load of 0.90. --David KI6ZHD cat /etc/lsb-release LSB_VERSION=1.4 DISTRIB_ID=Arch DISTRIB_RELEASE=rolling DISTRIB_DESCRIPTION="Arch Linux" Linux ww6bay-asl 4.14.97-1-ARCH #1 SMP Tue Feb 5 20:10:34 UTC 2019 armv7l GNU/Linux Analog_Bridge.ini ---------------------------------------------------------------------------------------------------------------------------------- ; Analog_Bridge configuration file. ; This file should be placed in either /etc or it can be ; supplied as a path on the Analog_Bridge command line. ; General Section describes settings for Analog_Bridge itself. ; For RPI, don't forget to modprobe snd_pcm_oss to get the devices populated [GENERAL] logLevel = 2 ; Show messages and above 0=No logging, 1=Debug, 2=Message, 3=Info, 4=Warning, 5=Error, 6=Fatal ; Metadata management exportMetadata = true ; Export metadata to USRP partner (transcode setups require this) subscriberFile = /var/lib/dvswitch/subscriber_ids.csv ; DMR ID to callsign lookup data ; General vocoder setup information decoderFallBack = false ; Allow software AMBE decoding if a hardware decoder is not found useEmulator = false ; Use the MD380 AMBE emulator for AMBE72 (DMR/YSFN/NXDN) emulatorAddress = 127.0.0.1:2470 ; IP address and port of the server ; Audio devices are normally not needed when in gateway service. These devices should ; only be set when local monitor or dongle modes are required. outputAudioDevice = /dev/null ; Audio device /dev/null, /dev/dsp1, portaudio, etc inputAudioDevice = /dev/null ; Only used for dongle mode ; Below values are for using this as a local DMR dongle (no ASL needed) useMicrophone = false ; Use app as just a fancy dongle for DMR useVox = false ; If using dongle mode (useMicrophone), enable VOX voxDecay = 2 ; Hang time in seconds voxTrigger = 200 ; Value to trip PTT (0-32767) ; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC) [AMBE_AUDIO] server = 127.0.0.1 ; IP address of xx_Bridge.py fromDMRPort = 31100 ; was rxport; AMBE frames from xx_Bridge (should match "toGatewayPort" in xx_Bridge.cfg) toDMRPort = 31103 ; was txport; 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 = <removed> ; ID the DMR listener will see when Allstar people speak; the repeater's main DMR ID; ID to use when transmitting from Analog_Bridge repeaterID = <removed> ; private DMR ID used in the MMDVM bridge config; ID of source repeater txTg = 31075 ; 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 ; Color Code to assign DMR frames ; Information for USRP channel driver. This interface uses PCM to transfer audio information ; There are two typical configurations, ASL and Transcode. ASL (AllstarLink) is for analog clients connected ; to a digital network. Transcode is when Analog_Bridge actually points its PCM interfaces back at itself, ; causing a TLV <-- (pcm <--> pcm) --> TLV type of architecture. ; When using ASL, this matches the rpt.conf ASL file with a setting like: ; rxchannel = usrp/127.0.0.1:34001:32001 ; When Transcoding, make toASLPort equal to the other instance fromASLPort (crossover) [USRP] server = 127.0.0.1 ; IP address of Allstar/Asterisk toASLPort = 32001 ; Analog_Bridge <-- ASL fromASLPort = 34001 ; Analog_Bridge --> ASL aslAudio = AUDIO_UNITY ; Audio to ASL (AUDIO_UNITY, AUDIO_USE_AGC, AUDIO_USE_GAIN) agcGain = -20 ; Gain (in db) of the AGC filter dmrAudio = AUDIO_UNITY ; Audio from ASL (AUDIO_UNITY, AUDIO_USE_GAIN, AUDIO_BPF) dmrGain = 0.35 ; Gain factor of audio from ASL (0.0-1.0) ; Information for DV3000 hardware decoder ; There are two configuration modes: IP (AMBEServer) and serial (direct connect hardware) ; Use top server and port if using AMBEServer ; Use bottom server/port and serial = true if using the DV3000u (thumbdv) ; Did you run AMBETest4.py before using this? [DV3000] ; server = 127.0.0.1 ; IP address of AMBEServer ; port = 2460 ; Port of AMBEServer server = /dev/ttyUSB0 ; Device of DV3000U on this machine port = 460800 ; Baud rate of the dongle serial = true ; Use serial (DV3000U) or IP ---------------------------------------------------------------------------------------------------------------------------------- [root@ww6bay-asl Analog_Bridge]# /opt/Analog_Bridge/Analog_Bridge /opt/Analog_Bridge/Analog_Bridge.ini I: 2019-09-06 03:00:10.769 Analog Bridge Version 1.1 Wed 9 May 05:56:17 EDT 2018 I: 2019-09-06 03:00:10.769 Copyright (C) 2018 DVSwitch, INAD. I: 2019-09-06 03:00:10.769 Created by Mike N4IRR and Steve N4IRS I: 2019-09-06 03:00:10.769 Analog Bridge comes with ABSOLUTELY NO WARRANTY I: 2019-09-06 03:00:10.769 I: 2019-09-06 03:00:10.769 This software is for use on amateur radio networks only, I: 2019-09-06 03:00:10.770 it is to be used for educational purposes only. Its use on I: 2019-09-06 03:00:10.770 commercial networks is strictly prohibited. I: 2019-09-06 03:00:10.770 I: 2019-09-06 03:00:10.770 Analog Bridge is starting M: 2019-09-06 03:00:10.770 Setting [GENERAL] logLevel -> 2 M: 2019-09-06 03:00:10.770 Setting [GENERAL] exportMetadata -> true M: 2019-09-06 03:00:10.770 Setting [GENERAL] subscriberFile -> /var/lib/dvswitch/subscriber_ids.csv M: 2019-09-06 03:00:10.770 Setting [GENERAL] decoderFallBack -> false M: 2019-09-06 03:00:10.770 Setting [GENERAL] useEmulator -> false M: 2019-09-06 03:00:10.770 Setting [GENERAL] emulatorAddress -> 127.0.0.1:2470 M: 2019-09-06 03:00:10.770 Setting [GENERAL] outputAudioDevice -> /dev/null M: 2019-09-06 03:00:10.770 Setting [GENERAL] inputAudioDevice -> /dev/null M: 2019-09-06 03:00:10.770 Setting [GENERAL] useMicrophone -> false M: 2019-09-06 03:00:10.770 Setting [GENERAL] useVox -> false M: 2019-09-06 03:00:10.771 Setting [GENERAL] voxDecay -> 2 M: 2019-09-06 03:00:10.771 Setting [GENERAL] voxTrigger -> 200 M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] server -> 127.0.0.1 M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] fromDMRPort -> 31100 M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] toDMRPort -> 31103 M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] ambeMode -> DMR M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] minTxTimeMS -> 2000 M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] gatewayDmrId -> <removed> M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] repeaterID -> <removed> M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] txTg -> 31075 M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] txTs -> 2 M: 2019-09-06 03:00:10.771 Setting [AMBE_AUDIO] colorCode -> 1 M: 2019-09-06 03:00:10.771 Setting [USRP] server -> 127.0.0.1 M: 2019-09-06 03:00:10.771 Setting [USRP] toASLPort -> 32001 M: 2019-09-06 03:00:10.771 Setting [USRP] fromASLPort -> 34001 M: 2019-09-06 03:00:10.771 Setting [USRP] aslAudio -> AUDIO_UNITY M: 2019-09-06 03:00:10.771 Setting [USRP] agcGain -> -20 M: 2019-09-06 03:00:10.771 Setting [USRP] dmrAudio -> AUDIO_UNITY M: 2019-09-06 03:00:10.771 Setting [USRP] dmrGain -> 0.35 M: 2019-09-06 03:00:10.771 Setting [DV3000] server -> /dev/ttyUSB0 M: 2019-09-06 03:00:10.771 Setting [DV3000] port -> 460800 M: 2019-09-06 03:00:10.772 Setting [DV3000] serial -> true W: 2019-09-06 03:00:10.772 ioctl reset error W: 2019-09-06 03:00:10.772 ioctl speed error W: 2019-09-06 03:00:10.772 ioctl stereo error W: 2019-09-06 03:00:10.772 ioctl setfmt error M: 2019-09-06 03:00:10.772 Audio In/Out Device: /dev/null I: 2019-09-06 03:00:10.772 Open UDP listener on 127.0.0.1:31100 I: 2019-09-06 03:00:10.772 Open USRP on 127.0.0.1:32001 M: 2019-09-06 03:00:10.772 Connecting to DV3000 hardware...... M: 2019-09-06 03:00:10.808 Begin DV3000 decode Project 25 IMBE Encoder/Decoder Fixed-Point implementation Developed by Pavel Yazev E-mail: pyazev@... Version 1.0 (c) Copyright 2009 This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; see the file ``LICENSE'' for details. I: 2019-09-06 03:00:10.808 Subscriber IDs loaded: 0 I: 2019-09-06 03:00:10.808 Default extended metadata <3107955> I: 2019-09-06 03:00:10.809 Using hardware AMBE vocoder I: 2019-09-06 03:00:10.809 Starting Analog_Bridge --> USRP thread I: 2019-09-06 03:00:10.809 Open UDP listener on 127.0.0.1:34001 I: 2019-09-06 03:00:10.809 Starting USRP --> HB_Bridge thread
|
|
|
|
Re: Jackhammer Sound
Chris K7AZ
I double checked the md-380.emu and then rebooted. After that, it worked again without jack hammer. Cue Twilight Zone music :) Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message -------- From: Waldek SP2ONG <sp2ong@...> Date: 8/31/19 23:22 (GMT-08:00) To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] Jackhammer Sound Sometimes it helped me solve this problem with changing the port of md380 from 2470 to for example 2450 The port number is defined in /lib/systemd/system/md380-emu.services change ExecStart=/opt/md380-emu/md380-emu -S 2470 to ExecStart=/opt/md380-emu/md380-emu -S 2450 restart md3800emu systemctl restart md380-emu and change in Analog_Bridge.ini from emulatorAddress = 127.0.0.1:2470 to emulatorAddress = 127.0.0.1:2450 restart analog bridge systemctl restart analog_bridge On Sat, Aug 31, 2019 at 08:24 PM, Chris K7AZ wrote: jackhammer
|
|
|
|
Re: YSFN -- > Wires X Not keying up
Skyler Fennell
Why are you bridging anything to SD all star hub ysfreflector or dmr without permission. Thank you charles WV8CW On Fri, Aug 30, 2019 at 2:49 PM Charles Wiant via Groups.Io <kd8itc=aol.com@groups.io> wrote:
|
|
|
|
Re: Jackhammer Sound
SP2ONG Waldek
Hi,
toggle quoted messageShow quoted text
Sometimes it helped me solve this problem with changing the port of md380 from 2470 to for example 2450 The port number is defined in /lib/systemd/system/md380-emu.services change ExecStart=/opt/md380-emu/md380-emu -S 2470 to ExecStart=/opt/md380-emu/md380-emu -S 2450 restart md3800emu systemctl restart md380-emu and change in Analog_Bridge.ini from emulatorAddress = 127.0.0.1:2470 to emulatorAddress = 127.0.0.1:2450 restart analog bridge systemctl restart analog_bridge
On Sat, Aug 31, 2019 at 08:24 PM, Chris K7AZ wrote:
jackhammer
|
|
|
|
Re: Jackhammer Sound
Chris K7AZ
Hi Steve, Also battling the jackhammer thing. Can you send clip of A_B.ini showing where to disable the MD380? Thanks, Chris K7AZ Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message -------- From: Steve N4IRS <szingman@...> Date: 8/2/19 13:44 (GMT-08:00) To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] Jackhammer Sound On 8/2/19 4:43 PM, Jeff Lehman, N8ACL via Groups.Io wrote: > Any thoughts on where I should start? I agree that it would sound much > better, but I have no idea where to start with that one... > > On 8/2/19 4:42 PM, Steve N4IRS wrote: >> Your best bet is to try to troubleshoot md380-emu since it will sound >> better then the built in OP25. (for DMR, YSFn, NXDN and definitive >> D-Star) >> >> On 8/2/19 4:39 PM, Jeff Lehman, N8ACL via Groups.Io wrote: >>> ooops.....Lemme try again.... >>> >>> That did it....I stopped the md380-emu and disabled it in the >>> bridge. it is working now. >>> >>> Thanks Steve.... >>> >>> Jeff, N8ACL >>> >>> On 8/2/19 4:26 PM, Steve N4IRS wrote: >>>> Did you disable use emulator in AB.ini? >>>> >>>> On 8/2/19 4:09 PM, Jeff Lehman, N8ACL via Groups.Io wrote: >>>>> I stopped it and still got the jackhammer..... >>>>> >>>>> I checked status of the Emulator.... >>>>> >>>>> systemctl status md380-emu >>>>> * md380-emu.service - MD-380 Emulator Service >>>>> Loaded: loaded (/lib/systemd/system/md380-emu.service; enabled; >>>>> vendor preset: enabled) >>>>> Active: activating (auto-restart) (Result: exit-code) since Fri >>>>> 2019-08-02 20:09:04 UTC; 209ms ago >>>>> Process: 673 ExecStart=/opt/md380-emu/md380-emu -S 2470 >>>>> (code=exited, status=203/EXEC) >>>>> Main PID: 673 (code=exited, status=203/EXEC) >>>>> md380-emu.service: Failed with result 'exit-code'. >>>>> >>>>> On 8/2/19 4:01 PM, Steve N4IRS wrote: >>>>>> That would be my guess. Turn off the emulator and retest. >>>>>> >>>>>> On 8/2/19 3:59 PM, Jeff Lehman, N8ACL via Groups.Io wrote: >>>>>>> HI all, >>>>>>> >>>>>>> I just did an install of another bridge and I am getting this >>>>>>> weird sound. Background.... >>>>>>> >>>>>>> I am building a DMR<--> ASL bridge on a VM. I have one system on >>>>>>> one VM and the Bridge on another. I am using USRP to connect >>>>>>> from the main ASL system to the VM/Bridge. I have done this >>>>>>> before with a YSF reflector, using USRP to connect to AB on a >>>>>>> second VM with the YSF reflector running on it with MB. >>>>>>> >>>>>>> I have AB and MB on the bridge VM and have USRP connected >>>>>>> properly. When I key up I can see the traffic flow in the right >>>>>>> directions. >>>>>>> >>>>>>> Problem is, I get this jackhammer, almost grinding sound when I >>>>>>> key up from Either end. If i key from ASL, I have the grinding >>>>>>> on DMR. Same thing if I key from the radio going to ASL. >>>>>>> >>>>>>> This has happened before in the past and I was able to reload >>>>>>> the system from a snapshot and the problem went away. My gut >>>>>>> says it's something maybe with md380-emu? >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Jeff, N8ACL >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >> >> >> >>
|
|
|
|
Re: YSFN -- > Wires X Not keying up
Charles Wiant
Why are you bridging anything to SD all star hub ysfreflector or dmr without permission. Thank you charles WV8CW
toggle quoted messageShow quoted text
On Aug 30, 2019, at 1:18 AM, Ernie Gm7kbk <erniepratt@...> wrote:
|
|
|
|
Re: YSFN -- > Wires X Not keying up
Skyler Fennell
The update did fix it. This was a bug in MMDVM_Bridge. Can someone tell me exactly what the bug was and why it caused some radios to not hear the signal through? Just because I am curios Does anybody have breakdown of the bits of YSF protocol metadata?
On Fri, Aug 30, 2019 at 8:20 AM Skyler Fennell via Groups.Io <electricity440=gmail.com@groups.io> wrote:
|
|
|
|
Re: YSFN -- > Wires X Not keying up
Skyler Fennell
I'm still on Debian Jessie. I need to update at some point wget libstdc++6 http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.10_amd64.deb
sudo dpkg --force-all -i libstdc++6
On Fri, Aug 30, 2019 at 7:19 AM Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: YSFN -- > Wires X Not keying up
No it is not. Show output of uname -a and which binary you are running. Also output of cat /etc/debian.version
Sent via smoke signal (AT&T)
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Skyler Fennell <electricity440@...>
Sent: Friday, August 30, 2019 8:11:01 AM To: main@dvswitch.groups.io <main@dvswitch.groups.io> Subject: Re: [DVSwitch] YSFN -- > Wires X Not keying up Is there source code available so I can compile myself? I am not able to run the latest versions due to this error--
usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./MMDVM_Bridge.amd64) On Fri, Aug 30, 2019 at 12:18 AM Ernie Gm7kbk <erniepratt@...> wrote:
Use the latest version of Analog_Bridge and MMDVM_Bridge.
|
|
|
|
Re: YSFN -- > Wires X Not keying up
Skyler Fennell
Is there source code available so I can compile myself? I am not able to run the latest versions due to this error--
usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./MMDVM_Bridge.amd64)
On Fri, Aug 30, 2019 at 12:18 AM Ernie Gm7kbk <erniepratt@...> wrote: Use the latest version of Analog_Bridge and MMDVM_Bridge.
|
|
|
|
Re: YSFN -- > Wires X Not keying up
Use the latest version of Analog_Bridge and MMDVM_Bridge.
|
|
|
|
YSFN -- > Wires X Not keying up
Skyler Fennell
I am running an RF link to bridge YSFReflector to WIRES-X. This RF link consists of a Pi-Star based image with a MCS2000 Radio as the link radio to convert between YSF and Wires X. I have a YSFReflector and am using MMDVM_Bridge and Analog_Bridge to bridge stuff into the reflector. What Works: USER ON HOTSPOT <--> YSFREFLECTOR <---> RF LINK < --- > REPEATER WITH WIRES X What Does NOT work ANALOG USER < --- > ANALOG_BRIDGE < -- > MMDVM_BRIDGE < ---- > YSFREFLECTOR <---> RF LINK < --- > REPEATER WITH WIRES X When it does not work, the symptom is the repeater repeats the audio just fine locally, but the WIRES-X box says "LOCAL ONLY" and does not network. Also What DOES Work, to check to see if it worked on someone else's system ANALOG USER << ----- >> AllStar South Dakota HUB < ---- > YSF REFLECTOR South Dakota HUB < --> RF LINK < --- > REPEATER WITH WIRES X. Also What Works ANALOG USER < --- > ANALOG_BRIDGE < -- > MMDVM_BRIDGE < ---- > YSFREFLECTOR <---> Digital Hotspot User I can't figure out what configuration setting might be wrong. Linked below are my bridge files: Analog_bridge: MMDVM_Bridge: Thanks for any help or useful information skyler
|
|
|
|
Re: HBlink3 OB use
area51now@...
Sorry I just realized i put this in the wrong section
|
|
|
|
HBlink3 OB use
area51now@...
Hello all have got stuck on getting the openbridge working, Branmister confirmed they see my connection but as of yet I am not able to get any traffic too or from BM, I was hoping one of the experts our here can take a look at my rules and ob set up to see if I have it correct.
BRIDGES = { 'BM-3102 Tac310': [ {'SYSTEM': 'OBP-1', 'TS': 1, 'TGID': 310, 'ACTIVE': True, 'TIMEOUT': 25, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, {'SYSTEM': 'MASTER-1', 'TS': 1, 'TGID': 310, 'ACTIVE': True, 'TIMEOUT': 25, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}, [OBP-1] MODE: OPENBRIDGE ENABLED: True IP: PORT: 62035 NETWORK_ID: 316111350 PASSPHRASE: xxxxxxx TARGET_IP: 3103.repeater.net TARGET_PORT: 62035 USE_ACL: True SUB_ACL: DENY:1 TGID_ACL: PERMIT:ALL Thank you Bob KB6LED
|
|
|
|
Re: Transcoders Per Linux Box?
Chris,
toggle quoted messageShow quoted text
There is no fixed limit. Depends on CPU, Memory etc. I would say a decent host could run more then you would need.
On 8/25/19 12:36 AM, Chris K7AZ via Groups.Io wrote:
Curios how many transcoders can be implemented in na Linux ASL box?
|
|
|
|
Transcoders Per Linux Box?
Chris K7AZ
Curios how many transcoders can be implemented in na Linux ASL box?
I am assuming different internal ports would be needed for each one? Thank you, Chris K7AZ DMR AARG - ASL 29837 so far…
|
|
|
|
Re: MMDVM_Bridge and Analog_Bridge log file name and timezone changes possible?
Well,
toggle quoted messageShow quoted text
It make no sense to me to restart asterisk when rotating the AB log. AB does not need a restart, so why bother? postrotate /usr/sbin/asterisk -rx 'logger reload' > /dev/null 2>&1 This says after the rotate (postrotate) reload the asterisk logger. You could restart AB, but again why bother.
On 8/24/19 5:40 PM, David Ranch wrote:
|
|
|