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

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.

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.

We're talking about people who manually update/upgrade the underlying Debian/Linux system on the Kiwi by logging into the Beagle as root and running, for example, the "apt" command. Please don't do this. We only validate specific Debian distributions. If you update manually you run the risk of "bricking" your Kiwi server. That is, downloading something causing an unexpected side-effect which prevents the Kiwi server from running. This will stop further auto-updates and will require a manual intervention to fix. Possibly by re-flashing your Beagle using the Seeed SD-card and losing your entire Kiwi configuration (unless you've backed up).

This is exactly what has happened since a change was made in late February by one of the Beagle developers that made its way into the Debian update stream. We've identified the problem and have asked them to make a change. But it is not clear when this might happen. If you have a Kiwi in this condition then please use the following workaround:

Symptom: The Kiwi server won't stay running. The log shows it just crashes and restarts over and over again with the error "SYS_PANIC: open spidev".

Workaround:

If you look carefully at the free version of the DUC/DDC compiler provided with Vivado you'll see that it is not general purpose. It is targeted to the cell phone industry (LTE/CDMA) and does not have the bit widths, clock rates and decimation factors needed by the Kiwi.

The Kiwi does take advantage of some Vivado IP blocks, like the DDS compiler. And it makes very heavy use of the Artix DSP blocks to save FPGA fabric gates. We also wanted to have a design fully independent of any FPGA manufacturer's architecture in case we need to change devices in the future. It was also a learning experience for us to implement everything from first principles.