In previous posts we showed how Phillip Hahn had been trying to use his RTL-SDR as a GPS receiver on a high powered rocket in order to overcome the COCOM limits which prevent commercial GPS devices from operating when moving faster than 1,900 kmph/1,200 mph and/or higher than 18,000 m/59,000 ft.
In order to test future flights with the RTL-SDR GPS receiver, Phillip has been simulating GPS rocket trajectory signals and using his LimeSDR. The RTL-SDR then receives the simulated GPS signals which are then fed into SoftGNSS for decoding. The simulation simulates the Japanese SS-520-4 rocket which is a 32′ long, 2′ diameter small high powered rocket capable of putting loads like cubesats into orbit affordably. Using the simulated data Phillip is able to calculate the trajectory and see all the motor burns in the velocity profile.
While Phillip intends to use the RTL-SDR on a similar rocket in the future, he notes that the simulation does not take into account problems such as thermal noise, or RF interference, rocket jerk, satellite occlusion and vibration problems.
Back in April we posted about Philip Hahn and Paul Breed’s experiments to use an RTL-SDR for GPS logging on their high powered small rockets. As GPS is owned by the US military, a standard GPS module cannot be used on a rocket like this, as they are designed to fail if the GPS device breaches the COCOM limit, which is when it calculates that it is moving faster than 1,900 kmph/1,200 mph and/or higher than 18,000 m/59,000 ft. The idea is that this makes it harder for GPS to be used in non-USA or home made intercontinental missiles. As SDR GPS decoders are usually programmed in open source software, there is no need for the programmers to add in these artificial limits.
In their last tests they managed to gather lots of GPS data with an RTL-SDR, but were only able to decode a small amount of it with the GNSS-SDR software. In this post Philip discoversa flaw in the way the GNSS-SDR performs acquisition and retrackingthat GNSS-SDR decodes in such a way that makes it difficult to obtain a location solution with noisy high-acceleration data. By using a different GPS implementation coded in MATLAB, he was able to get decoded GPS data from almost the entire ascent up until the parachutes deploy. Once the parachutes deploy the GPS has a tough time keeping a lock as it sways around. His post clearly explains the differences in the way the code is implemented in GNSS-SDR and in the MATLAB solution and shows why the GNSS-SDR implementation may not be suitable for high powered rockets.
In addition, they write that while the flight was just under the artificial COCOM GPS fail limits for speed and height, the commercial GPS solution they also had on board failed to collect data for most of the flight too. With the raw GPS data from the RTL-SDR + some smart processing of it, they were able to decode GPS data where the commercial solution failed.
Over on the SDRGPS blog Philip Hahn and fellow aerospace engineer Paul Breed have been working together to try and use an RTL-SDR to help get accurate GPS data for tracking small high powered rockets. They write that their end goal is to be able to “track high power rockets in high acceleration / speed / altitude environments”.
In their latest attempt they launched a rocket with an RTL-SDR on board with it capturing GPS data to be later processed with GNSS-SDR. The goal was to get a GPS fix throughout the flight. Unfortunately they found that a good fix was only obtained while the rocket was on the ground, and not much data was obtained while it was in the air. They write that they suspect that the fault lies in the vibration in the rocket which can affect the frequency stability of the crystal oscillator, or in the GPS satellite tracking loop algorithm.
They still hope to be able to get some usable information from the flight by trying other algorithms on the data, but they are also seeking advice from anyone who might know how to help them, so please contact them if you know anything that may help.
If you were to try to simply spot a GPS signal at 1.575 GHz in the spectrum on a waterfall in a program like SDR# you would probably fail to see anything. This is because GPS signals are very weak, and operate below the thermal noise floor. Only through clever processing algorithms can the actual signal be recovered.
To receive GPS e.p. uses one of our RTL-SDR blog units (back in stock soon!) with the bias tee enabled which is used to power a cheap 5V active GPS antenna. For software he uses GNSS-SDRLIB and RTKLIB which runs on Windows. Using the RTL-SDR, GPS antenna and the decoding software he was able to get his current position to within about 5 meters of accuracy.
In his blog post e.p. shows a step by step guide on how to install and use the Windows software. In later posts he also shows how to install and use another program called GNSS-SDR which runs in Linux and can also be used to acquire GPS fixes with an RTL-SDR dongle.
To illustrate the software in action e.p. has also uploaded a video to YouTube which is shown below.
At this years Defcon 2015 conference researcher Lin Huang from Qihoo 360 presented her work on spoofing GPS signals. Qihoo 360 is a Chinese security company producing antivirus software. Lin works at Qihoo as a security researcher where her main job is to prevent their antivirus software and users from becoming vulnerable to wireless attacks. Her research brought her to the realm of GPS spoofing, where she discovered how easy it was to use relatively low cost SDRs like a USRP B210/BladeRF/HackRF to emulate GPS signals which could allow a wireless attacker to manipulate the GPS on smartphones and cars.
Previous attempts at GPS spoofing have all used more expensive custom hardware. One attempt in 2013 allowed university researchers to send a 213-foot yacht off course, and it is suspected that hackers from the Iranian government have used GPS spoofing to divert and land an American stealth drone back in 2011.
In Lin’s presentation she shows how she was able to trick a smartphone into thinking it was in a different location. In addition she writes how this method could be used to trick the phone into changing it’s time, as many smartphones will periodically refresh the clock accuracy by using GPS satellites. She also shows how she was able to bypass a DJI drones forbidden area no fly zone policy. DJI drones come with a feature where the engines will not power up if the on board GPS detects that it is in a no drone fly zone. By spoofing the GPS she was able to get the drone to power up inside a no fly zone in Beijng.
Over on his blog /dev/thrash RTL-SDR experimenter Elia has been attempting to build an antenna to receive Global Positioning System (GPS) signals with his RTL-SDR. After doing some research he decided to build a Skew Planer Wheel antenna which he tuned for the GPS L1 frequency at 1575.42 MHz. A Skew Planar Wheel antenna is circularly polarized omnidirectional antenna which can be built out of wire. It is well suited to receiving signals from low earth orbiting (LEO) satellites such as the GPS satellites.
Elia later tested his antenna with a commercial GPS receiver circuit and was able to obtain a GPS fix.
Following on from our last post where dewdude showed how to decode DGPS signals, Frank K2NCC has uploaded a video on YouTube showing DGPS decoding in action. In his video Frank uses an Airspy plus ham-it-up upconverter, a Sirio discone antenna and for software he uses SDR# with audio piped into MultiPSK for decoding.
In the video you can clearly see the decoded DGPS messages showing the pseudorange corrections and station numbers. To decode DGPS with MultiPSK you will need to use the paid version which costs approximately $50 USD, however in the free version the DGPS will run for 5 minutes each time MultiPSK is opened before expiring.
Below is an example of a decoded message.
Message type : 9 (GPS partial correction set)
Station number : 172 (Appleton WA USA 300.0 Khz TXID 871 100bps)
Z-count : 4215 ( 42 mn 9.0 s )
Sequence count : 2le factor=0.3)
Sat. ID|SF|UDRE|Pseudorange corr. |Range rate corr.|IOD|CRC
25 |0 |1-4m| -7.68 m | 0.000 m/s |62 |OK
31 |0 |1-4m| 1.54 m | 0.000 m/s |27 |OK
32 |0 |1-4m| 0.70 m | 0.000 m/s |99 |Error