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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
