May 2016 - Allstar-Digital - lists.keekles.org

DV4Home
by Robert Newberry 11 May '16

11 May '16

Anyone seen this yet? It sounds similar to something Mike teased a while back with a RPI2, DV3000, with a speaker and microphone. Are there any updates on this? N1XBM Apparare Scientor Paratus Communicare Allstar Node # 27086, 41540, 41812, 42086, 42658, 42657 www.radioguysrepeaternetwork.com

3 13

DMRGui screen shots
by Steve Zingman 11 May '16

11 May '16

Here are a couple of screen shots of DMRGui. It can be used standalone (with ambe_audio and DMRGateway) plus mic and speaker to access a IPSC network. (DMR-MARC, DCI, BrandMeister...) or control a existing ASL <---> DMR Gateway. The screenshot I took was from my Windows 7 machine. The DMRGui will use any X Window server. Free versions of the X Window server are available for Windows, OSX, Android and of course Linux. <https://www.dropbox.com/s/zudl1vdbkfp2v02/DMRGui.PNG> <https://www.dropbox.com/s/4q4ae912fmz35wh/DMRGui_1.PNG> -- "Anything is possible if you don't know what you are talking about." 1st Law of Logic

1 0

Local TG
by Robert Newberry 10 May '16

10 May '16

I was setting up TS2 TG9 for a local repeat only. Would I need to do anything in my bridge_rules.py? I'm thinking no since it is only repeating locally. N1XBM Apparare Scientor Paratus Communicare Allstar Node # 27086, 41540, 41812, 42086, 42658, 42657 www.radioguysrepeaternetwork.com

3 2

Re: [Allstar Digital] Allstar-Digital Digest, Vol 6, Issue 2
by Chris HIll/K7AZ 09 May '16

09 May '16

Is this digest still active? Chris K7AZ Sent from my dumb-smart DROID... allstar-digital-request(a)lists.keekles.org wrote: >Send Allstar-Digital mailing list submissions to > allstar-digital(a)lists.keekles.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital >or, via email, send a message with subject or body 'help' to > allstar-digital-request(a)lists.keekles.org > >You can reach the person managing the list at > allstar-digital-owner(a)lists.keekles.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Allstar-Digital digest..." > > >Today's Topics: > > 1. Re: status so far (Robert Newberry) > 2. Looking for test subject (Robert Newberry) > 3. Re: status so far (Steve Zingman) > 4. Re: status so far (Robert Newberry) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 2 Mar 2016 13:06:07 -0500 >From: Robert Newberry <N1XBM(a)amsat.org> >To: Digital linking using Asterisk and app_rpt > <allstar-digital(a)lists.keekles.org> >Subject: Re: [Allstar Digital] status so far >Message-ID: > <CAM09xEYpzQx4Z7xzgSkWSGE2XNzzzkhDqTxx1kpsGY4-CuEmrA(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >My fault on the ID, I understand why the IDs need to be unique. I >misunderstood the big picture. Once Mike explained it, I understood. > >Now what about the template.bin? Is there an explanation for that such as a >screw up in my end? > >N1XBM >Apparare Scientor >Paratus Communicare >Allstar Node # 27086, 41540, 41812, 42086, 42658 > >On Mar 1, 2016 10:02 AM, "Steve Zingman" <szingman(a)msgstor.com> wrote: > >> Update: >> I logged in to Roberts node. He had the Radio ID for the dmrlink.cfg peer >> set the same as the Motorola repeater he was trying to connect from. That >> is wrong. Each Master / Peer in a IPSC network needs a unique Radio ID. He >> also had the gatewayDmrId set to the same Radio ID as the repeater. Last >> but not least, template.bin which is required for AllStar ---> DMR was not >> in the ambe_audio directory. He is now up and running. >> >> 73, Steve N4IRS >> >> On Sun, Feb 28, 2016 at 10:18 PM, Robert Newberry <N1XBM(a)amsat.org> wrote: >> >>> Going to call it a night, the bridge appears to be working OK. I am >>> hearing feeds from other networks. >>> >>> I do not have the gateway running yet. for audio in either direction. >>> When ambe_audio.py runs I am not seeing any errors on DEBUG. I am how ever >>> not seeing any traffic when I key up my HT, which leads me to believe I've >>> missed a setting somewhere. I would assume I should see some reference to >>> TS and TG that it might be seeing. >>> >>> Now I'm too a point where I'm spinning my wheels and need some rest. >>> >>> _______________________________________________ >>> Allstar-Digital mailing list >>> Allstar-Digital(a)lists.keekles.org >>> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital >>> >>> >> >> _______________________________________________ >> Allstar-Digital mailing list >> Allstar-Digital(a)lists.keekles.org >> http://lists.keekles.org/cgi-bin/mailman/listinfo/allstar-digital >> >> >

2 1

DMRGateway configuration
by Steve Zingman 07 May '16

07 May '16

I know it's been rather quiet lately. Mike and I have been working on a number of Digital and Analog projects. Some will be demonstrated at Dayton, so we are coming down to the wire. I have been configuring DMRGateway on a Micro-Node DPAC for the show. It's built on the next revision of DIAL for the RPi. Though most of the underlying Asterisk, DMRGateway and DMRlink code is mostly unchanged I ran in to something "interesting" Consider the DPAC. It's a dual node AllStar server with 2 radio ports, hardware real time clock, serial console port and dual TFT displays. it mounts in a 1 RU box. For the demo, I set it up with 2 analog repeaters and a DMRGateway. The idea is that the DMRGateway is a "private" node (1997) if either of the 2 analog repeaters wanted DMR access they could just connect to 1997 and they would be on DMR. Pretty much the same way that anyone might setup a tightly controlled ASL <---> DMR Gateway. Using the remote control ability built into ambe_audio a analog user can change to pre-defined TS / TG configurations with DTMF. This can also be done from Allmon2. There is also a standalone client coming called DMRGui. Think a DMR node with a local mic and speaker. Now comes the issue. We know that a DMRGateway node should be setup with duplex = 0 and comment out the idrecording and idtalkover entries so no ID goes out over DMR. With a duplex = 0 there should be no hang time or telemetry. Or so would one think. Turns out that the USRP channel driver still uses the hangtime and possibly the alt hangtime values. If you just comment them out, you get the default values of 5000 ms. Set hangtime and althangtime to 0 !!! Otherwise there is a hang time between the drop of the input analog signal and the drop of the outbound DMR signal. We are checking the code now, and we THINK it's in the USRP channel driver. Not sure it's a negative yet. There is a small hang built in DMRGateway on purpose. For INAD, 73 Steve N4IRS -- "Anything is possible if you don't know what you are talking about." 1st Law of Logic

1 0