Tx duty cycle using tagging and USRP sink

I’d like to build a simple duty-cycle tagger for my outgoing Tx
stream. I currently have a steady stream of outgoing packets that are
continuously transmitted, but I would like to modify this so that N
samples are sent, followed by a fixed-length gap, then the next N
samples are sent, and so on.

I figure I can do this with a tagger, but where I get concerned is in
the setup process and the process of remaining synchronized with the
USRP’s internal clock. Pseudocode:

Set the tags at the start of the burst:
tx_time(absolute time reference in seconds and fractional seconds)
tx_sob(true)

At the end of the burst:
tx_eob(true)

The tx_time for the next burst will be based on the sample rate, the
length of the burst, and the burst period.

I figure I can implement my tagger as a sync block. The problem is
determining the USRP’s clock value so that I can set tx_time
correctly. Options:

  1. I could pass in a reference to the USRP sink block via make(),
    which would let me query the radio’s clock directly from my tagger
    block. Problem: I wouldn’t know how far into the USRP buffer it’s
    gotten, so it would be hard to know where, in time, my tagger is
    working relative to the USRP’s time.
  2. I could pass in a “start time” reference to make() as a time_spec
    object. It would be up to the block calling the constructor to fetch
    the time from the USRP and add an appropriate (???) delay to allow for
    startup connections to be built. Problem: non-determinism in the time
    between constructor/make() call and actual work start.
  3. I pass in a reference to the USRP sink block via make(), then use
    the start() method to fetch the current USRP time. Again, I would need
    to add an appropriate delay to guess how much time will be needed
    before the work() function has set up the initial burst’s tags.

What is the best approach here? Basically I don’t care about the
absolute time that a burst is transmitted, but rather the relative
time between the bursts starting. It would be great to be able to tell
the USRP to leave a silent gap, with a width defined as an integer
number of samples (or even time_spec). That would avoid me needing to
keep track of all these absolute times that I don’t really care about.
Is there an option like this? If not, what approach should I take?

How different would it be if I simply inserted zeroes into the
outgoing IQ stream, rather than tagging my bursts?

Thanks in advance!

Ethan

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