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

[ValentinG]

Thanks a lot Josh! Adding return not done() instead of return true did work.
I'm running Ubuntu in virtualbox, hence the lack of resources.

Couple more questions if you don't mind:
1) Where does the number of items per packet (which is 365 in my case) comes
from? Or is it the format USRP2 always uses to send the data to the host?

2) After specifying -N as 1000 I got the following output:

Got packet: 1267693414 secs, 35564266 ticks
Got packet: 1267693414 secs, 35570106 ticks
Got packet: 1267693414 secs, 35575946 ticks

So the number of ticks between the packets is 5840, dividing by 365 we get
16-the number of ticks per sample, and the decimation is 16 which is
consistent. My question is: if I want to extract the timestamps for each
sample individually I would need to take the timestamp of the packet and
subtract the required number of 16*N (e.g. for the sample number 300 in the
first packet the timestamp is 35564266-65*16=35563226) or is there a
different way the get hold of timestamps for individual samples?

Thank you very much for your help.
Valentin


Josh Blum-2 wrote:
> 
> 
>> 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
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/rx_timed_samples.cc-doesn%27t-stop-streaming-of-samples-tp27771324p27780844.html
Sent from the GnuRadio mailing list archive at Nabble.com.