|
Re: ASL - Analog - HB Bridge help please
F1TZO - Michel
Hi Steve
Sorry, I found ! In my rpt.conf, my IP address for USRP pointed to local and I had to change it to the IP where the Analog_Bridge is running. Now I have sound from ASL to DMR and from DMR to ASL ;-) Next step, connect HB_Bridge with BM ..... I will try to find in the DVSwith group ;-) I did this config in hblink.cfg, it'ssems to connect but when I speak on DMr, I listen me on hoseline, but nothing come to hb_bridge # PROGRAM-WIDE PARAMETERS GO HERE # PATH - working path for files, leave it alone unless you NEED to change it # PING_TIME - the interval that clients will ping the master, and re-try registraion # - how often the Master maintenance loop runs # MAX_MISSED - how many pings are missed before we give up and re-register # - number of times the master maintenance loop runs before de-registering a client [GLOBAL] PATH: ./ PING_TIME: 5 MAX_MISSED: 3 # SYSTEM LOGGER CONFIGURAITON # This allows the logger to be configured without chaning the individual # python logger stuff. LOG_FILE should be a complete path/filename for *your* # system -- use /dev/null for non-file handlers. # LOG_HANDERLS may be any of the following, please, no spaces in the # list if you use several: # null # console # console-timed # file # file-timed # syslog # LOG_LEVEL may be any of the standard syslog logging levels, though # as of now, DEBUG, INFO, WARNING and CRITICAL are the only ones # used. # [LOGGER] LOG_FILE: /tmp/hblink.log LOG_HANDLERS: console-timed LOG_LEVEL: DEBUG LOG_NAME: HBlink # DOWNLOAD AND IMPORT SUBSCRIBER, PEER and TGID ALIASES # Ok, not the TGID, there's no master list I know of to download # This is intended as a facility for other applcations built on top of # HBlink to use, and will NOT be used in HBlink directly. # STALE_DAYS is the number of days since the last download before we # download again. Don't be an ass and change this to less than a few days. [ALIASES] TRY_DOWNLOAD: True PATH: ./ PEER_FILE: peer_ids.csv SUBSCRIBER_FILE: subscriber_ids.csv TGID_FILE: talkgroup_ids.csv PEER_URL: http://www.dmr-marc.net/cgi-bin/trbo-database/datadump.cgi?table=repeaters&format=csv&header=0 SUBSCRIBER_URL: http://www.dmr-marc.net/cgi-bin/trbo-database/datadump.cgi?table=users&format=csv&header=0 STALE_DAYS: 7 # EXPORT AMBE DATA # This is for exporting AMBE audio frames to an an "external" process for # decoding or other nefarious actions. [AMBE] EXPORT_IP: 127.0.0.1 EXPORT_PORT: 1234 # MASTER INSTANCES - DUPLICATE SECTION FOR MULTIPLE MASTERS # HomeBrew Protocol Master instances go here. # IP may be left blank if there's one interface on your system. # Port should be the port you want this master to listen on. It must be unique # and unused by anything else. # Repeat - if True, the master repeats traffic to clients, False, it does nothing. [MASTER-1] MODE: MASTER ENABLED: False REPEAT: True EXPORT_AMBE: False IP: PORT: 54000 ##PORT: 62031 #PASSPHRASE: s3cr37w0rd PASSPHRASE: passw0rd GROUP_HANGTIME: 5 # CLIENT INSTANCES - DUPLICATE SECTION FOR MULTIPLE CLIENTS # There are a LOT of errors in the HB Protocol specifications on this one! # MOST of these items are just strings and will be properly dealt with by the program # The TX & RX Frequencies are 9-digit numbers, and are the frequency in Hz. # Latitude is an 8-digit unsigned floating point number. # Longitude is a 9-digit signed floating point number. # Height is in meters [REPEATER-1] MODE: CLIENT ENABLED: True EXPORT_AMBE: False IP: PORT: 54001 MASTER_IP: 213.222.29.197 MASTER_PORT: 62031 #MASTER_PORT: 62031 PASSPHRASE: passw0rd CALLSIGN: F1ZHH RADIO_ID: 2088012 RX_FREQ: 439000000 TX_FREQ: 434000000 TX_POWER: 25 COLORCODE: 1 SLOTS: 1 LATITUDE: 38.0000 LONGITUDE: -095.0000 HEIGHT: 75 LOCATION: Anywhere, FR DESCRIPTION: This is a cool repeater URL: www.f1tzo.com SOFTWARE_ID: 20170529 PACKAGE_ID: MMDVM_HBlink GROUP_HANGTIME: 5 OPTIONS: 73, Michel - F1TZO
|
||||||||||||
|
|
||||||||||||
|
[New post] Last Chance for the XC-3006
 John D. Hays Edmonds, WA K7VE   
|
||||||||||||
|
|
||||||||||||
|
Re: ASL - Analog - HB Bridge help please
F1TZO - Michel
Hi Steve, Thanks, I did the correction, but always nothing from ASL (Echolink) to DMR. In fact, when I speak from DMR to ASL, in the Analog_bride logs, I see the TX, but when I speak from ASL to DMr, I didn't see anything. Here are the analog_bridge log, start, speak from DMR (2 times) and after speak from ASL : I: 2018-02-14 20:57:47.337 Analog_Bridge - Version 20170719 M: 2018-02-14 20:57:47.337 Setting [GENERAL] logLevel -> 2 M: 2018-02-14 20:57:47.337 Setting [GENERAL] outputAudioDevice -> /dev/null M: 2018-02-14 20:57:47.337 Setting [GENERAL] inputAudioDevice -> /dev/null M: 2018-02-14 20:57:47.337 Setting [GENERAL] decoderFallBack -> false M: 2018-02-14 20:57:47.337 Setting [GENERAL] useMicrophone -> false M: 2018-02-14 20:57:47.337 Setting [GENERAL] useVox -> True M: 2018-02-14 20:57:47.338 Setting [GENERAL] voxDecay -> 2 M: 2018-02-14 20:57:47.338 Setting [GENERAL] voxTrigger -> 200 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] server -> 127.0.0.1 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] fromDMRPort -> 31002 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] toDMRPort -> 31003 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] ambeSize -> 72 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] minTxTimeMS -> 2000 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] gatewayDmrId -> 2088012 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] repeaterID -> 12088012 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] txTg -> 20815 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] txTs -> 2 M: 2018-02-14 20:57:47.338 Setting [AMBE_AUDIO] colorCode -> 1 M: 2018-02-14 20:57:47.338 Setting [USRP] server -> 192.168.200.83 M: 2018-02-14 20:57:47.338 Setting [USRP] toASLPort -> 32001 M: 2018-02-14 20:57:47.338 Setting [USRP] fromASLPort -> 34001 M: 2018-02-14 20:57:47.338 Setting [USRP] aslAudio -> AUDIO_USE_AGC M: 2018-02-14 20:57:47.338 Setting [USRP] agcGain -> -20 M: 2018-02-14 20:57:47.338 Setting [USRP] dmrAudio -> AUDIO_UNITY M: 2018-02-14 20:57:47.338 Setting [USRP] dmrGain -> 0.95 M: 2018-02-14 20:57:47.338 Setting [DV3000] server -> 192.168.200.81 M: 2018-02-14 20:57:47.338 Setting [DV3000] port -> 2461 W: 2018-02-14 20:57:47.338 ioctl reset error W: 2018-02-14 20:57:47.338 ioctl speed error W: 2018-02-14 20:57:47.338 ioctl stereo error W: 2018-02-14 20:57:47.338 ioctl setfmt error M: 2018-02-14 20:57:47.338 Audio In/Out Device: /dev/null I: 2018-02-14 20:57:47.339 Open UDP listener on 127.0.0.1:31002 I: 2018-02-14 20:57:47.339 Open USRP on 192.168.200.83:32001 M: 2018-02-14 20:57:47.339 Connecting to DV3000 hardware...... M: 2018-02-14 20:57:47.352 Begin DV3000 decode I: 2018-02-14 20:57:47.408 Subscriber IDs loaded: 73611 I: 2018-02-14 20:57:47.408 Using hardware AMBE decoder I: 2018-02-14 20:57:47.408 Starting Analog_Bridge --> USRP thread I: 2018-02-14 20:57:47.408 Open UDP listener on 192.168.200.83:34001 I: 2018-02-14 20:57:47.408 Starting USRP --> HB_Bridge thread I: 2018-02-14 20:58:04.521 Begin TX: src=2088006 rpt=2088006 dst=20815 slot=2 cc=1 I: 2018-02-14 20:58:04.712 Connected to USRP 192.168.200.83:32001 I: 2018-02-14 21:01:35.249 Begin TX: src=2088006 rpt=2088006 dst=20815 slot=2 cc=1 Thanks for your help Regards, Michel - F1TZO ----
Le 14/02/2018 à 01:16, Steve N4IRS a écrit :
Michel,
|
||||||||||||
|
|
||||||||||||
|
hb_bridge_all.py get ACLs
Cort N0MJS <n0mjs@...>
Today I added Access Control Lists (ACLs) to hb_bridge_all.py
This was in response to those with no desire to re-write TGID or TS, but who wanted some ability to limit how/what traffic is forwarded. This isn’t quite as simple as a “whitelist” and/or a “blacklist” like MMDVM, because it’s inherently multipoint, with greater than 1 possible target each direction. But it does include most of the simplicity of the whitelist/blacklist approach. For example, let’s say you want an upstream connection to Brandmeister, but want to keep TGIDs, 1,2,17,3000, and 41109 just on your systems… not a problem. Let’s say you want to block particular subscribers or ranges on a certain system? Not a problem. ACLs include: Subscriber ID (SID) Talkgroup ID (TGID) There are global SID and TGID ACLs and per-system SID and TGID ACLs FIRST MATCH EXITS Evaluation: GLOBAL first, SYSTEM second ACLs are evaluated on ingress and egress BOTH. Each ACL may be either “PERMIT” or “DENY”, and may contain multiple entires that are single IDs, (e.g. 3120101), ranges of IDs, (e.g. 1-3000), or a special identifier “ALL” that will match all valid IDs. Cort Buffington 785-865-7206
|
||||||||||||
|
|
||||||||||||
|
Re: ASL - Analog - HB Bridge help please
Michel,
toggle quoted messageShow quoted text
In Analog_Bridge.ini you have this in the AMBE_Audio section: gatewayDmrId = 2088012 ; ID to use when transmitting from Analog_Bridge repeaterID = 2088012 ; ID of source repeater gatewayDmrid is the ID that will display on the DMR radio when someone transmits from analog repeaterID is the DMR ID of the repeater the signal is coming from. Thay can not be the same. If you have a real DMR repeater ID, use it. Otherwise, add a 1 to your repeaterID so that it is 12088012 73, Steve N4IRS
On 02/13/2018 06:57 PM, F1TZO - Michel wrote:
Hi Steve and all
|
||||||||||||
|
|
||||||||||||
|
ASL - Analog - HB Bridge help please
F1TZO - Michel
Hi Steve and all
I write from France, so please, sorry for my English ;-) So, I try to make working ASL <-> Analog_Bridge <-> HB_Bridge to link Echolink with DMR. I installed ASL in a VM and Analog_Brige + HB_Bridge in an other VM. I have a Raspi with a DV3000U and AMBEserver running And I have a MMDVM Hotspot connected on the HB_Bridge in DMR After looking a lot the messages in the group, I made the configurations and the results are : - MMDVM Hostspot is connected on HB_Bridge : OK - ASL + HB_Bridge + Analog_bridge are started - DMR to ASL : OK sound's good - ASL to DMR : Nothing, no TX, no log in Analog_bridge I don't see any error in the logs. So .... I need help ;-) and when it'll work, I have to find how connect this to BM .... Here are my config files in attach. Thanks for your works and your help Regards, Michel - F1TZO
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
Mike,
toggle quoted messageShow quoted text
A little history for you. Mike, N4IRR and I discovered the work Cort did on DMRLink a few years ago. We quickly realized that it could be leveraged to connect a c-Bridge to AllStarLink. We forked DMRlink and created DMRGateway. So as to not require any changes to AllStarLink, we decided to re-purpose the chan_usrp channel driver. We had a working DMR to AllStarLink gateway. Somewhere around that time, Cort invited us to work directly on DMRLink and later HBlink. When it came time to add the same capability to HBlink we decided to slightly modify the connectivity approach. Each "Network" would get a connectivity Partner. We had DMRlink (IPSC), HBlink (HB) and AllStarLink (analog) A new naming convention was in order. So we renamed DMRGateway to Analog_Bridge and added IPSC_Bridge and HB_Bridge. As a side note, days after we renamed to Analog_Bridge, G4KLX released DMRGateway for use by MMDVMHost. One of the things I was asked for a LOT was a replacement for the AllStarLink chan_dstar channel driver. We decided "why recreate the wheel?" We knew DummyRepeater and ircDDBGateway from G4KLX did everything we needed to connect to D-Star. It output and input analog audio. Why not just modify DummyRepeater to use analog audio in a format that AllStarLink could use? So, the modification to DummyRepeater does just that, it uses the USRP formatted PCM. A simple AllStarLink to D-Star bridge just uses DummyRepeater and AllStarLink. Analog_Bridge is not used in that configuration. Along the same lines a bridges to YSF and P25 are working now. The P25Bridge test is in daily use on BM TG 31665 and P25 TG 31665. All of these things are built on the same premise that Cort defined, "We don't build networks, we build tools to build networks" All of these pieces are mix and match. Pick what you want to connect to and choose that partner. Nothing is built in a vacuum. Without the work of Cort, Jonathan and others, we would have nothing to connect to. So yes, I think I know how Analog_Bridge is used. 73, Steve N4IRS
On 2/13/2018 9:21 AM, Mike Swiatkowski
via Groups.Io wrote:
Steve,It's used quite a bit more than you think. You don't have to look that hard on google or Yahoo to find examples. There is no easy way to go from DMR to D-Star so Analog_bridge is used. I guess you could use XLX these days and maybe that's another option.
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
Steven Blackford
Hey Mike, Just to follow up on using ThumbDV's with the XLXD software. Like I told you in chat, I've setup a few of these now. They work great & have been rock solid using the 1.1 version of the AMBED server software. I've had lots of issues w/ dropouts on the 1.3 version. I also modified the latency in the 1.1/1.3 versions to try to cut down on the issues. That' makes all the difference in the world on the 1.1 version. The default value is 4, drop it down to 1 & I haven't had any issues at all. If you need more info about that, let me know. I will say that as far as doing the DMR<->D-Star bridge either setup works. Using the Analog_Bridge, HB_Bridge, Dummy Repeater is the most flexible way to go. It allows you to changes things on the fly pretty quickly. Twice a week normally I swap the "Carolina Link" from it's home on XLXD054B over to REF054C/REF061C for a couple of nets. With the XLXD reflector I have setup, I can't do that, but I do have a full time interlink from the BM Network on that & it works great after making the changes noted above. I've had better luck setting the XLXD transcoding system on an X64 system also. I know a few people running them on PI3's & have good luck. The last one I helped setup, we even used a powered USB Hub & had issues w/ it being reliable. Just my $0.02. :-) Hope that helps. 73 de K4SQI. Steve, K4SQI
On Tue, Feb 13, 2018 at 9:21 AM, Mike Swiatkowski via Groups.Io <mjswiatk@...> wrote: Steve,It's used quite a bit more than you think. You don't have to look that hard on google or Yahoo to find examples. There is no easy way to go from DMR to D-Star so Analog_bridge is used. I guess you could use XLX these days and maybe that's another option. --
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
Steven Blackford
Hey Mike, Hope things are going well. What happened w/ the audio levels from when we initially setup your bridge? I've setup various different bridges & the only time I've had to modify the audio levels was when going from ASL<->DMR. That did take a while to get the audio level set. Post your current Analog_Bridge.ini file & we can start then start modifying it to bring the levels to what you need. You just need to do it in small increments & test it. As far as different AMBE devices goes, you can use the PIDV, ThumbDV for the DMR side of things and you can also use them for D-Star along w/ the original Blue DV-Dongle as well. I use a PIDV and a DV-Dongle for my DStar<->DMR bridge. PIDV's are great because you don't have the USB issues to deal with on PI's, but they're hard to come by these days. 73 de K4SQI. Steve, K4SQI
On Sun, Feb 11, 2018 at 10:22 AM, Mike Swiatkowski via Groups.Io <mjswiatk@...> wrote: Steve, --
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
DMR to D-Star, yes you need Analog_Bridge
toggle quoted messageShow quoted text
D-Star to ASL Analog_Bridge is NOT used. I think I know pretty well how Analog_Bridge, HB_Bridge, IPSC_Bridge are used. 73, Steve N4IRS
On 2/13/2018 9:21 AM, Mike Swiatkowski
via Groups.Io wrote:
Steve,It's used quite a bit more than you think. You don't have to look that hard on google or Yahoo to find examples. There is no easy way to go from DMR to D-Star so Analog_bridge is used. I guess you could use XLX these days and maybe that's another option.
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
Mike, AA9VI
Steve,It's used quite a bit more than you think. You don't have to look that hard on google or Yahoo to find examples. There is no easy way to go from DMR to D-Star so Analog_bridge is used. I guess you could use XLX these days and maybe that's another option.
|
||||||||||||
|
|
||||||||||||
|
Re: Transcoding between AMBE+ and AMBE+2
Steve, KB9MWR
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
Analog_Bridge is not used in that configuration. we can look at adding audio level controls to DummyRepeater
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
Mike, AA9VI
Yes.
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
Mike,
toggle quoted messageShow quoted text
Just to be clear, we are talking about DummyPrepeater to AllStarLink? DummyRepeater <---> Allstarlink Steve
On 02/11/2018 10:22 AM, Mike
Swiatkowski via Groups.Io wrote:
Steve,
|
||||||||||||
|
|
||||||||||||
|
Re: Analog_Bridge to D-Star audio levels
Mike, AA9VI
Steve,
I noticed the source of my problem was setting AUDIO_UNITY on the ASL side in Analog_Bridge.ini. Unity sounds better but the amplitude is probably 40% of what it needs to be. Is there any way to bump up that level? If I set AUDIO_USE_AGC I get the right drive level but the audio quality is a little less smooth. I also experimented with AUDIO_USE_GAIN and that is about the same as with AGC interms of audio fidelity. Question 2: What other AMBE interfaces can work with Analog_Bridge besides the ThumbDV from NW Digital? I wonder if there is a better transcoder out there. Mike, AA9VI
|
||||||||||||
|
|
||||||||||||
|
Analog_Bridge to D-Star audio levels
Mike, AA9VI
I am trying to increase the audio amplitude from Allstar to dummyrepeater using Analog_Bridge. Besides Analog_Bridge.ini settings where can I do this?
Thanks, Mike, AA9VI
|
||||||||||||
|
|
||||||||||||
|
Re: Transcoding between AMBE+ and AMBE+2
That is an option, but most parts are SMD and construction time is significant. I think you can buy as few as 10 pieces of the 3003 and pay before shipment. This whole project is to help the community, it is not a high volume or profit item. (Building them in a professional assembly house and there are project costs.) If there is not enough interest, it will simply not happen. (Orders will be refunded.) Currently the order count is a few short but close.
On Feb 7, 2018 14:00, "JJ Cummings" <cummingsj@...> wrote:
|
||||||||||||
|
|
||||||||||||
|
Re: Transcoding between AMBE+ and AMBE+2
JJ Cummings
Here is a homebrew project that costs substantially less and has 3 channels: The killer is the AMBE3003 chip, you have to order them in quantities of 90 from DVSI I have been told. This would be much more economical thing to build or even have built I would think. JJC N0PKT
On Wed, Feb 7, 2018 at 12:23 PM, John D Hays - K7VE <john@...> wrote: I don't know if this group is aware of the 6 channel AMBE device build that is being planned, based on getting enough orders, see
|
||||||||||||
|
|
||||||||||||
|
Transcoding between AMBE+ and AMBE+2
I don't know if this group is aware of the 6 channel AMBE device build that is being planned, based on getting enough orders, see
http://nwdigitalradio.com/xcode-3006/
|
||||||||||||
|
|
