Re: [Discuss-gnuradio] gr-osmosdr issues ?
After finding this some of the sample rates make more sense: > The sample rates are dictated by the RTL2832U chip, not the tuner chip. > The RTL2832U can sample from two ranges ... > 225001 to 30 and 91 to 320. > Pick any number that lies in either of those two ranges. > (http://forums.radioreference.com/software-defined-radio/305969-rtl-sdr-sample-rate-calculations.html#post2322632) I am able to reproduce your audio problem using the uhd source directly, or an osmocom source with either usrp or rtlsdr hardware. I think this is a pulseaudio problem; specifying the audio device to "hw:1,0" for direct access gives me good audio. With or without an audio sink, I get the PLL message at flowgraph startup. I'm not sure the PLL message means much if there are only one or two messages, and the recording looks sane. On Mon, Jan 11, 2016 at 1:08 PM, Jean-Michel FRIEDT wrote: > Thanks for the answers. All sampling rates are in the 1.5-2.5 MHz range, > namely 11025*128=1.4112 MHz when decoding POCSAG, or 48000*32=1.536 MHz when > decoding commercial FM (for these trivial tests). The issue about > synchronization only arises when an audio sink is used: sending the data to > a named pipe or scope sink displays the "PLL not locked" message but the > decoding/display look fine. I should emphasize that > rtl_fm -f 104.4e6 -M wbfm -s 20 -r 48000 - | aplay -r 48k -f S16_LE > (running a friend's computer) works perfectly well, hence my concern about > gr-osmosdr at opposed to the RTL libs. > > JM > > >> It's hardly a trivial report; RTL devices with gr-osmosdr are a very >> commonly used platform. >> >> I've seen similar messages from gqrx, but sound quality has not been >> impacted. My guess is that this may be related to rapid retuning for >> rtl devices, which basically involves not waiting for the PLL to lock. >> >> Does osmosdr-->nullsink display the same message? >> What about rtl_sdr ... > /dev null? >> Does this only happen at certain sample rates or at any rate? And are >> you using a supported sample rate? >> >> https://github.com/csete/gqrx/commit/d805c426f24f987cdb16e37bbab564d30da473c2 >> >> On Mon, Jan 11, 2016 at 11:16 AM, jmfriedt >> wrote: >>> >>> My apologies for such a trivial bug report, but has anyone experienced >>> issues with gr-osmosdr >>> "lately" (not sure when the problem started) about "PLL not locked" and >>> data flow rate mismatch >>> in gnuradio data flows ? >>> >>> I have a couple dozen RTL2832U based dongles used for various SDR >>> activities which have been >>> working quite flawlessly until this summer at least. Being currently in >>> the process of preparing >>> the new teaching semester, I just discovered that *all* dongles (E4k, >>> R820T or R820T2) experience >>> the same lack of PLL locking and data flow rate mismatch when connected >>> to USB ports *on laptops* >>> (tested on four different laptop models, yet all running Debian/GNU Linux >>> distributions, testing >>> and sid releases). The audio output in such a simple decoding stream as >>> Osmosdr Source - Low pass >>> filter - WBFM decoder - audio output is not continuous and of very bad >>> quality. The *same* dongles >>> connected to desktop setups with the same Debian/GNU Linux distribution >>> exhibit no issue: stream >>> rate is consistent and sound quality excellent. Of course searching on >>> the web for "PLL not locked" >>> yields a couple of million hits explaining that the tuned frequency range >>> is not within the >>> bandwidth of the dongle VCO, which is not the case here. >>> >>> Has anyone seen reports of this issue before ? >>> >>> Thanks, JM >>> >>> -- >>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 >>> Besancon, France >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> >> -- >> GDB has a 'break' feature; why doesn't it have 'fix' too? >> > > > > -- > JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 > Besancon, France > > > This message was sent using IMP, the Internet Messaging Program. > -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-osmosdr issues ?
Thanks for the answers. All sampling rates are in the 1.5-2.5 MHz range, namely 11025*128=1.4112 MHz when decoding POCSAG, or 48000*32=1.536 MHz when decoding commercial FM (for these trivial tests). The issue about synchronization only arises when an audio sink is used: sending the data to a named pipe or scope sink displays the "PLL not locked" message but the decoding/display look fine. I should emphasize that rtl_fm -f 104.4e6 -M wbfm -s 20 -r 48000 - | aplay -r 48k -f S16_LE (running a friend's computer) works perfectly well, hence my concern about gr-osmosdr at opposed to the RTL libs. JM It's hardly a trivial report; RTL devices with gr-osmosdr are a very commonly used platform. I've seen similar messages from gqrx, but sound quality has not been impacted. My guess is that this may be related to rapid retuning for rtl devices, which basically involves not waiting for the PLL to lock. Does osmosdr-->nullsink display the same message? What about rtl_sdr ... > /dev null? Does this only happen at certain sample rates or at any rate? And are you using a supported sample rate? https://github.com/csete/gqrx/commit/d805c426f24f987cdb16e37bbab564d30da473c2 On Mon, Jan 11, 2016 at 11:16 AM, jmfriedt wrote: My apologies for such a trivial bug report, but has anyone experienced issues with gr-osmosdr "lately" (not sure when the problem started) about "PLL not locked" and data flow rate mismatch in gnuradio data flows ? I have a couple dozen RTL2832U based dongles used for various SDR activities which have been working quite flawlessly until this summer at least. Being currently in the process of preparing the new teaching semester, I just discovered that *all* dongles (E4k, R820T or R820T2) experience the same lack of PLL locking and data flow rate mismatch when connected to USB ports *on laptops* (tested on four different laptop models, yet all running Debian/GNU Linux distributions, testing and sid releases). The audio output in such a simple decoding stream as Osmosdr Source - Low pass filter - WBFM decoder - audio output is not continuous and of very bad quality. The *same* dongles connected to desktop setups with the same Debian/GNU Linux distribution exhibit no issue: stream rate is consistent and sound quality excellent. Of course searching on the web for "PLL not locked" yields a couple of million hits explaining that the tuned frequency range is not within the bandwidth of the dongle VCO, which is not the case here. Has anyone seen reports of this issue before ? Thanks, JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- GDB has a 'break' feature; why doesn't it have 'fix' too? -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France This message was sent using IMP, the Internet Messaging Program. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-osmosdr issues ?
Thanks for the answers. All sampling rates are in the 1.5-2.5 MHz range, namely 11025*128=1.4112 MHz when decoding POCSAG, or 48000*32=1.536 MHz when decoding commercial FM (for these trivial tests). The issue about synchronization only arises when an audio sink is used: sending the data to a named pipe or scope sink displays the "PLL not locked" message but the decoding/display look fine. I should emphasize that rtl_fm -f 104.4e6 -M wbfm -s 20 -r 48000 - | aplay -r 48k -f S16_LE (running a friend's computer) works perfectly well, hence my concern about gr-osmosdr at opposed to the RTL libs. JM It's hardly a trivial report; RTL devices with gr-osmosdr are a very commonly used platform. I've seen similar messages from gqrx, but sound quality has not been impacted. My guess is that this may be related to rapid retuning for rtl devices, which basically involves not waiting for the PLL to lock. Does osmosdr-->nullsink display the same message? What about rtl_sdr ... > /dev null? Does this only happen at certain sample rates or at any rate? And are you using a supported sample rate? https://github.com/csete/gqrx/commit/d805c426f24f987cdb16e37bbab564d30da473c2 On Mon, Jan 11, 2016 at 11:16 AM, jmfriedt wrote: My apologies for such a trivial bug report, but has anyone experienced issues with gr-osmosdr "lately" (not sure when the problem started) about "PLL not locked" and data flow rate mismatch in gnuradio data flows ? I have a couple dozen RTL2832U based dongles used for various SDR activities which have been working quite flawlessly until this summer at least. Being currently in the process of preparing the new teaching semester, I just discovered that *all* dongles (E4k, R820T or R820T2) experience the same lack of PLL locking and data flow rate mismatch when connected to USB ports *on laptops* (tested on four different laptop models, yet all running Debian/GNU Linux distributions, testing and sid releases). The audio output in such a simple decoding stream as Osmosdr Source - Low pass filter - WBFM decoder - audio output is not continuous and of very bad quality. The *same* dongles connected to desktop setups with the same Debian/GNU Linux distribution exhibit no issue: stream rate is consistent and sound quality excellent. Of course searching on the web for "PLL not locked" yields a couple of million hits explaining that the tuned frequency range is not within the bandwidth of the dongle VCO, which is not the case here. Has anyone seen reports of this issue before ? Thanks, JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- GDB has a 'break' feature; why doesn't it have 'fix' too? -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France This message was sent using IMP, the Internet Messaging Program. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-osmosdr issues ?
It's hardly a trivial report; RTL devices with gr-osmosdr are a very commonly used platform. I've seen similar messages from gqrx, but sound quality has not been impacted. My guess is that this may be related to rapid retuning for rtl devices, which basically involves not waiting for the PLL to lock. Does osmosdr-->nullsink display the same message? What about rtl_sdr ... > /dev null? Does this only happen at certain sample rates or at any rate? And are you using a supported sample rate? https://github.com/csete/gqrx/commit/d805c426f24f987cdb16e37bbab564d30da473c2 On Mon, Jan 11, 2016 at 11:16 AM, jmfriedt wrote: > My apologies for such a trivial bug report, but has anyone experienced issues > with gr-osmosdr > "lately" (not sure when the problem started) about "PLL not locked" and data > flow rate mismatch > in gnuradio data flows ? > > I have a couple dozen RTL2832U based dongles used for various SDR activities > which have been > working quite flawlessly until this summer at least. Being currently in the > process of preparing > the new teaching semester, I just discovered that *all* dongles (E4k, R820T > or R820T2) experience > the same lack of PLL locking and data flow rate mismatch when connected to > USB ports *on laptops* > (tested on four different laptop models, yet all running Debian/GNU Linux > distributions, testing > and sid releases). The audio output in such a simple decoding stream as > Osmosdr Source - Low pass > filter - WBFM decoder - audio output is not continuous and of very bad > quality. The *same* dongles > connected to desktop setups with the same Debian/GNU Linux distribution > exhibit no issue: stream > rate is consistent and sound quality excellent. Of course searching on the > web for "PLL not locked" > yields a couple of million hits explaining that the tuned frequency range is > not within the > bandwidth of the dongle VCO, which is not the case here. > > Has anyone seen reports of this issue before ? > > Thanks, JM > > -- > JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 > Besancon, France > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-osmosdr issues ?
On 01/11/2016 02:16 PM, jmfriedt wrote: My apologies for such a trivial bug report, but has anyone experienced issues with gr-osmosdr "lately" (not sure when the problem started) about "PLL not locked" and data flow rate mismatch in gnuradio data flows ? I have a couple dozen RTL2832U based dongles used for various SDR activities which have been working quite flawlessly until this summer at least. Being currently in the process of preparing the new teaching semester, I just discovered that *all* dongles (E4k, R820T or R820T2) experience the same lack of PLL locking and data flow rate mismatch when connected to USB ports *on laptops* (tested on four different laptop models, yet all running Debian/GNU Linux distributions, testing and sid releases). The audio output in such a simple decoding stream as Osmosdr Source - Low pass filter - WBFM decoder - audio output is not continuous and of very bad quality. The *same* dongles connected to desktop setups with the same Debian/GNU Linux distribution exhibit no issue: stream rate is consistent and sound quality excellent. Of course searching on the web for "PLL not locked" yields a couple of million hits explaining that the tuned frequency range is not within the bandwidth of the dongle VCO, which is not the case here. Has anyone seen reports of this issue before ? Thanks, JM If you're running at low sample rates, use buflen=16384 in your device arguments, otherwise, things will be "lumpy". ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-osmosdr issues ?
My apologies for such a trivial bug report, but has anyone experienced issues with gr-osmosdr "lately" (not sure when the problem started) about "PLL not locked" and data flow rate mismatch in gnuradio data flows ? I have a couple dozen RTL2832U based dongles used for various SDR activities which have been working quite flawlessly until this summer at least. Being currently in the process of preparing the new teaching semester, I just discovered that *all* dongles (E4k, R820T or R820T2) experience the same lack of PLL locking and data flow rate mismatch when connected to USB ports *on laptops* (tested on four different laptop models, yet all running Debian/GNU Linux distributions, testing and sid releases). The audio output in such a simple decoding stream as Osmosdr Source - Low pass filter - WBFM decoder - audio output is not continuous and of very bad quality. The *same* dongles connected to desktop setups with the same Debian/GNU Linux distribution exhibit no issue: stream rate is consistent and sound quality excellent. Of course searching on the web for "PLL not locked" yields a couple of million hits explaining that the tuned frequency range is not within the bandwidth of the dongle VCO, which is not the case here. Has anyone seen reports of this issue before ? Thanks, JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
