A couple of pointers: - This is a bit like radar, where you want to time rx and tx in sync very tightly. Check out the gr-radar toolbox as an example how to do this. - You can evaluate and write tags to control the transmission time of bursts. Check out the gr-uhd manual for tag names.
...I wish I had more advice right now; and I'm still thinking about when the USRP source produces tags. If you're running it as a full duplex block (i.e. rx is 'on' permanently), I'm not sure the tx/rx switching would incur tags, because the GR block wouldn't know about that. M On 19.05.2015 08:42, Will Thompson wrote: > Hi All > I'm using N210 USRP with XCVR2450 (Rev2) hardware. > > I'm writing an out of tree module for GRC in C++ for a consensus > synchronisation system. > > The block takes in a certain number of samples from the USRP, then > estimated when it needs to transmit its signal. > I set the transmit time for the outputted data using the tx_time tag. > I then need to start recapturing the data after the transmission has ended. > > I was wondering what is the best way to do this? > > My current plan is to use nitems_read to count how many samples have > been in-putted into the block. > So I would have the fist set of data (call this BlockA) that I process > to estimate the required Tx time, I would then have a certain period of > guard samples (lets call this BlockB) that would occupy the time between > the end of BlockA and the start of the transmission. (I have tried to > illustrate the frame structure below for two repetitions, with sample > number increasing along the page). > > ----------------------------------------------------------------------------------------------------------------------------------- > > | BlockA(1) | BlockB(1) | Transmit(1) | BlockA(2) | > BlockB(2) | Transmit(2) | ....... > -------------------------------------------------------------------------------------------------------------------------------------- > > I need to know when to expect the first sample of the next BlockA. > If the USRP sent a stream tag when it switched from a transmitter to a > receiver this would be easy, is this possible?? I thought the USRP are > meant to produce a tag on each stream disruption, but I have not been > able to see any!? > > If not, I need to use nitems_read. I can estimate the length of BlockB > by seeing how many samples would exist between the end of BlockA and the > requested transmit time. > But what would happen if I set the transmit time to not be an integer > multiple of the sample period (1/rx_rate) from the start (I use the > initial tag to set a time zero). i.e. Say the samples are arriving at > 1us, 2us, 3us... and I set a transmit time of 8.5us. > Will the length of BlockB be rounded down to the number of complete > samples between the end of BlockA and the start of transmission? > > I'm worried that if I get this wrong I will start to mix up samples from > BlockA and BlockB when the block is run for a long time. > > > Any help with this would be much appreciated. > (This question was originally posted in [email protected] but I > was advised to post it here as well) > > > Kind regards > Will > > > ------------------------------------------------------------------------ > > NOTE: The information in this email and any attachments may be > confidential and/or legally privileged. This message may be read, copied > and used only by the intended recipient. If you are not the intended > recipient, please destroy this message, delete any copies held on your > system and notify the sender immediately. > > Toshiba Research Europe Limited, registered in England and Wales > (2519556). Registered Office 208 Cambridge Science Park, Milton Road, > Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl > > > > ------------------------------------------------------------------------ > This email has been scanned for email related threats and delivered > safely by Mimecast. > For more information please visit http://www.mimecast.com > ------------------------------------------------------------------------ > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
