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.
>
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
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
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
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
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
