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
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
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
On 03/04/2010 11:56 AM, ValentinG wrote:
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
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
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
