Forum: GNU Radio USRP FPGA 8-bit Data Ordering

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F5883c861da3a3026d8cc82879c51e6a?d=identicon&s=25 Paul Creekmore (Guest)
on 2009-01-21 19:56
(Received via mailing list)
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
F5883c861da3a3026d8cc82879c51e6a?d=identicon&s=25 Paul Creekmore (Guest)
on 2009-01-21 23:48
(Received via mailing list)
Paul Creekmore wrote:
>
> 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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-01-22 01:48
(Received via mailing list)
On Wed, Jan 21, 2009 at 05:47:19PM -0500, Paul Creekmore wrote:
>> where each grouping of two channels makes one 16-bit word.
>> after another, everything is in sequential order for whatever
>
> 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
F5883c861da3a3026d8cc82879c51e6a?d=identicon&s=25 Paul Creekmore (Guest)
on 2009-01-22 03:51
(Received via mailing list)
Eric Blossom wrote:
>>>
>>>     0, 1, 2, 3,   4, 5, 6, 7,    0, 1, 2, 3,   ...
>>> Thanks,
>> --Paul
>   |              Q0               |              I0               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-01-22 05:49
(Received via mailing list)
On Wed, Jan 21, 2009 at 09:50:41PM -0500, Paul Creekmore wrote:
>>
>> 4 bit I & Q:
>>
> 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?

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.

OK, good.  "Make it so" :-)

Eric
g
F5883c861da3a3026d8cc82879c51e6a?d=identicon&s=25 Paul Creekmore (Guest)
on 2009-01-28 20:32
(Received via mailing list)
Eric Blossom wrote:
>>> ought to go like this (everything packed into a 32-bit word):
>>>   |      Q1       |      I1       |      Q0       |       I0      |
>>> What are you thoughts about this?
> illustrative.
> g
>
And who should I notify (this list?) when this is ready for peer
review?  I'm doing my own validation right now, which is going well.

--Paul
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-01-28 22:40
(Received via mailing list)
On Wed, Jan 28, 2009 at 02:31:34PM -0500, Paul Creekmore wrote:
>>>>
>>>>
>>>> etc...
>>
>> Eric
>> g
>>
> And who should I notify (this list?) when this is ready for peer review?
> I'm doing my own validation right now, which is going well.

This list is a good place.  Just point us to your develeloper branch
and ask us to build and test.  A couple of examples of usage would
probably be helpful.  In my experience, if I want somebody to test
something, I need to make it _easy_ for them to test it.

Thanks for all your efforts!
Eric
This topic is locked and can not be replied to.