[arm-allstar] USB Subsystem on RPi Unstable & Problem with LocalPlay

Mon Mar 26 19:32:22 EST 2018

Thanks Jesse. I will look at that. What radio are those levels for? I am using a Moto GM300.

I have an RX level of 350. I put in 3 khz deviation and set the meter on simpleusb tuner to the 3 kHz mark but the audio sounds to low. Should I be using the CLI radio level set instead?  Just trying to make it consistent across the network.

I changed out the Pi wall wart for a 5v UBEC and am running it off the same supply rail as the radio. I also added some ferrites. USB works perfectly now.

Localplay is stil not keying the transmitter, though.  That has not changed.

I am running stock HamVOiP 1.5rc16.

What are you running? I was considering downgrading, but what’s the fun of ham radio if you can’t live on the bleeding edge???

Thank you for your assistance.

73’
John N1CTF node 29309

Sent from ProtonMail Mobile

On Mon, Mar 26, 2018 at 6:51 PM, Jesse Royall <w5los at yahoo.com> wrote:

> Check the TX audio in the simple usb tune. I had mine set over 50 that caused me issues. Guessing it was over driving and putting spurs in the signal and made the usb shut down after a short time. Plus it would decode all the time. The next is the pre-emphases and de-emphases. I tested these settings by toggling them on and off and watching my in the asterisk cli for good decodes. Then watched the RX at tried to keep things at 3kz. Then I turned on plfilter as well I think which cleaned up the audio more. But the first thing, I made sure my radios were tuned right. David suggested grounds but I didn’t have to go that far yet. My RX settings are set for 475 and TX at 35 I believe. That got me in the ballpark. Sent from my iPhone > On Mar 26, 2018, at 5:11 PM, David McGough via arm-allstar wrote: > > > Hi John, > > Lets try to tackle these issues one at the time. > > The USB bus issue, with the URI becoming non functional is the first > problem to address. Your comment about power-cycling the USB bus (menu > option 14) is interesting, since the RPi sometimes crashes when you > perform this operation....I highly suspect a power supply issue of some > type. What type of 5V power supply are you using? > > Another common power issue is ground loops or faults. The simplest > solution I've found for grounding issues is to supply good ground paths > from the URI to the radio and *ALSO* a ground path from the RPi board / > power supply to the radio. > > We're working on a "best practices" guide for RPi power and grounding now. > > I'll post some photos of how I've got all my systems setup, too. I've > got RPi3's in some very harsh places and have found reliability to be > better than that of the PC computers the RPi3 boards replaced. > > > 73, David KB4FXC > > >> On Mon, 26 Mar 2018, "john.chartkoff via arm-allstar" wrote: >> >> Hello, >> I am having 2 issues with HamVOiP1.5.rc16. >> Specifics: >> Node = 29309 >> Set up as duplex=0 >> Single node operation >> FOB = URIx (tried RIM-Maxtrac also) >> 32 G SD card bit tested using H2TestW (tried two cards with complete new builds) >> RPi 2 Mod B (also tried RPi3) >> RPi power supply running at 5.02 VDC (tried two separate supplies) >> Motorola GM-300 with channel steering enabled >> Reporting correctly to APRS as N1CTF-1 (same issue when gps.conf deleted) >> Reporting correctly to Echolink as N1CTF/L (same issue when echolink.conf deleted) >> Test radio is a Motorola XTS2500 M3 >> Using SimpleUSB >> Everything tuned up nicely on the service monitor >> The only non factory settings are additions to simpleusb.conf [usb] and rpt.conf [functions] for the GPIO control and parrot mode per the "how-to" on asterisk/app_rpt. >> >> The system is awesome, and sounds great, except for two flaws. >> >> Issue #1: The USB subsystem fails to respond to DTMF after having been operational for minutes. These are some operational notes: >> A: The rest of the system is functional. >> B: If I reset the USB subsystem it starts to work again, but usually not for more than a few minutes. But sometimes its OK for an hour or so. >> C: Resetting the USB subsystem sometimes crashes the Linux session completely and requires a hard reset. >> D: When the system is not working, there is a continuous stream of messages on the CLI as follows, even though no DCS is decoded and the receiver is quiet : >> >> [Mar 26 04:38:17] WARNING[435]: chan_simpleusb.c:1606 soundcard_writeframe: soundcard_writeframe bytes dropped: written = -1, requested = 3840 >> >> E: I am using the CTCSS input only. "COSFROM" is set to "NO." The Realtime RX Telemetry Display always shows that the COS input is keyed, even though it is set to "NO." (Not sure if that matters or is even a problem...) CTCSS input responds to DCS decode on the GM300. >> >> Issue #2: When issuing DTMF command "*82" on a local portable, the macro does not key up the transmitter if the "say24time.pl" Perl script calls "localplay." Localplay plays the script, and it is showing on the CLI, but the only way to hear it over the radio is if someone else is talking and doubling with the script and causing the radio to go into PTT. But if I change the script to run "playback," it works fine. This is a sufficient workaround for scripts, but it does not fix some non-macro voice playbacks. >> >> One more piece of evidence: If I dial *81, for example, on iaxrpt, running on an Ubuntu box in Wine, on the same private LAN, the radio keys up and I can hear it over the air. But if I issue the samep commands on the XTS2500 right next to the node, the CLI shows all the tones are decoded, and it shows the message is being played on the CLI, but the radio doesn't key up. >> >> So, to summarize issue 2: scripts calling "localplay" do not key up the transmitter if originated from a radio using DTMF commands. But they do key up if they are commanded by the DTMF pad on iaxrpt. However the transmitter doesn't key right up and the first part is cut off (if the macro is calling localplay.) >> >> Macros works great using "playback." >> >> Status messages do not play at all, but I cant find where to change localplay to playback for status messages. >> >> Thank you very much for your help and for developing this fantastic system. >> >> John --N1CTF >> _______________________________________________ >> >> arm-allstar mailing list >> arm-allstar at hamvoip.org >> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar >> >> Visit the BBB and RPi2/3 web page - http://hamvoip.org >> > > _______________________________________________ > > arm-allstar mailing list > arm-allstar at hamvoip.org > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar > > Visit the BBB and RPi2/3 web page - http://hamvoip.org @hamvoip.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20180326/a36f87ac/attachment-0001.html>