Theo, Jamey, K, Andrew, Devin and I have been putting in lots of hours
this week on GPS issues.

* 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.

* 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
  + 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

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.

(presently down)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

psas-avionics mailing list

Reply via email to