Global Localization Playback Mode - GNSS Ingest Error and Termination (Initial X not PSD)

[karthikreddy157]

Hi @TanguyHardelin
Thanks again for your guidance

@TanguyHardelin

For the type of environment present in your SVO, I recommend using the GEN_1 positional tracking mode with the NEURAL depth mode. This configuration will be better suited than GEN_2, especially for higher speeds.

As you suggested i have set my mode to NEURAL but while ingesting GNSS to zed i am getting INVALID TIMESTAMP issue apart from any Non performance depth mode iam getting INVALID TIMESTAMP but As u informed in the difference is expected to be less than 4 seconds i have verified difference betweeb GNSS Time and sl.getCurrentTimeStamp() it is less than a second still iam getting INVALID TIMESTAMP.

Observations:

• The GNSS timestamp and the sl.getCurrentTimeStamp() are less than 1 second apart, which is well within the <4s threshold mentioned in the docs.
• The issue disappears when switching to a performance depth mode (e.g., PERFORMANCE).
• The error only occurs in NEURAL and other non-performance depth modes, which are necessary for our use case due to the scene’s complexity and speed.

CODE

LOGS

Additional Notes:

• As you suggested earlier, we are actively working on increasing the GNSS covariance to assist with fusion stability.
• The INVALID_TIMESTAMP issue appears tightly linked to NEURAL mode — possibly due to an internal delay or different sync behavior compared to PERFORMANCE mode.

Questions:

1. Could NEURAL depth mode introduce a delay that causes GNSS timestamps to be misaligned internally?
2. Is there a known workaround or recommended approach to ensure reliable GNSS fusion when using NEURAL mode?

In the meantime, if there’s any solution or workaround available for the INVALID_TIMESTAMP issue specifically, it would be extremely helpful to keep our pipeline moving forward.

Thanks in advance for your support!