- App_rpt-users - lists.keekles.org

Re: [App_rpt-users] URI-X Issues With New Raspbian build
by Jim Aspinwall No1PC 12 Jul '18

12 Jul '18

So, I 'blew' the latest Stretch build into a new USB flash device... booted and tried to configure an existing node onto it on hardware that is known to work under prior. 1. ASL-MENU did NOT over-write the rpt.conf nor iax.conf files with given parameters - run as 'repeater' sudo root or enabled root user. FAIL. How is this fail 'possible' ? 2. Asterisk -rvvvvv... consistently revealed that the attached known interface did not exist and failed out with "...var/run/asterisk.ctl..." does not exist... when it actually does - what condition manifests this? NO low voltage errors on the console... all this on a known Pi3 AND RA-40 interface configuration under prior Jessie install... To this... after decades of WinTel system support and a variety of x-Nix support work... ... please understand I do NOT *want* to hint at, support, or indicate that 'Crompton' may be on to something because his builds aren't all that stable and documentation and support are no better an often wrong, accusational... but have not exhibited this level of 'stupid' non-function. I am also someone at the brunt of "it doesn't work" as an esclation point in massive enterprises, and can at least identify and analyze log files that may contain some hints... "give me (path)xxx log file..." and at least I provide or know full paths, not casual non-specific references. I would hope, expect the contributing community to be robust in definitive, helpful logging and not simply dismiss users to unqualified rhetoric/fault. That said...the latest Jessie build is a failure. The latest Stretch build is a failure. "change my mind" I'm back to tweaking the prior Jessie build to work as 'advertised' sans asl-menu and don't dare chance an upgrade/update process to the latest... I merely anticipate the coders know various failure conditions, can detect and log them... but that is an anticipation not rendered in actual logical recorded fact.| OK - get it - code contributors are volunteers. Volunteers that are supposedly intimate and knowledgeable with the code, functions, conditions, etc. Bad power (not evident), bad storage/boot device (not evident), yadda... so, what? If you cannot document the 'proper' necessary requirements for hardware, process, etc. you cannot hold us users accountable or nor unknown circumstances to blame for failures. This is logical, programmatic... SOMETHING can detect (or not) attached hardware and communications functions... but yet not tell us what part(s) failed? Certainly when a convenient configuration menu/utility cannot/will not write-out changed parameters - one can determine a file system or rights issue... and reveal same... not leaving the user with the deception the system is good to go when it is sitting there at useless defaults. We really do NOT want this project left to Crompton for the popular vote, nor the x-Nix elitists... it's much too good for either of that. I among others are willing to dig deep and provide any log files, etc. that are effective to supportive solutions. If logging content is ambiguous, not adequate to specific known logical issues, improve logging. If scripts do not work... let's debug... The leave behind is that if you were lucky enough to capture a prior Jesse build... sans asl-menu... stash it away and work around manual configs, leave it not user-friendly. If there are specific hardware, storage device requirements, document and better test for them. Obviously a current bootable latest Jessie build is NOT effective to new or existing node success. Why? Leave all of this to unstable, undocumented Crompton builds, or do equal or better... How can I/we help? -------------------Today's Topics: 1. Re: URI-X Issues With New Raspbian build (Steve Zingman) 2. Replay of June 26th Net at 8pm EDT (tonight) on 29999 (Mike) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Jul 2018 15:31:47 -0400 From: Steve Zingman <szingman(a)msgstor.com> To: Users of Asterisk app_rpt <app_rpt-users(a)lists.allstarlink.org> Subject: Re: [App_rpt-users] URI-X Issues With New Raspbian build Message-ID: <b9e5a338-8b97-9d40-5a73-7a1757b76366(a)msgstor.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" If I had to guess, I would say a bad SD card burn. or a bad card. Steve N4IRS

6 6

Asterisk MODULES required for Phone Patch ?
by Mike 12 Jul '18

12 Jul '18

Can anyone state for the record, What asterisk 'MODULES' are required for the phone patch to function ? ...mike/kb8jnm

3 5

*** NODE LOAD TESTING HAS BEEN CANCELED FOR THIS SAT 14th ***
by Mike 12 Jul '18

12 Jul '18

*** NODE LOAD TESTING HAS BEEN CANCELED FOR THIS SAT 14th *** Reason... 'One' participant, and that participant stated he would not be around for the test. ???????? While I think this is 'very important', I personally will not 'ENTERTAIN' anyone state to me that I should use a 'untested resource' for use in nets etc . Nobody will be putting your head on the chopping block when things do not work out. I feel the more the better but _everyone needs some experience doing this sort of stuff. _Pass the torch !_ _ And this is not the same game it was just 2-3 years ago. I do know since I have taken part in many very large nets. How do you make judgements on load distribution without this data ? Just throw a lot of what you think are large assets at it and 'hope' it works ? _Well, Good luck in your 'RELIABLE' ecomm endeavors. _ Anyone think they have a 'magic formula' for figuring this out ? ... Keep guessing ! Most think it is simply a Network Bandwidth issue, and more often, it is a CPU/Memory bandwidth issue. Allison will eat into that 'heavily on smaller systems'. Heavy loads to your allmon page will do the same because it uses PHP server side scripting and is constantly querying your system for live data with each visitor that just sits there and monitors. Unlike HTML where you are just 'reading' the text, PHP uses the servers CPU to generate a HTML output in a dynamic way. I could state other things that eat into your available mem/cpu but for most of us, those are the 2 major ones but does not account for other services some run in their systems. Both of those mean less available resources for voice data to be distributed. So it is not just about 'Internet Bandwidth'. (It's-A Put-Up or Shut-Up situation. Just so all those 'back seat drivers' know where they stand with me.) I have been putting the work up to make 'even better things' possible and understandable going forward, and most of all, PLAN-ABLE. A large group of successful 'real world' tests will help us develop a formula that everyone will benefit from. Or we can continue to head down the path of failure from our own ignorance as this continues to grow rapidly. The issues will not be going away, but getting more important. I have stated my case for it the best I know how. Blaming it on 'the summer', *_I will re-visit the idea again this winter_*. 73, ...mike/kb8jnm

1 0

URI-X Issues With New Raspbian build
by Jim Aspinwall No1PC 12 Jul '18

12 Jul '18

Coincidence? Serendipity? I just tried the latest builds from: http://dvswitch.org/files/ASL_Images/Raspberry_Pi/Stretch/ Liking asl-menu... that helps... but as with others below... I have found, on a Pi3 + RA-40 that works under the prior 'build' - I too am experiencing multiple errors and ultimately failure of asterisk app to identify, connect to and use the USB-connected RA-40 as either USBRadio or SimpleUSB that worked under same configuration parameters. It's even complaining that asterisk.ctl is not in /var/run when it clearly is there. On the console I am getting low voltage errors I never saw before... using the same power source. Measurement at the board is minimum 4.96v. Power source is a PowerPole USBBuddy 3A device from clean DC - these run all of my field-racked nodes so far. Even a 1.5a wall-wart has been fine prior. Doesn't make sense when the operational voltage tolerance of the Pi is greater than this 0.8% difference. If the low-voltage check is getting in the way... how do we fix that? Separate power sources for Pi vs interface boards? If the voltage issue is NOT "getting in the way" of Asterisk using a good known USB-interfaced device? What is? Again, I can shut down the boards, swap the USB Flash drive from the latest build to the prior and it runs fine. I'm reluctant to in-place update the working node/stick... until I can properly clone the stick and test on an expendable build. (What tool does one use to make an image from a bootable stick?) Yeah it's decidedly an issue with snd-pcm-oss missing from the system.. > may need to compile a custom kernel.. _shrug_ >> this may not be relevant, but worth saying at this point. >> >> I have found that if you initialize a pi node while not supplying the Pi >> board with enough current >> >> during the initial start-up. Many things seem to go wrong. >> >> I'm building a bigger 5v power supply to handle 2 or three of these at >> once to verify what I'm thinking, >> >> but not tested anything yet. >> >> In my case, it is Dahdi >>> Not sure why but the /dev/dsp1 seems to be missing... I've installed >>> oss-compat and tried a number of things.. see below output... >>> >>> $ sudo uridiag >>> URIDiag, diagnostic program for the DMK Engineering URI >>> USB Radio Interface, version 0.9, 08/14/15 >>> >>> Found CM119 USB Radio Interface at 001/005 >>> Unable to re-open DSP device 1: /dev/dsp1 >>>

4 5

Replay of June 26th Net at 8pm EDT (tonight) on 29999
by Mike 12 Jul '18

12 Jul '18

So we are live testing our NET Playback script from the June 26th NET on node 29999 at 8pm EDT "tonight: July 10th". I will take a moment to talk about what is coming up in our next net and a little about the playback script. Q&A if any before running it. It will sound as good/or bad as the original. So if you missed that net or are curious how well this works, TUNE IN ! 73 ...mike/kb8jnm

1 1

URI-X Issues With New Raspbian build
by JJC 10 Jul '18

10 Jul '18

Didi a fresh install of the latest ASL from the repo on a fresh install of raspbian on an RPI 3. The issue is simple... the pi sees the URI but ASL seems to have issues.. I have included sample output from a variety of commands below which clearly details the underlying OS sees the URI as it should, and the given address etc... see the example output below... taken from /var/log/asterisk/messages [Jul 7 22:19:46] WARNING[6703] chan_usbradio.c: Loaded parameters from usbradio_tune_usb.conf for device usb . [Jul 7 22:19:46] WARNING[6703] chan_usbradio.c: Unable to re-open DSP device 1 (usb): No such file or directory $ cat /proc/asound/cards 0 [ALSA ]: bcm2835_alsa - bcm2835 ALSA bcm2835 ALSA 1 [Device ]: USB-Audio - USB PnP Sound Device C-Media Electronics Inc. USB PnP Sound Device at usb-3f980000.usb-1.1.3, full s $ lsusb Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 001 Device 005: ID 0d8c:013a C-Media Electronics, Inc. Bus 001 Device 006: ID 0424:7800 Standard Microsystems Corp. Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub $ cat /etc/asterisk/usbradio_tune_usb.conf [usb] ; name=usb ; devicenum=1 devstr=1-1.1.3:1.0 rxmixerset=500 txmixaset=450 txmixbset=500 rxvoiceadj=0.557342 rxctcssadj=0.930165 txctcssadj=220 rxsquelchadj=754 fever=1

4 20

// REMINDER - Node Load Test Day This Sat -14th Sign-up by Thurs 12th
by Mike 10 Jul '18

10 Jul '18

NODE LOAD TEST DAY THIS SAT 14th @ 5pm EDT Details www.29999.link You must submit a request for testing by thurs 12th... see details in link. ...mike/kb8jnm

1 0

Re: [App_rpt-users] URI-X Issues With New Raspbian build
by Mike 10 Jul '18

10 Jul '18

Additional testing shows a few things on this issue: Much of it depends on your power supply to the Pi board. When you reach the limit of current from the power supply, the connection can get 'noisy' meaning that the switching transistors in regulation start showing 'pulses' that are never good for a computer with a timing clock. So a quick check to just the voltage is not always enough. But needs to be done in any case. Just additional info to look at/for. ...mike/kb8jnm On 7/9/2018 7:30 PM, George Csahanim wrote: > I agree on this point. I was running my 28599 node on a usb power > supply where I thought for sure it had enough smoke. Nope. The board > did odd stuff even shut down a few times. Changed the power supply... > not a problem since. Though this may not be your issue, Mike has a > good point > > George Csahanin > Retired > Sent from my iPhone > > On Jul 8, 2018, at 10:44 AM, Mike <mm(a)midnighteng.com > <mailto:mm@midnighteng.com>> wrote: > >> Well, >> >> this may not be relevant, but worth saying at this point. >> >> I have found that if you initialize a pi node while not supplying the >> Pi board with enough current >> >> during the initial start-up. Many things seem to go wrong. >> >> I'm building a bigger 5v power supply to handle 2 or three of these >> at once to verify what I'm thinking, >> >> but not tested anything yet. >> >> In my case, it is Dahdi >> >> So, just something to look at and if it appears to be likely, >> >> I would say get the required current supplied and start anew with a >> fresh img. >> >> Not sure if it helps, but something to look for. >> >> ...mike/kb8jnm >> >> >> On 7/8/2018 9:44 AM, JJC wrote: >>> Not sure why but the /dev/dsp1 seems to be missing... I've installed >>> oss-compat and tried a number of things.. see below output... >>> >>> $ sudo uridiag >>> URIDiag, diagnostic program for the DMK Engineering URI >>> USB Radio Interface, version 0.9, 08/14/15 >>> >>> Found CM119 USB Radio Interface at 001/005 >>> Unable to re-open DSP device 1: /dev/dsp1 >>> >>> On Sat, Jul 7, 2018 at 10:44 PM JJC <cummingsj(a)gmail.com >>> <mailto:cummingsj@gmail.com>> wrote: >>> >>> Didi a fresh install of the latest ASL from the repo on a fresh >>> install of raspbian on an RPI 3. The issue is simple... the pi >>> sees the URI but ASL seems to have issues.. >>> >>> I have included sample output from a variety of commands below >>> which clearly details the underlying OS sees the URI as it >>> should, and the given address etc... >>> >>> see the example output below... >>> >>> taken from /var/log/asterisk/messages >>> [Jul 7 22:19:46] WARNING[6703] chan_usbradio.c: Loaded >>> parameters from usbradio_tune_usb.conf for device usb . >>> [Jul 7 22:19:46] WARNING[6703] chan_usbradio.c: Unable to >>> re-open DSP device 1 (usb): No such file or directory >>> >>> $ cat /proc/asound/cards >>> 0 [ALSA ]: bcm2835_alsa - bcm2835 ALSA >>> bcm2835 ALSA >>> 1 [Device ]: USB-Audio - USB PnP Sound Device >>> C-Media Electronics Inc. USB PnP Sound >>> Device at usb-3f980000.usb-1.1.3, full s >>> >>> $ lsusb >>> Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. >>> RTL2838 DVB-T >>> Bus 001 Device 005: ID 0d8c:013a C-Media Electronics, Inc. >>> Bus 001 Device 006: ID 0424:7800 Standard Microsystems Corp. >>> Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB >>> 2.0 Hub >>> Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB >>> 2.0 Hub >>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> >>> $ cat /etc/asterisk/usbradio_tune_usb.conf >>> [usb] >>> ; name=usb >>> ; devicenum=1 >>> devstr=1-1.1.3:1.0 >>> rxmixerset=500 >>> txmixaset=450 >>> txmixbset=500 >>> rxvoiceadj=0.557342 >>> rxctcssadj=0.930165 >>> txctcssadj=220 >>> rxsquelchadj=754 >>> fever=1 >>> >>> >>> >>> >>> _______________________________________________ >>> App_rpt-users mailing list >>> App_rpt-users(a)lists.allstarlink.org >>> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users >>> >>> To unsubscribe from this list please visithttp://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" >>> You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. >>

1 0

Some General Announcements & Net Tues July 17th @ 8:30pm edt - Open Source Engineering -Show & Tell
by Mike 10 Jul '18

10 Jul '18

*Some general announcements and more:* *Don't forget to sign-up for node load testing by/on thurs* - 'details' @ *www.29999.link* Testing on Sat. --- The previous net from *Tues June 26 2018* will be 'played back' to * * *"any & all connected stations"* to *_node 29999 _**starting at 8pm edt* Tues July 10 This is one more beta test of our new playback script. More details to follow. (no, it will not time-out your node... just connect to witness how it works... A brief explanation before starting) --- WX8L/Sean is at least one of the guest speakers for the *coming net on July 17*. (there will be other material) So if you have been planning a ASL Micro/HotSpot, look at this and tune-in the the net 'NEXT' tues . *https://wx8l.blogspot.com/2018/06/personal-allstar-pocket-node-based-on.html* *Sean is eager to answer questions and help you along in your quest !* --- I will have some follow-up info for the group before the next (real/not playback) net. See Ya Real Soon... ...Yes we are doin' 'STUFF' ...mike/kb8jnm

1 0

PI3 Audio Gaps
by David Osborn 08 Jul '18

08 Jul '18

Hi Guys, I've built a few nodes over the years, with PC's, Thin Clients, and now the Pi3. I have three Pi3 nodes running nicely, but the one I'm currently working on has me foxed. The problem is "gapping" on receive audio. When in talkthrough, there are very short but unmissable breaks in the incoming audio. Even on an unmodulated carrier, one can hear short silences in the background noise. There are sometimes no gaps for several seconds, other times there are two or three breaks per second. There is no obvious pattern and they are somewhat erratic. It doesn't seem to matter if there's audio present or not, but a tone on the incoming signal makes the issue really obvious. Link audio is fine as are Alison's chants, it's just local RX audio. Reports indicate that a remote node can hear these gaps as well. I connected my CM108 dongle to a recently retired node computer - a Wyse Thin Client PC running Limey Linux - and it was flawless with no gaps and good quality. When re-connected to the Pi, there are the gaps again. The only difference I can find between this new node and previous pi-based ones is that I'm using WiFi on this one; the others being hard-wired. (If anyone can suggest how to get WiFi working on Limey, that would do nicely!) I've tried SimpleUSB and "full fat" USB, and also tried different variations of carrierfrom and ctcssfrom in USBRadio.conf but I cannot discern a difference in behaviour regardless of the configuration. I'm tempted to get an image from one of my other nodes and plug it in to this one to see if that makes a difference. Has anyone had this issue and what was the solution? David - GD4HOZ

2 2