jks

They played back fine, but the iq file didn't sound quite right as you mentioned. It sounded like the I (or Q) channel was just being duplicated in both left/right channels. It was missing the "phase shifting" effect you normally hear between the stereo channels. I'll have a look at this.

I find that +15 to +18 dB SNR minimum is needed for uninterrupted audio when the broadcaster is using 64 QAM.

1) In gps/gps.h change the constants FC, FS and FS_I to match what your front-end chip produces.

2) Further down you'll see the constants FFT_LEN and NSAMPLES are a function of FS_I. So this will be the size of the acquisition FFT assuming no decimation (DECIM = 1). But there are several aspects of the Verilog that depend on these constants, and they are not automatically taken into account as FS and FS_I are changed. So you have to check the sizes and adjust the Verilog if necessary. For the SE4150L the clock is 16.368 MHz, so FFT_LEN and NSAMPLES is 65472. In verilog/gps/sampler.v the size of the sampler memory is 1-bit by 64k (65536). So NSAMPLES just fits. If your clock if faster you need to increase the size of the memory. Some chips like the MAX can give you a range of output clock frequencies which helps. If your clock is slower it doesn't matter -- the buffer will just be larger than it needs to be. The code in gps/search.cpp:Sample() and e_cpu/kiwi.gps.asm:CmdGetGPSSamples() always moves the correct amount of data.

3) The other piece of Verilog that changes depending on clock frequency is the maximum size of the integrators in the tracking loops. Look at Andrew's article: http://www.aholme.co.uk/GPS/Main.htm Go down to the tracking loop diagram in yellow and green. See how the yellow parts are in the FPGA hardware clocked at 10 MHz? The 10 MHz shown is the front end clock rate, so on the Kiwi this is really 16.368 MHz. The integrators shown (sigma symbols with n = 1 .. 10000) accumulate the input bit stream for one PRN repetition period (one millisecond). 10 MHz times one milliseconds is 10000. So the integrators must be at least 14-bits wide (2^14 = 16384, 2^13 = 8192 would be too small).

For the Kiwi clock the value is 16368. I can't remember why but I ended up using 16-bits (2^16 = 65536). I think there is some rounding in the integrators that would cause 2^14 to overflow in some cases, so at least 15-bit would be needed (see the business with the "lsb" register). This integrator width is in verilog/gps/demod.v Go to the comment that says "Down-convert to baseband". Then you'll see the integrator registers defined with [16:1] i.e. 16-bits. The integrator values are transferred all the way to the e_cpu code. So further down you'll see the serial transmission code that also takes the 16-bit register width into account.

If your clock rate fits into 16-bits (with some margin) then there is no need to change any of this. It should just work. I forgot another complication. The code in e_cpu/kiwi.gps.asm:GPS_Method() assumes the IQ samples will fit into an unsigned 16-bit value initially. If you need more than this then that code will have to be rewritten. Eventually 32 and 64-bit values are used for the loop filtering code. But you'd have to change the initial IQ processing 16-bit code to be 32-bit or something.

Another NDB assist: the large (outer) + and - frequency step buttons will increment in alternating 400 and 1000 Hz steps to match the common NDB modulation spacings.

Also from Europe try beginning at these times: 04Z 9800 RRI, 06Z 3955 BBC, 06Z 6040 RRI, 08Z 17790 BBC

See http://www.hfcc.org/drm Not all the signals listed there seem to be transmitting.

That way you can get in and set the Debian root password. Then ssh / putty login should work. I'll remove the hack on a subsequent release.

This is because for real-time GPS data this code needs to run PLL loop filter code at 1 kHz.

See Andrew's description here: http://www.aholme.co.uk/GPS/Main.htm

I don't think my simulation code is fast enough to do this in real-time. Anyway, the simulation code only simulates both the GPS FPGA logic (e.g. sdgps/a_ise/gps_iq15_1/demod.v) and the embedded processor together. It does not know how to work with the GPS logic running in the actual FPGA but the embedded processor simulated. But this embedded processor is quite simple and shouldn't be much of a problem to get working on the Zynq.

There is another problem to consider. My old "sdgps" project that you have running is targeted for a Spartan-6. But also for the Xilinx ISE toolchain. I believe Zynq requires the newer Vivado toolchain. So you will have to make some adjustment, e.g. instead of a .ucf format file for the FPGA pin mappings you will need a .xcf format file. And the definitions for the required Xilinx IP blocks is a little different. The GPS part of the newer KiwiSDR project targets the Artix-7 which of course requires Vivado. So you will find a .xcf file there and the Vivado-compatible IP block definitions.

After this is working there is the question of moving the C/C++ code off the Beagle into the Arm processor of the Zynq. But that is a separate consideration.

And now for something new: The "sdgps" project just outputs to the terminal as you know. And the GPS in the KiwiSDR project has this nice web interface as part of the admin page. What I've been working on the last few days is a version of the KiwiSDR project that has most of the "SDR" code removed. This will leave just the GPS code. There will be fewer files, it will compile much faster and be much easier to understand. The KiwiSDR project is currently at https://github.com/jks-prv/Beagle_SDR_GPS so I will make a new project called https://github.com/jks-prv/Beagle_GPS in a few days. I'm not sure if this will help you for using the Zedboard but I've had several requests for a version of the Kiwi for people who just want to do GPS development / experimentation and don't care about SDR.