Syncronising transmitting and receiving streams to and from a USRP

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

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

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