Data conversion process from 8 bit to 16 bit??

[youngmin]

Hi,

I have couple of questions for ADC's(or USRP Driver's) internal process of converting  data.

1. I could get data of 50MS/s IQ rate by setting sample width as 8-bit. After that I compared 8-bit binary data with 16-bit data acquired under same condition like single tone acquisition(1MS/s IQ rate).

I thought 8-bit data type only uses LSB of 16-bit data( like 00000000 xxxxxxxx) as USRP Driver only provides I16 Fetch mode, but it looked like 8-bit sample width data also used all 16 bits.

So, my first question is.... can you explain how I get 16 bit full scale data even though I set sample width as 8-bit?

2. My second qustion similar as first one. It's about data conversion of ADC.

As USRP's ADC has resolution of 14 bits, there should be a process matching 14 bit quantized data to 16 bit. Can you explain how this happens as well?

3. I could get 50MS/s IQ rate for acquisition but as USRP Driver does not support 8bit Integer Write function, I couldn't get 50MS/s playback.

Is there any plan for supporting this 8 bit fetch/write function?

Thanks for your help!

Regards,

YoungMin

[psisterhen]

YoungMin,

1.  There are three attributes that are relevant to sample width.  

The first is Sample Width, which actually configures the width of data transferred across the bus.  Sounds like you want to set this to 8.

The second is Host Data Type.  This specifies what type is used on the host machine (the type of data used in the Fetch and Write VIs).  Your choices here are Complex Double or I16.  In the case of I16, the real and imaginary components are interleaved.  You could transfer 8-bits over the bus and Fetch the data as Complex Doubles, or vice-versa.  The Host Data Type shouldn't affect your achievable bandwidth, which is limited by the data rate over the bus.

The third attribute is Expected Peak.  This tells the driver which bits to send over the bus.  Let's say you configure a Sample Width of 8 bits.  Some signals are large and their 16-bit values range between +/- 32,000.  In this case you want to send the most-significant 8-bits over the bus.  Other signals may be small and only range between +/- 127.  In that case, you want to send the least-significant 8-bits over the bus.

The Expected Peak tells the driver the expected range of the data in the FPGA.  If your Sample Width is 8-bits, and the Expected Peak is 1.0, the driver will send the most significant 8-bits of the 16-bit sample over the bus.  If the Expected Peak is 0.5, the driver will drop the most significant bit and send the 14-7 bits (because the data is never expected to be more than .5 of full-scale).  To send the least-significant 8 bits, the Expected Peak should be set to .00390625.

So, to answer your question, the samples are 16-bit in the FPGA.  You are sending the most-significant 8 bits over the bus.  The driver returns this as a 16-bit value, which is why you see full scale data.  The point is to transfer the minimum number of bits over the bus, but preserve the significant bits.

2.  You can consider the data from the ADC to be left-justified.  So, the 14-bits are in a 16-bit value, where the two least-significant bits are 0.  Incidentally, decimation in the FPGA can increase the resolution such that the processed values have information in the two least significant bits.

3. There is no 8-bit Write VI, but if you set the Sample Width to 8-bits, then only 8-bits will be sent over the bus, whether you use the CDB or I16 Write VIs.  

See the "niUSRP EX Tx Customize Write Type and Sample Width.vi" example for more help.