Re: [Discuss-gnuradio] gr-osmosdr issues ?

[Chris Kuethe]

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 300000 and 900001 to 3200000.
> 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
<address@hidden> 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 200000 -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
>> <address@hidden> 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
>>> address@hidden
>>> 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?

simple_fm_rx.grc.png
Description: PNG image