Re: [Discuss-gnuradio] precise transmit scheduling

[Yan Nie]

Thank you so much for your reply, Steven. 

I tried to use gr.message_source to push the new data into the msg_queue? As my understanding, the msg_queue push new data by using msg_queue.insert_tail(gr_message_sptr msg. The new data pushed into the msg_queue need to be the type of gr_message_sptr. How can I convert my binary Barker code of this message type?The data I'm trying to sent bit-by-bit is a binary sequence Barker code, like 5-bit Barker: 1,1,1,0,1. When I sent them together as a whole sequence, I used vector_source_s directly write them as vector. In order to sending them bit-by-bit, how can I push this sequence in to the msg_queue bit-by-bit?

Thank you so much for your help!

Sincerely,
Yan

On 11/04/10, "Steven Clark" <address@hidden> wrote:

On Thu, Nov 4, 2010 at 5:33 PM, Yan Nie <address@hidden <address@hidden>> wrote:

Dear all,

I am developing a transmitter on USRP1 with LFTX daughterboard. This transmitter sends a BPSK modulated Barker code sequence up-converting to a frequency ranging from 1MHz to 20MHz. I implemented the transmission of the whole sequence in one fixed frequency in the requried range on one USRP1 board and receiving on the other USRP1 board.

My question is :

How can I scheduling the transmitter by sending several bits of the sequence a time and the delays between each time transmitting are 1ms?

How can the RF frequency be linearly hopping from 1MHz to 20MHz by secheduling?

I've seen that m-blocks appears partially motivated by precise scheduling of transmission. Is the m-block implements is suitable for this scheduling?  If so, could anyone give me any suggestion on how can it implement the scheduling for my project? Tons of thanks in advance! I really need your help with this scheduling.

Sincerely,
Yan

I am also very interested in this. I have had some success by using gr.message_source, and having a python thread that periodically pushes new data into the system by putting it on the message queue. Transmitter auto_tr is enabled so that when the usrp runs out of data it turns off the transmit until the next message arrives. Scheduling at the python level seems very rough, with intervals varying ~+/- 1ms without tuning each time, and ~+/- 10ms when tuning before each burst. I was under the impression that calling set_rx_freq() to tune just the DUC rather than usrp.tune() should be faster/more responsive, but I haven't seen this to be true...

Any scheduling / hopping tips would be greatly appreciated!

-Steven

ynie3.vcf
Description: Card for "Yan Nie" <ynie3@uwo.ca>