Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
Fancy satellite simulating hardware would be cool. In the interim, there are a few software simulators we can try to feed out through a HackRF. At the same time, it would be nice to try some other correlators like the gnss-sdr code. And there are probably more tests we can do with the simple sweeping sine trick. Like verifying that received samples have the same sweep frequency as transmitted. The giant Doppler shift is pretty odd. It would be interesting to put together a sample of two satellite vehicle prn sequences and see if they end up with a matching Doppler shift. If they do, then we can probably just blame the mixer precision in the HackRF. I'll have my HackRF One and Jawbreaker on hard to compare. Maybe it's time to dust off the Noctar too. For the most recent tests, the HackRF One was set for 1.57542GHz at 4.092MS/s. The flow goes directly from File Source (in repeat mode) to osmocom Sink so I'm not doing any intentional frequency shifting. My output from soft-correlator looks the same as yours. $ while :; do cat data/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.000.000590 # 1 satellites in view; average clock error 0.000590 chips/s I'm looking forward to hacking more on GPS stuff at noon. Who else is going to come? We need all the GPS brains! It seems like we must be really close to tipping this over the edge of making sense and doing what we want. For anyone interested in software defined GPS or the approaches we have been taking to debug it, there is an informal bi-weekly SDR meetup this Monday evening at Ctrl-H. I'll be there and would be happy to talk about the bits I understand and/or hack on GPS stuff more then. If Friday and Monday don't work for your schedule, suggest another time and I'll try to make it. -- Kenny -+---+++-++---+--+-+-++--++--+-+-++--+++-+++-++-+++---++--++ On Thu, 2015-06-04 at 10:59 -0700, Jamey Sharp wrote: > Awesome! And nice job on the pretty pictures! > > I think this is strong evidence that we should get access to a real > satellite simulator, soon. > > Though I don't understand why it saw a -14.8kHz Doppler shift. The > original file is a zero-IF sample. Did you set the HackRF at a center > frequency different than 1575.42MHz, or multiply the file sample by a > sine wave, perhaps? That seems outside the range of reasonable clock > errors to me. > > Hey, does your copy of soft-correlator produce the same output mine > does for the looped original prn1? It looks like we didn't push the > change that sets the IF center frequency to 0 instead of 1.95MHz. > > Notice the bogus satellites have very low signal/noise ratios > (although you should be skeptical of my math for computing those, > FYI). Apparently my heuristic is wrong for guessing that a satellite > is visible; I based it on my clock error estimate, and all of that is > something I made up, not something I've seen documented as the usual > way to build a receiver. > > Jamey > > On Jun 4, 2015 10:27 AM, "Kenny" wrote: > For all you folks following along at home who want to see some > pretty > pictures, here you go! > > > https://drive.google.com/open?id=1pnFV5MWkx5YR9ZlutetgDrejNG9SZx6Zp6xbdKl48Ps&authuser=0 > > I sometimes have blissful moments of forgetting that Google > wants all of > my data, always. In this particular instance, we may as well > let them > help out. So there is a Google Drive folder linked at the > bottom of the > doc which contains "gpslog_big-outside.raw" along with various > other > files we have been talking about. > > Transmitting the prn1 converted to complex floats through the > HackRF and > grabbing a sample with jGPSv3 correlates! Check out that > signal-to-noise ratio for SV 1!. > > $ ./soft-correlator < data/gpslog_prn1_rx.raw > # frequency of 1-bits: i-sign 51.7%, i-mag 33.6%, q-sign > 48.8%, q-mag 30.0% > # SV, S/N ratio, doppler shift (Hz), code phase (chips), > sample clock error (chips/s) > * 1 601.457508 -14801.532243 253.00 > 9.611385 > * 2 14.721936 -799.801893 330.00 > 0.519352 > * 4 15.425549 -6801.062185669.00 > 4.416274 > * 1114.114000 -10801.489275 302.00 > 7.013954 > * 1715.250208 2199.254809 77.00 > -1.428088 > * 2414.148221 -7794.920364335.00 > 5.061637 > * 2813.145979 14199.180477545.00 > -9.220247 > * 3013.199176 5798.007429 466.75 >
Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
There was a request off-list for more background on this stuff, because we're using plenty of jargon. One of the big goals for this group is education, so I'm eager to help people understand what's going on. But I don't want to answer questions privately, because I'm sure more people are confused and curious. For general context on this particular discussion, try Google searches about Software Defined Radio, and Andrew's masters thesis about GPS, which you can find along with other resources here: http://gps.psas.pdx.edu/GpsResources/ Looks like http://gnss-sdr.org and http://swiftnav.com have material that might be good too, although I haven't read any of their stuff. Let me know whether it helps you. :-) They're solving the same problems we are from different perspectives. If you want to dig into the specifics of what we're working on right now, there are four relevant git repositories at https://github.com/psas/: gps-rf-board, gps-cpld, stm32 (gpsv3 branch), and gps. The datasheet for the MAX2769 chip on the RF board is the main thing we've been struggling with lately. You might find the commit history in stm32's gpsv3 branch and in the gps repo informative for more context on what we've been doing most recently. Finally, I want to encourage everyone to ask questions, both on this mailing list and during our weekly meetings. It's super important for the future of this group that we help newer folks get comfortable participating in everything we're doing, and we can't do that if we don't know what you need. Jamey On Wed, Jun 3, 2015, 7:44 AM Kenny wrote: > Into the wee hours, we kept on doing stuff. > > * Gavin and Andrew wired up the FDT custom Uninterruptible Power Supply > without melting any fingers in the process. I'm sure it was much safer > than it sounded. > * David(?) fired up the Geiger counter on picam2 and received data! So > we have another cool thing that is ready for launch. > * Kenny set up Splunk on the NUC and configured ground based systems to > do remote logging. It even integrates with Nagios so when something > goes down, the Splunk search for that host/service is a click away. > * Theo and Jamey hacked on GPS stuff > + 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. > + Python test scripts were overhauled to send our best known > configuration to the MAX2769 and take a short sample. Even more magic > was added to automate testing many different configurations. > + 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. > + After running through all the settings and deciding we understood > most of them to be what they should be, the correlator still wasn't able > to pick up anything in an outdoor test. > + Jamey said we could fly with this configuration and probably figure > out how to tease satellites out of the logged data later. It is > starting to look like the MAX2769 configuration is about as good as it > can get. We just need to look at the data harder. > + For fun, Kenny collected a larger sample outside from the MAX2769, > returned to the basement while converting it for GNURadio, played it > back through the HackRF in transmit mode and watched to see if the > nearby COTS GPS receiver could lock. No position lock, but I wasn't > watching the data stream to see if it was able to see any satellites at > all. Some attenuators and a direct connection might help. > > Other people did stuff too! Like rebuilding an RCS controller board and > ordering parts. I didn't keep track of all the cool things so please > correct my fumbles and add your news. > > -- > Kenny > > -+---+++-++---+--+-+-++--++--+-+-++--+++-+++-++-+++---++--++ > > > > ___ > psas-avionics mailing list > psas-avionics@lists.psas.pdx.edu > http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics > ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
Speaking of Doppler shifts, back when we were doing the GPS class we were catching satellites at >10kHz Doppler using the recorded data we found, and that really shouldn't be possible for a receiver at rest (relative to the Earth surface). I never looked into it further but i am suspicious of the doppler numbers we get from the soft correlator. -Nathan On Thu, Jun 4, 2015 at 10:59 AM, Jamey Sharp wrote: > Awesome! And nice job on the pretty pictures! > > I think this is strong evidence that we should get access to a real > satellite simulator, soon. > > Though I don't understand why it saw a -14.8kHz Doppler shift. The original > file is a zero-IF sample. Did you set the HackRF at a center frequency > different than 1575.42MHz, or multiply the file sample by a sine wave, > perhaps? That seems outside the range of reasonable clock errors to me. > > Hey, does your copy of soft-correlator produce the same output mine does for > the looped original prn1? It looks like we didn't push the change that sets > the IF center frequency to 0 instead of 1.95MHz. > > Notice the bogus satellites have very low signal/noise ratios (although you > should be skeptical of my math for computing those, FYI). Apparently my > heuristic is wrong for guessing that a satellite is visible; I based it on > my clock error estimate, and all of that is something I made up, not > something I've seen documented as the usual way to build a receiver. > > Jamey > > On Jun 4, 2015 10:27 AM, "Kenny" wrote: >> >> For all you folks following along at home who want to see some pretty >> pictures, here you go! >> >> >> https://drive.google.com/open?id=1pnFV5MWkx5YR9ZlutetgDrejNG9SZx6Zp6xbdKl48Ps&authuser=0 >> >> I sometimes have blissful moments of forgetting that Google wants all of >> my data, always. In this particular instance, we may as well let them >> help out. So there is a Google Drive folder linked at the bottom of the >> doc which contains "gpslog_big-outside.raw" along with various other >> files we have been talking about. >> >> Transmitting the prn1 converted to complex floats through the HackRF and >> grabbing a sample with jGPSv3 correlates! Check out that >> signal-to-noise ratio for SV 1!. >> >> $ ./soft-correlator < data/gpslog_prn1_rx.raw >> # frequency of 1-bits: i-sign 51.7%, i-mag 33.6%, q-sign 48.8%, q-mag >> 30.0% >> # SV, S/N ratio, doppler shift (Hz), code phase (chips), sample clock >> error (chips/s) >> * 1 601.457508 -14801.532243 253.00 9.611385 >> * 2 14.721936 -799.801893 330.00 0.519352 >> * 4 15.425549 -6801.062185669.00 4.416274 >> * 1114.114000 -10801.489275 302.00 7.013954 >> * 1715.250208 2199.254809 77.00 -1.428088 >> * 2414.148221 -7794.920364335.00 5.061637 >> * 2813.145979 14199.180477545.00 -9.220247 >> * 3013.199176 5798.007429 466.75 -28.764940 >> # 8 satellites in view; average clock error -1.598834 chips/s >> >> I'm surprised to see that the added noise was enough to correlate the >> pseudo-noise sequence from other satellite vehicles. This was done in >> the basement, so I know it wasn't accidentally picking up any real >> satellites. >> >> -- >> Kenny >> >> -+---+++-++---+--+-+-++--++--+-+-++--+++-+++-++-+++---++--++ >> >> >> >> > > ___ > psas-avionics mailing list > psas-avionics@lists.psas.pdx.edu > http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics > ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
Awesome! And nice job on the pretty pictures! I think this is strong evidence that we should get access to a real satellite simulator, soon. Though I don't understand why it saw a -14.8kHz Doppler shift. The original file is a zero-IF sample. Did you set the HackRF at a center frequency different than 1575.42MHz, or multiply the file sample by a sine wave, perhaps? That seems outside the range of reasonable clock errors to me. Hey, does your copy of soft-correlator produce the same output mine does for the looped original prn1? It looks like we didn't push the change that sets the IF center frequency to 0 instead of 1.95MHz. Notice the bogus satellites have very low signal/noise ratios (although you should be skeptical of my math for computing those, FYI). Apparently my heuristic is wrong for guessing that a satellite is visible; I based it on my clock error estimate, and all of that is something I made up, not something I've seen documented as the usual way to build a receiver. Jamey On Jun 4, 2015 10:27 AM, "Kenny" wrote: > For all you folks following along at home who want to see some pretty > pictures, here you go! > > > https://drive.google.com/open?id=1pnFV5MWkx5YR9ZlutetgDrejNG9SZx6Zp6xbdKl48Ps&authuser=0 > > I sometimes have blissful moments of forgetting that Google wants all of > my data, always. In this particular instance, we may as well let them > help out. So there is a Google Drive folder linked at the bottom of the > doc which contains "gpslog_big-outside.raw" along with various other > files we have been talking about. > > Transmitting the prn1 converted to complex floats through the HackRF and > grabbing a sample with jGPSv3 correlates! Check out that > signal-to-noise ratio for SV 1!. > > $ ./soft-correlator < data/gpslog_prn1_rx.raw > # frequency of 1-bits: i-sign 51.7%, i-mag 33.6%, q-sign 48.8%, q-mag 30.0% > # SV, S/N ratio, doppler shift (Hz), code phase (chips), sample clock > error (chips/s) > * 1 601.457508 -14801.532243 253.00 9.611385 > * 2 14.721936 -799.801893 330.00 0.519352 > * 4 15.425549 -6801.062185669.00 4.416274 > * 1114.114000 -10801.489275 302.00 7.013954 > * 1715.250208 2199.254809 77.00 -1.428088 > * 2414.148221 -7794.920364335.00 5.061637 > * 2813.145979 14199.180477545.00 -9.220247 > * 3013.199176 5798.007429 466.75 -28.764940 > # 8 satellites in view; average clock error -1.598834 chips/s > > I'm surprised to see that the added noise was enough to correlate the > pseudo-noise sequence from other satellite vehicles. This was done in > the basement, so I know it wasn't accidentally picking up any real > satellites. > > -- > Kenny > > -+---+++-++---+--+-+-++--++--+-+-++--+++-+++-++-+++---++--++ > > > > > ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
For all you folks following along at home who want to see some pretty pictures, here you go! https://drive.google.com/open?id=1pnFV5MWkx5YR9ZlutetgDrejNG9SZx6Zp6xbdKl48Ps&authuser=0 I sometimes have blissful moments of forgetting that Google wants all of my data, always. In this particular instance, we may as well let them help out. So there is a Google Drive folder linked at the bottom of the doc which contains "gpslog_big-outside.raw" along with various other files we have been talking about. Transmitting the prn1 converted to complex floats through the HackRF and grabbing a sample with jGPSv3 correlates! Check out that signal-to-noise ratio for SV 1!. $ ./soft-correlator < data/gpslog_prn1_rx.raw # frequency of 1-bits: i-sign 51.7%, i-mag 33.6%, q-sign 48.8%, q-mag 30.0% # SV, S/N ratio, doppler shift (Hz), code phase (chips), sample clock error (chips/s) * 1 601.457508 -14801.532243 253.00 9.611385 * 2 14.721936 -799.801893 330.00 0.519352 * 4 15.425549 -6801.062185669.00 4.416274 * 1114.114000 -10801.489275 302.00 7.013954 * 1715.250208 2199.254809 77.00 -1.428088 * 2414.148221 -7794.920364335.00 5.061637 * 2813.145979 14199.180477545.00 -9.220247 * 3013.199176 5798.007429 466.75 -28.764940 # 8 satellites in view; average clock error -1.598834 chips/s I'm surprised to see that the added noise was enough to correlate the pseudo-noise sequence from other satellite vehicles. This was done in the basement, so I know it wasn't accidentally picking up any real satellites. -- Kenny -+---+++-++---+--+-+-++--++--+-+-++--+++-+++-++-+++---++--++ 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
Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
Interesting, good to know; although in this case it's a two-bit ADC (literally and, perhaps, figuratively?), so it kind of doesn't have low-order bits to dither. :-) Considering that the noise floor is higher than the signal amplitude, you could alternately look at it as being entirely dither, but not a predictable kind. Though it's not significantly oversampled; we're only 2x over the Nyquist limit. Jamey On Jun 4, 2015 9:09 AM, "Bart Massey" wrote: > The other thing to keep in mind is that low-order ADC bits are sometimes > regular patterns rather than actual signal because dithering and parasitic > signals. > > On Thu, Jun 4, 2015 at 12:16 AM Jamey Sharp wrote: > >> 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) >> * 1766.360819-0.9092890.000.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 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" wrote: >> >> > + The STM32 which controls the MAX2769 (GPS baseband rece
Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
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) * 1766.360819-0.9092890.000.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 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" 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
Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
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" 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
Re: [psas-avionics] Tuesday latenight updates (mostly GPS news)
On Jun 3, 2015 7:44 AM, "Kenny" 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 ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
Re: [psas-avionics] Tuesday
Hey all, I'm going to have to leave shortly after this meeting but I'll probably make it if we do a Sunday session. Ron On Tue, Jun 18, 2013 at 7:08 PM, Clark Wachsmuth wrote: > Unless someone knows of a manned rocket near Astoria, I'm going to be in > to Portland too late for tonight's meeting, unfortunately. I can meet for > another coding session this Sunday if it's needed or wanted. > > Thanks, > > Clark > > ___ > psas-avionics mailing list > psas-avionics@lists.psas.pdx.edu > http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics > > ___ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
