Programming RTL-SDR: changing frequency while acquiring samples ?
2,312 views
Skip to first unread message
Paweł Jałocha
Jul 2, 2013, 3:39:10 PM7/2/13
to ultra-c...@googlegroups.com
Anybody can say whether this is possible: change the centre frequency of RTL-SDR radio while the samples are being acquired. This seems to crash (stop) the acquisition. I speak from a point of view of a C programmer. The goal is scanning or hopping across frequencies.
Thank you, Pawel.
Thank you, Pawel.
Sylvain AZARIAN
Jul 2, 2013, 3:48:57 PM7/2/13
to ultra-c...@googlegroups.com
Hi,
From my experience this strongly depends on the operating system/platform... For example on Windows, asking for a new frequency with rtlsdr_set_center_freq takes "a certain time", and you clearly "see it" (less than 1 second, but takes time). On linux (even on Raspberry Pi) no delay ... at least not visible.
I have not really investigated this, as I am mainly working with Linux and some porting to Windows.. but I suspect some difference in the libusb packet querying/scheduling and I guess it seems the requests (usually endpoint 0) are not processed correctly while streaming on a different endpoint (samples)
The interesting thing is : if you look at the rtl_tcp application, there is no special care in the way the set frequency is called. One thread is processing the samples, while the second thread is locked on socket read.
This is more or less what I am doing in my case, but I do not get the same fast tuning... using rtl_tcp with sdr application does not show stalling/crash while tuning, and I am not able to have the same behavior too....
sylvain
Anybody can say whether this is possible: change the centre frequency of RTL-SDR radio while the samples are being acquired. This seems to crash (stop) the acquisition. I speak from a point of view of a C programmer. The goal is scanning or hopping across frequencies.
Thank you, Pawel.
--
You received this message because you are subscribed to the Google Groups "Ultra Cheap SDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ultra-cheap-s...@googlegroups.com.
To post to this group, send email to ultra-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/ultra-cheap-sdr.
For more options, visit https://groups.google.com/groups/opt_out.
Paweł Jałocha
Jul 2, 2013, 4:09:45 PM7/2/13
to ultra-c...@googlegroups.com
RIght, it is interesting, that rtl_tcp can do it, and I can not :-)
I am programming on Linux (PC and RaspberryPI) and have as well two threads: one acquires and processes the data, second post-processes and does some slow-control. I tried to chage the frequency in both threads, but this stops the data flowing and I need to kill -9 the program.
Pawel.
I am programming on Linux (PC and RaspberryPI) and have as well two threads: one acquires and processes the data, second post-processes and does some slow-control. I tried to chage the frequency in both threads, but this stops the data flowing and I need to kill -9 the program.
Pawel.
Sylvain AZARIAN
Jul 2, 2013, 4:15:45 PM7/2/13
to ultra-c...@googlegroups.com
I am using three threads: one is stalled because it starts the async calls... and this does not crash. The callback function enqueues samples in a linked list, the other threads do signal processing and command handling, quite like rtl-tcp.
How do you collect the samples ?
In my case the system is stable and can run for hours.
Sylvain
Paweł Jałocha
Jul 2, 2013, 4:22:05 PM7/2/13
to ultra-c...@googlegroups.com
It is possibly the same configuration.
The main thread does the control, prepares the SDR and then it kicks off a separate thread which only executes rtlsdr_read_async() and then waits for its completion, while the callback function processes the samples. There is some C++ wrapping involved but not very much.
This can run for hours, does not crash, unless I try to change the frequency in the main thread.
Thus you actually change the frequency while running your application ?
Pawel.
The main thread does the control, prepares the SDR and then it kicks off a separate thread which only executes rtlsdr_read_async() and then waits for its completion, while the callback function processes the samples. There is some C++ wrapping involved but not very much.
This can run for hours, does not crash, unless I try to change the frequency in the main thread.
Thus you actually change the frequency while running your application ?
Pawel.
Sylvain AZARIAN
Jul 2, 2013, 4:27:19 PM7/2/13
to ultra-c...@googlegroups.com
Yes... except I do not use C++, just C.
The command processing thread receives tuning requests and this works...
:-(
Paweł Jałocha
Jul 2, 2013, 4:35:30 PM7/2/13
to ultra-c...@googlegroups.com
Just tried to switch the frequency but without locking the SDR and it seems to work ?
The call to change frequency comes back after about 100 ms. Possibly this has to do with the size fo the sample batch ?
Pawel.
The call to change frequency comes back after about 100 ms. Possibly this has to do with the size fo the sample batch ?
Pawel.
Sylvain AZARIAN
Jul 2, 2013, 4:44:44 PM7/2/13
to ultra-c...@googlegroups.com
I have the same delay... but on windows only
Sylvain
Leif Asbrink
Jul 2, 2013, 5:22:09 PM7/2/13
to ultra-c...@googlegroups.com
Hi Paweł,
Yes. you can change the frequency while sampling.
In Linrad it works fine.
The interface to the osmocom library is contained in
rtl2832.c which is about 400 lines of code. You can find it
in lir03-48.tbz or lir03-48.zip (the archives contain the
same files.)
http://www.sm5bsz.com/linuxdsp/linrad.htm
Linrad uses a modified library that allows better performance
for E4000 tuners, but it is fully compatible with the osmocom
library (or at least it was in April 2013.)
Frequency hopping is fast and you should have no problem.
73
Leif / SM5BSZ
Yes. you can change the frequency while sampling.
In Linrad it works fine.
The interface to the osmocom library is contained in
rtl2832.c which is about 400 lines of code. You can find it
in lir03-48.tbz or lir03-48.zip (the archives contain the
same files.)
http://www.sm5bsz.com/linuxdsp/linrad.htm
Linrad uses a modified library that allows better performance
for E4000 tuners, but it is fully compatible with the osmocom
library (or at least it was in April 2013.)
Frequency hopping is fast and you should have no problem.
73
Leif / SM5BSZ
jdow
Jul 2, 2013, 9:29:05 PM7/2/13
to ultra-c...@googlegroups.com
It is. It is a very slow process comparatively speaking. Older versions
which exposed the "LO Frequency" setting highlight this feature.
{^_^}
which exposed the "LO Frequency" setting highlight this feature.
{^_^}
Leif Asbrink
Jul 3, 2013, 3:37:43 PM7/3/13
to ultra-c...@googlegroups.com
Hi all,
From "a point of view of a C programmer." I think the frequency
change is reasonably fast. This call:
rtlsdr_set_center_freq(dev_rtlsdr, frequency);
does the frequency cange. Under Windows XP on Compaq 6510b
with Intel Centrino Duo it returns in 42 to 44 milliseconds.
Under Debian squeeze on a Pentium4 it returns in 37 ms.
That is with Linrad when sampling at 1 MHz. The call to change
the frequency is of course not in a thread involved with the
sampling.
Regards
Leif / SM5BSZ
From "a point of view of a C programmer." I think the frequency
change is reasonably fast. This call:
rtlsdr_set_center_freq(dev_rtlsdr, frequency);
does the frequency cange. Under Windows XP on Compaq 6510b
with Intel Centrino Duo it returns in 42 to 44 milliseconds.
Under Debian squeeze on a Pentium4 it returns in 37 ms.
That is with Linrad when sampling at 1 MHz. The call to change
the frequency is of course not in a thread involved with the
sampling.
Regards
Leif / SM5BSZ
Sylvain AZARIAN
Jul 3, 2013, 4:21:00 PM7/3/13
to ultra-c...@googlegroups.com
My tests were on Windows 7 Pro 64 bits, compiled with MinGW 32 bits.
I am far from the timings you annouce. More in the range of several hundreds of milliseconds
sylvain
Leif Asbrink
Jul 3, 2013, 5:47:01 PM7/3/13
to ultra-c...@googlegroups.com
Hi Sylvain,
I have a Windows 7 Home Premium 32 bit installation on the
Compaq 6510b. The calls
rtlsdr_set_center_freq(dev_rtlsdr, frequency);
return in 39 milliseconds wirth an exception for the first
one (during startup) which returns in 44 milliseconds.
That is with a sampling rate of 1 MHz and with an interrupt
rate of 122 Hz (block size 8192 samples) which is default
in Linrad.
Leif / SM5BSZ
I have a Windows 7 Home Premium 32 bit installation on the
Compaq 6510b. The calls
rtlsdr_set_center_freq(dev_rtlsdr, frequency);
return in 39 milliseconds wirth an exception for the first
one (during startup) which returns in 44 milliseconds.
That is with a sampling rate of 1 MHz and with an interrupt
rate of 122 Hz (block size 8192 samples) which is default
in Linrad.
Leif / SM5BSZ
wa5ngp
Jul 3, 2013, 8:27:58 PM7/3/13
to ultra-c...@googlegroups.com
hello Pawel,
I also have a raspberry pi that I will evnentually want to use for the sdr. Is there a way to exchange our emails without jeopardizing security? I'm not very familiar with how gmail groups work. There must be a way. is there a process have a personal message exchange. I you look me up in QRZ.com, WA5NGP you will find my email address.
I also have a raspberry pi that I will evnentually want to use for the sdr. Is there a way to exchange our emails without jeopardizing security? I'm not very familiar with how gmail groups work. There must be a way. is there a process have a personal message exchange. I you look me up in QRZ.com, WA5NGP you will find my email address.
jdow
Jul 4, 2013, 1:17:37 AM7/4/13
to ultra-c...@googlegroups.com
The number of bytes stored up in buffers already queued for processing
will make a huge difference in the apparent time to change frequencies.
1 megabyte of buffers at 1 Msps will take 1 second to clear. Cut the
number of buffers used to a bare minimum and you'll be able to scan
quicker.
Track down the other sources of latency and you can probably speed the
system even more. Although if you use an FFT to pinpoint signals within
the 1 MHz band (maybe 800 kHz usable) at 1 Msps you get another one
quarter second of latency if you use 262144 FFT bins.
{^_^}
will make a huge difference in the apparent time to change frequencies.
1 megabyte of buffers at 1 Msps will take 1 second to clear. Cut the
number of buffers used to a bare minimum and you'll be able to scan
quicker.
Track down the other sources of latency and you can probably speed the
system even more. Although if you use an FFT to pinpoint signals within
the 1 MHz band (maybe 800 kHz usable) at 1 Msps you get another one
quarter second of latency if you use 262144 FFT bins.
{^_^}
Sylvain AZARIAN
Jul 4, 2013, 5:08:03 AM7/4/13
to ultra-c...@googlegroups.com
Thanks for the tips. The delay I am talking about is the time required just to process this call :
/*.......*/
rc = rtlsdr_set_center_freq(rtlsdr_device, fMHZ*1e6 + fHZ );
/*.....*/
this very simple call is taking several hundreds of milliseconds, sampling at 1MSPS
regards
sylvain
To unsubscribe from this group and stop receiving emails from it, send an email to ultra-cheap-sdr+unsubscribe@googlegroups.com.
To post to this group, send email to ultra-cheap-sdr@googlegroups.com.
Visit this group at http://groups.google.com/group/ultra-cheap-sdr.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Ultra Cheap SDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ultra-cheap-sdr+unsubscribe@googlegroups.com.
To post to this group, send email to ultra-cheap-sdr@googlegroups.com.
Leif Asbrink
Jul 4, 2013, 9:34:23 AM7/4/13
to ultra-c...@googlegroups.com
Hi Sylvain,
I have no idea why the call is so slow for you. Here it is
pretty fast under Windows as well as under Linux.
The callback
rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
has the value 32768 for len with the standard parameters
in Linrad. Even if I increase to 524288, the time to call
rtlsdr_set_center_freq() remains 40 milliseconds in
Linrad.
I am using mingw32 and I had problems generating libusb.a due
to some bug I have now forgotten about. Maybe you would get a
better response with the libusb.a that you can find in linrad-libs here:
http://www.sm5bsz.com/linuxdsp/install/compile/wincompile.htm
(The source code is at the bottom of the page and the changes
are in libusb/os/poll_windows.c)
Regards
Leif
> Thanks for the tips. The delay I am talking about is the time required just
> to process this call :
>
> /*.......*/
> rc = rtlsdr_set_center_freq(rtlsdr_device, fMHZ*1e6 + fHZ );
> /*.....*/
> this very simple call is taking several hundreds of milliseconds, sampling
> at 1MSPS
>
> regards
> sylvain
>
>
> 2013/7/4 jdow <jd...@earthlink.net>
>
> > The number of bytes stored up in buffers already queued for processing
> > will make a huge difference in the apparent time to change frequencies.
> >
> > 1 megabyte of buffers at 1 Msps will take 1 second to clear. Cut the
> > number of buffers used to a bare minimum and you'll be able to scan
> > quicker.
> >
> > Track down the other sources of latency and you can probably speed the
> > system even more. Although if you use an FFT to pinpoint signals within
> > the 1 MHz band (maybe 800 kHz usable) at 1 Msps you get another one
> > quarter second of latency if you use 262144 FFT bins.
> >
> > {^_^}
> >
> >
> > On 2013/07/03 12:37, Leif Asbrink wrote:
> >
> >> Hi all,
> >>
> >> From "a point of view of a C programmer." I think the frequency
> >>>
> >> change is reasonably fast. This call:
> >> rtlsdr_set_center_freq(dev_**rtlsdr, frequency);
> >>> .
> >>> To post to this group, send email to ultra-cheap-sdr@googlegroups.**com<ultra-c...@googlegroups.com>
> >>> .
> >>> Visit this group at http://groups.google.com/**group/ultra-cheap-sdr<http://groups.google.com/group/ultra-cheap-sdr>
> >>> .
> >>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> >>> .
> > .
> > To post to this group, send email to ultra-cheap-sdr@googlegroups.**com<ultra-c...@googlegroups.com>
> > .
> > Visit this group at http://groups.google.com/**group/ultra-cheap-sdr<http://groups.google.com/group/ultra-cheap-sdr>
> > .
> > For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> > .
> To post to this group, send email to ultra-c...@googlegroups.com.
I have no idea why the call is so slow for you. Here it is
pretty fast under Windows as well as under Linux.
The callback
rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
has the value 32768 for len with the standard parameters
in Linrad. Even if I increase to 524288, the time to call
rtlsdr_set_center_freq() remains 40 milliseconds in
Linrad.
I am using mingw32 and I had problems generating libusb.a due
to some bug I have now forgotten about. Maybe you would get a
better response with the libusb.a that you can find in linrad-libs here:
http://www.sm5bsz.com/linuxdsp/install/compile/wincompile.htm
(The source code is at the bottom of the page and the changes
are in libusb/os/poll_windows.c)
Regards
Leif
> Thanks for the tips. The delay I am talking about is the time required just
> to process this call :
>
> /*.......*/
> rc = rtlsdr_set_center_freq(rtlsdr_device, fMHZ*1e6 + fHZ );
> /*.....*/
> this very simple call is taking several hundreds of milliseconds, sampling
> at 1MSPS
>
> regards
> sylvain
>
>
> 2013/7/4 jdow <jd...@earthlink.net>
>
> > The number of bytes stored up in buffers already queued for processing
> > will make a huge difference in the apparent time to change frequencies.
> >
> > 1 megabyte of buffers at 1 Msps will take 1 second to clear. Cut the
> > number of buffers used to a bare minimum and you'll be able to scan
> > quicker.
> >
> > Track down the other sources of latency and you can probably speed the
> > system even more. Although if you use an FFT to pinpoint signals within
> > the 1 MHz band (maybe 800 kHz usable) at 1 Msps you get another one
> > quarter second of latency if you use 262144 FFT bins.
> >
> > {^_^}
> >
> >
> > On 2013/07/03 12:37, Leif Asbrink wrote:
> >
> >> Hi all,
> >>
> >> From "a point of view of a C programmer." I think the frequency
> >>>
> >> change is reasonably fast. This call:
> >> does the frequency cange. Under Windows XP on Compaq 6510b
> >> with Intel Centrino Duo it returns in 42 to 44 milliseconds.
> >> Under Debian squeeze on a Pentium4 it returns in 37 ms.
> >>
> >> That is with Linrad when sampling at 1 MHz. The call to change
> >> the frequency is of course not in a thread involved with the
> >> sampling.
> >>
> >> Regards
> >>
> >> Leif / SM5BSZ
> >>
> >>
> >>
> >>
> >>
> >> jdow <jd...@earthlink.net> wrote:
> >>
> >> It is. It is a very slow process comparatively speaking. Older versions
> >>> which exposed the "LO Frequency" setting highlight this feature.
> >>>
> >>> {^_^}
> >>>
> >>> On 2013/07/02 12:39, Paweł Jałocha wrote:
> >>>
> >>>> Anybody can say whether this is possible: change the centre frequency
> >>>> of RTL-SDR
> >>>> radio while the samples are being acquired. This seems to crash (stop)
> >>>> the
> >>>> acquisition. I speak from a point of view of a C programmer. The goal is
> >>>> scanning or hopping across frequencies.
> >>>>
> >>>> Thank you, Pawel.
> >>>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Ultra Cheap SDR" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> >>> an email to ultra-cheap-sdr+unsubscribe@**googlegroups.com<ultra-cheap-sdr%2Bunsu...@googlegroups.com>
> >> with Intel Centrino Duo it returns in 42 to 44 milliseconds.
> >> Under Debian squeeze on a Pentium4 it returns in 37 ms.
> >>
> >> That is with Linrad when sampling at 1 MHz. The call to change
> >> the frequency is of course not in a thread involved with the
> >> sampling.
> >>
> >> Regards
> >>
> >> Leif / SM5BSZ
> >>
> >>
> >>
> >>
> >>
> >> jdow <jd...@earthlink.net> wrote:
> >>
> >> It is. It is a very slow process comparatively speaking. Older versions
> >>> which exposed the "LO Frequency" setting highlight this feature.
> >>>
> >>> {^_^}
> >>>
> >>> On 2013/07/02 12:39, Paweł Jałocha wrote:
> >>>
> >>>> Anybody can say whether this is possible: change the centre frequency
> >>>> of RTL-SDR
> >>>> radio while the samples are being acquired. This seems to crash (stop)
> >>>> the
> >>>> acquisition. I speak from a point of view of a C programmer. The goal is
> >>>> scanning or hopping across frequencies.
> >>>>
> >>>> Thank you, Pawel.
> >>>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Ultra Cheap SDR" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> >>> .
> >>> To post to this group, send email to ultra-cheap-sdr@googlegroups.**com<ultra-c...@googlegroups.com>
> >>> .
> >>> Visit this group at http://groups.google.com/**group/ultra-cheap-sdr<http://groups.google.com/group/ultra-cheap-sdr>
> >>> .
> >>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> >>> .
> >>>
> >>>
> >>>
> >>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ultra Cheap SDR" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to ultra-cheap-sdr+unsubscribe@**googlegroups.com<ultra-cheap-sdr%2Bunsu...@googlegroups.com>
> >>>
> >>>
> >>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Ultra Cheap SDR" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > .
> > To post to this group, send email to ultra-cheap-sdr@googlegroups.**com<ultra-c...@googlegroups.com>
> > .
> > Visit this group at http://groups.google.com/**group/ultra-cheap-sdr<http://groups.google.com/group/ultra-cheap-sdr>
> > .
> > For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> > .
> >
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Ultra Cheap SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ultra-cheap-s...@googlegroups.com.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Ultra Cheap SDR" group.
> To post to this group, send email to ultra-c...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages