NI-Scope fetch binary 16

[ESD]

I am using a PXI-5105 for pulse height analysis and I have been confused by empty bins in my pulse height histograms.  The fetch binary I16 vi returns 16-bit integer arrays with elements that only have values in multiples of 16.

This is my theory on what is happening:

The 5105 is a 12-bit digitizer and the NI-Scope Fetch Binary I16 returns a 16-bit waveform, so at some point there is a conversion from 12-bit integer to 16-bit integer.  Instead of just adding 4 empty bits to the 12-bit number, they go to the trouble of distributing the range of 12-bit values (-2048 to 2047) over the range of 16-bit values (-32768 to 32767). So a (12-bit) -2048 converts to (16-bit) -32768, a (12-bit) 2047 converts to (16-bit) 32767, and so on.  The problem is that you then end up with gaps of 16 between all of your (12-bit converted to 16-bit)numbers.

[dansch]

Hi ESD,

The four extra bits are padded on, but they are added as least significant bits. Thus, the numbers will appear to be 16 values apart. So you are correct that this method will effectively cause the data to cover the entire 16-bit range.

Similarly, if you were to specify the Binary Sample Width property to be something lower than the resolution of your device, it would drop the least significant bits to still allow the data to fit the entire vertical range (since you can't change the way the ADC samples the data) at the expense of resolution. This information can be seen in the following help description for the Binary Sample Width property: 

"Indicates the bit width of the binary data in the acquired waveform, which can help you determine which Binary Fetch to use. To configure the device to store samples with a lower resolution than the native, set this property to the desired binary width. This configuration can be useful for streaming at faster speeds, but at the cost of resolution. The least significant bits are lost with this configuration."

Hope this helps,

[ESD]

Thanks Daniel.  I figured out that the logical bit shift vi wont work for converting the negative numbers back, but the scale by power of 2 vi works with n=-4 for both the positive and negative 16-bit numbers.  Is there a better(ie. faster computation) way to do this?

[dansch · Accepted solution]

Hi ESD,

Scaling by a power of 2 works best when converting the value but still representing it at a higher resolution. This is because you are effectively dividing every number by 16, which will maintain the sign. A logical shift will also work as it should, but the problem is that you are taking a 16-bit number, shifting it to be a 12-bit number, but representing it still as an I16. This will not work because 0000100000000000 ≠ 100000000000 when dealing with signed numbers (one number is positive while the other is negative). To truly represent the 12-bit value appropriately, you would need to use a 12-bit fixed point data type. This can be seen in the image below.

In fact, this is why padding zeros on the MSB is a problem with signed integers. If a straight, one-to-one conversion were used, we would have to perform a sign extension, meaning that the MSB of our 12-bit number would have to be padded on as the 4 MSB of the 16-bit number. I suppose it is just easier to pad zeros on the LSB side for every case when converting to a higher resolution value.