WARNING! MAY BE ILLEGAL IN YOUR AREA. Check all regulations that apply to you. I am not responsible for your actions. Don't be that guy/gal, keep it in safe test environments.
Linux SDR distribution. I use Kali and installed the SDR tools.
apt update && apt upgrade -y && apt dist-upgrade -y && apt install kali-linux-sdr
1x HackRF One https://hakshop.com/collections/wireless-gear/products/hackrf?variant=701314117
1x Board design https://github.com/osqzss/gps-sdr-sim/tree/master/extclk
- I used OSHPark and got 3x for $1.80 USD https://oshpark.com/shared_projects/LUrNnBgA
1x Ceramic Capacitor http://www.digikey.com/product-detail/en/murata-electronics-north-america/GRM219R61A105KA01D/490-5760-1-ND/2771955
1x Header Pins http://www.digikey.com/product-detail/en/amphenol-fci/67997-412HLF/609-3244-ND/1878517
1x Passive Antenna for GPS http://www.digikey.com/product-search/en?keywords=TS.07.0113
1x 30 db RF attenuator. I purchased one off ebay. Specs: SMA male - SMA Female, 30 dB, 50 Ohm, 2W max power, DC to 6 GHz
Soldering Iron, Flux, Solder, etc.
Optional (Same part):
Getting it working:
Construct the board using the pictures from the github as a reference: https://github.com/osqzss/gps-sdr-sim/blob/master/extclk/hackrf_tcxo.jpg
Connect your RF attenuator and GPS antenna to the HackRF.
After you have checked all your solder joints for the external clock, see if the hackRF will detect the clock via https://github.com/mossmann/hackrf/wiki/HackRF-One
External Clock Interface (CLKIN and CLKOUT)HackRF One produces a 10 MHz clock signal on CLKOUT. The signal is a 10 MHz square wave from 0 V to 3 V intended for a high impedance load.The CLKIN port on HackRF One is a high impedance input that expects a 0 V to 3 V square wave at 10 MHz. Do not exceed 3.3 V or drop below 0 V on this input. Do not connect a clock signal at a frequency other than 10 MHz (unless you modify the firmware to support this). You may directly connect the CLKOUT port of one HackRF One to the CLKIN port of another HackRF One.HackRF One uses CLKIN instead of the internal crystal when a clock signal is detected on CLKIN. The switch to or from CLKIN only happens when a transmit or receive operation begins.To verify that a signal has been detected on CLKIN, use
hackrf_debug --si5351c -n 0 -r. The expected output with a clock detected is
[ 0] -> 0x01. The expected output with no clock detected is
[ 0] -> 0x51.
Go into the satgen directory and run make as well.
Download a brdc*.*n.Z from
In order to get this working with the HackRF, you need to use the -b flag with a value of 8. Here is a modified example from the github page:
./gps-sdr-sim -b 8 -e brdc3540.14n -l 37.808880,-122.410167,216 -o StaticLocation.bin
This runs the program using -b 8 for the HackRF, -e for the historic GPS ephemeris data (This cannot do current day, but yesterday's compiled file should work. Read up more on that if you are interested.), -l for gps location and the last number is the altitude in meters, -o for output.bin file. The max duration for gps-sdr-sim is 300 seconds. If you use the default/max 300 seconds, it will generate a ~1.5 GB output.bin file. Keep this in mind if you are saving multiple locations. If you forget to use the -o option, it will create gpssim.bin.
From there you can broadcast that .bin file with HackRF using the following command:
hackrf_transfer -f 1575420000 -s 2600000 -a 1 -x 0 -R -t StaticLocation.bin
Use hackrf_tansfer -h to know what all the options do.
You may notice that your phone will not accept the GPS broadcast. The first thing to do is enable "Device Only" GPS mode. Do not use High Accuracy. I also had to use an app (GPS Status) in order to clear my A-GPS cache. Then I use a different app (GPS Test) in order to see if my phone gets a GPS lock. I usually leave the phone in airplane mode with WiFi turned off in order for GPS Status to clear the cache and not auto-download A-GPS data. Then I will run GPS Test and wait for a lock before turning on WiFi.
Garmin GPS units and similarly other devices shouldn't have an issue detecting your GPS signals.
You can create a path using Google Earth and saving out the path into a KML. Using that SatGen program, you can load the KML and it will show you some options you can manipulate, and also a crude picture of your path.
You can manipulate some of the options to your liking and hit the preview button to have it refresh and show your new speed graph. When you are happy, click "Generate NMEA" and save that file.
Move that file over to the gps-sim-sdr/satgen directory and run the program which you should have compiled earlier to convert the NMEA to a user motion file for gps-sdr-sim.
./nmea2um Usage: nmea2um <nmea_gga> <user_motion>
./gps-sdr-sim -b 8 -e brdc2980.16n -u Hak5_Usermotion -o Hak5example.bin
Notice the total time at the bottom of the SatGen program 111.40 seconds. You will need to keep it under 300 seconds to work with gps-sdr-sim. You can modify gps-sdr-sim to increase the max number of seconds by editing USER_MOTION_SIZE in gpssim.h and then recompile with gcc. Use caution as this will allow you to create very large files. The default of 300 seconds caps approximately 1.5 GB.
From there it's a matter of transmitting the .bin file like before.
hackrf_transfer -f 1575420000 -s 2600000 -a 1 -x 0 -R -t Hak5example.bin