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

Shannon Holland holland at loser.net
Fri Aug 28 12:47:00 EDT 2015


First off, apologies for my newbieness here - first time using hackrf and first real attempt at anything SDR like.

I’m trying to capture a segment of the Bluetooth LE spectrum and seem to be hitting issues with hackrf_transfer. I’m running on Mac OS X (with everything installed via homebrew) so that might be part of my problem. Although I also see exactly the same behavior when running under a linux virtual machine.

I’m running the latest firmware/cpld along with the latest host software:

$ hackrf_info 
Found HackRF board 0:
USB descriptor string: 0000000000000000406464c82390594b
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Part ID Number: 0xa000cb3c 0x00624f4f
Serial Number: 0x00000000 0x00000000 0x406464c8 0x2390594b

If I power cycle the hackrf (reset doesn’t seem to have the same effect) 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
call hackrf_sample_rate_set(8000000 Hz/8.000 MHz)
call hackrf_baseband_filter_bandwidth_set(5000000 Hz/5.000 MHz)
call hackrf_set_freq(2440000000 Hz/2440.000 MHz)
call hackrf_set_amp_enable(1)
samples_to_xfer 32000000/32Mio
Stop with Ctrl-C
16.0 MiB / 1.005 sec = 15.9 MiB/second
16.0 MiB / 1.004 sec = 15.9 MiB/second
16.0 MiB / 1.002 sec = 16.0 MiB/second
16.3 MiB / 1.005 sec = 16.2 MiB/second

Exiting... hackrf_is_streaming() result: HACKRF_ERROR_STREAMING_EXIT_CALLED (-1004)
Total time: 4.01563 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit
0000000: 02 ff 04 fe f9 0c fc 00 04 ff 06 fd 03 fe ff 03  ................
0000010: 04 02 fd fb 07 02 0a 11 06 02 04 f7 07 fd 04 07  ................
0000020: 00 00 f8 fe 00 06 0d 04 04 f6 0b 07 0f 11 ff 00  ................
0000030: fe 07 0f 09 0c 09 fc fe 0a f9 1a 01 09 00 f7 04  ................
0000040: f9 11 fa 13 05 09 fa fd fa 01 0a fb fe 07 06 0c  ................
0000050: 0a f8 01 03 ff 0b fc 04 ff 05 06 0b ff 06 f9 0d  ................
0000060: 0e 11 08 0b fc 0c fa 02 02 0d 09 00 02 02 02 04  ................
0000070: 03 08 09 0c fb 07 00 fa 06 05 06 0f 04 00 07 f9  ................
0000080: 06 00 05 0b 07 fa 08 fd 03 00 04 07 08 0c 06 02  ................
0000090: 0d 04 04 07 09 0c 09 00 05 fd 04 ff 02 05 f9 00  ................

However, if I immediately re-run the same command, I get very uninteresting (very low signal) data:

$ 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
call hackrf_sample_rate_set(8000000 Hz/8.000 MHz)
call hackrf_baseband_filter_bandwidth_set(5000000 Hz/5.000 MHz)
call hackrf_set_freq(2440000000 Hz/2440.000 MHz)
call hackrf_set_amp_enable(1)
samples_to_xfer 32000000/32Mio
Stop with Ctrl-C
16.0 MiB / 1.003 sec = 15.9 MiB/second
16.0 MiB / 1.003 sec = 15.9 MiB/second
16.0 MiB / 1.005 sec = 15.9 MiB/second
16.3 MiB / 1.003 sec = 16.2 MiB/second

Exiting... hackrf_is_streaming() result: HACKRF_ERROR_STREAMING_EXIT_CALLED (-1004)
Total time: 4.01379 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit
0000000: 02 02 03 02 02 03 02 03 02 02 02 03 02 03 02 03  ................
0000010: 02 03 02 03 02 02 02 03 02 03 02 03 02 03 02 02  ................
0000020: 02 03 02 03 02 03 02 03 02 02 02 03 02 03 02 03  ................
0000030: 02 03 02 03 02 03 02 02 02 02 02 02 02 03 02 02  ................
0000040: 02 03 02 03 02 03 02 03 02 02 03 03 02 02 02 03  ................
0000050: 02 03 02 03 02 03 02 03 02 02 02 02 02 03 02 03  ................
0000060: 02 03 02 03 02 02 02 02 02 03 02 02 02 03 02 03  ................
0000070: 02 03 02 02 02 03 02 02 02 02 02 03 02 02 02 03  ................
0000080: 02 03 03 03 02 02 02 03 02 03 02 03 02 02 02 03  ................
0000090: 02 03 02 03 02 03 02 03 02 02 02 03 03 02 03 03  ................

The data will remain pretty much constant until I power cycle the hackrf again, at which point the process repeats.

Might anyone have any suggestions as to what I’m doing wrong here? 

Thank you!

Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20150828/dc3c57bf/attachment.html>


More information about the HackRF-dev mailing list