I'm trying to write some code that uses a Raspberry Pi not just to capture the samples, but also to do the DSP. The signal I'm working (aviation VOR) is narrow and the DSP is not too hard-core, but it'll be easier if I can sample at a lower rate.
Though rtlsdr_set_sample_rate returns no errors and rtlsdr_get_sample_rate returns the same value I gave it (or quite close), it does not appear to be working. I had been working at 250ksps but wanted to try 125ksps or even 62500sps, but none of those seem to work.
Is this just a limitation of the hardware?
I have a NooElec RTL2832 / R820T device if that matters.
Regards, Dave J
Thanks, Sylvain. That makes sense. I probably wouldn't have spent so much time on it if the lib gave some indication that it wasn't setting those rates.
On Thu, Jun 27, 2013 at 1:49 AM, Sylvain Munaut 246tnt@gmail.com wrote:
Is this just a limitation of the hardware?
Yes.
Cheers,
Sylvain
Thanks, Sylvain. That makes sense. I probably wouldn't have spent so much time on it if the lib gave some indication that it wasn't setting those rates.
Well, we don't really know exactly what rates are supported by the hardware or not since there isn't exactly good documentation on it ... and the lib will just pass that to the hardware as long as the range fits into the "registers". This way users can experiment ...
But if you want reliable operation you should stick to "known" working samples rates like 250k 1M 1.024M 2M 2.048M 2.4M
Cheers
Sylvain
One could probably write a program that can tune to a known signal and then test through a range of sample rates to determine which ones generate a data stream that when treated at the expected sample rate gives the expected signal
.... a project for another day.
On Thu, Jun 27, 2013 at 2:16 AM, Sylvain Munaut 246tnt@gmail.com wrote:
Thanks, Sylvain. That makes sense. I probably wouldn't have spent so much time on it if the lib gave some indication that it wasn't setting those rates.
Well, we don't really know exactly what rates are supported by the hardware or not since there isn't exactly good documentation on it ... and the lib will just pass that to the hardware as long as the range fits into the "registers". This way users can experiment ...
But if you want reliable operation you should stick to "known" working samples rates like 250k 1M 1.024M 2M 2.048M 2.4M
Cheers
Sylvain
You shouldn't need to do any tuning. http://cgit.osmocom.org/rtl-sdr/tree/include/rtl-sdr.h search "test mode" in the file. Once you have enabled the counter, just check the incoming samples to see if you drop any data. I *think* rtl_test does it when running in async mode, but I'm not so sure. I'd like an official word from the devs on this.
2013/6/27 David Jacobowitz david.jacobowitz@gmail.com
One could probably write a program that can tune to a known signal and then test through a range of sample rates to determine which ones generate a data stream that when treated at the expected sample rate gives the expected signal
.... a project for another day.
On Thu, Jun 27, 2013 at 2:16 AM, Sylvain Munaut 246tnt@gmail.com wrote:
Thanks, Sylvain. That makes sense. I probably wouldn't have spent so
much
time on it if the lib gave some indication that it wasn't setting those rates.
Well, we don't really know exactly what rates are supported by the hardware or not since there isn't exactly good documentation on it ... and the lib will just pass that to the hardware as long as the range fits into the "registers". This way users can experiment ...
But if you want reliable operation you should stick to "known" working samples rates like 250k 1M 1.024M 2M 2.048M 2.4M
Cheers
Sylvain
-
David Jacobowitz -
Francesco Gugliuzza -
Sylvain Munaut