Hi: In moving my DVSwitch to a local Raspberry Pi 4 rather than running it on the VPS, connecting to a remote AMBEserver, I'm running into a problem.
I now have audio going from DMR to USRP, but not the other way. It is bi-directional when running DVSwitch on the VPS.
Looking at the logs for Analog_Bridge, it doesn't appear to get audio from ASL, as there is nothing in the log when there is a transmission from Allstar.
In rpt.conf, I have:
rxchannel = USRP/0.0.0.0:34001:32001; GNU Radio interface USRP
In Analog_Bridge.ini:
[AMBE_AUDIO] address = 127.0.0.1 ; IP address of xx_Bridge txPort = 31103 ; Transmit TLV frames to partner on this port rxPort = 31100 ; Listen for TLV frames from partner on this port ambeMode = DMR ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW (encode PCM to this format) [USRP] address = xlx.borris.me ; IP address of USRP partner (Allstar/Asterisk or another Analog_Bridge) txPort = 32001 ; Transmit USRP frames on this port rxPort = 34001 ; Listen for USRP frames on this port
In DVSwitch.ini:
[DMR] Address = 127.0.0.1 ; Address to send AMBE TLV frames to (export) TXPort = 31100 ; Port to send AMBE TLV frames to (export) RXPort = 31103 ; Port to listen on (import) Slot = 2 ; Export slot
Here is a full log from Analog_Bridge. During this period, there were several Allstar transmissions, but they didn't make it to the log. Only DMR is seen.
I: 2019-11-17 05:23:55.512 Analog Bridge Version 1.4.1 Mon Nov 11 19:06:12 UTC 2019 I: 2019-11-17 05:23:55.513 Copyright (C) 2018 DVSwitch, INAD. I: 2019-11-17 05:23:55.513 Created by Mike N4IRR and Steve N4IRS I: 2019-11-17 05:23:55.513 Analog Bridge comes with ABSOLUTELY NO WARRANTY I: 2019-11-17 05:23:55.513 I: 2019-11-17 05:23:55.513 This software is for use on amateur radio networks only, I: 2019-11-17 05:23:55.513 it is to be used for educational purposes only. Its use on I: 2019-11-17 05:23:55.513 commercial networks is strictly prohibited. I: 2019-11-17 05:23:55.513 I: 2019-11-17 05:23:55.513 Analog Bridge is starting M: 2019-11-17 05:23:55.513 Setting [GENERAL] logLevel -> 2 M: 2019-11-17 05:23:55.513 Setting [GENERAL] subscriberFile -> /var/lib/dvswitch/subscriber_ids.csv M: 2019-11-17 05:23:55.513 Setting [GENERAL] exportMetadata -> true M: 2019-11-17 05:23:55.514 Setting [GENERAL] decoderFallBack -> true M: 2019-11-17 05:23:55.514 Setting [GENERAL] useEmulator -> false M: 2019-11-17 05:23:55.514 Setting [GENERAL] emulatorAddress -> 127.0.0.1:2470 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] address -> 127.0.0.1 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txPort -> 31103 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] rxPort -> 31100 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] ambeMode -> DMR M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] minTxTimeMS -> 2500 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] gatewayDmrId -> 3138495 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] repeaterID -> 3154444 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTg -> 31679 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTs -> 2 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] colorCode -> 1 M: 2019-11-17 05:23:55.514 Setting [USRP] address -> xlx.borris.me M: 2019-11-17 05:23:55.514 Setting [USRP] txPort -> 32001 M: 2019-11-17 05:23:55.514 Setting [USRP] rxPort -> 34001 M: 2019-11-17 05:23:55.514 Setting [USRP] usrpAudio -> AUDIO_UNITY M: 2019-11-17 05:23:55.515 Setting [USRP] usrpGain -> 1.10 M: 2019-11-17 05:23:55.515 Setting [USRP] tlvAudio -> AUDIO_UNITY M: 2019-11-17 05:23:55.515 Setting [USRP] tlvGain -> 0.35 M: 2019-11-17 05:23:55.515 Setting [DV3000] address -> 127.0.0.1 M: 2019-11-17 05:23:55.515 Setting [DV3000] rxPort -> 2460 I: 2019-11-17 05:23:55.515 Open UDP listener on 127.0.0.1:31100 I: 2019-11-17 05:23:55.515 Open USRP on xlx.borris.me:32001 M: 2019-11-17 05:23:55.515 Connecting to DV3000 hardware...... M: 2019-11-17 05:23:55.535 Begin DV3000 decode I: 2019-11-17 05:23:55.930 Subscriber IDs loaded: 146120 I: 2019-11-17 05:23:55.930 Default extended metadata <KE4DYI> I: 2019-11-17 05:23:55.931 Using hardware AMBE vocoder I: 2019-11-17 05:23:55.934 Connected to USRP xlx.borris.me:32001 I: 2019-11-17 05:23:55.935 Starting TLV --> Analog_Bridge (decoder) --> USRP thread I: 2019-11-17 05:23:55.935 Starting USRP --> Analog_Bridge (encoder) -> TLV thread I: 2019-11-17 05:24:06.913 Begin TX: src=3138495 rpt=0 dst=31679 slot=2 cc=0 call=KE4DYI I: 2019-11-17 05:24:39.132 Begin TX: src=3138495 rpt=0 dst=31679 slot=2 cc=0 call=KE4DYI I: 2019-11-17 05:24:58.271 Signal 2 received, exiting Analog_Bridge
What am I missing here?
Thanks and 73
de
KE4DYI
|
|
I forgot to mention that UDP 34001 and 31100 are forwarded through my local NAT to the Pi running DVSwitch.
|
|

Brad N8PC
in your Analog_Bridge.ini file turn your txPort and rxPort around.
txPort =31100 rxPort=31103
toggle quoted messageShow quoted text
On 11/17/2019 12:45 AM, Patrick Perdue wrote: Hi: In moving my DVSwitch to a local Raspberry Pi 4 rather than running it on the VPS, connecting to a remote AMBEserver, I'm running into a problem.
I now have audio going from DMR to USRP, but not the other way. It is bi-directional when running DVSwitch on the VPS.
Looking at the logs for Analog_Bridge, it doesn't appear to get audio from ASL, as there is nothing in the log when there is a transmission from Allstar.
In rpt.conf, I have:
rxchannel = USRP/0.0.0.0:34001:32001; GNU Radio interface USRP
In Analog_Bridge.ini:
[AMBE_AUDIO] address = 127.0.0.1 ; IP address of xx_Bridge txPort = 31103 ; Transmit TLV frames to partner on this port rxPort = 31100 ; Listen for TLV frames from partner on this port ambeMode = DMR ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW (encode PCM to this format) [USRP] address = xlx.borris.me ; IP address of USRP partner (Allstar/Asterisk or another Analog_Bridge) txPort = 32001 ; Transmit USRP frames on this port rxPort = 34001 ; Listen for USRP frames on this port
In DVSwitch.ini:
[DMR] Address = 127.0.0.1 ; Address to send AMBE TLV frames to (export) TXPort = 31100 ; Port to send AMBE TLV frames to (export) RXPort = 31103 ; Port to listen on (import) Slot = 2 ; Export slot
Here is a full log from Analog_Bridge. During this period, there were several Allstar transmissions, but they didn't make it to the log. Only DMR is seen.
I: 2019-11-17 05:23:55.512 Analog Bridge Version 1.4.1 Mon Nov 11 19:06:12 UTC 2019 I: 2019-11-17 05:23:55.513 Copyright (C) 2018 DVSwitch, INAD. I: 2019-11-17 05:23:55.513 Created by Mike N4IRR and Steve N4IRS I: 2019-11-17 05:23:55.513 Analog Bridge comes with ABSOLUTELY NO WARRANTY I: 2019-11-17 05:23:55.513 I: 2019-11-17 05:23:55.513 This software is for use on amateur radio networks only, I: 2019-11-17 05:23:55.513 it is to be used for educational purposes only. Its use on I: 2019-11-17 05:23:55.513 commercial networks is strictly prohibited. I: 2019-11-17 05:23:55.513 I: 2019-11-17 05:23:55.513 Analog Bridge is starting M: 2019-11-17 05:23:55.513 Setting [GENERAL] logLevel -> 2 M: 2019-11-17 05:23:55.513 Setting [GENERAL] subscriberFile -> /var/lib/dvswitch/subscriber_ids.csv M: 2019-11-17 05:23:55.513 Setting [GENERAL] exportMetadata -> true M: 2019-11-17 05:23:55.514 Setting [GENERAL] decoderFallBack -> true M: 2019-11-17 05:23:55.514 Setting [GENERAL] useEmulator -> false M: 2019-11-17 05:23:55.514 Setting [GENERAL] emulatorAddress -> 127.0.0.1:2470 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] address -> 127.0.0.1 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txPort -> 31103 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] rxPort -> 31100 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] ambeMode -> DMR M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] minTxTimeMS -> 2500 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] gatewayDmrId -> 3138495 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] repeaterID -> 3154444 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTg -> 31679 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTs -> 2 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] colorCode -> 1 M: 2019-11-17 05:23:55.514 Setting [USRP] address -> xlx.borris.me M: 2019-11-17 05:23:55.514 Setting [USRP] txPort -> 32001 M: 2019-11-17 05:23:55.514 Setting [USRP] rxPort -> 34001 M: 2019-11-17 05:23:55.514 Setting [USRP] usrpAudio -> AUDIO_UNITY M: 2019-11-17 05:23:55.515 Setting [USRP] usrpGain -> 1.10 M: 2019-11-17 05:23:55.515 Setting [USRP] tlvAudio -> AUDIO_UNITY M: 2019-11-17 05:23:55.515 Setting [USRP] tlvGain -> 0.35 M: 2019-11-17 05:23:55.515 Setting [DV3000] address -> 127.0.0.1 M: 2019-11-17 05:23:55.515 Setting [DV3000] rxPort -> 2460 I: 2019-11-17 05:23:55.515 Open UDP listener on 127.0.0.1:31100 I: 2019-11-17 05:23:55.515 Open USRP on xlx.borris.me:32001 M: 2019-11-17 05:23:55.515 Connecting to DV3000 hardware...... M: 2019-11-17 05:23:55.535 Begin DV3000 decode I: 2019-11-17 05:23:55.930 Subscriber IDs loaded: 146120 I: 2019-11-17 05:23:55.930 Default extended metadata <KE4DYI> I: 2019-11-17 05:23:55.931 Using hardware AMBE vocoder I: 2019-11-17 05:23:55.934 Connected to USRP xlx.borris.me:32001 I: 2019-11-17 05:23:55.935 Starting TLV --> Analog_Bridge (decoder) --> USRP thread I: 2019-11-17 05:23:55.935 Starting USRP --> Analog_Bridge (encoder) -> TLV thread I: 2019-11-17 05:24:06.913 Begin TX: src=3138495 rpt=0 dst=31679 slot=2 cc=0 call=KE4DYI I: 2019-11-17 05:24:39.132 Begin TX: src=3138495 rpt=0 dst=31679 slot=2 cc=0 call=KE4DYI I: 2019-11-17 05:24:58.271 Signal 2 received, exiting Analog_Bridge
What am I missing here?
Thanks and 73
de
KE4DYI
|
|
Hmm...
That doesn't make sense to me, because then the TX and RX ports match on both MMDVM_Bridge and Analog_Bridge. TX should go to RX of the other, which is how it is by default.
I did try it, which caused nothing to pass in either direction.
toggle quoted messageShow quoted text
On 11/17/2019 8:16 AM, Brad N8PC wrote: in your Analog_Bridge.ini file turn your txPort and rxPort around.
txPort =31100 rxPort=31103
On 11/17/2019 12:45 AM, Patrick Perdue wrote:
Hi: In moving my DVSwitch to a local Raspberry Pi 4 rather than running it on the VPS, connecting to a remote AMBEserver, I'm running into a problem.
I now have audio going from DMR to USRP, but not the other way. It is bi-directional when running DVSwitch on the VPS.
Looking at the logs for Analog_Bridge, it doesn't appear to get audio from ASL, as there is nothing in the log when there is a transmission from Allstar.
In rpt.conf, I have:
rxchannel = USRP/0.0.0.0:34001:32001; GNU Radio interface USRP
In Analog_Bridge.ini:
[AMBE_AUDIO] address = 127.0.0.1 ; IP address of xx_Bridge txPort = 31103 ; Transmit TLV frames to partner on this port rxPort = 31100 ; Listen for TLV frames from partner on this port ambeMode = DMR ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW (encode PCM to this format) [USRP] address = xlx.borris.me ; IP address of USRP partner (Allstar/Asterisk or another Analog_Bridge) txPort = 32001 ; Transmit USRP frames on this port rxPort = 34001 ; Listen for USRP frames on this port
In DVSwitch.ini:
[DMR] Address = 127.0.0.1 ; Address to send AMBE TLV frames to (export) TXPort = 31100 ; Port to send AMBE TLV frames to (export) RXPort = 31103 ; Port to listen on (import) Slot = 2 ; Export slot
Here is a full log from Analog_Bridge. During this period, there were several Allstar transmissions, but they didn't make it to the log. Only DMR is seen.
I: 2019-11-17 05:23:55.512 Analog Bridge Version 1.4.1 Mon Nov 11 19:06:12 UTC 2019 I: 2019-11-17 05:23:55.513 Copyright (C) 2018 DVSwitch, INAD. I: 2019-11-17 05:23:55.513 Created by Mike N4IRR and Steve N4IRS I: 2019-11-17 05:23:55.513 Analog Bridge comes with ABSOLUTELY NO WARRANTY I: 2019-11-17 05:23:55.513 I: 2019-11-17 05:23:55.513 This software is for use on amateur radio networks only, I: 2019-11-17 05:23:55.513 it is to be used for educational purposes only. Its use on I: 2019-11-17 05:23:55.513 commercial networks is strictly prohibited. I: 2019-11-17 05:23:55.513 I: 2019-11-17 05:23:55.513 Analog Bridge is starting M: 2019-11-17 05:23:55.513 Setting [GENERAL] logLevel -> 2 M: 2019-11-17 05:23:55.513 Setting [GENERAL] subscriberFile -> /var/lib/dvswitch/subscriber_ids.csv M: 2019-11-17 05:23:55.513 Setting [GENERAL] exportMetadata -> true M: 2019-11-17 05:23:55.514 Setting [GENERAL] decoderFallBack -> true M: 2019-11-17 05:23:55.514 Setting [GENERAL] useEmulator -> false M: 2019-11-17 05:23:55.514 Setting [GENERAL] emulatorAddress -> 127.0.0.1:2470 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] address -> 127.0.0.1 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txPort -> 31103 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] rxPort -> 31100 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] ambeMode -> DMR M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] minTxTimeMS -> 2500 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] gatewayDmrId -> 3138495 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] repeaterID -> 3154444 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTg -> 31679 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTs -> 2 M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] colorCode -> 1 M: 2019-11-17 05:23:55.514 Setting [USRP] address -> xlx.borris.me M: 2019-11-17 05:23:55.514 Setting [USRP] txPort -> 32001 M: 2019-11-17 05:23:55.514 Setting [USRP] rxPort -> 34001 M: 2019-11-17 05:23:55.514 Setting [USRP] usrpAudio -> AUDIO_UNITY M: 2019-11-17 05:23:55.515 Setting [USRP] usrpGain -> 1.10 M: 2019-11-17 05:23:55.515 Setting [USRP] tlvAudio -> AUDIO_UNITY M: 2019-11-17 05:23:55.515 Setting [USRP] tlvGain -> 0.35 M: 2019-11-17 05:23:55.515 Setting [DV3000] address -> 127.0.0.1 M: 2019-11-17 05:23:55.515 Setting [DV3000] rxPort -> 2460 I: 2019-11-17 05:23:55.515 Open UDP listener on 127.0.0.1:31100 I: 2019-11-17 05:23:55.515 Open USRP on xlx.borris.me:32001 M: 2019-11-17 05:23:55.515 Connecting to DV3000 hardware...... M: 2019-11-17 05:23:55.535 Begin DV3000 decode I: 2019-11-17 05:23:55.930 Subscriber IDs loaded: 146120 I: 2019-11-17 05:23:55.930 Default extended metadata <KE4DYI> I: 2019-11-17 05:23:55.931 Using hardware AMBE vocoder I: 2019-11-17 05:23:55.934 Connected to USRP xlx.borris.me:32001 I: 2019-11-17 05:23:55.935 Starting TLV --> Analog_Bridge (decoder) --> USRP thread I: 2019-11-17 05:23:55.935 Starting USRP --> Analog_Bridge (encoder) -> TLV thread I: 2019-11-17 05:24:06.913 Begin TX: src=3138495 rpt=0 dst=31679 slot=2 cc=0 call=KE4DYI I: 2019-11-17 05:24:39.132 Begin TX: src=3138495 rpt=0 dst=31679 slot=2 cc=0 call=KE4DYI I: 2019-11-17 05:24:58.271 Signal 2 received, exiting Analog_Bridge
What am I missing here?
Thanks and 73
de
KE4DYI
|
|
What is your dmr id number. I had mine original 1139899 and had to upgrade it to the 3146521 to make mine work
toggle quoted messageShow quoted text
On Sun, Nov 17, 2019, 9:10 AM Patrick Perdue <patrick@...> wrote:
Hmm...
That doesn't make sense to me, because then the TX and RX ports match on
both MMDVM_Bridge and Analog_Bridge. TX should go to RX of the other,
which is how it is by default.
I did try it, which caused nothing to pass in either direction.
On 11/17/2019 8:16 AM, Brad N8PC wrote:
> in your Analog_Bridge.ini file turn your txPort and rxPort around.
>
> txPort =31100
> rxPort=31103
>
>
>
> On 11/17/2019 12:45 AM, Patrick Perdue wrote:
>> Hi:
>> In moving my DVSwitch to a local Raspberry Pi 4 rather than running
>> it on the VPS, connecting to a remote AMBEserver, I'm running into a
>> problem.
>>
>> I now have audio going from DMR to USRP, but not the other way. It is
>> bi-directional when running DVSwitch on the VPS.
>>
>> Looking at the logs for Analog_Bridge, it doesn't appear to get audio
>> from ASL, as there is nothing in the log when there is a transmission
>> from Allstar.
>>
>>
>> In rpt.conf, I have:
>>
>> rxchannel = USRP/0.0.0.0:34001:32001; GNU Radio interface USRP
>>
>> In Analog_Bridge.ini:
>>
>> [AMBE_AUDIO]
>> address = 127.0.0.1 ; IP address of xx_Bridge
>> txPort = 31103 ; Transmit TLV frames to
>> partner on this port
>> rxPort = 31100 ; Listen for TLV frames from
>> partner on this port
>> ambeMode = DMR ; DMR, DMR_IPSC, DSTAR, NXDN,
>> P25, YSFN, YSFW (encode PCM to this format)
>> [USRP]
>> address = xlx.borris.me ; IP address of USRP
>> partner (Allstar/Asterisk or another Analog_Bridge)
>> txPort = 32001 ; Transmit USRP frames on
>> this port
>> rxPort = 34001 ; Listen for USRP frames on
>> this port
>>
>>
>> In DVSwitch.ini:
>>
>> [DMR]
>> Address = 127.0.0.1 ; Address to send AMBE TLV frames to
>> (export)
>> TXPort = 31100 ; Port to send AMBE TLV frames to
>> (export)
>> RXPort = 31103 ; Port to listen on (import)
>> Slot = 2 ; Export slot
>>
>>
>> Here is a full log from Analog_Bridge. During this period, there were
>> several Allstar transmissions, but they didn't make it to the log.
>> Only DMR is seen.
>>
>>
>> I: 2019-11-17 05:23:55.512 Analog Bridge Version 1.4.1 Mon Nov 11
>> 19:06:12 UTC 2019
>> I: 2019-11-17 05:23:55.513 Copyright (C) 2018 DVSwitch, INAD.
>> I: 2019-11-17 05:23:55.513 Created by Mike N4IRR and Steve N4IRS
>> I: 2019-11-17 05:23:55.513 Analog Bridge comes with ABSOLUTELY NO
>> WARRANTY
>> I: 2019-11-17 05:23:55.513
>> I: 2019-11-17 05:23:55.513 This software is for use on amateur radio
>> networks only,
>> I: 2019-11-17 05:23:55.513 it is to be used for educational purposes
>> only. Its use on
>> I: 2019-11-17 05:23:55.513 commercial networks is strictly prohibited.
>> I: 2019-11-17 05:23:55.513
>> I: 2019-11-17 05:23:55.513 Analog Bridge is starting
>> M: 2019-11-17 05:23:55.513 Setting [GENERAL] logLevel -> 2
>> M: 2019-11-17 05:23:55.513 Setting [GENERAL] subscriberFile ->
>> /var/lib/dvswitch/subscriber_ids.csv
>> M: 2019-11-17 05:23:55.513 Setting [GENERAL] exportMetadata -> true
>> M: 2019-11-17 05:23:55.514 Setting [GENERAL] decoderFallBack -> true
>> M: 2019-11-17 05:23:55.514 Setting [GENERAL] useEmulator -> false
>> M: 2019-11-17 05:23:55.514 Setting [GENERAL] emulatorAddress ->
>> 127.0.0.1:2470
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] address -> 127.0.0.1
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txPort -> 31103
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] rxPort -> 31100
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] ambeMode -> DMR
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] minTxTimeMS -> 2500
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] gatewayDmrId -> 3138495
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] repeaterID -> 3154444
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTg -> 31679
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTs -> 2
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] colorCode -> 1
>> M: 2019-11-17 05:23:55.514 Setting [USRP] address -> xlx.borris.me
>> M: 2019-11-17 05:23:55.514 Setting [USRP] txPort -> 32001
>> M: 2019-11-17 05:23:55.514 Setting [USRP] rxPort -> 34001
>> M: 2019-11-17 05:23:55.514 Setting [USRP] usrpAudio -> AUDIO_UNITY
>> M: 2019-11-17 05:23:55.515 Setting [USRP] usrpGain -> 1.10
>> M: 2019-11-17 05:23:55.515 Setting [USRP] tlvAudio -> AUDIO_UNITY
>> M: 2019-11-17 05:23:55.515 Setting [USRP] tlvGain -> 0.35
>> M: 2019-11-17 05:23:55.515 Setting [DV3000] address -> 127.0.0.1
>> M: 2019-11-17 05:23:55.515 Setting [DV3000] rxPort -> 2460
>> I: 2019-11-17 05:23:55.515 Open UDP listener on 127.0.0.1:31100
>> I: 2019-11-17 05:23:55.515 Open USRP on xlx.borris.me:32001
>> M: 2019-11-17 05:23:55.515 Connecting to DV3000 hardware......
>> M: 2019-11-17 05:23:55.535 Begin DV3000 decode
>> I: 2019-11-17 05:23:55.930 Subscriber IDs loaded: 146120
>> I: 2019-11-17 05:23:55.930 Default extended metadata <KE4DYI>
>> I: 2019-11-17 05:23:55.931 Using hardware AMBE vocoder
>> I: 2019-11-17 05:23:55.934 Connected to USRP xlx.borris.me:32001
>> I: 2019-11-17 05:23:55.935 Starting TLV --> Analog_Bridge (decoder)
>> --> USRP thread
>> I: 2019-11-17 05:23:55.935 Starting USRP --> Analog_Bridge (encoder)
>> -> TLV thread
>> I: 2019-11-17 05:24:06.913 Begin TX: src=3138495 rpt=0 dst=31679
>> slot=2 cc=0 call=KE4DYI
>> I: 2019-11-17 05:24:39.132 Begin TX: src=3138495 rpt=0 dst=31679
>> slot=2 cc=0 call=KE4DYI
>> I: 2019-11-17 05:24:58.271 Signal 2 received, exiting Analog_Bridge
>>
>> What am I missing here?
>>
>> Thanks and 73
>>
>> de
>>
>> KE4DYI
>>
>>
>>
>>
>
>
>
|
|
3138495, but not sure that it matters.
I have it working in both directions on my VPS, where
Analog_Bridge is connecting to a remote AMBE server. The problem
with that setup is Analog_Bridge likes to stop passing audio after
a while, which is why I'm trying to set DVSwitch up locally on a
Pi, and have it connect to a remote USRP/ASL, rather than using
DVSwitch on the VPS, and relying on a remote AMBEserver.
The Raspberry Pi is behind NAT with incoming UDP port 34001, but
nothing from ASL ever makes it to my Analog_Bridge. Outbound
traffic from DMR to ASL works fine.
toggle quoted messageShow quoted text
On 11/17/2019 2:31 PM, Brad NK8J wrote:
What is your dmr id number. I had mine original
1139899 and had to upgrade it to the 3146521 to make mine work
On Sun, Nov 17, 2019, 9:10 AM
Patrick Perdue <patrick@...> wrote:
Hmm...
That doesn't make sense to me, because then the TX and RX
ports match on
both MMDVM_Bridge and Analog_Bridge. TX should go to RX of the
other,
which is how it is by default.
I did try it, which caused nothing to pass in either
direction.
On 11/17/2019 8:16 AM, Brad N8PC wrote:
> in your Analog_Bridge.ini file turn your txPort and
rxPort around.
>
> txPort =31100
> rxPort=31103
>
>
>
> On 11/17/2019 12:45 AM, Patrick Perdue wrote:
>> Hi:
>> In moving my DVSwitch to a local Raspberry Pi 4
rather than running
>> it on the VPS, connecting to a remote AMBEserver, I'm
running into a
>> problem.
>>
>> I now have audio going from DMR to USRP, but not the
other way. It is
>> bi-directional when running DVSwitch on the VPS.
>>
>> Looking at the logs for Analog_Bridge, it doesn't
appear to get audio
>> from ASL, as there is nothing in the log when there
is a transmission
>> from Allstar.
>>
>>
>> In rpt.conf, I have:
>>
>> rxchannel = USRP/0.0.0.0:34001:32001; GNU Radio
interface USRP
>>
>> In Analog_Bridge.ini:
>>
>> [AMBE_AUDIO]
>> address = 127.0.0.1 ; IP address
of xx_Bridge
>> txPort = 31103 ; Transmit
TLV frames to
>> partner on this port
>> rxPort = 31100 ; Listen for
TLV frames from
>> partner on this port
>> ambeMode = DMR ; DMR,
DMR_IPSC, DSTAR, NXDN,
>> P25, YSFN, YSFW (encode PCM to this format)
>> [USRP]
>> address = xlx.borris.me
; IP address of USRP
>> partner (Allstar/Asterisk or another Analog_Bridge)
>> txPort = 32001 ; Transmit
USRP frames on
>> this port
>> rxPort = 34001 ; Listen for
USRP frames on
>> this port
>>
>>
>> In DVSwitch.ini:
>>
>> [DMR]
>> Address = 127.0.0.1 ; Address to send
AMBE TLV frames to
>> (export)
>> TXPort = 31100 ; Port to send AMBE
TLV frames to
>> (export)
>> RXPort = 31103 ; Port to listen on
(import)
>> Slot = 2 ; Export slot
>>
>>
>> Here is a full log from Analog_Bridge. During this
period, there were
>> several Allstar transmissions, but they didn't make
it to the log.
>> Only DMR is seen.
>>
>>
>> I: 2019-11-17 05:23:55.512 Analog Bridge Version
1.4.1 Mon Nov 11
>> 19:06:12 UTC 2019
>> I: 2019-11-17 05:23:55.513 Copyright (C) 2018
DVSwitch, INAD.
>> I: 2019-11-17 05:23:55.513 Created by Mike N4IRR and
Steve N4IRS
>> I: 2019-11-17 05:23:55.513 Analog Bridge comes with
ABSOLUTELY NO
>> WARRANTY
>> I: 2019-11-17 05:23:55.513
>> I: 2019-11-17 05:23:55.513 This software is for use
on amateur radio
>> networks only,
>> I: 2019-11-17 05:23:55.513 it is to be used for
educational purposes
>> only. Its use on
>> I: 2019-11-17 05:23:55.513 commercial networks is
strictly prohibited.
>> I: 2019-11-17 05:23:55.513
>> I: 2019-11-17 05:23:55.513 Analog Bridge is starting
>> M: 2019-11-17 05:23:55.513 Setting [GENERAL] logLevel
-> 2
>> M: 2019-11-17 05:23:55.513 Setting [GENERAL]
subscriberFile ->
>> /var/lib/dvswitch/subscriber_ids.csv
>> M: 2019-11-17 05:23:55.513 Setting [GENERAL]
exportMetadata -> true
>> M: 2019-11-17 05:23:55.514 Setting [GENERAL]
decoderFallBack -> true
>> M: 2019-11-17 05:23:55.514 Setting [GENERAL]
useEmulator -> false
>> M: 2019-11-17 05:23:55.514 Setting [GENERAL]
emulatorAddress ->
>> 127.0.0.1:2470
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO]
address -> 127.0.0.1
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO]
txPort -> 31103
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO]
rxPort -> 31100
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO]
ambeMode -> DMR
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO]
minTxTimeMS -> 2500
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO]
gatewayDmrId -> 3138495
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO]
repeaterID -> 3154444
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTg
-> 31679
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO] txTs
-> 2
>> M: 2019-11-17 05:23:55.514 Setting [AMBE_AUDIO]
colorCode -> 1
>> M: 2019-11-17 05:23:55.514 Setting [USRP] address
-> xlx.borris.me
>> M: 2019-11-17 05:23:55.514 Setting [USRP] txPort
-> 32001
>> M: 2019-11-17 05:23:55.514 Setting [USRP] rxPort
-> 34001
>> M: 2019-11-17 05:23:55.514 Setting [USRP] usrpAudio
-> AUDIO_UNITY
>> M: 2019-11-17 05:23:55.515 Setting [USRP] usrpGain
-> 1.10
>> M: 2019-11-17 05:23:55.515 Setting [USRP] tlvAudio
-> AUDIO_UNITY
>> M: 2019-11-17 05:23:55.515 Setting [USRP] tlvGain
-> 0.35
>> M: 2019-11-17 05:23:55.515 Setting [DV3000] address
-> 127.0.0.1
>> M: 2019-11-17 05:23:55.515 Setting [DV3000] rxPort
-> 2460
>> I: 2019-11-17 05:23:55.515 Open UDP listener on 127.0.0.1:31100
>> I: 2019-11-17 05:23:55.515 Open USRP on xlx.borris.me:32001
>> M: 2019-11-17 05:23:55.515 Connecting to DV3000
hardware......
>> M: 2019-11-17 05:23:55.535 Begin DV3000 decode
>> I: 2019-11-17 05:23:55.930 Subscriber IDs loaded:
146120
>> I: 2019-11-17 05:23:55.930 Default extended metadata
<KE4DYI>
>> I: 2019-11-17 05:23:55.931 Using hardware AMBE
vocoder
>> I: 2019-11-17 05:23:55.934 Connected to USRP xlx.borris.me:32001
>> I: 2019-11-17 05:23:55.935 Starting TLV -->
Analog_Bridge (decoder)
>> --> USRP thread
>> I: 2019-11-17 05:23:55.935 Starting USRP -->
Analog_Bridge (encoder)
>> -> TLV thread
>> I: 2019-11-17 05:24:06.913 Begin TX: src=3138495
rpt=0 dst=31679
>> slot=2 cc=0 call=KE4DYI
>> I: 2019-11-17 05:24:39.132 Begin TX: src=3138495
rpt=0 dst=31679
>> slot=2 cc=0 call=KE4DYI
>> I: 2019-11-17 05:24:58.271 Signal 2 received, exiting
Analog_Bridge
>>
>> What am I missing here?
>>
>> Thanks and 73
>>
>> de
>>
>> KE4DYI
>>
>>
>>
>>
>
>
>
|
|

Mike Zingman - N4IRR
Here is what I suspect (of course I could be wrong). USRP uses UDP as its transport.
If you are using DVSM, you set the mobile client to talk to AB on a single port. This setting in AB (where TX and RX ports are the same) tells AB to use an enhanced protocol to talk to the client. This enhancement is used to keep the NAT traversal path open to the client. The trick is that AB will send keep alive packets back to DVSM to tell the router/firewall that the NAT connection should be maintained. As long as the keep alive packets are sent often enough the router will maintain the connection.
If you are using ASL as your USRP client to AB, you are using two ports (TX and RX). AB does not try to tell ASL to keep the connection open (since ASL would not understand the keep alives). So, if you are using ASL on a different machine than AB and there is a NAT between them, you will have problems.
Any of the above make sense?
|
|

Steve N4IRS
I'm going to suggest a alternative configuration.
Put your public ASL node on your VPS No radio interface needed.
Setup a private node at your house. Add AB, MB etc. Setup a full
time IAX connection between the 2 nodes.
Done...
toggle quoted messageShow quoted text
On 11/17/19 7:43 PM, Mike Zingman -
N4IRR wrote:
Here is what I suspect (of course I could be wrong). USRP uses
UDP as its transport.
If you are using DVSM, you set the mobile client to talk to AB on
a single port. This setting in AB (where TX and RX ports are the
same) tells AB to use an enhanced protocol to talk to the client.
This enhancement is used to keep the NAT traversal path open to
the client. The trick is that AB will send keep alive packets
back to DVSM to tell the router/firewall that the NAT connection
should be maintained. As long as the keep alive packets are sent
often enough the router will maintain the connection.
If you are using ASL as your USRP client to AB, you are using two
ports (TX and RX). AB does not try to tell ASL to keep the
connection open (since ASL would not understand the keep alives).
So, if you are using ASL on a different machine than AB and there
is a NAT between them, you will have problems.
Any of the above make sense?
|
|
Sounds reasonable. As I am moving soon, I'll set up an identical
private node with a second AMBE dongle in another location, then
just switch to that for the duration of downtime.
toggle quoted messageShow quoted text
On 11/17/2019 8:09 PM, Steve N4IRS
wrote:
I'm going to suggest a alternative configuration.
Put your public ASL node on your VPS No radio interface needed.
Setup a private node at your house. Add AB, MB etc. Setup a full
time IAX connection between the 2 nodes.
Done...
On 11/17/19 7:43 PM, Mike Zingman -
N4IRR wrote:
Here is what I suspect (of course I could be wrong). USRP uses
UDP as its transport.
If you are using DVSM, you set the mobile client to talk to AB
on a single port. This setting in AB (where TX and RX ports are
the same) tells AB to use an enhanced protocol to talk to the
client. This enhancement is used to keep the NAT traversal path
open to the client. The trick is that AB will send keep alive
packets back to DVSM to tell the router/firewall that the NAT
connection should be maintained. As long as the keep alive
packets are sent often enough the router will maintain the
connection.
If you are using ASL as your USRP client to AB, you are using
two ports (TX and RX). AB does not try to tell ASL to keep
the connection open (since ASL would not understand the keep
alives). So, if you are using ASL on a different machine than
AB and there is a NAT between them, you will have problems.
Any of the above make sense?
|
|

Mike Zingman - N4IRR
Partick,
I just wanted to say thank you! I decided to go back and inspect the code for UDP encode and decode to a remote AMBE server. What I found was that there was an error in the logic that was causing your AB to stop listening for new packets from the remote server. I have fixed that error and when Steve releases a new build to github, I would love for you to re-test and verify that you no longer have to stop and start your AB instance on regular intervals.
However, the architecture that Steve pointed you at will also work and you may want to implement that anyway. Your call.
Again, thank you! Mike N4IRR
|
|
Mike:
I'll probably end up implementing another instance of ASL, but testing that once it's available is easier in the short-term. So, I'll do that, too.
|
|

Steve N4IRS
toggle quoted messageShow quoted text
On 11/18/2019 11:23 AM, Mike Zingman -
N4IRR wrote:
Partick,
I just wanted to say thank you! I decided to go back and inspect
the code for UDP encode and decode to a remote AMBE server. What
I found was that there was an error in the logic that was causing
your AB to stop listening for new packets from the remote server.
I have fixed that error and when Steve releases a new build to
github, I would love for you to re-test and verify that you no
longer have to stop and start your AB instance on regular
intervals.
However, the architecture that Steve pointed you at will also work
and you may want to implement that anyway. Your call.
Again, thank you!
Mike N4IRR
|
|
So far, the new version of Analog_Bridge, connected to a remote
AMBEserver, is working well. I've had it up for a few hours with a
reasonable amount of cross-mode traffic, and it hasn't fallen over
yet. Sometimes, with the old version, it wouldn't last an hour
with heavy traffic. I'll report back if this changes.
toggle quoted messageShow quoted text
On 11/18/2019 1:18 PM, Steve N4IRS
wrote:
I have pushed the update to Analog_Bridge for all architectures to
github. <https://github.com/DVSwitch/Analog_Bridge>
Steve N4IRS
On 11/18/2019 11:23 AM, Mike Zingman
- N4IRR wrote:
Partick,
I just wanted to say thank you! I decided to go back and
inspect the code for UDP encode and decode to a remote AMBE
server. What I found was that there was an error in the logic
that was causing your AB to stop listening for new packets from
the remote server. I have fixed that error and when Steve
releases a new build to github, I would love for you to re-test
and verify that you no longer have to stop and start your AB
instance on regular intervals.
However, the architecture that Steve pointed you at will also
work and you may want to implement that anyway. Your call.
Again, thank you!
Mike N4IRR
|
|
Steve
I have updated Ananlog_Bridge i386 (github show that file was updated 22 hours) but in log show me
I: 2019-11-19 16:09:17.351 Analog Bridge Version 1.4.1 Mon Nov 11 14:23:21 EST 2019 I: 2019-11-19 16:09:17.351 Copyright (C) 2018 DVSwitch, INAD.
it looks like on github is the version which I have download 14 November
toggle quoted messageShow quoted text
|
|

Steve N4IRS
Waldek,
That is the correct version. We did not update the version or date
information for those binaries. The next push will have updated
version and date information.
Steve
toggle quoted messageShow quoted text
On 11/19/2019 11:13 AM, Waldek SP2ONG
wrote:
Steve
I have updated Ananlog_Bridge i386 (github show that file was
updated 22 hours) but in log show me
I: 2019-11-19 16:09:17.351 Analog Bridge Version 1.4.1
Mon Nov 11 14:23:21 EST 2019
I: 2019-11-19 16:09:17.351 Copyright (C) 2018 DVSwitch, INAD.
it looks like on github is the version which I have download 14
November
On Mon, Nov 18, 2019 at 10:18 AM, Steve N4IRS wrote:
I have pushed the update to Analog_Bridge for all
architectures to github. <https://github.com/DVSwitch/Analog_Bridge>
|
|
Steve, thank you for info
73 Waldek
|
|