List, We are implementing a packet-based system with gnuradio, and we experience that the packets are not sent in one flush from the USRP. In our transmitter we are maintaining a data path and a control path, so we exactly know where is the beginning of a packet and where is the end. We use this method to pad the outgoing complex waveform to the multiple of 128 samples, as it is required by the USRP (in a particular setup our packet is 468 samples long, so it is padded to 512 samples). Image  shows the abs of the complex waveform that our transmitter block produces, this is fed into the USRP sink (a copy of the ofdm benchmark's USRP sink). Image  shows abs from the received signal when the transmitter was operating. You can discover the preamble in the received signal and similar things to the rest of the packet, but this is not continuous. Interestingly there seems to be some parts from the previous packet before the preamble. We tried to set the fusb_block_size of the USRP sink to 8, so this buffer will hold a whole packet, but this did not help either. Any ideas would be greatly appreciated. Best, Peter.  http://nd.edu/~pvizi/transmitted.png  http://nd.edu/~pvizi/onair.png
on 2009-03-10 22:13
on 2009-03-10 23:05
On Tue, Mar 10, 2009 at 4:13 PM, Peter V. <firstname.lastname@example.org> wrote: > > > Any ideas would be greatly appreciated. > > Best, Peter. > >  http://nd.edu/~pvizi/transmitted.png >  http://nd.edu/~pvizi/onair.png Please label your axes! I'm not sure what I'm looking at here. Also, from what I gather, you are doing a comparison, but you are using two different ranges in the x-axis. I am not at all clear what the problem you are having is from your explanation. Tom
on 2009-03-11 17:52
Tom, I'm sorry if I was not clear enough. On Tue, 2009-03-10 at 17:03 -0400, Tom R. wrote: > Please label your axes! I'm not sure what I'm looking at here. Also, > from what I gather, you are doing a comparison, but you are using two > different ranges in the x-axis. I am not at all clear what the problem > you are having is from your explanation. In image  you see the absolute values of the baseband waveform that my transmitter produces (I did not plot the real and complex part separately). In this case it is 512 samples long after padding with zeros for the USRP. In  you can see a part of the received baseband waveform (again only plotting the abs, not real and imaginary part). As you pointed out the range of x axis is different, and that is exactly the problem: the samples in  with high snr are belonging to my packet, and it is not 512 samples long, rather it is spread over 1000 samples, which in my opinion means that the USRP does not send the whole packet at once but in small chunks. Best, Peter.  http://nd.edu/~pvizi/transmitted.png  http://nd.edu/~pvizi/onair.png
on 2009-09-25 02:55
I am experiencing the same problem using transmit_path to send packets. When I send a packet it is not sent as one continuous transmission. Observing it on a spectrum analyser, the packet is sent as (random) bursts with short quiet periods in between. I want the packet to be sent as one continuous transmission with no gaps. I have played around with the USB settings to no effect. What is causing these gaps to occur?
on 2009-09-25 03:22
Nevermind ; my python control thread was hogging execution.