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

[王康]

nice work, jxj!

I will try it myself later. And how are you going to do with DC offset,
since you want to use the full 20MHz bandwidth.


On Friday, April 11, 2014, Jiao Xianjun <putaoshu at gmail.com> wrote:


> 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) HACKRF support added to OpenCL TDD/FDD LTE Cell Searcher

> Tracker <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<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','jared at sharebrained.com');>

>> > wrote:

>>

>>>

>>> > On Apr 8, 2014, at 18:59, Jiao Xianjun <putaoshu at gmail.com<javascript:_e(%7B%7D,'cvml','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/fef3291a/attachment.html