discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] USRP FPGA 8-bit Data Ordering


From: Paul Creekmore
Subject: Re: [Discuss-gnuradio] USRP FPGA 8-bit Data Ordering
Date: Wed, 21 Jan 2009 21:50:41 -0500
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)

Eric Blossom wrote:
On Wed, Jan 21, 2009 at 05:47:19PM -0500, Paul Creekmore wrote:
  
Paul Creekmore wrote:
    
Context: I'm adding new quantization (sample width) options to the  
USRP FPGA configuration.  (Long time in coming; yes, I know.)

Question: I'm seeing that in 8-bit mode, the USRP outputs samples from  
its internal channels in the following sequence (an 8-bit, 8-channel  
example):

    1, 0,     3, 2,     5, 4,     7, 6,    1,0,   3,2,     ...

where each grouping of two channels makes one 16-bit word.

----> What is the rationale behind this convention? 

As I'm deciding how to output 4, 2, and 1-bit samples, it makes much  
more sense to me to use a sequential order, like this (4-bit,  
8-channel example):

    0, 1, 2, 3,   4, 5, 6, 7,    0, 1, 2, 3,   ...

This way if the user writes the data directly to a file, one word  
after another, everything is in sequential order for whatever  
post-processing later.

----> Will the GNU Radio world fall apart if use a sequential channel  
ordering for my output and submit this development for inclusion in a  
future release?


Thanks,
Paul
      
Amendment:

I see now why the sequence is as it is.  As a real-time program reads  
one word at a time and picks off samples from LSB to MSB, the ordering  
makes sense.  I may just include a setting to reverse the sample order  
for more efficient data recording.  If the powers that be have any other  
thoughts, please let me know.

--Paul
    

Thanks for answering your own question :-)

The USRP1 is little endian.  My not-fully-considered thought is that it
ought to go like this (everything packed into a 32-bit word):

16 bit I & Q (same as today):

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Q0               |              I0               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8 bit I & Q (different from today: see usrp_source_c.cc):

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Q1       |      I1       |      Q0       |       I0      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4 bit I & Q:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Q3   |  I3   |   Q2  |  I2   |   Q1  |   I1  |  Q0   |  I0   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

etc...

What are you thoughts about this?

Eric
  
First off, current USRP words are 16-bit, are they not?  The rx_buffer module in the FPGA code stores data in a 16-bit FIFO.  Are you suggesting changing this, or is the 32-bit width above merely illustrative?  Either way, I agree with your sample ordering above.  It's consistent for all sample widths, and it should make host-side code straight-forward.

--Paul

reply via email to

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