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

[est]

Holycrap!  you can order HackRF on TaoBao now? 太给力了。

I am still waiting for my Kickstarter early bird HackRF One






On Fri, Apr 11, 2014 at 12:40 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:


> Thank you scateu that http://hackrf.net/ offering me the demo board for

> debugging purpose!

>

> The board seemingly has a much higher sensitivity than rtl-sdr dongle

> after I tune gains of LNA and VGA.

>

> Yes I saw a little bit DC offset in IQ stream. But it shouldn't matter

> much to LTE, because LTE doesn't use DC sub-carrier.

>

> I haven't think about this issue for general purpose. But DC offset is

> popular in many system, and there must have been mature algorithm to combat

> with it.

>

>

>

> On Fri, Apr 11, 2014 at 12:20 PM, 王康 <scateu at gmail.com> wrote:

>

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

>>>>

>>>>

>>>>

>>>

>

> _______________________________________________

> HackRF-dev mailing list

> HackRF-dev at greatscottgadgets.com

> http://nine.pairlist.net/mailman/listinfo/hackrf-dev

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://nine.pairlist.net/pipermail/hackrf-dev/attachments/20140411/ad35de93/attachment.html