I'm happy to get a copy of the file from you next time I see you. I don't know if we have a sensible place to stick 200MB test files.
I've attached a single cycle of the pseudo-noise sequence from satellite vehicle #1, in the packed format, IF, and sample rate that we're using. You can loop it and feed it to soft-correlator like so: $ while :; do cat prn1; done | ./soft-correlator # frequency of 1-bits: i-sign 50.0%, i-mag 100.0%, q-sign 50.0%, q-mag 0.0% # SV, S/N ratio, doppler shift (Hz), code phase (chips), sample clock error (chips/s) * 1 766.360819 -0.909289 0.000000 0.000590 # 1 satellites in view; average clock error 0.000590 chips/s So you should be able to try passing through your HackRF and our RF frontend too, and see if soft-correlator gets similar results then. It would also be interesting to look at a waterfall display for the original and over-the-air versions. I'm glad you did that compression test as I've learned something from it. Nobody needs to know this, but I thought it was a fun exercise, so read it if you like. :-) Both gzip and bzip2 use Huffman coding, and it turns out that because of the MAX2769's automatic gain control, Huffman coding should be able to compress the data a little bit. In each byte of our data, bits 1, 3, 5, and 7 have a 50% chance of being a 1, but the other bits have only a 33.2% chance. That skews the distribution of bytes. If byte values were uniformly distributed, then each possible value would occur about 0.4% of the time, but with this AGC the probabilities are sometimes higher, sometimes lower: 0.1% 16 0.2% 64 0.3% 96 0.6% 64 1.2% 16 Given those probabilities, the theoretical lower bound is about 7.7 compressed bits per 8-bit byte of input, for a compressed size of 95.8%. Huffman coding can't reach that bound though because these probabilities aren't negative powers of two, and Huffman coding only uses integer numbers of bits for each symbol. That theoretical limit is not as good as what you actually saw, which was about 91.3%. So that's interesting. Apparently there's even more structure in this signal than one might predict from the AGC behavior. Samples off a GPS-band RF frontend should be nearly uncorrelated (they should look like white noise). So I still expect that pattern-recognition, dictionary compression techniques like Lempel-Ziv (used in gzip) and the Burrows-Wheeler transform plus run-length encoding (used in bzip2) don't help very much. But the low-pass filter reduces the variance of the noise, and that's going to result in some correlation across samples, so maybe the compressors are picking that up? You could test that by setting the CONF1 register's FBW (filter bandwidth) field to 0b10 (4.2MHz) and seeing how well that more broad-band noise compresses. Jamey On Wed, Jun 3, 2015 at 3:18 PM, Kenny <ke...@romhat.net> wrote: > For generating pseudonoise, NOAA helpfully posted some Matlab code: > http://www.ngs.noaa.gov/gps-toolbox/MPsimul.htm > > > The "bigger" sample I took is only 196MB in raw I/Q sign/mag binary > format. But that turns into 3.1GB in complex 32-bit floats. I tried > compressing a few different ways: > > 3.1G gpslog_big-outside.floats > 196M gpslog_big-outside.raw > 181M gpslog_big-outside.raw.gz # gzip --best > 181M gpslog_big-outside.raw.7z # 7z -mx=9 > 179M gpslog_big-outside.raw.bz2 # bzip2 --best > > Compressing by almost 10% is pretty surprising to me. It doesn't seem > like the fixed frequency spurs (at DC and -400kHz) would be enough to > account for this. Maybe some of the aliasing artifacts could be > compressed? > > I don't have a good place to post this file at the moment. > Recommendations? I'll have it with me on a thumbdrive for the capstones > Thursday, Friday hackday and Sunday lab hours. > > -- > Kenny > -+---+++-++-++++--+------+-+-++--++--+-+-++--+++-++----+-++-+++---+----+--+----+ > > > > On Wed, 2015-06-03 at 12:14 -0700, Jamey Sharp wrote: >> On Jun 3, 2015 7:44 AM, "Kenny" <ke...@romhat.net> wrote: >> > + The STM32 which controls the MAX2769 (GPS baseband receiver) now >> > dynamically configures the MAX according to instructions received by >> > debug scripts so we can test all the configurations we want without >> > reprogramming the STM32 each time. >> >> I was skeptical about whether this would be worth the engineering >> effort, but Theo's time spent building it already paid for itself last >> night. Excellent idea. >> >> > + Kenny joined the party to help transmit a sweeping sine wave +/- >> > 2MHz around GPS baseband using HackRF. Samples received from the >> > MAX2769, converted and viewed in baudline showed the same sweeping >> sine >> > wave (with noise and other artifacts). This turned out to be a good >> way >> > to test poorly documented configuration settings and lay to rest >> > bit-order questions. >> >> I disagree. It was a *great* way to test. ;-) We now have confidence >> about the meaning of most of the MAX2769 registers, and we know the >> entire signal path on the jGPSv3 board is functioning! >> >> I have two next steps in mind for testing: >> >> First, someone (Nathan or me probably) should generate one GPS >> satellite's pseudonoise sequence in a file. We should test feeding it >> into soft-correlator first, which ought to report a strong signal from >> that satellite at 0 Doppler shift. Then we should feed the same signal >> through HackRF, record it with jGPSv3, and try feeding *that* to the >> correlator. If that doesn't work, I don't know what's wrong; bad noise >> maybe? If it does work, we can also try simulating some Doppler shifts >> and adding varying amounts of noise in GNU Radio. >> >> After that: don't we know some folks who make GPS satellite >> simulators? We're ready to ask them for help. >> >> In parallel, I think it's time to do the other engineering tasks we >> need: send the COTS GPS data to Ethernet simultaneously with the MAX >> samples; log it all to disk on the FC; stream the COTS data to the >> ground; and log it all to SDCard on the STM if we're going to do that. >> >> I suspect that's mostly on Theo's plate, but anyone who's interested >> in the microcontroller firmware or flight computer software could >> help. >> >> > + Jamey said we could fly with this configuration and probably >> figure >> > out how to tease satellites out of the logged data later. >> >> I won't swear there's anything to tease out. I just think at this >> point we've mitigated most of the risks of hardware problems. So if we >> decided to fly with the hardware in this state, I'd feel pretty >> comfortable that we'd done our due diligence toward getting useful >> science out of the flight. And I think I should shift to focusing on >> roll control and overall system engineering details. >> >> > + For fun, Kenny collected a larger sample outside from the >> MAX2769, ... >> >> Could you post that larger sample somewhere? How big is it? And out of >> curiosity, do any of the general purpose compression algorithms (gzip, >> bzip2, etc) manage to compress it at all? (If they do we've probably >> screwed something up, so that would be good to know.) >> >> Maybe we can try feeding the sample into the GNSS-SDR code we looked >> at last fall, as another check. I think that's a good task for K if he >> has time; he had that code running successfully IIRC. >> >> Jamey >>
prn1
Description: Binary data
_______________________________________________ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
