[Top][All Lists]

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

Re: [Discuss-gnuradio] Reading from USRP

From: Timur Alperovich
Subject: Re: [Discuss-gnuradio] Reading from USRP
Date: Sun, 12 Jul 2009 15:10:37 -0400

On Sun, Jul 12, 2009 at 2:55 PM, Timur Alperovich<address@hidden> wrote:
>> On Sunday 12 July 2009 08:09:24 Timur Alperovich wrote:
>>> Hey guys,
>>> I've been trying to read from the USRP by simply doing u->read(buf,
>>> 512, overrun). I used the usrp_inband_usb_packet class to extract the
>>> payload size and the payload from each USB packet received. As I
>>> understand, the USB packets contain pairs of I and Q for each (I
>>> didn't change the format from the default). I was expecting the
>>> payload size then to be a multiple of 4, since it is 2 shorts. I
>>> frequently see payload sizes such as 7, 13, etc. What is going on
>>> here? Are there examples of getting the data from a dbsrx using this
>>> method and processing it? I found the test_standard_rx example, but it
>>> doesn't do any processing and just reads.
>> If you want to use the inband code, of course you have to use the inband
>> firmware as well. Most probably, you use the standard firmware, and the
>> "payload size" you see is a normal sample.
> Thank you Stefan. That definitely explains it! What is the
> advantage/reason for using the inband firmware? I was working on
> adapting some of the OpenBTS code for what I'm trying to do and I
> didn't realize they're using the inband firmware and didn't realize
> the differences in the data returned by the different firmware.
> Searching gnuradio.org, I couldn't find anything on the wiki about it.

Ok, I found the information about in-band signaling, which render my
other questions moot: http://gnuradio.org/trac/wiki/InBandSignaling.
Thanks for the help again.

>> USB packets produced by the standard firmware always contain 512 bytes/128
>> complex samples (as long as you stick to standard sample resolution of 16 bit
>> per component).
>> The inband firmware will produce packets containing 504 bytes of payload (126
>> samples), and it will accept shorter packets.
>> Regards,
>> Stefan


reply via email to

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