Rx_timed_samples.cc doesn't stop streaming of samples

Hi All,

  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?

  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)
    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?

Thanks
Valentin


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

  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.

  1. 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

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 16N (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 B.-2 wrote:

fixes it for you.

nitems

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

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?

Its probably the MTU (1500 bytes) minus the ip/udp/ethernet headers
sizes minus the size of the vrt headers. Basically, the maximum number
of samples per frame.

subtract the required number of 16N (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?

That’s correct:
The Nth sample will be Nusrp2_clock_rate/samp_rate ticks offset from
the timestamp or in this case N
16 ticks offset. Each sample has a
temporal ambiguity equal to the width of 16 clock ticks.

-Josh

On 03/04/2010 11:56 AM, ValentinG wrote:

Got packet: 5 secs, 2244 ticks
Got packet: 5 secs, 8084 ticks

Yes, the timestamp that comes with the vrt header is the timestamp for
the first sample in that packet.

where 2244 is not divisible by 16, hence represents some sort of delay
before the first sample gets received after the clock reset. Or am I missing
something?

Unless, you use the start streaming with a timestamp, the timestamp that
you see above will be somewhat arbitrary as to where it starts.

In the above case, the pps event occurs within: “Got packet: 212 secs,
12264266 ticks” Which explains why the third packet “Got packet: 5 secs,
2244 ticks” has a significantly larger than zero ticks value.

-Josh

And the offset seems to be positive, i.e. the packet timestamp is the
time of
the first sample in the packet and not of the last one (referring to my
previous calculation: for the sample number 300 in the first packet the
timestamp is 35564266+300*16=35569066). I’ve come up to this conclusion
by
applying a PPS signal to the boards and calling
u2->set_time_at_next_pps(5,0) and the output was:

Got packet: 212 secs, 12258426 ticks
Got packet: 212 secs, 12264266 ticks
Got packet: 5 secs, 2244 ticks
Got packet: 5 secs, 8084 ticks

where 2244 is not divisible by 16, hence represents some sort of delay
before the first sample gets received after the clock reset. Or am I
missing
something?

Valentin

Josh B.-2 wrote:

sample individually I would need to take the timestamp of the packet and
-Josh


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs