[Hackrf-dev] HACKRF support added to OpenCL TDD/FDD LTE Cell Searcher Tracker!

[Jiao Xianjun]

Thank you Jared.


OpenCL LTE Cell Searcher Tracker (
https://github.com/JiaoXianjun/LTE-Cell-Scanner) supports HACKRF board now!

With HACKRF, decoding LTE SIB informaton becomes possible in the future,
because HACKRF has 20MHz bandwidth which is much higher than rtl-sdr
dongle. (Now the program can only decode LTE MIB information because it was
designed for rtl-sdr dongle).

See a demo vide here:

(outside China) http://www.youtube.com/watch?v=3hnlrYtjI-4 ,
(inside China) http://v.youku.com/v_show/id_XNjk3Mjc1MTUy.html



On Wed, Apr 9, 2014 at 10:35 AM, Jiao Xianjun <putaoshu at gmail.com> wrote:


>

> 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/20140411/681a6253/attachment.htm