jks

I would start by seeing if the e_cpu firmware is sending data correctly to the C code. I'm not sure exactly what codebase you're using. So adjust what I say here to match what you have. In gps.asm change the UploadSamples routine to return a constant pattern instead of data from the FPGA and see if you get this pattern on the C code side. Replace the "wrEvt GET_SAMPLES" with the two instructions "push 0x1234" and "wrReg HOST_TX". Then in search.cpp where the "spi_get(CmdGetSamples, &rx, PACKET)" happens print out rx.word[0] and look for the 0x1234 (it might be byte swapped).

If that looks ok put gps.asm back the way it was and change the FPGA code to send a constant pattern. In sampler.v send a fixed pattern on dout[15:0] instead of the output from the RAMB16_S1_S4. Say something like "dout <= 16'h1234" inside a "always @ (posedge clk)" block.

You should always see transitions in the IF signal, even if no antenna is connected.

Speaking of the antenna. Are you sure you are presenting enough sat signal to the gp2015? Are you using an active antenna and supplying bias voltage on the cable? Are you using too much lossy cable (e.g. rg174) that would result in too weak a signal at the chip? This is extremely important. See here: http://freqelec.com/gps_gnss/gps_ant_issues_r1_5-07.pdf

On the admin GPS tab the switch labeled "Plot Galileo?" determines if separate position solutions including Galileo, and not, are computed and displayed. But note that this only works if there are at least 4 sats of each category present (i.e. 4 Galileo, 4 Navstar/QZSS). On the new "Map" display different color pins will be used to show the differences. See the legend at the bottom of the map.

Sometimes when Galileo sats are used the positions don't agree with Navstar/QZSS (i.e. the green and red/yellow pins will be spaced some distance apart). This may be due to the well known false-peak locking issue with the Galileo waveform. We are still implementing a solution for this issue.

Andrew's scheme is this: After his mixer IF = 22.6 MHz. Then comes hard limiter. Then D-FF runs at 10 MHz which is also the system clock. So FS = 10e6, FS_I = 10000000 in the code. The D-FF under samples the 22.6 to produce 2.6 MHz as the final IF. So FC = 2.6e6 in the code.

So for the gp2015 you have IF of 4.309 MHz. Now you must sample with a D-FF. The gp2015 does this with a 5.71 MHz clock to produce a final IF of 1.405 MHz. If you use something else, like 10 MHz, you would get 10 MHz +/- 4.309. The difference term would be 5.691 and you can set FC to that. Then it should work.

You can see from the orbital tracks why the shadow hole exists if you're located close enough to the poles. From the north pole all GPS sats would appear biased toward the south.

Due to QZSS I learned there is a difference between the terms geosynchronous and geostationary. 3 of the 4 QZSS sats trace the same figure-8 pattern on the Earth because they are geosynchronous (and have a high inclination). QZS-3 is truly geostationary (appears at a single point on the Earth) like the majority of the communications satellites.

On the admin GPS display the "hold" count is the number of bits recovered noise-free from the 50 baud data stream. When it gets to 300 a check is made for a valid subframe. While searching for the 8-bit subframe sync pattern the hold count is reduced by one. So that's why it is stuck at 299 much of the time. It is searching for sync. If sync is achieved, but subsequent 30-bit words have parity errors, the hold count is reduced by the number of word bits in error. Then it will start incrementing again as new bits start coming in. A valid subframe is declared when there is sync and ten 30-bit words with no parity errors (300 bits per subframe). A 60 second watchdog timer releases the channel tracking if no subframes are found.

An RSSI value of 3xx is pretty weak. You can bring up the IQ display for the channel and notice the x-axis spacing is small between the I & Q scatter plot regions.