Hi, thanks for the reply and elaboration. I also found myself thinking about these same issues, but the paper I referenced seemed (to my understanding) to imply that the device was adding timestamps to each sample. It's clear to me now how this was achieved.
Regards, Alex -----Original Message----- From: [email protected] <[email protected]> Sent: Monday, June 21, 2021 8:48 PM To: [email protected] Subject: [USRP-users] Re: Adding Timestamps to B210 RX Samples On 06/21/2021 07:33 PM, Alex Bouvy via USRP-users wrote: > Hi Marcus, > > Got it, makes sense! Thanks for the info. > > Regards, > Alex We should perhaps for a moment consider what it would mean for the hardware to adorn every single sample with a time-stamp. Over-the-wire samples occupy 4 bytes (16-bit I 16-bit Q). Timestamps are (AFAIR) 64 bits or 8 bytes. If every single sample were adorned with a time-stamp *on the wire*, that would *triple* the occupied bandwidth of samples flowing over the wire--meaning less bandwidth would be available for actual samples. Similarly, if UHD adorned every sample as it arrived, there'd be considerable ballooning of memory occupancy, and memory-bandwidth consumption. Putting in all this overhead to avoid a simple calculation on the part of the application writer would be bad engineering, IMHO. > -----Original Message----- > From: Marcus Müller <[email protected]> > Sent: Monday, June 21, 2021 5:31 PM > To: [email protected] > Subject: [USRP-users] Re: Adding Timestamps to B210 RX Samples > > Hi Alex, > > that's the right (and only) approach: Metadata contains the time stamp for > the first sample in a packet; the rest is counting! > > Best regards, > > Marcus > > DISCLAIMER: Any attached Code is provided As Is. It has not been tested or > validated as a product, for use in a deployed application or system, or for > use in hazardous environments. You assume all risks for use of the Code. Use > of the Code is subject to terms of the licenses to the UHD or RFNoC code with > which the Code is used. Standard licenses to UHD and RFNoC can be found at > https://www.ettus.com/sdr-software/licenses/. > > NI will only perform services based on its understanding and condition that > the goods or services (i) are not for the use in the production or > development of any item produced, purchased, or ordered by any entity with a > footnote 1 designation in the license requirement column of Supplement No. 4 > to Part 744, U.S. Export Administration Regulations and (ii) such a company > is not a party to the transaction. If our understanding is incorrect, please > notify us immediately because a specific authorization may be required from > the U.S. Commerce Department before the transaction may proceed further. > > On 22.06.21 00:24, Alex Bouvy via USRP-users wrote: >> Hello, >> >> >> >> In the paper below, the authors say that they have set up their USRP >> device to include timestamps for each recorded sample, but do not provide >> detail on how this was achieved: >> >> >> >> https://ieeexplore.ieee.org/document/6533293 >> <https://ieeexplore.ieee.org/document/6533293> >> >> >> >> I have been looking into what is required to achieve something >> similar. Particularly, I have been working with the source code of >> the rx_timed_samples.cpp example provided in the UHD files, along with this >> page in the Ettus manual: >> >> >> >> https://files.ettus.com/manual/page_sync.html >> <https://files.ettus.com/manual/page_sync.html> >> >> >> >> Looking through the rx_timed_samples code, it appears that the >> metadata associated with the recv(..) function contains a time_spec >> field which is the timestamp for the first sample in the IO stream, >> but it's not immediately clear to me how that might be used to >> timestamp all of the samples, which makes me think this may be the wrong >> approach. Is there a simpler method to do this that is known? >> >> >> >> Tangentially, I've also looked into adding the timestamps through >> GNURadio, but there does not appear to be a way to do this as far as I can >> tell. >> >> >> >> Any help is much appreciated. >> >> >> >> Thank you, >> >> Alex >> >> >> _______________________________________________ >> USRP-users mailing list -- [email protected] To unsubscribe >> send an email to [email protected] > _______________________________________________ > USRP-users mailing list -- [email protected] To unsubscribe > send an email to [email protected] > _______________________________________________ > USRP-users mailing list -- [email protected] To unsubscribe > send an email to [email protected] _______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
