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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
