Git Product home page Git Product logo

kalibrate-hackrf's Introduction

kalibrate-hackrf

Kalibrate, or kal, can scan for GSM base stations in a given frequency band and can use those GSM base stations to calculate the local oscillator frequency offset.

Kalibrate-hackrf is a fork of Joshua Lackey's kalibrate originally for USRP, ported to support the HackRF.

The documentation below is adapted from the original website at http://thre.at/kalibrate (defunct since 2013).

On Clocks

SDRs have a built-in oscillator which is only guaranteed accurate to within some range (for example, the USRP1 to 20 parts per million (ppm). (Although in practice the USRP oscillator is normally closer to 3ppm.) This is sufficient for a number of purposes, but not for others. Some SDRs (including the HackRF and USRP) also support external oscillators. For example, the Clock Tamer, the KSP 52MHz and the FA-SY 1 are all accurate clocks.

Normally, these external clocks must be calibrated to ensure they are set as accurately as possible. An oscilloscope is probably the best way to determine the accuracy of these clocks. However a good oscilloscope is expensive and not everyone has access to one. There are other ways to calibrate these devices -- the FA-SY 1 documentation discusses using the WWVB time signals. Similarly, GSM base stations are required to be accurate to within 0.05ppm and so they can also provide an accurate reference clock.

If you own a USRP daughterboard that covers the GSM frequencies in your area, using a GSM base station is a particularly convenient.

Description

A base station transmits a frequency correction burst on the Frequency Correction CHannel (FCCH) in regular positions. The FCCH repeats every 51 TDMA frames and the frequency correction burst is located in timeslot 0 of frames 0, 10, 20, 30, and 40.

A frequency correction burst consists of a certain bit pattern which, after modulation, is a sine wave with frequency one quarter that of the GSM bit rate. I.e., (1625000 / 6) / 4 = 67708.3 Hz. By searching a channel for this pure tone, a mobile station can determine its clock offset by determining how far away from 67708.3Hz the received frequency is.

There are many ways which a pure tone can be identified. For example, one can capture a burst of data and then examine it with a Fourier transformation to determine if most of the power in the signal is at a certain frequency. Alternatively, one can define a band-pass filter at 67708.3 Hz and then compare the power of the signal before and after it passes through the filter. However, both of these methods have drawbacks. The FFT method requires significant resources and cannot easily detect the frequency correction burst edge. The filter method either isn't accurate or cannot detect larger offsets. Multiple filters can be used, but that requires significant resources.

kal uses a hybrid of the FFT and filter methods. The filter kal uses is an adaptive filter as described in the paper:

G. Narendra Varma, Usha Sahu, G. Prabhu Charan, Robust Frequency Burst Detection Algorithm for GSM/GPRS.

An Adaptive Line Equalizer (ALE) attempts to predict the input signal byadapting its filter coefficients. The prediction is compared with the actual signal and the coefficients are adapted so that the error is minimized. If the input contains a strong narrow-band signal embedded in wide-band noise, the filter output will be a pure sine at the same frequency and almost free of the wide-band noise.

kal applies the ALE to the buffer and calculates the error between the ALE prediction and the input signal at each point in the signal. kal then calculates the average of all the errors. When the error drops below the average for the length of a frequency correction burst, this indicates a detected burst.

Once we have the location of the frequency correction burst, we must determine what frequency it is at so we can calculate the offset from 67708.3 Hz. We take the input signal corresponding to the low error levels and run that through a FFT. The largest peak in the FFT output corresponds to the detected frequency of the frequency correction burst. This peak is then used to determine the frequency offset.

Any noise in the system affects the measurements and so kal averages the results a number of times before displaying the offset. The range of values as well as the standard deviation is displayed so that an estimate of the measurement accuracy can be made.

How

kal requires fftw3 and version 3.2 or higher of libusrp. kal also requires a USRP and daughterboards appropriate for the desired GSM frequency band. An external clock is not required; kal can also calculate the offset of the built-in USRP clock.

kal uses the GNU Autoconf system and should be easily built on most *nix platforms.

	jl@thinkfoo:~/src$ cd kal-v0.4.1
	jl@thinkfoo:~/src/kal-v0.4.1$ ./bootstrap && CXXFLAGS='-W -Wall -O3' ./configure && make
	[...]
	jl@thinkfoo:~/src/kal-v0.4.1$ src/kal -h
	kalibrate v0.4.1, Copyright (c) 2010, Joshua Lackey

	Usage:
		GSM Base Station Scan:
			kal <-s band indicator> [options]

		Clock Offset Calculation:
			kal <-f frequency | -c channel> [options]

	Where options are:
		-s	band to scan (GSM850, GSM900, EGSM, DCS, PCS)
		-f	frequency of nearby GSM base station
		-c	channel of nearby GSM base station
		-b	band indicator (GSM850, GSM900, EGSM, DCS, PCS)
		-R	side A (0) or B (1), defaults to B
		-A	antenna TX/RX (0) or RX2 (1), defaults to RX2
		-g	gain as % of range, defaults to 45%
		-F	FPGA master clock frequency, defaults to 52MHz
		-v	verbose
		-D	enable debug messages
		-h	help
	jl@thinkfoo:~/src/kal-v0.4.1$ src/kal -s 850
	kal: Scanning for GSM-850 base stations.
	GSM-850:
		chan: 128 (869.2MHz -  13Hz)	power: 9400.80
		chan: 131 (869.8MHz +   7Hz)	power: 4081.75
		chan: 139 (871.4MHz +  10Hz)	power: 2936.20
		chan: 145 (872.6MHz -   7Hz)	power: 33605.48
	jl@thinkfoo:~/src/kal-v0.4.1$ src/kal -c 145
	kal: Calculating clock frequency offset.
	Using GSM-850 channel 145 (872.6MHz)
	average		[min, max]	(range, stddev)
	-   1Hz		[-8, 7]	(14, 3.948722)
	overruns: 0
	not found: 0

ChangeLog

2016-6-6 Update:

Fix library not found for -lrt on OS X.

Author: @rxseger

2015-3-3 Update:

Add ability to specify channel when scanning to check power output for a single channel.

Author: xorrbit

2014-8-23 Update:

Thanks to [email protected] who did a bunch of tinkering with this port of kalibrate.

https://github.com/ckuethe/kalibrate-hackrf/

This now runs as fast as kalibrate-rtl

v0.4.1. This version contains the following fixes:

  • Support for Mac OS X (i.e., support for POSIX shared memory rather than just SysV shared memory)
  • Specifying the FPGA master clock frequency actually works now.
  • Some constants subtly depend on the sample rate. I've removed the decimation option and now calculate that automatically.

The latest version should be the most accurate. I'd urge anyone running an old version to update.

Versions of kal previous to 0.4 used an algorithm that was extremely sensitive to noise. Version 0.4 of kal is more processor intensive, but also much more accurate.

Credits

I'd like to thank Alexander Chemeris for his valuable input, ideas, and his testing of a large number of alpha versions. I'd also like to thank Mark J. Blair for his help getting kal to work with Mac OS X.

I'd also like to thank Mark J. Blair for his help getting kal to work with Mac OS X. (And also for helping me realize that I never actually used the -F parameter...)

Copyright (c) 2010, Joshua Lackey ([email protected])

Copyright (c) 2010, Joshua Lackey ([email protected])

Copyright (c) 2012, Steve Markgraf ([email protected])

modified for use with hackrf devices,

Copyright (c) 2014, Wang Kang ([email protected])

http://hackrf.net : A Chinese HackRF Community

Windows pre-compiled version

Thanks to ikaya1965:

kalibrate-hackrf's People

Contributors

ckuethe avatar mutability avatar pinkavaj avatar rxseger avatar scateu avatar steve-m avatar wizardishungry avatar xorrbit avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

kalibrate-hackrf's Issues

Scan freeze at first frequency

When executing any type of scan it will begin and remain at the first frequency it tries.
For example if I execute:

$ ./kal -s GSM900 -v

It will go through the init steps and remain at

hackrf_init()
hackrf_open()
hackrf_set_sampe_rate(8000000)
hackrf: set gain 0/0/0
kal: Scanning for GSM-900 base stations.
hackrf_set_freq 935200000

I compiled it on a fresh Debian 9 install running inside VBox on Win10.

How can I use kalibrate-hackrf with RTL-SDR device?

Hi, I have downloaded, as well as installed on vMware, an ubuntu distribution, in which there are all the tools to operate, including gr-gsm and others, such as kalibrate-hackrf. The problem is that I am unable to use it with SDR-RTL. I thought that it was compatible with sdr-rtl too.

I have entered the command "kal -s GSM900", and it appears the following message: "no hackrf device found". I have ran "kal -h", and it appears this:

Where options are:
        -s      band to scan (GSM850, GSM-R, GSM900, EGSM, DCS, PCS)
        -f      frequency of nearby GSM base station
        -c      channel of nearby GSM base station
        -b      band indicator (GSM850, GSM-R, GSM900, EGSM, DCS, PCS)
        -a      rf amplifier enable
        -g      vga (bb) gain in dB, 0-40dB, 8dB step
        -l      lna (if) gain in dB, 0-62dB, 2dB step
        -d      rtl-sdr device index
        -e      initial frequency error in ppm
        -E      manual frequency offset in hz
        -v      verbose
        -D      enable debug messages
        -h      help

It seems that it offers the possibility of using with rtl-sdr, but I don't know what is the right command's syntax. It says to digit "d", but I am unable to figure out how to use it with my rtl-sdr. Any suggestion?

Thank you.

No package 'libhackrf' found

Am able to run hackrf fine. Have tried installing kalibrate but throws up :


No package 'libhackrf' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBHACKRF_CFLAGS
and LIBHACKRF_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Tried to reinstall libhackrf-dev and libhackrf0 however I get the following error:


libhackrf0 is already the newest version (2015.07.2-myriadrf1~wily).
hackrf is already the newest version (2015.07.2-myriadrf1~wily).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
 libhackrf-dev : Depends: libhackrf0 (= 2015.07.2-6) but 2015.07.2-myriadrf1~wily is to be installed
E: Unable to correct problems, you have held broken packages.




HackRF+Portapack+Havok firmware - kal -s not scanning

csi@csi-analyst:/opt$ kalibrate-hackrf/src/kal -s GSM900 -E 10000
kal: Scanning for GSM-900 base stations.
sticks here

On the Portapack -> put into HackRF mode so the SRD passes through. On the LCD screen, the frequencies are not changing. Staying at 935200000

When I use other scanners, the frequencies on the LCD do change.

c0_detect.cc:183:17: warning: absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value [-Wabsolute-value]

Getting this warning compiling with clang 7.3.0 on OS X 10.11.5: (should be a straightforward fix, but needs testing)

kalibrate-hackrf $ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in src
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-c0_detect.o -MD -MP -MF .deps/kal-c0_detect.Tpo -c -o kal-c0_detect.o `test -f 'c0_detect.cc' || echo './'`c0_detect.cc
c0_detect.cc:183:17: warning: absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value [-Wabsolute-value]
      if (r && (fabsf (offset - GSM_RATE / 4) < ERROR_DETECT_OFFSET_MAX))
                ^
c0_detect.cc:183:17: note: use function 'std::abs' instead
      if (r && (fabsf (offset - GSM_RATE / 4) < ERROR_DETECT_OFFSET_MAX))
                ^~~~~
                std::abs
1 warning generated.
mv -f .deps/kal-c0_detect.Tpo .deps/kal-c0_detect.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-kal.o -MD -MP -MF .deps/kal-kal.Tpo -c -o kal-kal.o `test -f 'kal.cc' || echo './'`kal.cc
mv -f .deps/kal-kal.Tpo .deps/kal-kal.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-offset.o -MD -MP -MF .deps/kal-offset.Tpo -c -o kal-offset.o `test -f 'offset.cc' || echo './'`offset.cc
mv -f .deps/kal-offset.Tpo .deps/kal-offset.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-usrp_source.o -MD -MP -MF .deps/kal-usrp_source.Tpo -c -o kal-usrp_source.o `test -f 'usrp_source.cc' || echo './'`usrp_source.cc
mv -f .deps/kal-usrp_source.Tpo .deps/kal-usrp_source.Po
g++ -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2   -o kal kal-arfcn_freq.o kal-c0_detect.o kal-circular_buffer.o kal-fcch_detector.o kal-kal.o kal-offset.o kal-usrp_source.o kal-util.o -L/usr/local/Cellar/fftw/3.3.4_1/lib -lfftw3 -L/usr/local/Cellar/hackrf/2015.07.2/lib -lhackrf 
kalibrate-hackrf $ 

Wrong ARFCN and frequencies -- is `-E` needed?

Hi

As far as I experienced, the results provided by kalibrate-hackrf -s are always wrong (at least on recent host/firmware/CPLD). I get wrong ARFCN numbers and their advertised center frequencies correction is way to high (and on top of that, are contradictory, sometimes positive and sometimes negative), for example

	chan:   20 (939.0MHz + 17.102kHz)	power:  579119.98
	chan:   22 (939.4MHz - 32.928kHz)	power:  617854.92
	chan:   45 (944.0MHz + 17.110kHz)	power:  796347.98

Similar behaviour can be seen on various online tutorials here and there. The frequency correction does not make any sense on those reports either.

This issue is very much related to #16 and #23. As for the latter, I had indeed to go up to gains 32/32 to actually get some output, which should not be necessary as the BTS signals are supposedly strong enough.

Maybe this is all about HackRF One's DC spike? Is this what -E manual frequency offset in hz is made for? If so, how far away am I supposed to peak around? In what direction, -200Khz +200Khz? In short, how to use -E?

Thanks
update: and this is a duplicate of #6.

Invalid ARFCN error

I keep getting an Invalid ARFCN error when attempting to calibrate my hackrf to a particular channel

first line I enter is "kal -s 1900 -g 40 -l 40"
I get correct output along with gsm 1900 channels that are in the area

I then enter "kal -c 535" 535 just being an example
This is where the error comes up.
I have also tried to just put in the frequency with the "kal -f 1934" 1934 being an example again.

Which HackRF Firmware?

Which version of the HackRF firmware does this support? The original version for the jawbreaker had unsigned output and the newer version that supports the HackRF One has signed output.

I have the Jawbreaker and haven't upgraded yet. I can't seem to get Kalibrate to work, so I am wondering if it is an issue with my firmware version.

Homebrew formula for kalibrate-hackrf

Instead of https://github.com/scateu/kalibrate-hackrf/blob/master/INSTALL.homebrew manual instruction steps, why not submit a formula to homebrew-core so installation is simple as brew install kalibrate-hackrf?

I started one here: https://github.com/rxseger/homebrew-hackrf/blob/master/kalibrate-hackrf.rb - it is not in the main homebrew-core repo, so it has to be tapped:

brew tap rxseger/homebrew-hackrf
brew install kalibrate-hackrf

also it uses https://github.com/rxseger/kalibrate-hackrf instead of https://github.com/scateu/kalibrate-hackrf primarily for #8, but this could be changed.

And it doesn't fully follow the homebrew formula cookbook rules yet. The main blocker seems to kalibrate-hackrf would need a "stable release", e.g. a version tag, instead of only the git development 'master' branch:

Stable versions
Formulae in the core repository must have a stable version tagged by the upstream project. Tarballs are preferred to git checkouts, and tarballs should include the version in the filename whenever possible.

Software that only provides a development/beta, tagged version should be put in homebrew/devel-only. We don’t accept software without a tagged version because they regularly break due to upstream changes; we can’t provide bottles for them; and we don’t have an automatic update mechanism for head-only formulae which makes them very quickly outdated.

would you be willing to make an official "release" of kalibrate-hackrf for this purpose?

Running kalibrate causes gqrx to not work with hackrf one until system reboot.

Running "kal -s GSM850 -g 50 -l 50" causes gqrx to become unresponsive from that point until reboot of the pc.

i7 4GB RAM
Fresh install/update of Kali 2 rolling distro on the metal: 4.6.0-kali1-amd64 #1 SMP Debian 4.6.3-1kali1 (2016-07-12) x86_64 GNU/Linux,
Running a compiled version of kalibrate, from this git repo after following the procedure here:
https://docs.google.com/document/d/1E_LQZ0xTs697L-0QsANQ7sDzc09QhO_7q4ue_WXezI0/pub
with a hackrf one using the latest release firmware version 2015.07.2
I'm running gnome classic, latest gqrx from the rolling kali repo (also tried it with latest compiled gqrx from git, same results)
kalibrate works and finds several signals, but after it finishes (I don't ^c it) gqrx will no longer produce output. Gqrx works fine before running it.

The bug seems to only be present when I run kal from a GNOME terminal session in the desktop I run gqrx from. When I ssh into the machine and run kal from the ssh session, gqrx runs just fine in the desktop. (As is often the case when bug hunting, documenting the bug above uncovered other peculiarities). Also verified that it was not the addition of the "-v -D" for the purposes of the debug text output included above and reran "kal -s GSM850 -g 50 -l 50" in the ssh session.
debug_kal.txt

./configure: line 5064: `PKG_CHECK_MODULES(FFTW3, fftw3 >= 3.0)'

I still have the issue after following this thread (though it's for RTL but looks similar issue)
I have all dependencies installed, all fftw3 and libhackrf libs including reinstalling pkg-config afterward.

./configure: line 5064: syntax error near unexpected token `FFTW3,'
./configure: line 5064: `PKG_CHECK_MODULES(FFTW3, fftw3 >= 3.0)'

If I comment these lines in the configure file, then the line considering similar things with LIBHACKRF below results in a similar error.
Tried to comment PKG_CHECK_MODULES for LIBHACKRF and compile but eventually, of course, it does not find the libs.

The libs installed on my Debian system:

/usr/include/fftw3-mpi.f03
/usr/include/fftw3-mpi.h
/usr/include/fftw3.f
/usr/include/fftw3.f03
/usr/include/fftw3.h
/usr/include/fftw3l-mpi.f03
/usr/include/fftw3l.f03
/usr/include/fftw3q.f03
/usr/lib/i386-linux-gnu/libfftw3.so.3
/usr/lib/i386-linux-gnu/libfftw3.so.3.5.8
/usr/lib/i386-linux-gnu/libfftw3_omp.so.3
/usr/lib/i386-linux-gnu/libfftw3_omp.so.3.5.8
/usr/lib/i386-linux-gnu/libfftw3_threads.so.3
/usr/lib/i386-linux-gnu/libfftw3_threads.so.3.5.8
/usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindFFTW3f.cmake
/usr/lib/x86_64-linux-gnu/libfftw3.a
/usr/lib/x86_64-linux-gnu/libfftw3.so
/usr/lib/x86_64-linux-gnu/libfftw3.so.3
/usr/lib/x86_64-linux-gnu/libfftw3.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3_mpi.a
/usr/lib/x86_64-linux-gnu/libfftw3_mpi.so
/usr/lib/x86_64-linux-gnu/libfftw3_mpi.so.3
/usr/lib/x86_64-linux-gnu/libfftw3_mpi.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3_omp.a
/usr/lib/x86_64-linux-gnu/libfftw3_omp.so
/usr/lib/x86_64-linux-gnu/libfftw3_omp.so.3
/usr/lib/x86_64-linux-gnu/libfftw3_omp.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3_threads.a
/usr/lib/x86_64-linux-gnu/libfftw3_threads.so
/usr/lib/x86_64-linux-gnu/libfftw3_threads.so.3
/usr/lib/x86_64-linux-gnu/libfftw3_threads.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3f.a
/usr/lib/x86_64-linux-gnu/libfftw3f.so
/usr/lib/x86_64-linux-gnu/libfftw3f.so.3
/usr/lib/x86_64-linux-gnu/libfftw3f.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3f_mpi.a
/usr/lib/x86_64-linux-gnu/libfftw3f_mpi.so
/usr/lib/x86_64-linux-gnu/libfftw3f_mpi.so.3
/usr/lib/x86_64-linux-gnu/libfftw3f_mpi.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3f_omp.a
/usr/lib/x86_64-linux-gnu/libfftw3f_omp.so
/usr/lib/x86_64-linux-gnu/libfftw3f_omp.so.3
/usr/lib/x86_64-linux-gnu/libfftw3f_omp.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.a
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.so
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3
/usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3l.a
/usr/lib/x86_64-linux-gnu/libfftw3l.so
/usr/lib/x86_64-linux-gnu/libfftw3l.so.3
/usr/lib/x86_64-linux-gnu/libfftw3l.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3l_mpi.a
/usr/lib/x86_64-linux-gnu/libfftw3l_mpi.so
/usr/lib/x86_64-linux-gnu/libfftw3l_mpi.so.3
/usr/lib/x86_64-linux-gnu/libfftw3l_mpi.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3l_omp.a
/usr/lib/x86_64-linux-gnu/libfftw3l_omp.so
/usr/lib/x86_64-linux-gnu/libfftw3l_omp.so.3
/usr/lib/x86_64-linux-gnu/libfftw3l_omp.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3l_threads.a
/usr/lib/x86_64-linux-gnu/libfftw3l_threads.so
/usr/lib/x86_64-linux-gnu/libfftw3l_threads.so.3
/usr/lib/x86_64-linux-gnu/libfftw3l_threads.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3q.a
/usr/lib/x86_64-linux-gnu/libfftw3q.so
/usr/lib/x86_64-linux-gnu/libfftw3q.so.3
/usr/lib/x86_64-linux-gnu/libfftw3q.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3q_omp.a
/usr/lib/x86_64-linux-gnu/libfftw3q_omp.so
/usr/lib/x86_64-linux-gnu/libfftw3q_omp.so.3
/usr/lib/x86_64-linux-gnu/libfftw3q_omp.so.3.5.8
/usr/lib/x86_64-linux-gnu/libfftw3q_threads.a
/usr/lib/x86_64-linux-gnu/libfftw3q_threads.so
/usr/lib/x86_64-linux-gnu/libfftw3q_threads.so.3
/usr/lib/x86_64-linux-gnu/libfftw3q_threads.so.3.5.8
/usr/lib/x86_64-linux-gnu/pkgconfig/fftw3.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/fftw3f.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/fftw3l.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/fftw3q.pc

For libhackrf:

/usr/include/libhackrf
/usr/include/libhackrf/hackrf.h
/usr/lib/udev/rules.d/60-libhackrf0.rules
/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libHackRFSupport.so
/usr/lib/x86_64-linux-gnu/libhackrf.a
/usr/lib/x86_64-linux-gnu/libhackrf.so
/usr/lib/x86_64-linux-gnu/libhackrf.so.0
/usr/lib/x86_64-linux-gnu/libhackrf.so.0.5.0
/usr/lib/x86_64-linux-gnu/pkgconfig/libhackrf.pc
/usr/local/lib/python3.8/dist-packages/urh.libs/libhackrf-a1897859.so.0.5.0

(irrelevant doc and info files are omitted)

Can someone help with this?
Or maybe with how should I adjust the Makefile after removing the lines from configure and trying to set up the libraries manually?

Thanks

Is it right (wildly inconsistent results on different channels, e.g. -33.570 ppm vs 38.369 ppm)

Dear Scateu:
The result of kal for my hackrf like this:

~$ kal -s GSM900 -g 40 -a 1 -l 62 -g 40 
kal: Scanning for GSM-900 base stations.
GSM-900:
    chan: 9 (936.8MHz + 9.492kHz)   power: 4747328.95
    chan: 10 (937.0MHz + 33.101kHz) power: 4713891.86
    chan: 11 (937.2MHz + 27.741kHz) power: 4337386.69
    chan: 12 (937.4MHz - 34.957kHz) power: 4701652.01
    chan: 13 (937.6MHz + 5.849kHz)  power: 4921123.13
    chan: 14 (937.8MHz - 21.308kHz) power: 4489852.31
    chan: 15 (938.0MHz - 34.885kHz) power: 4948715.02
    chan: 19 (938.8MHz + 26.684kHz) power: 6055087.82
    chan: 20 (939.0MHz + 9.026kHz)  power: 5445623.90
    chan: 21 (939.2MHz - 18.874kHz) power: 5233643.37
    chan: 22 (939.4MHz - 24.310kHz) power: 5065278.10
    chan: 23 (939.6MHz - 23.830kHz) power: 4335606.89
    chan: 30 (941.0MHz + 10.342kHz) power: 4648356.57
    chan: 33 (941.6MHz + 38.018kHz) power: 4827731.90
    chan: 35 (942.0MHz - 22.521kHz) power: 5083162.67
    chan: 37 (942.4MHz - 26.626kHz) power: 4908658.42
    chan: 38 (942.6MHz + 33.284kHz) power: 5212849.03
    chan: 40 (943.0MHz + 31.026kHz) power: 5540634.65
    chan: 41 (943.2MHz + 6.383kHz)  power: 4640401.30
    chan: 42 (943.4MHz - 18.894kHz) power: 5560045.69
    chan: 43 (943.6MHz - 34.992kHz) power: 5796947.19
    chan: 83 (951.6MHz + 34.020kHz) power: 5017814.47
    chan: 86 (952.2MHz + 3.445kHz)  power: 4978590.71
    chan: 87 (952.4MHz - 20.500kHz) power: 4915357.25
    chan: 88 (952.6MHz - 38.684kHz) power: 5128484.07

$ kal -c 83 -g 40 -a 1 -l 62 -g 40 
kal: Calculating clock frequency offset.
Using GSM-900 channel 83 (951.6MHz)
average     [min, max]  (range, stddev)
+ 31.945kHz     [27474, 37282]  (9808, 2693.206787)
overruns: 0
not found: 2
average absolute error: -33.570 ppm

$ kal -c 43 -g 40 -a 1 -l 62 -g 40 
kal: Calculating clock frequency offset.
Using GSM-900 channel 43 (943.6MHz)
average     [min, max]  (range, stddev)
- 36.205kHz     [-39592, 2312]  (41904, 6233.333496)
overruns: 0
not found: 4
average absolute error: 38.369 ppm

I am confused about the result. -33.570 ppm and 38.369 ppm?
For my dvb-t dongle, the result of kal-sdr is about -36 ppm for all channels.

Can you give some hints about it. Thank you!

Merge kalibrate-hackrf with kalibrate-rtl? (add RTL-SDR support) and-or kalibrate-bladerf? / or use SDR abstraction layer (SoapySDR?)

Would it be possible to merge the two kalibrate's for hackrf and rtl into one project supporting both SDRs?

kalibrate-rtl: https://github.com/steve-m/kalibrate-rtl - last updated 2013, but includes several open pull requests: steve-m/kalibrate-rtl#5 steve-m/kalibrate-rtl#6 steve-m/kalibrate-rtl#9

kalibrate-rtl is also included in Kali Linux: http://tools.kali.org/wireless-attacks/kalibrate-rtl - but not http://tools.kali.org/wireless-attacks/kalibrate-hackrf

I was about to try to merge kalibrate-rtl and kalibrate-hackrf, but even though they both descended from kalibrate 0.4.1 (originally from http://thre.at/kalibrate/kal-v0.4.1.tar.bz2 but now thre.at is down), the code formatting style is different (whitespace) for some reason making this non-trivial (but did merge the -rtl PR's into: https://github.com/rxseger/kalibrate-hackrf). Which should be considered the "original" fork to merge the other one into?


update: answering my own question, -hackrf is a direct ancestor of -rtl, no additional commits merged into -rtl after Dec 14th, 2013, which -hackrf (this repo) is based on. The main device-specific commits are:

would be cool to support all three (USRP, RTL-SDR, HackRF), but perhaps rebuilding Kalibrate on top of an abstracted SDR platform e.g. GNU Radio would be better?

kal -s GSM900 fail to find signal found by gr-gsm

Hi. After building the source on Debian Jessie, the binary fail to find any base stations. This is rather strange, as gr-gsm is able to find GSM data. Any idea how to debug it?

$ time src/kal -s GSM900
kal: Scanning for GSM-900 base stations.
GSM-900:

real    2m55,877s
user    2m55,136s
sys     0m1,492s
%

ld: library not found for -lrt

On OS X 10.11.5, following the instructions at https://github.com/scateu/kalibrate-hackrf/blob/master/INSTALL.homebrew (and https://web.archive.org/web/20131226204943/http://thre.at/kalibrate), I get an error about a missing library: ld: library not found for -lrt

Full output:

kalibrate-hackrf $ brew install fftw hackrf libtool
Warning: fftw-3.3.4_1 already installed
Warning: hackrf-2015.07.2 already installed
Warning: libtool-2.4.6 already installed
kalibrate-hackrf $ ./bootstrap
kalibrate-hackrf $ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking whether ln -s works... yes
checking for ranlib... ranlib
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for inline... inline
checking for working strtod... yes
checking for floor... yes
checking for getpagesize... yes
checking for memset... yes
checking for sqrt... yes
checking for strtoul... yes
checking for strtol... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for FFTW3... yes
checking for LIBHACKRF... yes
checking build system type... x86_64-apple-darwin15.5.0
checking host system type... x86_64-apple-darwin15.5.0
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
kalibrate-hackrf $ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in src
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-arfcn_freq.o -MD -MP -MF .deps/kal-arfcn_freq.Tpo -c -o kal-arfcn_freq.o `test -f 'arfcn_freq.cc' || echo './'`arfcn_freq.cc
mv -f .deps/kal-arfcn_freq.Tpo .deps/kal-arfcn_freq.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-c0_detect.o -MD -MP -MF .deps/kal-c0_detect.Tpo -c -o kal-c0_detect.o `test -f 'c0_detect.cc' || echo './'`c0_detect.cc
c0_detect.cc:183:17: warning: absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value [-Wabsolute-value]
      if (r && (fabsf (offset - GSM_RATE / 4) < ERROR_DETECT_OFFSET_MAX))
                ^
c0_detect.cc:183:17: note: use function 'std::abs' instead
      if (r && (fabsf (offset - GSM_RATE / 4) < ERROR_DETECT_OFFSET_MAX))
                ^~~~~
                std::abs
1 warning generated.
mv -f .deps/kal-c0_detect.Tpo .deps/kal-c0_detect.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-circular_buffer.o -MD -MP -MF .deps/kal-circular_buffer.Tpo -c -o kal-circular_buffer.o `test -f 'circular_buffer.cc' || echo './'`circular_buffer.cc
mv -f .deps/kal-circular_buffer.Tpo .deps/kal-circular_buffer.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-fcch_detector.o -MD -MP -MF .deps/kal-fcch_detector.Tpo -c -o kal-fcch_detector.o `test -f 'fcch_detector.cc' || echo './'`fcch_detector.cc
mv -f .deps/kal-fcch_detector.Tpo .deps/kal-fcch_detector.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-kal.o -MD -MP -MF .deps/kal-kal.Tpo -c -o kal-kal.o `test -f 'kal.cc' || echo './'`kal.cc
mv -f .deps/kal-kal.Tpo .deps/kal-kal.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-offset.o -MD -MP -MF .deps/kal-offset.Tpo -c -o kal-offset.o `test -f 'offset.cc' || echo './'`offset.cc
mv -f .deps/kal-offset.Tpo .deps/kal-offset.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-usrp_source.o -MD -MP -MF .deps/kal-usrp_source.Tpo -c -o kal-usrp_source.o `test -f 'usrp_source.cc' || echo './'`usrp_source.cc
mv -f .deps/kal-usrp_source.Tpo .deps/kal-usrp_source.Po
g++ -DHAVE_CONFIG_H -I. -I..    -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2 -MT kal-util.o -MD -MP -MF .deps/kal-util.Tpo -c -o kal-util.o `test -f 'util.cc' || echo './'`util.cc
mv -f .deps/kal-util.Tpo .deps/kal-util.Po
g++ -I/usr/local/Cellar/fftw/3.3.4_1/include -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -g -O2   -o kal kal-arfcn_freq.o kal-c0_detect.o kal-circular_buffer.o kal-fcch_detector.o kal-kal.o kal-offset.o kal-usrp_source.o kal-util.o -L/usr/local/Cellar/fftw/3.3.4_1/lib -lfftw3 -L/usr/local/Cellar/hackrf/2015.07.2/lib -lhackrf -lrt 
ld: library not found for -lrt
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [kal] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Where can I get rt? Nothing in Homebrew named exactly "rt" or "librt" (closest match is: librtlsdr).


Found this: https://forum.qt.io/topic/35487/osx-and-librt OSX and librt

It works great on Windows and LInux, but for some reason QT wants librt.a (the POSIX realtime Library), and it's not implemented on OSX, so trying to build with

Support calibrating from 60 kHz WWVB time signal? (or 72 MHz Primex FM rebroadcasts)

From the original website:

There are other ways to calibrate these devices -- the FA-SY 1 documentation discusses using the WWVB time signals.

More details at https://en.wikipedia.org/wiki/WWVB

The 70 kW ERP signal transmitted from WWVB is a continuous 60 kHz carrier wave, the frequency of which is derived from a set of atomic clocks located at the transmitter site, yielding a frequency uncertainty of less than 1 part in 10^12

60 kHz may require downconverters for use with common SDR hardware, but could be interesting to support it anyways, as an alternative to the GSM FCCH signal

ld: library not found for -lrt

bootstrap and configure seem to complete successfully.

But then I get the error on make. It looks like I'm missing a library.

make error

$ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in src
g++ -I/usr/local/Cellar/fftw/3.3.4_1/include  -I/usr/local/Cellar/hackrf/2015.07.2/include/ -I/usr/local/Cellar/libusb/1.0.19/include/libusb-1.0  -g -O2   -o kal kal-arfcn_freq.o kal-c0_detect.o kal-circular_buffer.o kal-fcch_detector.o kal-kal.o kal-offset.o kal-usrp_source.o kal-util.o -L/usr/local/Cellar/fftw/3.3.4_1/lib -lfftw3  -L/usr/local/Cellar/hackrf/2015.07.2/lib -lhackrf  -lrt
ld: library not found for -lrt
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [kal] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

HackRF info

Found HackRF board 0:
USB descriptor string: 0000000000000000457863c82e33551f
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Part ID Number: 0xa000cb3c 0x00484f3e
Serial Number: 0x00000000 0x00000000 0x457863c8 0x2e33551f

OS X 10.10.4

gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix

Any ideas? Thanks!

PCS 1900

I used QXDM to check the phone that there are several severing cells nearby. But I can't find any frequency in PCS 1900 band by kalibrate-hackrf. What should I do so that I can detect PCS 1900 band frequency?

Besides, I can find the frequency when I used GSM 850. I think it can work.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.