[arm-allstar] gsm files not playing with localplay
john.chartkoff
john.chartkoff at protonmail.com
Tue Mar 27 05:42:49 EST 2018
Doug,
My apologies, as my initial message was a bit over detailed.
I have configured all as you have described.
I have issued the following commands at the CLI, with no other changes, and nothing else touched:
______________________________________________________________________
DOES NOT KEY THE TRANSMITTER and NO ADUIO ON URIx OUTPUT
N1CTF*CLI> rpt localplay 29309 /tmp/current-time
-- <DAHDI/pseudo-1484592387> Playing '/tmp/current-time' (language 'en')
== Refreshing DNS lookups.
-- Hungup 'DAHDI/pseudo-1484592387'
______________________________________________________________________
DOES KEY THE TRANSMITTER WITH AUDIO
N1CTF*CLI> rpt playback 29309 /tmp/current-time
-- <DAHDI/pseudo-843582991> Playing '/tmp/current-time' (language 'en')
-- Hungup 'DAHDI/pseudo-843582991'
-- <DAHDI/pseudo-1800368025> Playing '/etc/asterisk/local/node-id' (language 'en')
-- Hungup 'DAHDI/pseudo-1800368025'
______________________________________________________________________
DOES NOT KEY THE TRANSMITTER and NO ADUIO ON URIx OUTPUT
N1CTF*CLI> rpt localplay 29309 /etc/asterisk/local/node-id
-- <DAHDI/pseudo-543296438> Playing '/etc/asterisk/local/node-id' (language 'en')
-- Hungup 'DAHDI/pseudo-543296438'
______________________________________________________________________
DOES KEY THE TRANSMITTER WITH AUDIO
N1CTF*CLI> rpt playback 29309 /etc/asterisk/local/node-id
-- <DAHDI/pseudo-1387884274> Playing '/etc/asterisk/local/node-id' (language 'en')
-- Hungup 'DAHDI/pseudo-1387884274'
______________________________________________________________________
Any suggestions????
Thank you,
John --N1CTF
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 26, 2018 9:38 PM, <arm-allstar-request at hamvoip.org> wrote:
>
>
> Send arm-allstar mailing list submissions to
>
> arm-allstar at hamvoip.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> or, via email, send a message with subject or body 'help' to
>
> arm-allstar-request at hamvoip.org
>
> You can reach the person managing the list at
>
> arm-allstar-owner at hamvoip.org
>
> When replying, please edit your Subject line so it is more specific
>
> than "Re: Contents of arm-allstar digest..."
>
> Today's Topics:
>
> 1. Re: USB Subsystem on RPi Unstable & Problem with LocalPlay
>
> (Jesse Royall)
>
> 2. Re: USB Subsystem on RPi Unstable & Problem with LocalPlay
>
> (Doug Crompton)
>
>
> Message: 1
>
> Date: Mon, 26 Mar 2018 19:58:25 -0500
>
> From: Jesse Royall w5los at yahoo.com
>
> To: "john.chartkoff" john.chartkoff at protonmail.com
>
> Cc: ARM Allstar arm-allstar at hamvoip.org, David McGough
>
> <kb4fxc at inttek.net>
>
>
> Subject: Re: [arm-allstar] USB Subsystem on RPi Unstable & Problem
>
> with LocalPlay
>
> Message-ID: 35763AF9-69A9-4A04-BACB-6FA37B1BEB07 at yahoo.com
>
> Content-Type: text/plain; charset="utf-8"
>
> It?s setup for the ft1500m with the data jack on 1200 pin.
>
> I use the cli so I can see my dtmf decodes are successful. And another terminal running simple-usb-tune. Then I just trial and error it for consistent decodes.
>
> Then found a busy node/reflector so I could fine tune the TX level. And weather radio to match audio levels.
>
> I used a gm300 for a year and lost the finals in it as a node radio. But i didn?t cool it. Had it turned down to 15w. I think they tend to work better at their higher power and fans.
>
> I was loosing the usb and the uri would just drop. Which lead David and I in believing it was a ground as well. While waiting for him to send me docs for the uri/ground and such I starting tinkering with audio levels. Looked at my old node from my thin client and noticed the TX level in simple tune was really low.
>
> Then I noticed the link radio was off .05.... talking about BCDA. So I learned to lock The dials as well!
>
> Good luck. But don?t forget after trying the above. You might still have a loose ground. I found my loose ground!
>
> Sent from my iPhone
>
> > On Mar 26, 2018, at 7:32 PM, john.chartkoff john.chartkoff at protonmail.com wrote:
> >
> > 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-c
>
> ycling 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 = UR
>
> Ix (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 s
>
> tarts 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
>
> -------------- next part --------------
>
> An HTML attachment was scrubbed...
>
> URL: http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20180326/e842c403/attachment-0001.html
>
> --
>
> Message: 2
>
> Date: Mon, 26 Mar 2018 21:38:27 -0400
>
> From: Doug Crompton wa3dsp at gmail.com
>
> To: ARM Allstar arm-allstar at hamvoip.org
>
> Subject: Re: [arm-allstar] USB Subsystem on RPi Unstable & Problem
>
> with LocalPlay
>
> Message-ID:
>
> CAMp6vst9JG0Y-1LZbmQYDVZTS0EnN3qp7KrsNxmQ8U_eaFM9cQ at mail.gmail.com
>
> Content-Type: text/plain; charset="utf-8"
>
> 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.html
>
> --
>
> Subject: Digest Footer
>
> arm-allstar mailing list
>
> arm-allstar at hamvoip.org
>
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
>
> --------------------------------------------------------------------------------------------------------------------
>
> End of arm-allstar Digest, Vol 46, Issue 56
More information about the arm-allstar
mailing list