27 Jun
2013
27 Jun
'13
10:32 a.m.
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
11:11 a.m.
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(a)gmail.com> wrote:
Is this just a
limitation of the hardware?
Yes.
Cheers,
Sylvain
11:16 a.m.
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
12:52 p.m.
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(a)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
1:03 p.m.
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(a)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(a)gmail.com> wrote:
--
Francesco Gugliuzza
B.Sc. in Computer Engineering
HackLabProject.org Administrator
Linux user #374630
Tel (VoIP geographic number): +39 0921440446
Tel (Libera il VoIP number): 5125320
E-mail: f.gugliuzza(a)hacklabproject.org
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
3978
days inactive
3978
days old
5 comments
3 participants
participants (3)
-
David Jacobowitz -
Francesco Gugliuzza -
Sylvain Munaut