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

Jiao Xianjun putaoshu at gmail.com
Tue Apr 8 22:35:37 EDT 2014


Your explanation matches what I have seen when signal is weak: there is
only little ripple around zero.

Thanks a lot!




On Wed, Apr 9, 2014 at 10:18 AM, Jared Boone <jared at sharebrained.com> wrote:


>

> > 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://nine.pairlist.net/pipermail/hackrf-dev/attachments/20140409/bd0a1195/attachment.htm


More information about the HackRF-dev mailing list