# Purpose of extra two bits sent to FX2 chip with data samples

**URL:** <https://www.ruby-forum.com/t/purpose-of-extra-two-bits-sent-to-fx2-chip-with-data-samples/159138>\
**Category:** GNU Radio\
**Created:** [February 1, 2009, 6:31am UTC](https://www.ruby-forum.com/t/purpose-of-extra-two-bits-sent-to-fx2-chip-with-data-samples/159138 "2009-02-01T06:31:48Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![paul](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@paul](https://www.ruby-forum.com/u/paul)\
**Post date:** [February 1, 2009, 6:31am UTC](https://www.ruby-forum.com/t/purpose-of-extra-two-bits-sent-to-fx2-chip-with-data-samples/159138/1 "2009-02-01T06:31:48Z")

</div>

The FPGA on USRP1 sends an extra two bits of data with each 16-bit word  
(to the FX2 chip). If I’m not mistaken, the first bit is set when  
accompanying a sample from rx channel 0, and the second bit is set when  
accompanying an inphase (as opposed to quadrature) sample (presumably  
from channels 0, 2, 4, or 6).

- What significance do these two bits have in the handling of the data  
after the FPGA?

I’m trying to figure out how best to set these bits in the case of  
packed samples at lower quantization levels.

Thanks,  
Paul

---

<div class="post-metadata">

**Author:** ![paul](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@paul](https://www.ruby-forum.com/u/paul)\
**Post date:** [February 1, 2009, 7:02am UTC](https://www.ruby-forum.com/t/purpose-of-extra-two-bits-sent-to-fx2-chip-with-data-samples/159138/2 "2009-02-01T07:02:46Z")

</div>

On Sun, Feb 01, 2009 at 12:30:58AM -0500, Paul C. wrote:

> packed samples at lower quantization levels.
> 
> Thanks,  
> Paul

Uhh, what two extra bits? The GPIF bus is 16-bits wide…

The FPGA does report two status bits (independent of the data bits)  
that indicate whether (1) it has room for a new packet from the FX2  
and (2) if it has a packet available for the FX2. I don’t think  
anything you’re doing should have anything to do with how those flags  
are generated.

Did this help?

Eric

---

<div class="post-metadata">

**Author:** ![paul](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@paul](https://www.ruby-forum.com/u/paul)\
**Post date:** [February 2, 2009, 6:53am UTC](https://www.ruby-forum.com/t/purpose-of-extra-two-bits-sent-to-fx2-chip-with-data-samples/159138/3 "2009-02-02T06:53:19Z")

</div>

Eric B. wrote:

> > 
> 
> that indicate whether (1) it has room for a new packet from the FX2  
> and (2) if it has a packet available for the FX2. I don’t think  
> anything you’re doing should have anything to do with how those flags  
> are generated.
> 
> Did this help?
> 
> Eric

Hmm… no, I don’t think we’re talking about the same thing. I’m,  
looking at usrp/fpga/sdr\_lib/rx\_buffer.v, lines 90 and 97. Here’s an  
excerpt:

88 fifo\_4k\_18 rxfifo  
89 ( // DSP Write Side  
90 .data ( {ch0\_in, phase[0], fifodata} ),  
91 .wrreq (~rx\_full & (phase != 0)),  
92 .wrclk ( rxclk ),  
93 .wrfull ( rx\_full ),  
94 .wrempty ( ),  
95 .wrusedw ( ),  
96 // USB Read Side  
97 .q ( {ch0\_out,iq\_out,usbdata} ),  
98 .rdreq ( RD & ~read\_count[8] ),  
99 .rdclk ( ~usbclk ),  
100 .rdfull ( ),  
101 .rdempty ( ),  
102 .rdusedw ( rxfifolevel ),  
103 // Async, shared  
104 .aclr ( reset ) );

This is the port mapping for the receive fifo. The fifo is 18 bits  
wide, and “ch0\_in” and “phase[0]” are concatenated with the 16-bit data  
word to form the input to the fifo.

–Paul

---

<div class="post-metadata">

**Author:** ![paul](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@paul](https://www.ruby-forum.com/u/paul)\
**Post date:** [June 20, 2011, 5:30pm UTC](https://www.ruby-forum.com/t/purpose-of-extra-two-bits-sent-to-fx2-chip-with-data-samples/159138/4 "2011-06-20T17:30:28Z")

</div>

we have a problem with the 2 bits mentioned in the post before , we are  
using fft core in our project and we think that this 2 bits are the  
headers of the data sent which will allow us to differentiate between  
the real receiving band and the fft output , can any one help us ???
