jks

When you get acquisitions do the PRNs (sats) agree with those known to be visible in the sky? (i.e. as reported by another working GPS receiver). I guess you pretty much said yes. If acquisition is working then you know the constants FC, FS and FS_I must be set to the correct values for the NT1065. Max SNR values of 50 are fine (will depend on your antenna). I don't think the increased sampling bandwidth will matter much to the SNR because it is derived from the normalized output of the acquisition FFT. But I am no expert about that.

If the RSSI during the tracking phase is never over 300 then the tracking loop is probably never locking. Have you tried tracking using the SE4150? Does it ever lock? A lot of things have to work correctly for the tracking loop to lock.

There is some Verilog Andrew has called logger.v It is a buffer for storing IQ samples from the tracking loop. There is Verilog in gps.v to attach logger.v to the PUT_LOG, GET_LOG and LOG_RST commands sent by ecpu code. But there is no ecpu code currently to send these commands. But it would not be difficult to add. You would just be using PUT_LOG to save the I & Q values from the tracking loop to the buffer. And then implement a command sent from the host (Beagle) side that uses GET_LOG to upload the IQ values through the SPI. If the loop is locked you'll get a stable IQ display pattern like what is shown on Andrew's site. Look for the graph that has the heading "(ii) Lock". 

When you are decimating 4:1 in the FPGA from the 65 MHz sample rate of the NT1065 to 16.354 MHz are you doing decimation properly by first filtering the signal bandwidth before downsampling by 4? If you don't filter then you will be aliasing signal and/or noise into the decimated passband and this is perhaps why tracking doesn't lock.

There is a similar one in the BeagleBone Black system reference manual (SRM): System Reference Manual