[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Syncronising transmitting and receiving streams t

From: Martin Braun
Subject: Re: [Discuss-gnuradio] Syncronising transmitting and receiving streams to and from a USRP
Date: Wed, 20 May 2015 09:53:40 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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.


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 address@hidden 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

reply via email to

[Prev in Thread] Current Thread [Next in Thread]