[Discuss-gnuradio] Stop GRC flow graph after defined time
Hallo, I'm executing a flow graph in GRC and want to stop this flow graph after some defined time, for example 3 seconds, or after a defined amount of samples. Currently I stop the flow graph by clicking on Kill the flow graph. How can I implement, that the flow graph is stopped automatically? Thorsten ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] strange receiver behaviour with UHD
Thanks for all your replies! We did some additional experiments where we divided our program into 2 phases. In phase 1 we did all the initialization like setting rx rate, center frequency, gain, synchronizing to ref clock, and finally issued a stream command to receive samples. The received samples are then thrown away as you suggested. In phase 2 all the settings are already set so we issue a new stream command to receive new samples. If we look at the abs value of these samples we still have the same spike in the beginning of the collected set. Our conclusion is that the stream command somehow introduce this spike so we always need to receive more samples with the stream command and throw away the beginning of the collected set. We also tried different stream modes (STREAM_MODE_NUM_SAMPS_AND_DONE or STREAM_MODE_NUM_SAMPS_AND_MORE) but with the same result. Regards - Patrik -Original Message- From: discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu.org [mailto:discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu. org] On Behalf Of Per Zetterberg Sent: Tuesday, September 28, 2010 7:46 PM To: Marcus D. Leech Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] strange receiver behaviour with UHD On Tue, 2010-09-28 at 13:34 -0400, Marcus D. Leech wrote: It's likely that initialization of the board gain and frequency settings will take some finite but non-zero amount of time to settle. It's always a good idea to toss the first few samples until things settle down. The settling time will be different for each daughterboard and should be experimentally determined in your application. --n Yup, and I'd like to point out that this isn't just a quirk of this particular hardware. All such hardware takes a finite amount of time to settle -- the synthesizers often take a handful of milliseconds to settle to their final value, and even VGA settings take finite time. The A/D has no way of knowing what that time is, so it starts sending samples right away--those samples will contain artifacts of whatever settling has to take place. Fact of life. I don't know how the filters in the FPGA are coded, but it also wouldn't surprise me if they take some finite amount of time to converge on correct output, since they'll have some indeterminate startup state. My experience is that it doesn't matter how long I wait after setting the gain and frequency. It could be FPGA filters. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Stop GRC flow graph after defined time
You can use the Misc-Head block to limit the samples. Then set the flow graph options to run to completion, this option is only available in non-gui mode. See the options blocks. -Josh On 09/29/2010 04:31 AM, Thorsten Laude wrote: Hallo, I'm executing a flow graph in GRC and want to stop this flow graph after some defined time, for example 3 seconds, or after a defined amount of samples. Currently I stop the flow graph by clicking on Kill the flow graph. How can I implement, that the flow graph is stopped automatically? Thorsten ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Same File Size
Hello All, I am expecting to see a similiar file size in a simple test file that im running and I don't get that. Is there something Im missing? USRP2-FileSink SignalSource-Throttle-FileSink I have checked obvious things. The USRP2 block is set to a decimation of 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3 MS/s. So I set the overall sample rate to 250e3. I have also set the datatypes of all the blocks to floats. The Throttle is set to 250e3. If it matters the signal source is set to a saw tooth,1Hz. Im more interested in knowing that samples read back out of the files are synchronized. So I guess it doesn't matter if they are the same length if all this mean is that I need to trim the files to the same length. Thanks, Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Same File Size
On Wed, Sep 29, 2010 at 04:14:18PM -0400, Justin Bracken wrote: Hello All, I am expecting to see a similiar file size in a simple test file that im running and I don't get that. Is there something Im missing? USRP2-FileSink SignalSource-Throttle-FileSink I have checked obvious things. The USRP2 block is set to a decimation of 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3 MS/s. So I set the overall sample rate to 250e3. I have also set the datatypes of all the blocks to floats. The Throttle is set to 250e3. If it matters the signal source is set to a saw tooth,1Hz. Im more interested in knowing that samples read back out of the files are synchronized. So I guess it doesn't matter if they are the same length if all this mean is that I need to trim the files to the same length. Thanks, Justin If you want a particular number of samples in a file, etc., use gr.head. Generally you SHOULD NOT be using throttle. throttle causes so much confusion, I'm of the opinion that we should remove it from the code base. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Same File Size
-- Forwarded message -- From: Justin Bracken scourc...@gmail.com Date: Wednesday, September 29, 2010 Subject: Same File Size To: Eric Blossom e...@comsec.com Are the samples in the files synced? I.e. The sample at index 1 in file1 is recorded at the same time as the sample at index 1 in file2? In which case file length is irrelevant. On Sep 29, 2010, at 4:20 PM, Eric Blossom e...@comsec.com wrote: On Wed, Sep 29, 2010 at 04:14:18PM -0400, Justin Bracken wrote: Hello All, I am expecting to see a similiar file size in a simple test file that im running and I don't get that. Is there something Im missing? USRP2-FileSink SignalSource-Throttle-FileSink I have checked obvious things. The USRP2 block is set to a decimation of 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3 MS/s. So I set the overall sample rate to 250e3. I have also set the datatypes of all the blocks to floats. The Throttle is set to 250e3. If it matters the signal source is set to a saw tooth,1Hz. Im more interested in knowing that samples read back out of the files are synchronized. So I guess it doesn't matter if they are the same length if all this mean is that I need to trim the files to the same length. Thanks, Justin If you want a particular number of samples in a file, etc., use gr.head. Generally you SHOULD NOT be using throttle. throttle causes so much confusion, I'm of the opinion that we should remove it from the code base. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Same File Size
If throttle is removed then how can we prevent the cpu being used up if there is not rate limiting block in the flowgraph ? On Wed, Sep 29, 2010 at 1:46 PM, Justin Bracken scourc...@gmail.com wrote: -- Forwarded message -- From: Justin Bracken scourc...@gmail.com Date: Wednesday, September 29, 2010 Subject: Same File Size To: Eric Blossom e...@comsec.com Are the samples in the files synced? I.e. The sample at index 1 in file1 is recorded at the same time as the sample at index 1 in file2? In which case file length is irrelevant. On Sep 29, 2010, at 4:20 PM, Eric Blossom e...@comsec.com wrote: On Wed, Sep 29, 2010 at 04:14:18PM -0400, Justin Bracken wrote: Hello All, I am expecting to see a similiar file size in a simple test file that im running and I don't get that. Is there something Im missing? USRP2-FileSink SignalSource-Throttle-FileSink I have checked obvious things. The USRP2 block is set to a decimation of 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3 MS/s. So I set the overall sample rate to 250e3. I have also set the datatypes of all the blocks to floats. The Throttle is set to 250e3. If it matters the signal source is set to a saw tooth,1Hz. Im more interested in knowing that samples read back out of the files are synchronized. So I guess it doesn't matter if they are the same length if all this mean is that I need to trim the files to the same length. Thanks, Justin If you want a particular number of samples in a file, etc., use gr.head. Generally you SHOULD NOT be using throttle. throttle causes so much confusion, I'm of the opinion that we should remove it from the code base. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Optimal way of performing multiple FFTs on a stream of data
On Wed, Sep 29, 2010 at 01:47:22PM -0700, John Andrews wrote:
Hi,
This is more of a programming question than a gnuradio question.
I am writing a C++ block that takes in a stream of complex data, an N
element block {B} is chosen from the stream, this block is multiplied with a
set {M1, M2, M3...Mn} where size of each set element is N (same as data
block) too. I want to find FFT using FFTW library on each of the products
{B.M1, B.M2, B.Mn} in the general_work() function. As this can be an
intensive task can someone suggest me what could be the optimal strategy to
do without compromising efficiency and risk losing samples that is entering
the machine from the USRP. I was thinking about multithreading. Do you think
this is the way to go?
Thanks,
John
I'd measure first, and see if you've really got a problem.
(Premature optimization is the root of all evil.)
Note also that GNU Radio itself is multithreaded, and if you're doing
substantial work in other blocks, your cores may already being put to
productive work.
Make sure that the version of FFTW you're using was built with SSE
support enabled.
http://fftw.org/fftw3_doc/Installation-on-Unix.html
./configure --enable-sse --enable-float
Measure again :-)
If you do have a problem, and your cores are not already 100%
utilized, then you may want to look at using the FFTW's suport for
multithreading (inside of the package). Note that it will only make
sense if you use one of the advanced interfaces that allows you to ask
it to compute multiple FFT's in one call to the API. The standard
interface won't help, unless your FFTs are seriously big -- say, 1M
points.
http://fftw.org/fftw3_doc/Multi_002dthreaded-FFTW.html
http://fftw.org/fftw3_doc/Advanced-Complex-DFTs.html
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
