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: MMDVM_Bridge and HBLink3 missing CALL END
SP2ONG Waldek
The previous dump of CALL END in my last post appears in HBLink, but below the CALL END dump does not appear in HBLink
M: 2019-06-27 08:44:52.374 YSF, received network end of transmission, 1.1 seconds, 0% packet loss, BER: 0.0% M: 2019-06-27 08:44:52.379 DMR, TX state = OFF, DMR frame count was 17 frames D: 2019-06-27 08:44:52.379 Network Transmitted D: 2019-06-27 08:44:52.379 0000: 44 4D 52 44 11 27 C7 EF 00 00 69 00 03 F9 66 A2 *DMRD.'....i...f.* D: 2019-06-27 08:44:52.379 0010: 9D BE E3 54 03 FF 0C 68 03 B4 3B E8 4A 80 3C E0 *...T...h..;.J.<.* D: 2019-06-27 08:44:52.379 0020: C4 AD 5D 7F 77 FD 75 79 66 B4 04 F8 2E 80 05 C0 *..].w.uyf.......* D: 2019-06-27 08:44:52.379 0030: 72 01 C2 81 FD 00 00 *r......* D: 2019-06-27 08:44:55.773 YSF Network Poll Sent D: 2019-06-27 08:44:55.773 0000: 59 53 46 50 53 52 34 42 49 20 20 20 20 20 *YSFPSR4BI *
|
|
|
|
Re: MMDVM_Bridge and HBLink3 missing CALL END
SP2ONG Waldek
OK ,I have dump
M: 2019-06-27 08:53:17.996 YSF, received network end of transmission, 3.9 seconds, 0% packet loss, BER: 0.0% M: 2019-06-27 08:53:18.001 DMR, TX state = OFF, DMR frame count was 62 frames D: 2019-06-27 08:53:18.001 Network Transmitted D: 2019-06-27 08:53:18.001 0000: 44 4D 52 44 3E 27 C7 EF 00 00 69 00 03 F9 66 A2 *DMRD>'....i...f.* D: 2019-06-27 08:53:18.002 0010: BF F1 C3 54 03 FF 0C 68 03 B4 3B E8 4A 80 3C E0 *...T...h..;.J.<.* D: 2019-06-27 08:53:18.002 0020: C4 AD 5D 7F 77 FD 75 79 66 B4 04 F8 2E 80 05 C0 *..].w.uyf.......* D: 2019-06-27 08:53:18.002 0030: 72 01 C2 81 FD 00 00 *r......* D: 2019-06-27 08:53:20.989 YSF Network Poll Sent D: 2019-06-27 08:53:20.989 0000: 59 53 46 50 53 52 34 42 49 20 20 20 20 20 *YSFPSR4BI * D: 2019-06-27 08:53:25.992 YSF Network Poll Sent D: 2019-06-27 08:53:25.992 0000: 59 53 46 50 53 52 34 42 49 20 20 20 20 20 *YSFPSR4BI *
|
|
|
|
Re: MMDVM_Bridge and HBLink3 missing CALL END
SP2ONG Waldek
Steve
I have turn on debug in [DMR Network] debug=1 and [System Fusion Network] debug=1 [Log] # Logging levels, 0=No logging, 1=Debug, 2=Message, 3=Info, 4=Warning, 5=Error, 6=Fatal DisplayLevel=1 FileLevel=2 But I did not see more than I put in my previous post M: 2019-06-27 08:14:17.647 YSF, received network data from SP5AWK to ALL at SR0DMR I: 2019-06-27 08:14:17.647 YSF, Lookup call SP5AWK returned id 2605325 -> 2605325 M: 2019-06-27 08:14:17.652 DMR, TX state = ON I: 2019-06-27 08:14:17.652 DMR, Begin TX: src=2605325 rpt=0 dst=105 slot=2 cc=0 metadata=SP5AWK M: 2019-06-27 08:14:18.503 YSF, received network end of transmission, 1.6 seconds, 0% packet loss, BER: 0.0% M: 2019-06-27 08:14:18.503 DMR, TX state = OFF, DMR frame count was 25 frames
|
|
|
|
Re: MMDVM_Bridge and HBLink3 missing CALL END
Please turn on debug in MMDVM_Bridge and capture the call end. Steve N4IRS
From: Waldek SP2ONG
Sent: Wednesday, June 26, 2019 1:09 PM To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] MMDVM_Bridge and HBLink3 missing CALL END
Sorry in a previous email I forgot to add 2 hours to a few lines form MMDVM_Bridge. The MMDVM_Bridge in the log use my local time -2 hours, the HBLink3 use local time
|
|
|
|
Re: MMDVM_Bridge and HBLink3 missing CALL END
SP2ONG Waldek
I have seen that the problem missing CALL END only appear from time to time
|
|
|
|
Re: Raspberry Pi 4
Meh.... The specs aren't too much of a significant increase to justify purchasing a new SBC. The DVSwitch suite performs well, even on lesser boards and servers. If I were to be doing some digital signage though, the dual HDMI ports would be great. Steve KC1AWV
On Wed, Jun 26, 2019, 2:21 PM Mike AE4ML <mike.lussier@...> wrote: Looking forward to testing the Raspberry Pi 4 in the next week on one of my repeaters. Has anyone else considering getting one of these for testing ?
|
|
|
|
Raspberry Pi 4
Looking forward to testing the Raspberry Pi 4 in the next week on one of my repeaters. Has anyone else considering getting one of these for testing ?
Mike AE4ML
|
|
|
|
Re: MMDVM_Bridge and HBLink3 missing CALL END
SP2ONG Waldek
Sorry in a previous email I forgot to add 2 hours to a few lines form MMDVM_Bridge. The MMDVM_Bridge in the log use my local time -2 hours, the HBLink3 use local time
M: 2019-06-26 11:27:08.027 YSF, received network data from SP9AP to ALL at SR0DMR I: 2019-06-26 11:27:08.027 YSF, Lookup call SP9AP returned id 2609383 -> 2609383 M: 2019-06-26 11:27:08.033 DMR, TX state = ON I: 2019-06-26 11:27:08.033 DMR, Begin TX: src=2609383 rpt=0 dst=105 slot=2 cc=0 metadata=SP9AP M: 2019-06-26 11:28:12.568 YSF, received network end of transmission, 64.5 seconds, 0% packet loss, BER: 0.0% M: 2019-06-26 11:28:12.574 DMR, TX state = OFF, DMR frame count was 1073 frames M: 2019-06-26 11:28:16.720 YSF, received network data from SP6SG to ALL at SR0DMR I: 2019-06-26 11:28:16.720 YSF, Lookup call SP6SG returned id 2606075 -> 2606075 M: 2019-06-26 11:28:16.725 DMR, TX state = ON I: 2019-06-26 11:28:16.725 DMR, Begin TX: src=2606075 rpt=0 dst=105 slot=2 cc=0 metadata=SP6SG M: 2019-06-26 11:28:57.999 YSF, received network end of transmission, 41.5 seconds, 0% packet loss, BER: 0.0% M: 2019-06-26 11:28:57.999 DMR, TX state = OFF, DMR frame count was 690 frames M: 2019-06-26 11:29:01.162 YSF, received network data from SP9AP to ALL at SR0DMR I: 2019-06-26 11:29:01.162 YSF, Lookup call SP9AP returned id 2609383 -> 2609383 M: 2019-06-26 11:29:01.167 DMR, TX state = ON I: 2019-06-26 11:29:01.167 DMR, Begin TX: src=2609383 rpt=0 dst=105 slot=2 cc=0 metadata=SP9AP M: 2019-06-26 11:29:06.812 YSF, received network end of transmission, 5.8 seconds, 0% packet loss, BER: 0.0% M: 2019-06-26 11:29:06.818 DMR, TX state = OFF, DMR frame count was 95 frames but in HBlink3 we don't have information about finish transmission: INFO 2019-06-26 11:27:08,033 (YSF-Polska) *CALL START* STREAM ID: 580626459 SUB: SP9AP (2609383) PEER: SR4BI (260454) TGID 105 (105), TS 2 INFO 2019-06-26 11:28:16,725 (YSF-Polska) *CALL START* STREAM ID: 1801842986 SUB: SP6SG (2606075) PEER: SR4BI (260454) TGID 105 (105), TS 2 INFO 2019-06-26 11:28:57,999 (YSF-Polska) *CALL END* STREAM ID: 1801842986 SUB: SP6SG (2606075) PEER: SR4BI (260454) TGID 105 (105), TS 2, Duration: 41.27 INFO 2019-06-26 11:29:01,167 (YSF-Polska) *CALL START* STREAM ID: 3220854634 SUB: SP9AP (2609383) PEER: SR4BI (260454) TGID 105 (105), TS 2
|
|
|
|
MMDVM_Bridge and HBLink3 missing CALL END
SP2ONG Waldek
I have use MMDVM_Bridge version:
2019-06-26 08:33:55.010 MMDVM_Bridge-20180423 is starting M: 2019-06-26 08:33:55.010 Built 10:47:32 Jun 24 2019 (GitID #30648ec) I have setup link to YSF Reflector and I have see that in the log MMDVM_Bridge exist info about end transmision (transmision DMR, TX state =OFF) for SP9AP: M: 2019-06-26 09:27:08.027 YSF, received network data from SP9AP to ALL at SR0DMR I: 2019-06-26 09:27:08.027 YSF, Lookup call SP9AP returned id 2609383 -> 2609383 M: 2019-06-26 09:27:08.033 DMR, TX state = ON I: 2019-06-26 09:27:08.033 DMR, Begin TX: src=2609383 rpt=0 dst=105 slot=2 cc=0 metadata=SP9AP M: 2019-06-26 09:28:12.568 YSF, received network end of transmission, 64.5 seconds, 0% packet loss, BER: 0.0% M: 2019-06-26 09:28:12.574 DMR, TX state = OFF, DMR frame count was 1073 frames M: 2019-06-26 09:28:16.720 YSF, received network data from SP6SG to ALL at SR0DMR I: 2019-06-26 09:28:16.720 YSF, Lookup call SP6SG returned id 2606075 -> 2606075 M: 2019-06-26 11:28:16.725 DMR, TX state = ON I: 2019-06-26 11:28:16.725 DMR, Begin TX: src=2606075 rpt=0 dst=105 slot=2 cc=0 metadata=SP6SG M: 2019-06-26 11:28:57.999 YSF, received network end of transmission, 41.5 seconds, 0% packet loss, BER: 0.0% M: 2019-06-26 11:28:57.999 DMR, TX state = OFF, DMR frame count was 690 frames M: 2019-06-26 11:29:01.162 YSF, received network data from SP9AP to ALL at SR0DMR I: 2019-06-26 11:29:01.162 YSF, Lookup call SP9AP returned id 2609383 -> 2609383 M: 2019-06-26 11:29:01.167 DMR, TX state = ON I: 2019-06-26 11:29:01.167 DMR, Begin TX: src=2609383 rpt=0 dst=105 slot=2 cc=0 metadata=SP9AP M: 2019-06-26 11:29:06.812 YSF, received network end of transmission, 5.8 seconds, 0% packet loss, BER: 0.0% M: 2019-06-26 11:29:06.818 DMR, TX state = OFF, DMR frame count was 95 frames but in HBlink3 we don't have information about finish transmission: INFO 2019-06-26 11:27:08,033 (YSF-Polska) *CALL START* STREAM ID: 580626459 SUB: SP9AP (2609383) PEER: SR4BI (260454) TGID 105 (105), TS 2 INFO 2019-06-26 11:28:16,725 (YSF-Polska) *CALL START* STREAM ID: 1801842986 SUB: SP6SG (2606075) PEER: SR4BI (260454) TGID 105 (105), TS 2 INFO 2019-06-26 11:28:57,999 (YSF-Polska) *CALL END* STREAM ID: 1801842986 SUB: SP6SG (2606075) PEER: SR4BI (260454) TGID 105 (105), TS 2, Duration: 41.27 INFO 2019-06-26 11:29:01,167 (YSF-Polska) *CALL START* STREAM ID: 3220854634 SUB: SP9AP (2609383) PEER: SR4BI (260454) TGID 105 (105), TS 2 but this problem appears not always
|
|
|
|
Re: setting up MMDVM_Bridge and Analog_Bridge
#analog_bridge
#mmdvm_bridge
Node750Tt
Hi Steve,
On my XLX server I have the following all able to run without errors: Ambed ircddbgateway MMDVM_Bridge I have a DVstick-33 with uses AMBE3003 plugged in my server and transcoding XRF DSTAR > XLX DMR & XLX DMR > XRF DSTAR I am trying to set up a TGIF Network TG, and to do this, I understand that Analog_Bridge is required. One Analog_Bridge_DStar.ini and One Analog_Bridge_DMR.ini. Neither of these ini are able to run as both Analog_Bridges are referencing DV3000. My device is DVstick-33. I know the baudrate and the ttyUSB port the DVstick -33 is on, I put this info into both .ini files and [DVstick-33] as the header, yet the program is still referencing DV3000. Which I think is hard written into the program. Is there away for Analog_Bridge program to work with this DVstick-33 using the AMBE3003? I had a quick look inside the program and only saw reference to DV3000. Thanks Jeff
|
|
|
|
Re: setting up MMDVM_Bridge and Analog_Bridge
#analog_bridge
#mmdvm_bridge
The DVStick-33 is compatible with AB right?
|
|
|
|
Re: HBlink rules.py
I think your setup is not possible. You have 3 times 'MASTER' - all in slot2 - as a peer. But only one connection at the same time is possible on each slot on the same peer. With the XLX the same problem. Only OpenBridge protocol can handle multiple connections on the same slot - peers cannot.
You need to rebuild the bridges or you define 3 different peer connection for master and 2 different peer connection for XLX and then bring all together. 73 Heiko, DL1BZ
|
|
|
|
Re: 1 Way Audio (XLX DMR to ASL)
N0KEG
FWIW, it looks like a new binary of MMDVM_bridge was committed yesterday. I downloaded the new binary and it seems like the 1 way problem has been fixed. Thanks!
|
|
|
|
Re: YSF -> DMR ID/Callsign Display
N0KEG
Just fixed the same problem here. The DMRIds.dat file that I had on the YSF reflector was some weird semicolon delimited format, not sure where exactly it came from but I thought it was the one that shipped with the YSF packages. When I updated the file to a newer and properly space delimited format all the IDs loaded and I now see callsigns on the dashboard.
|
|
|
|
Re: setting up MMDVM_Bridge and Analog_Bridge
#analog_bridge
#mmdvm_bridge
[GENERAL]
toggle quoted messageShow quoted text
decoderFallBack = true ; Allow software AMBE decoding if a hardware decoder is not found
On 6/24/2019 1:17 PM, Dexter Harroo
wrote:
Hi Steve, How do i enable the internal vocoder
|
|
|
|
Re: setting up MMDVM_Bridge and Analog_Bridge
#analog_bridge
#mmdvm_bridge
Hi Steve, How do i enable the internal vocoder
Do i have to modify Here?
|
|
|
|
Re: setting up MMDVM_Bridge and Analog_Bridge
#analog_bridge
#mmdvm_bridge
Dexter,
toggle quoted messageShow quoted text
If you are referring to the ambed from XLX, it will not work. AB does not support that server. If you are using DMR you can use the internal vocoder in AB or the md380-emu. Steve N4IRS
On 6/24/2019 12:54 PM, Dexter Harroo
wrote:
Hi Guys, having this issue when starting A_B,Error DV3000 not found aborting, we have AMBED server running and the devices plugged into the same box that is running AMBE server and the reflector, is there something in the settings that I'm missing?
|
|
|
|
Re: setting up MMDVM_Bridge and Analog_Bridge
#analog_bridge
#mmdvm_bridge
Hi Guys, having this issue when starting A_B,
Error DV3000 not found aborting, we have AMBED server running and the devices plugged into the same box that is running AMBE server and the reflector, is there something in the settings that I'm missing?
|
|
|
|
Re: MMDVM_Bridge
As I know from our DMRplus-sysops in Germany, they say you need to set in the options-line all 2 TS, TG not used need to be setup by zero. You have 5 TGs for slot1 and 5 TGs for slot2 and the option to setup a startup-reflektor.
|
|
|
|
Re: OhioLink YSF to DMR bridge update
You will need to replace the Analog_Bridge executable with one from
here. <https://github.com/DVSwitch/Analog_Bridge/tree/master/bin>
toggle quoted messageShow quoted text
On 6/23/19 12:54 PM, Tom Corcoran
wrote:
and to change TG's do I enter *3TG in DVSM or just the TG#?
|
|
|