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

Mon Mar 26 20:38:27 EST 2018

John,

 Localplay should work. I see no issues in that code and nothing has been
changed. Make sure you are specifying a node in the localplay statement
that is on the server you are issuing it on, is valid, and has something
you can listen to it on.

 rpt localplay <nodename> <sound_file_base_name>

Also the file name CANNOT have an extent.  "somename.gsm"  becomes  as
specified in the command "somename"

And the file has to actually play! That is be a file in the proper format.

Go into the client and play it from there. Then you can see any error
messages.

*73 Doug*

*WA3DSP*

*http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*

On Mon, Mar 26, 2018 at 8:07 PM, "john.chartkoff via arm-allstar" <
arm-allstar at hamvoip.org> wrote:

> Hi David, Thank you got your response. I believe I have cleared up the
> ground loops as you advise. I also changed from using a wall wart supply to
> a UBEC and I fabricated a micro usb cable to the RPi 3. I then fed the UBEC
> from the same 12 volt Powerpole strip that the radio is using. I also added
> a ferrite to the GM300 data line and to the USB line. Now it is perfect.
>
> There is still the same issue with localplay though.
>
> Thanks again for your help!
>
> 73’
> John
>
> Sent from ProtonMail Mobile
>
>
> On Mon, Mar 26, 2018 at 6:11 PM, David McGough <kb4fxc at inttek.net> 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 same 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20180326/dd57fa99/attachment-0001.html>