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" <bart.mas...@gmail.com> 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 <ja...@psas.pdx.edu> 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)
>> * 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
>> >>
>> _______________________________________________
>> 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

Reply via email to