GPS Acquisition and Tracking on AMD RFSoC – Wrong PRNs from ADC Input (Loopback Works Fine)

Hi everyone,

I am working on the **GPS Acquisition and Tracking Using AMD RFSoC Device**

GPS Acquisition and Tracking Using AMD RFSoC Device - MATLAB & Simulink

reference design from MATLAB & Simulink, and I have run into a puzzling issue with the ADC path. I would really appreciate any insights from those who have worked with this design or with RFSoC ADC/DAC configurations in general.

**What Works**

In **loopback mode** (ADC input connected directly to DAC output), the system works perfectly — I can see correct PRN codes being acquired through the internal signal generator path.

**The Problem**

When I **disconnect the DAC** and feed real GPS data into the ADC (from a BladeRF via antenna or wire), I get **incorrect PRN codes**. The strange part is:

> **Even when the ADC is fully disconnected, I see those exact same wrong PRNs in the ILA (Integrated Logic Analyzer).**

This strongly suggests the issue is **not** with the incoming RF signal itself, but rather something internal — possibly a signal path that is not being properly muxed or gated when switching away from loopback, or a residual/default signal being driven onto the AXI-Stream bus when the ADC input is inactive.

[Kranti Balaga]

Hi Mohsin,

We have verified the ADC–DAC loopback on the RFSoC. We have not yet evaluated real GPS data on the hardware, but we did validate the captured real data in simulations and the expected results were observed.

Could you please elaborate on your setup for feeding real data? This will help us better understand your configuration.

Regarding the behavior you mentioned, getting the same output even after disconnecting the ADC — that is indeed unusual. We have not encountered such an issue so far, but we will recheck that part on our side and get back to you.

Thanks

Kranti

[Karthik Akula]

Also please use the reset each time you need a new set to observe. The acquisition will restart and try to acquire again if a reset signal is applied. Acquisition is a one time task, so once acquired you will see the same set until reset.

[Mohsin]

Hi Kranti and Karthik,

Thank you for the response and for looking into this.

Regarding Karthik's note on reset:

Yes, I am aware that acquisition is a one-time task and I have been applying the reset signal each time before observing a new set of results. The issue persists even after reset, the same wrong PRNs reappear consistently after every reset cycle, which is what made this particularly suspicious.

My Hardware Setup :

- RFSoC Board: [ZCU48DR]

- HDL IP: Generated from the gpshdlAcquisitionTracking model at a target frequency of 196.608 MHz

- Project Configuration:

- ADC sampling rate: 3922 MSPS

- Decimation factor: 5x, 4 samples per AXI-Stream cycle

- DAC interpolation: 5x, 8 samples per AXI-Stream cycle

GPS Signal Source:

- BladeRF SDR used as the GPS signal transmitter

- Transmitting a pre-generated GPS L1 C/A baseband waveform (bin file, int16 interleaved IQ) upconverted to 1575.42 MHz

- Tested via both direct wire connection (SMA cable, BladeRF TX → RFSoC ADC) and antenna (BladeRF TX antenna → RFSoC RX antenna)

- BladeRF configured at: TX frequency = 1575.42 MHz, sample rate = 32.768 Msps

Thank you again for your support.

Best regards,

Mohsin

[Mohsin]

Hi Im still open for answers or discussion

[Karthik Akula]

Is there any changes made to the model that's available with the toolbox? if yes, describe the changes. Let us know which matlab version is being used. We will try to reproduce accordingly.

Don't use GPS standard frequencies for local waveforms.