[Hackrf-dev] Odd issue on running hackrf_transfer multiple times in a row

[Shannon Holland]

Dominic,

Sadly, I think your comments were lost somewhere in the last email :(

When I first started working with the Hack RF I thought the output were unsigned bytes (had been reading older blog posting), now I realize that the output is signed two’s complement bytes. So, what appeared to be wildly different output to me initially is actually very similar.

The first set of readings would still appear to have a larger dynamic range by just looking at numbers (the real part bumping between 02->04->f9 verus 02->03->02) but I’m also wondering if part of the difference I’m seeing is a change in DC offset?

I’ve played with different rx gain settings (as well as turning the antenna amp on and off) and really see very little change in the recorded data. Looking at a FFT waterfall (using baudline) I do see an changes but am still not having any luck finding any sort of apparent signal from all the noise. Switching antennas did help a bit.

I’m trying to get a better BT LE test setup going (can I generate a controlled transmit pattern from the ubertooth?). The ubertooth does report a lot of activity while my test HackRF setup is not finding anything so I’m sure I’m doing something wrong. The ubertooth will report a steady stream of packets at 2440Mhz (where I’ve been tuning the HackRF to).

Dominic, I did find your excellent report on implementing a software Bluetooth stack in gnu radio. I’ve installed the gr-bluetooth modules but haven’t had a whole lot of luck getting them to run just yet (I was trying the included test samples but am getting a python error 'AttributeError: 'module' object has no attribute ‘multi_LAP’ - haven’t looked into that yet).

Any suggestions as to what I can do to improve things on the Rx side would be greatly appreciated!

Thank you!

Shannon


> On Aug 28, 2015, at 6:00 PM, Dominic Spill <dominicgs at gmail.com> wrote:
> 
> On 28 August 2015 at 09:47, Shannon Holland <holland at loser.net> wrote:
>> 
>> I get a seemingly “interesting" output from the hackrf:
>> 
>> $ hackrf_transfer -r test.bin -f 2440000000 -s 8000000 -n 32000000 -b
>> 5000000 -a 1 -l 16 -g 16; xxd -g 1 test.bin | head
> 
>> 0000000: 02 ff 04 fe f9 0c fc 00 04 ff 06 fd 03 fe ff 03  ...............