discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of sam


From: Josh Blum
Subject: Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
Date: Wed, 03 Mar 2010 10:20:32 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre


1) I've just installed the usrp2_vrt branch and tried running
rx_timed_samples.cc. No matter what number of samples i specify in the
options, the program just keeps running and printing out the timestamps...
Even after i press Ctrl+C the computer still continues to receive data
through the ethernet port implying that the u2->stop_rx_streaming doesn't
get called. Does anyone know what the problem could be?


Its possible that your machine is slow enough such that it always has samples in the packet ring and no lag time for the CPU. In this case, the rx_samples call does not get a chance to return and therefore the while loop cannot get a chance to check the done condition.

A remedy could be to change line 54:     return true; with the following
return not done(); This will cause the callback to return false when done, so that rx_samples with exit and the loop condition will be checked.

This is due to a false assumption on my part, let me know if that change fixes it for you.

2) Could anyone please clarify what nitems means in the following line of
the handler in rx_timed_samples.cc:
     operator()(const uint32_t *items, size_t nitems, const
vrt::expanded_header *vrt_header)

Its a callable object. An instance of it gets created and passed into u2->rx_samples(&my_handler);

As far as I can see from the code, d_num_samples gets incremented by nitems
every time rx_samples is called and then is comparared whith d_max_samples
implying that nitems is the number of samples received. But nitems is always
365,hence d_num_samples gets incremented in step of 365, therefore is it
correct that one can receive only a number of samples which is a multiple of
365? Hence what's the point in specifying 1000 as a number of samples to
receive?


1000 is an arbitrary number. If the actual number of items per packet is 365, then it should take 3 receives to have more than 1000 samples, and the program should be done.

-Josh




reply via email to

[Prev in Thread] Current Thread [Next in Thread]