September 2016 - App_rpt-users

Receive audio not passing through URI
by Chris Viningre 20 Sep '16

20 Sep '16

Greetings from a ham radio dummy. I'm old to ham radio but new to setting up repeaters, Allstar and URI. Also lost working with Linux. Yes pretty much a disaster looking for a place to happen. I have a repeater running with a RC-100 controller on VHF. I'm attempting to add a link to a linked system over Allstar. I have removed the old controller and wired the URI. To the best of my knowledge I have the wiring correct, but I could be wrong. I downloaded the Linux software from the Allstarlink website and made a bootable disk. I loaded the Debian with Asterisk software only, Not the Graphical version. At the end of the install I manually added my information. I put my node number and password number in. I followed the support information from the Allstar site and did a node download from Allstar. I checked for my node on the Allstar list and it is listed. I called the link phone number and I can get through the login but it doesn't seem to connect to my link. I get a busy signal and it hangs up. When I key a HT the repeater sometimes comes up. Most of the time I have the key the PTT 2 or 3 times in a row to make it key up. Either way I get no audio out of the transmitter other then the IDer and beep. I hear the receiver just fine. I have search for help all over the internet, but what information I find is like a Texan trying to read Arabic. I speak Texagain so I'm not really the best with the English language. At lease according to my wife. Well I'm hoping maybe someone can help me get this working or lead me in some kind of direction. Thank you. Chris Viningre 70 W. Roadrunner Salt Flat, Texas 79847 C:(915) 504-1510 chrisviningre(a)gmail.com Amateur Radio Operator: WS5B https://www.qrz.com/db/ws5b http://www.reverbnation.com/chrisviningre

5 7

Strange /var/log behavior
by Bob Roszkowski 20 Sep '16

20 Sep '16

I've been playing around with DIAL on a RPi and noticed something strange today. If I create a dir or file in /var/log and reboot, it is gone. Anyone else see this? Sincerely, boB - W5EVH

2 6

MOTOTRBO
by John Locke 16 Sep '16

16 Sep '16

Hi all, Does anybody have experience with MOTOTRBO? A customer have a couple of ambulances with mototrbo + GPS. It would be great to get the GPS positions, send messages, etc. Regards John

2 1

Dial and APRS support?
by Bob Roszkowski 16 Sep '16

16 Sep '16

In the new version of DIAL, is APRS still supported? boB - W5EVH

5 8

DIAL ate my homework!
by Steve Zingman 16 Sep '16

16 Sep '16

My new tag line: -- "Did you enable it in modules.conf?"

2 2

the endless (I hope) possibilities..
by Geoff 16 Sep '16

16 Sep '16

I wrote this, originally as a response to Steve to recognize his effort and work that he has put into his project, but it grew and I think the discussion and answers could benefit a few of us, here. First off, let me thank Jim Duuuude for first getting allstar up and running. Tim for his effort with Drupal and Steve for what you do with DIAL. On 09/14/2016 10:53 AM, Steve Zingman wrote: [...] > DIAL relies on the official Asterisk source for the SVN. No more no > less. I do not believe in fluff being part of a official distribution. > Sure, it can be added. I just don't want people to have to remove > things. There are quite a few great add on features and programs > available for AllStar. I'll continue to make sure they work, but I > don't think they should be part of the distribution. All of my work > for building DIAL and scripts to support more platforms is kept in a > GIT repository along with links to the "release candidate" for amd64, > i386 > and the RPi. <https://github.com/N4IRS/AllStar> > [...] > The reason for this romp down memory lane is just to point out that > DIAL is independent of the official source. I don't care is it is in a > SVN or GIT repository. As long as I can get to the current source, > DIAL is good. Quite the romp, Steve. Thanks for that input and reminder. I've been out of dealing with and running a node for a little over a year, now. I've kept up, kinda sorta in a round about way, you might say, maybe, with the happenings in this list. I -do- plan on getting something back up and running again. The problems from before, the mysterious 'hangs', the software being (in my opinion) "unstable", (coupled with the fact that where we moved to, while gorgeous, is heavily laden with awesome natural HF antenna supports) kinda kept me away from getting an allstar node up. The trees are nice and while they're good for hauling a wire in the air for lower frequencies, they are absolutely relentless in their pursuit of sucking dry every available watt of RF they can find, above about 60MHz. Having the gen-pole 'break' while going up with the last section of tower and the antenna on it, and no time/money/break-in-the-weather just... I dunno... kinda kicked the air outta my sails. I've got too many trees around me to do any good for V/UHF, unless I put up a 100' tower and the landlord ain't gonna go for -that-. So... now steering away from whining about RF restrictions, (and with deep respect and thanks to 'The Duuude') I am deeply curious about "DIAL". I've been a Linux user for about 15 years. I'm as comfortable at the command line as I am chasing an pointer shaped icon across a gui. That doesn't mean I'm some sort of programmer or heretofor knowledgeable about the intricate details of slamming scripts together, or creating chron events. Seems like every time I try to do these (seemingly Linux 'noobie') tasks, I've got to stop and research. So, that's my experience in Linux. You'd think that after 15 years something -more- would have stuck, but I'm a creature of habit. I've always gone back to 'dance with the one that brung ya' and SuSE and I have been together all of this time. A long way of saying I know .rpm platforms, best. Now, with all of THAT said, since DIAL was ported and made installable for the Debian flavor of Linux, your claim seems to be that the software is more stable than ever. I agree with trimming the code, and modulizing more components and the time and effort put into such and endeavor is, at least by me, appreciated. Thank you. Bottom line, I didn't want to just come out and ask a question without giving proper acknowledgment and appreciation ahead of my asking, so having done that (I hope) I'll ask... if there ever going to be an .rpm version of app_rpt that would be put together like so that the program could be installed onto an already-existing instance of Linux, instead of my previous experience where a dedicated machine was needed running CentOS? something as simple as $~> rpm -qvih allstar then having the script go out, create the directories it needed, put the files where they were supposed to go, update the libraries, set the environment, connect to the radio, use the current internet connection (if needed) and run by itself as "yalp" (yet another linux program) without the need of dedicating hardware to do so? It's always been a thought in my mind, that "if Linux is multi-user, multi-funtion capable, why is an entire machine required to be dedicated to running allstar?" Thanks for reading. 73 = Best Regards, -Geoff/W5OMR

2 1

EchoLink Updates
by David Osborn 16 Sep '16

16 Sep '16

Hi All, I'm sure that this has been asked before, but it's lost in the mists of time: Echolink updates seem to stop on my node from time to time. How can I kick start them without a reboot? Where can I see the list of Echolink nodes that are validated? I know that rpt_extnodes has the AllStar nodes. Hopefully simple questions with simple answers Cheers David - GD4HOZ

2 1

Echolink and Teamspeak
by Gareth Jackson 15 Sep '16

15 Sep '16

Hello all. Having being running the Teamspeak server for a few weeks now, it's thankfully working well with both Echolink and Allstar links (Even in the process of adding a DMR crosslink now). It is however running on windows based machines, and ideally, I'd like to run it on a Raspberry Pi 3. I keep being told that the "pi" is the future, and having seen a few videos of people using them, they do seem very neat and functional. My issue is that now I have 2 band new shiny Pi's sat in front of me, i'm struggling on where to go next. I can't find information about how to run Echolink (sysops) on them using virtual audio cables... I can however find lots of people that have a radio plugged in to them, but as it's a virtual server I don't need radios plugged into them. Has anyone any experience with this before? I'm guessing if anyone uses one for crosslinking Allstar and Echolink they would have had to address this issue. Cheers, Gareth PS: For anyone not knowing what Teamspeak is, it's an VOIP/ROIP app (running on my own private server) that allows hams that are not in range of repeaters etc, to access multiple talk groups using the teamspeak app for free. Teams speak runs on PC/Mac/Linux/Apple/Google devices etc... Happy to share the details of the server if anyone wants to try it out etc.

4 4

Stupid asterisk tricks
by Stacy 15 Sep '16

15 Sep '16

All, For those of you who may want to play with the code I put up at https://github.com/KG7QIN/AllStarLink-Asterisk-1.8 but don't have a radio or anything else they want to /can spare at the moment, there is something else you can do: Setup your console to dial. Once you do this, you can do something like "console dial 42088" and have the audio of your node play on your computer speakers. You could probably even use it to talk, but I don't really recommend it unless you know what you are doing. To set this up, you will need to: 1. Add comment our the noload => chan_alsa.so or noload => chan_oss.so line in your modules conf. 2. Edit your oss.conf or alsa.conf file (depending on which you use, I recommend alsa) to use your console. I use alsa.conf, so here is what the my test node's alsa.conf looks like: [general] autoanswer=no context=radio-control-console ;this needs to correspond to your nodes's number extension=42088 ;aplay -l can list your alsa devices input_device=plughw:0,1 output_device=plughw:0,0 ;default mute state mute=true For your extensions.conf, add this to the end of it so that radio-control-console context has somewhere to go (change the 42088 to match the node number you put in the extensions section in the file above. [radio-control-console] exten => 42088,1,Ringing exten => 42088,n,Wait(3) exten => 42088,n,Answer exten => 42088,n,Set(CALLERID(name)="KG7XXX") exten => 42088,n,Playback(rpt/connected) exten => 42088,n,Playback(rpt/node) exten => 42088,n,Saydigits(${EXTEN}) exten => 42088,n,Rpt(${EXTEN},P,${CALLERID(name)}) You can then startup asterisk, and on the console type "console dial <node>" and watch/listen as your system dials in using phone mode. "console dial <digits>" to dial. "console hangup" to hangup. (Note I have only done this with the 1.8 port I've put up in the github repository). -Stacy KG7QIN

2 2

app_rpt updates, upgrades etc.
by Steve Zingman 15 Sep '16

15 Sep '16

I've been watching the back and forth concerning updating app_rpt to run on "a more current version" of Asterisk in hopes of a number if improvements. Some of these improvements do have value, others not so much. A little history is in order here. I have been using and supporting AllStar for the past 10 years. Like most, I used ACID to get up and running. Centos is not my preferred Linux distribution. I prefer Debian and pretty quickly built what I needed to run AllStar on Debian for myself. Debian is not "bleeding edge" It's not meant to be. It's rock solid stable. About 1.5 years ago I started seeing a increasing number of people reporting issues with installing ACID on newer hardware. No network drivers etc. Since I did not have those issues running current Debian, I decided to see if I could do something about the problem. I took the current Debian netinst image and using the ability to "preseed" the answers required for a base install of Debian. From there it was a simple task to automate the download of the most current source from the "official" SVN compile and install it. Building the kernel modules for DAHDI had to be done also. With that, we had AllStar running on a distribution with up to date drivers and a fairly current kernel. With the apt system of Debian a user could update the OS easily. Pulling updates from the SVN for Asterisk can be done manually or via a pretty simple script. I now had what I called "Bare Metal Install" Could AllStar be turned into installable Debian programs? Yes a repository could be built. Scripts could be built to automate the package creation. To be honest I don't think AllStar changed that often to make this worthwhile. Someone could take this on. A couple of the things bothered me about ACID. First was that Asterisk loaded every conceivable module at startup. No matter if you needed the module or not. This worked and the user usually did not care. It put a lot of bogus errors in the log and to some extent, ate memory that was not needed. I tried to build every module, even if it was not needed but did not enable the module in modules.conf. The other thing that bothered me was that the sample rpt.conf and other config files were not complete. Most everything was there, but some thing were missing and I felt it was better to try to include all options AND add comments detailing all possible values. Nothing is ever perfect, but I tried and continue to add things I missed. Jim approached me and asked if I was willing to turn BMI into the official AllStar x86 distribution. I agreed and added the scripts to support the web portal for creation and backup of configs. Jim came up with a name DIAL. At the same time, Jim had heard I built a image for the Raspberry Pi using Debian Jessie. He asked if we could also us it as official PIi version. I agreed added the scripts and DIAL for the RPi was born. This image does not build on the fly as did BMI but the update path was the same. DIAL relies on the official Asterisk source for the SVN. No more no less. I do not believe in fluff being part of a official distribution. Sure, it can be added. I just don't want people to have to remove things. There are quite a few great add on features and programs available for AllStar. I'll continue to make sure they work, but I don't think they should be part of the distribution. All of my work for building DIAL and scripts to support more platforms is kept in a GIT repository along with links to the "release candidate" for amd64, i386 and the RPi. <https://github.com/N4IRS/AllStar> The reason for this romp down memory lane is just to point out that DIAL is independent of the official source. I don't care is it is in a SVN or GIT repository. As long as I can get to the current source, DIAL is good. For me, I could care less if appt_rpt is ported to a more current version of Asterisk. To me the current version is fine as a repeater controller, remote base and voter. I think the current attack surface is small and still be reduced within the host OS. If I want a PBK I'll spin up the current Asterisk and connect the 2. The time available for people that can work on app_rpt is limited. I think that time at least at first should be spent on app_rpt.c and the channel drivers. There is a LOT of code there and if more people understood it, the more people could maintain and enhance it. First that means comments! A push to comment the existing code would go a long way. Who knows what might be found while commenting the existing code. There are some parts of app_rpt that have a very limited audience. The support for the Uchameleon comes to mind. I'm not saying kill it. I'm saying break it out as a module and allow the user to load it if the user has one and wants to use it. Other areas that can get the same treatment could be the remote base. I know others have done work with Hamlib. It should be leveraged. I think it could be more of a module, not a set of scripts that need to be pasted together. Integrate it and let the user decide to enable it. The channel drivers could use some attention. Right now we have the PCI quad card and USB sound. Other devices are due in the future. Break out the "digital IO" from the channel driver. Move the PTT, COS and CTCSS and other digital IO away from the dependence on the CM1xx. I'm not saying remove it. Make it more modular. If I want the GPIO on the CM1xx great. If I want to use the GPIO of the RPi fine. If I want to use the parallel port on the PC, fine. This way only the Digital IO module needs to be modified, not the whole channel driver. Combine the simpleUSB and USBradio channel drivers. I know of at least one fork that did this with success. and future channel drivers are doing this soon. One less channel driver to maintain. Expand the capability of chan_usrp. We use this channel driver for the DMRGateway project with great success. Being able to pass more data between app_rpt and the outside world (and back) would enhance the abilities of both. Think of passing a MDC ID through to DMRGateway or D-StarGateway. I could go on and on. There are a ton of feature and enhancements people have asked for. All of this requires the "buy in" of Jim. Without it, it's just another fork. Just one off the top of my head. 73, Steve N4IRS -- "No, INAD is not JUST I need a drink"

3 3