Nice work tracking down that 1575MHz interference, everyone! I wish I'd
been there just to see how you figured it out, 'cause that sounds like deep
magic to me.

Another thing we could try: manually tune the gain, disabling AGC, to find
out what level of gain corresponds to the signal we're seeing. Theo and I
talked this evening about how to automate that on the STM32 or even the
CPLD, although both options are ugly.

For what it's worth, here's why I advocated for changing the clock settings
between the MAX2769 and the CPLD:

We'd already determined that the ADC in the MAX2769 should be driven with a
4MHz clock, not 16MHz as we previously thought. I have the impression that
we saw a reduction in noise when we made that change, though I'm not sure
why that would happen.

But we arranged to continue sending a 16MHz reference to the CPLD because
that's what we had programmed it to expect.

The CPLD, in turn, just divided that down to a 4MHz clock again, but there
was no guarantee that the two 4MHz clocks were in phase. So this meant we
were sampling the ADC output with a random delay. By just sending the ADC
clock to the CPLD and removing the clock divider from the CPLD, we get a
clock which is locked to the sample clock.

Also, we're sending a lower frequency signal across board traces this way.
As yesterday's exercises demonstrated, even these relatively low frequency
clocks may matter at the signal power levels we're dealing with.

Jamey

On Mon, Jun 8, 2015, 5:54 PM Kenny <ke...@romhat.net> wrote:

> Theo, Jamey, K, Andrew, Devin and I have been putting in lots of hours
> this week on GPS issues.
>
> Friday:
> * We spent more time verifying the data path between MAX2769 and "Flight
> Computer" (or laptop pretending to be the FC).
>   + Sequence numbers were added to the UDP stream
> * Clock divider stuff was changed on the MAX2769 and the CPLD was
> updated to match.  I think this simplified the CPLD code a bit, but I
> don't remember why else this was done.
> * After trying lots of stuff, we eventually decided that the bright
> yellow line at roughly -400KHz in our waterfall plots was such a strong
> signal that Auto-Gain Control in the MAX2769 was turning down
> sensitivity, making satellites too hard to see.
>   + We fiddled with lots of MAX2769 configurations as well as
> antenna/environmental changes, but the line never changed frequency.  So
> we concluded it was coming from something on-board, and probably outside
> of the MAX2769.
>
> Sunday:
> * The evil signal was at 1.575GHz and has been identified as a 25MHz
> clock harmonic (.025*63=1.575) coming from an STM32-PHY trace.  Thanks
> Devin!
>   + This is one of the two Ethernet PHY (physical layer transceiver)
> clocks.  Andrew and Theo found a way to put this clock into low-speed
> mode and made some other GPIO speed configurations on the STM32 to get
> harmonics away from our signal.  Nice!
>   + The evil yellow line is gone!  But we still don't correlate outside.
> * Transmitting high quality samples of single satellite PRN sequences
> via HackRF is still the only way we have managed to get good
> soft-correlator output from MAX2769 samples.  We did manage to do this
> with a short segment of a real live Satellite Vehicle #27 capture found
> online [1], as well as Jamey's generated prn1 "perfect" sequence.
> * We tried capturing samples with the HackRF outside using a passive GPS
> antenna and running them through the soft-correlator.  It couldn't pick
> out any satellites in this sample either.
> * After fighting with bad cables/adapters, we took a more calibrated
> look at output levels from the HackRF using a spectrum analyzer.
> Starting with -60dBm and adding 90dB attenuation, our input at the
> jGPSv3 board should have been in the neighborhood of -150dBm.  It is
> entirely reasonable to expect actual satellite signal to be at least
> this good at Earth.  With -150dBm into the MAX2769, Jamey's
> soft-correlator code was still able to pick out SV27 from the sigblips
> sample.
>
> So it seems that when one satellite talks at a time, everything is
> great.  But if the environment is noisy, then our signal isn't clean
> enough to pick out the satellites.  Why?
>
> Things to do:
> * Try correlating our samples from MAX2769 and HackRF using GNSS-SDR or
> other projects code
> * Try using the NOAA Matlab/Octave GPS multipath simulator [2] to create
> input for the HackRF to send to the MAX2769.  This might help us
> incrementally introduce noise.
> * Get a proper GPS simulator.  These are expensive.  Please tell your
> friends that we need one.
> * Figure out why the MAX2769 applies different AGC weighting to signal
> below vs above center frequency
> * Consider alternate ways of interpreting the bits we are receiving from
> the MAX2769
> * Thanks to some great code pushes by Jamey, we can easily run his
> soft-correlator on complex floats.  This makes it much easier to fiddle
> with common signal processing tools to try cleaning up our samples and
> see if we can get them to correlate.
> * Get out the SiGe GPS front-end development module and figure out how
> to pull samples with it to compare against the MAX2769.  Lots of useful
> Matlab code is posted by CCAR [3].
>
> I'll be at the SDR meetup at Ctrl-H [4] tonight with hardware.  If you
> want to work on GPS or just talk about what has been done so far, feel
> free to swing by.
>
>
> 1. http://setiquest.sigblips.com/download/2010-10-08-GPS-27_1575_1/
> (presently down)
> 2. http://www.ngs.noaa.gov/gps-toolbox/MPsimul.htm
> 3. http://ccar.colorado.edu/gnss/
> 4. http://www.meetup.com/CTRL-H/events/222979295/
>
> --
> 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

Reply via email to