discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] Tx duty cycle using tagging and USRP sink


From: Ethan Trewhitt
Subject: [Discuss-gnuradio] Tx duty cycle using tagging and USRP sink
Date: Tue, 29 Oct 2013 19:08:03 -0400

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



reply via email to

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