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

[Jiao Xianjun]

PS, I found two advantages of hackrf over rtl-sdr E4K dongle:
1. higher sensitivity.
2. lower power consumption. (For Thinkpad T410, I have to use the laptop
dock to ensure enough power supply to the E4K dongle. If the dongle is
plugged to T410 directly, it would be very unstable. Sometimes driver
crashed, sometimes computer lost responses... While hackrf can be used
freely with my T410 every where without dock, even without AC adapter).

Good board!



On Fri, Apr 11, 2014 at 2:23 PM, est <electronixtar at gmail.com> wrote:


> 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/20140412/f59899f2/attachment.htm