For those that are interested, I did some basic analysis and decoding of the posted GPS data set from October 8th, 2010. I took a look at the ranging pulses, the doppler shift, and the modulated data. I've posted the details here, http://www.acasper.org/2011/11/07/gps-signal-analysis/.
One thing I was hopeful someone from SETI may be able to clear up is an apparent discrepancy between the observation time listed in the meta file, and the decoded satellite time. They are off by about 8 minutes. Is it possible the time was recorded incorrectly in the meta information? If anyone has any ideas please let me know.
This decoding of the 2010-10-08 GPS 27 signal is outstanding!
Thanks to you and Dave the setiquest forum has suddently become interesting again.
The timestamp in the meta file is entered manually by the observer. It can be off by minutes, however the timestamp in the .hdrs file has sub-millisecond accuracy. I have included below this entry a command that demonstrates a method using perl to dump the timestamp associated with the first byte of the observation. This shows a difference of only nine seconds, when 7 hours is removed from UTC, between the observation timestamp and the timestamp you extracted from the GPS telemetry. The nine second difference should be almost entirely explained by dividing the sample byte rate (17476266.(6) bytes/second) into the number of bytes you processed to aquire the telemetry timestamp.
Let us know!
$ perl -e 'read(STDIN,$b,80);@t=unpack("x48L2",$b);printf("%s + %8.6f seconds\n",scalar(gmtime($t)),$t/(2**32))' <2010-10-08-GPS-27_1575_1-hdrs.dat
Fri Oct 8 20:15:48 2010 + 0.479664 seconds
Nice validation, Rob.
The time of the week counter indicates the time of the first ranging pulse from the next sub-frame. There are two ways I calculated this arrival. The first was to count GPS nav bits assuming each bit consists of 20, 1ms ranging pulses. The first ranging pulse I decode is 338616 samples into the data set, I then discard the first 4 pulses before I get to the first full, 20 bit, nav message bit. The first sub-frame starts at nav message bit 143. This gives a total delay of (338616/sF + 4e-3 + 142*20e-3 +6) = 8.8827 (S). The other way I measured the time was to detect the sample # of the first ranging pulse from the second sub-frame, which was sample # 77749791, or 8.8977 (could be off by a millisecond, I didn't pay very close attention to the latencies involved in this processing). To me, it makes sense that the first method would underestimate since the doppler shift indicates the satellite is moving away from the receiver. So, it appears the ranging mark indicating 12:15:57 arrives at approximately 12:15:57.377. A 377 ms TOF seems large (~113226 km) but I could be missing a few hundred milliseconds somewhere in the processing. If someone sees an error please let me know. Do you think it's possible there is a slight delay between when the time is recorded in the hdrs file and when the data begins arriving?
Great blog. Can I post a link to it on our main setiQuest page?
See the link on the front setiquest.org page. I also tweeted about it.
This is a very nice analyis and write-up. The costas loop implementation is a nice touch. An alternative is to simply square the BPSK signal for carrier recovery, which is what I've been doing with my GPS analyses. Looking forward to checking out your code.
-Billy Barott (ATA)