USRP w/ 4-bit I&Q samples

We have an application where the overall accuracy of the A/D converter
is not terribly important but where we need as high a sampling rate as
we can get. To this end, we found and intend to use the 8-bit option
that allows for 8-bit I and Q signals instead of the normal 16-bit.
However, is there a similar option that allows for 4-bit I and Q
samples? Or similarly, would it be relatively easy to implement a 4-
bits per sample scheme, possibly w/ slight modifications to the USRP
firmware? Any feedback and/or advice is greatly appreciated.

Regards,
Tyrel

Tyrel,

The current FPGA configuration does not support 4-bit samples, but it is
possible to modify the configuration (Verilog code) to convert the
samples to 4-bit.

My research group is currently working on adding 1, 2, and 4-bit
quantization options to the USRP, as well as accompanying data packing
to maximize the number of samples that we can squeeze across the USB
interface and thus also the receivable signal bandwidth. We’ve not yet
tested the modifications.

–Paul

Hi,

If the I,Q bit width output of the DDC is reduced from 16 bit to 12 bit,
then I & Q will occupy 24 bit (3 Bytes). Thus we will be able to
maximize the instantaneous bandwidth to 32MB/3 = 10.6MHz without
scarifying much because the original signal was digitized with 12 bit
ADC.

Regards,

Firas

Paul C. [email protected] wrote: Tyrel,

The current FPGA configuration does not support 4-bit samples, but it
is possible to modify the configuration (Verilog code) to convert the
samples to 4-bit.

My research group is currently working on adding 1, 2, and 4-bit
quantization options to the USRP, as well as accompanying data packing
to maximize the number of samples that we can squeeze across the USB
interface and thus also the receivable signal bandwidth. We’ve not yet
tested the modifications.

–Paul

Tyrel Newton wrote:

We have an application where the overall accuracy of the A/D
converter is not terribly important but where we need as high a sampling
rate as we can get. To this end, we found and intend to use the 8-bit
option that allows for 8-bit I and Q signals instead of the normal
16-bit. However, is there a similar option that allows for 4-bit I and Q
samples? Or similarly, would it be relatively easy to implement a 4-bits
per sample scheme, possibly w/ slight modifications to the USRP
firmware? Any feedback and/or advice is greatly appreciated.

Regards,
Tyrel

_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On Tue, Apr 8, 2008 at 1:01 PM, Firas A. [email protected]
wrote:

Hi,

If the I,Q bit width output of the DDC is reduced from 16 bit to 12 bit,
then I & Q will occupy 24 bit (3 Bytes). Thus we will be able to maximize
the instantaneous bandwidth to 32MB/3 = 10.6MHz without scarifying much
because the original signal was digitized with 12 bit ADC.

In theory down-sampling should be reducing the noise floor below the
initial 12 bit level though… so there should be some loss in dynamic
range.

Paul,

Would you mind sharing your implementation along with any accompanying
documentation? We are making some modifications to the FPGA firmware
ourselves (mods for a much more application specific usage) and while
I’m not sure how far we’ll get with needing the 4-bit samples, we’d
happily share any test/usage results if we get there.

Tyrel

We’ll be looking into the possibility of contributing the new FPGA
configuration to GNU Radio once our code has been tested and refined.

–Paul

On Wed, Apr 09, 2008 at 04:36:48PM -0400, Paul C. wrote:

We’ll be looking into the possibility of contributing the new FPGA
configuration to GNU Radio once our code has been tested and refined.

–Paul

Thanks!
Eric

Hi Paul and Tyrel,

I’m also in a similar situation to get the maximum bandwidth possible,
but just started… For me 2 bit quantization is sufficient

I’ve started modifying the FPGA firmware but I think it will take some
time before I implement and test it thoroughly…

Any approximate time frame that you are planning to complete this
activity? I’m also keen to contribute if I’m fast enough…

Nagaraj,
PhD Candidate,
University of New South Wales

Well, I’m hoping to have 1, 2, 4, 8, and 16-bit quantization options
tested and working by the end of the month, if not within the next two
weeks. We’re debugging an implementation right now.

But for full integration into GNU Radio, there are several other
considerations that my group has not been addressing. We’re only
writing data to disk, using our own C++ program that uses only the
lower-level GNU Radio libraries to access and control the USRP. I don’t
have a very good sense as to what it would take to “propagate” new
quantization options throughout the rest of GNU Radio to make them
available to the higher-level Python scripts. The data needs to be
unpacked somewhere along the way, too.

Additionally, the existing quantization algorithm that converts 16-bit
samples to 8-bit samples looks like it may not be the best for lower
quantization levels.

So while I expect to have the USRP soon delivering quantized, packed
data, handling it on the host side in GNU Radio is another task.

–Paul

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs