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

Dominic Spill dominicgs at gmail.com
Tue Sep 1 11:32:10 EDT 2015


On 29 August 2015 at 13:46, Shannon Holland <holland at loser.net> wrote:
>
> 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?

Good point!  Although the greater range of values in the first capture
is still something that I would like to look at.  Also, the very small
range of values that you see overall.

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

What are you using for your antenna?

> can I generate a controlled transmit pattern from the ubertooth?

Yes.  There is a transmit test in the firmware, it can be enabled from
ubertooth-util.  You can also produce test patterns from CSR Bluetooth
dongles using the bccmd tool, which is how I was able to write the
first version of gr-bluetooth.

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

That code is quite old, but I don't think it should be too much effort
to get it working with libbtbb (the Bluetooth baseband library).  It's
definitely on my list of projects to revive but it's not going to
happen very soon.  Any help would be gladly received; pull requests
are especially welcome.

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

Could you try some simple reception tasks with the HackRF, e.g. FM [1]
or ADS-B [2] ?  I think that will give us a better idea of whether the
radio is working correctly.  We can then address the out of date
gr-bluetooth code.

Dominic

[1] http://greatscottgadgets.com/sdr/1/ (there's an FM Rx GRC
flowgraph in the resources section of the page).
[2] https://github.com/itemir/dump1090_sdrplus


More information about the HackRF-dev mailing list