GPS HDL Receiver Not Working with Generated LNAV Data of the HDL Acquisition and Tracking using C/A Code model

Hello,

I am working with the MathWorks GPS HDL reference applications and I am facing an integration problem in the receiver model.

The examples I am referring to are the GPS HDL Acquisition and Tracking Using C/A Code - MATLAB & Simulink example, the GPS HDL Data Decode and Position Estimation - MATLAB & Simulink example, and theGPS HDL Reference Applications Overview - MATLAB & Simulink .

My issue is that the decoder model works correctly with its own default .mat LNAV data, but it does not work correctly when I feed it LNAV data generated from my Acquisition and Tracking IP. The same behavior also appears when I follow the reference receiver design and connect the acquisition/tracking output to the decoder, so the overall model does not work as expected.

I have already checked the signal magnitude, and it is being normalized in the model using a gain stage so that the data fits the sfix16_en14 range, approximately +2 to -2. So the difference is not simply an amplitude issue.

The LNAV stream is generated from a Simulink model, contains a 60-bit pattern, and is repeated over time. I am also making sure the LNAV data length is sufficient for the decoder input, but the model still behaves differently from the default .mat test data case.

My questions are:

1. Why does the decoder work with the example .mat LNAV data, but not with LNAV data generated by the acquisition and tracking IP?
2. What assumptions does the decoder make about the LNAV stream that are satisfied by the example data but not by my generated data?
3. Why does the same issue also appear when the reference receiver design is followed?
4. Is there any requirement on signal structure, timing, sign convention, normalization, or LNAV message length that I should verify?

Any guidance on how the decoder expects the LNAV stream to be structured would be greatly appreciated.

Thank you.

[Mohsin]

im still open for answer or any help, suggestions

[Kranti Balaga]

Hi Mohsin,

Thank you for the detailed report. The Acquisition & Tracking IP and the NAV Decoder operate at different sample rates. The provided .mat file was generated from simulated data at the exact rate the decoder expects, and validated against the Acquisition & Tracking example. Since the both models operate at different extreme rates, simulations take lot of time. We will try to reproduce and will provide the correct configuration options. Give us some time.

In the meantime, please verify the rate transitions between tracking output and decoder input are handled correctly.

Thanks

Kranti

[Mohsin]

Hi Kranti,

Thank you for the clarification.

Understood regarding the different operating rates between the Acquisition & Tracking IP and the NAV Decoder.

I will recheck the rate transition path between the tracking output and decoder input carefully. Currently, the tracking stage operates with a 196.608 MHz clock, while the navigation symbols are provided to the decoder through the valid-controlled interface at the expected lower rate.

I also verified the 1 kHz navigation valid rate on hardware using ILA, but I will further investigate whether there may still be a timing/alignment issue between lnavSym and valid.

One observation from my side is that even when using LNAV-related outputs generated from the Acquisition & Tracking workflow itself, the decoder still does not achieve frame synchronization. That made me suspect there could be some interface assumption or formatting requirement between the two stages that I may be missing.

I appreciate your help and I will wait for your findings regarding the correct configuration options.

Thank you.

Answer 1

[Kranti Balaga]

Hi Mohsin,

Thank you for your detailed observations. Due to abrupt rate changes, the simulations take longer to run, so we used the generated .mat file to validate the data decoding.

We have verified our models using captured data up to the position estimation stage, and the results are as expected. Additionally, we are planning enhancements to both data decoding and position estimation using acquisition and tracking outputs from the hardware in upcoming releases.

We will keep you updated on these improvements.

Thanks