jks

But today's build will take some time as the new compiler is downloaded and installed. Total update/build time will be approximately 15 minutes.

It is extremely important that you do not interrupt this process and potentially leave your Kiwi in a partially updated state unable to run or update further (i.e. "bricked").

I added the assertion a little while ago to make sure a hardware (FPGA) constraint wasn't getting overrun. If it is then a sat that is acquired may not be tracked properly. And we see this behavior sometimes. But this assertion has never occurred in my testing (or at least I've never caught it happening). So if I can understand what's going on and fix a bug this might result in greater tracking successes which would be very helpful.

I'll include this fix in the next update.

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

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.