[Hackrf-dev] What's the data format of hackrf_transfer->buffer when I call hackrf_start_rx?

[Jared Boone]

> On Apr 8, 2014, at 18:59, Jiao Xianjun <putaoshu at gmail.com> wrote:

> 

> One question is that what's the format of data received by transfer->buffer?

> 

> Simply I&Q interleaved? 8bit for each I or Q sample? Signed or unsinged?

> 

> Under above assumption, I checked raw data received by transfer->buffer and found that I channel are always around 252 or 253 and Q channel are always around 2 or 3 when there is no signal (or signal is pretty weak). Is this normal?


It depends. The CPLD bitstream was upgraded in the mossmann/hackrf repo in the last couple of months to transform the numbering scheme between the ADC/DAC IC (MAX5864) and the ARM processor. Before the change, the numbering scheme was simply the raw bits into and out of the MAX5864, which is unsigned 0-255 (0b00000000 - 0b11111111). The change has the CPLD doing a crude two's complement transformation by inverting all but the MSB. So:

0b00000000 unsigned -> 0b01111111 two's complement (127 signed)
0b00000001 unsigned -> 0b01111110 two's complement (126 signed)
0b01111111 unsigned -> 0b00000000 two's complement (0 signed)
0b10000000 unsigned -> 0b11111111 two's complement (-1 signed)
0b11111111 unsigned -> 0b10000000 two's complement (-128 signed)

This is not as ideal as doing a proper signed subtract by 128, but is small enough to fit in the CPLD and avoids saturation concerns, at the cost of a small DC offset, which is typically smaller than the DC offset present due to the radio's design.

It sounds to me like you're using the newer CPLD bitstream.

        - Jared