Question Regarding PPS Assertion Period on Jetson AGX Orin

[RUGE]

Hello Nvidia Engineers,

I am using a combined navigation system to obtain GPS positioning and synchronize the system time. When I used ppstest /dev/pps0 to check the PPS assertion, I found that the cycle is 1024ms instead of the expected 1000ms. Theoretically, the PPS cycle should be exactly 1 second. I also measured the PPS output pin from the combined navigation system using an oscilloscope, and its cycle was indeed 1000ms.

Upon researching online, I found that others using Jetson modules also reported a PPS cycle of 1024ms during ppstest testing. Is this behavior specific to the Jetson platform?

Below are the screenshots from my testing:

And here is the result from other Jetson users that I found online:

Thank you for your assistance!

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

The issue you’re experiencing with the PPS (Pulse Per Second) cycle being 1024ms instead of the expected 1000ms on the Jetson AGX Orin platform is intriguing and warrants a detailed examination. To address your question comprehensively, let’s break down the key points and compare them where necessary.

1. Understanding PPS: The PPS signal is a critical component in systems requiring precise timing, such as GPS and other time-sensitive applications. It is expected to pulse once per second, hence the name.

2. Observed Behavior: You’ve observed a PPS cycle of 1024ms, which deviates from the expected 1000ms (1 second). This discrepancy suggests there might be a timing or synchronization issue within the system.

3. Comparison with Other Jetson Users: Your research indicates that other users of Jetson modules have also reported similar issues with the PPS cycle being 1024ms. This suggests that the behavior might not be specific to your setup or the Jetson AGX Orin platform alone but could be a more widespread issue affecting Jetson modules in general.

4. Jetson Platform Considerations: The Jetson platform, including the Jetson AGX Orin, is designed for high-performance computing and AI applications. While it’s capable of handling complex tasks, timing discrepancies like the one you’ve encountered can be critical in applications requiring precise synchronization, such as GPS navigation.

5. Possible Causes: There could be several reasons for this discrepancy, including but not limited to:

   • Hardware Limitations: The hardware might have limitations or quirks that affect the PPS signal generation or reception.
   • Software or Firmware Issues: The issue could stem from the software or firmware controlling the PPS signal, possibly due to a bug or an incorrect configuration.
   • System Clock Synchronization: The system clock and the PPS signal might not be perfectly synchronized, leading to the observed discrepancy.

6. Comparison with Other Platforms: While the question focuses on the Jetson platform, it’s worth noting that timing discrepancies can occur on various platforms, not just those from NVIDIA. However, the specific issue of a 1024ms PPS cycle seems to be reported more frequently among Jetson users, suggesting there might be a platform-specific aspect to this problem.

7. Resolution Approaches: To resolve this issue, you might consider:

   • Checking Documentation and Forums: Look for any official documentation or community forums where similar issues have been discussed and possibly resolved.
   • Updating Software/Firmware: Ensure that all software and firmware are up to date, as updates might address known timing issues.
   • Directly Contacting NVIDIA Support: Given the specificity of the issue and its potential impact on applications requiring precise timing, contacting NVIDIA’s support directly might provide the most straightforward path to a resolution.

In conclusion, while the exact cause of the 1024ms PPS cycle on the Jetson AGX Orin (and possibly other Jetson modules) is not immediately clear from the provided information, it appears to be a behavior that has been observed by multiple users. This suggests that there could be a common underlying cause, potentially related to the platform’s hardware, software, or how the PPS signal is handled. Further investigation, potentially involving direct communication with NVIDIA’s support team, would be necessary to determine the root cause and find a suitable resolution.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[JerryChang]

hello RUGE,

FYI,
there’re two operating modes, (1) GPIO mode, and (2) Timer mode for NvPPS.
please check the evt_mode for confirmation,
for instance,

/* evt_mode */
NVPPS_MODE_GPIO: PPS time events are triggered by the 1PPS signal connected to the AON GPIO pin
NVPPS_MODE_TIMER: events are triggered by a periodical timer every second

[RUGE]

Hello,

I have performed some troubleshooting on this issue. First, I checked if the PPS signal cycle was incorrect. To do this, I modified the pps-gpio driver to print the timestamp in dmesg each time a hardware interrupt occurs. This helped me observe the PPS hardware interrupt cycle.

Here’s the modified code:

# Linux_for_Tegra/source/public/kernel/kernel-5.10/drivers/pps/clients/pps-gpio.c
static irqreturn_t pps_gpio_irq_handler(int irq, void *data)
{
	const struct pps_gpio_device_data *info;
	struct pps_event_time ts;
	int rising_edge;

	/* Get the time stamp first */
	pps_get_ts(&ts);

	info = data;

	rising_edge = gpiod_get_value(info->gpio_pin);
	if ((rising_edge && !info->assert_falling_edge) ||
			(!rising_edge && info->assert_falling_edge))
		pps_event(info->pps, &ts, PPS_CAPTUREASSERT, data);
	else if (info->capture_clear &&
			((rising_edge && info->assert_falling_edge) ||
			(!rising_edge && !info->assert_falling_edge)))
		pps_event(info->pps, &ts, PPS_CAPTURECLEAR, data);
+ printk("pps irq +1\n");
	return IRQ_HANDLED;
}

After reloading the driver, I noticed that the cycle printed in dmesg was 1000ms:

nvidia@adu550:~$ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1753695194.352839958, sequence: 335 - clear  0.000000000, sequence: 0
source 0 - assert 1753695195.376838582, sequence: 336 - clear  0.000000000, sequence: 0
source 0 - assert 1753695196.400839670, sequence: 337 - clear  0.000000000, sequence: 0
source 0 - assert 1753695197.424838773, sequence: 338 - clear  0.000000000, sequence: 0
source 0 - assert 1753695198.448839957, sequence: 339 - clear  0.000000000, sequence: 0
source 0 - assert 1753695199.472839092, sequence: 340 - clear  0.000000000, sequence: 0
source 0 - assert 1753695200.496838036, sequence: 341 - clear  0.000000000, sequence: 0
source 0 - assert 1753695201.520839444, sequence: 342 - clear  0.000000000, sequence: 0
source 0 - assert 1753695202.544839187, sequence: 343 - clear  0.000000000, sequence: 0
source 0 - assert 1753695203.568838963, sequence: 344 - clear  0.000000000, sequence: 0
^C
nvidia@adu550:~$ sudo dmesg | grep pps
[    1.418105] pps_core: LinuxPPS API ver. 1 registered
[    1.423070] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    3.988032] pps pps0: new PPS source ktimer
[    3.992330] pps pps0: ktimer PPS source registered
[    3.997245] pps_ldisc: PPS line discipline registered
[  194.505433] pps pps1: new PPS source pps.-1
[  194.505486] pps pps1: Registered IRQ 303 as PPS source
[  194.691572] pps irq +1
[  195.690955] pps irq +1
[  196.690829] pps irq +1
[  197.691202] pps irq +1
[  198.691386] pps irq +1
[  199.691225] pps irq +1
[  200.691217] pps irq +1
[  201.691155] pps irq +1

It appears that the issue lies with the pps_get_ts(&ts); function, which is returning a system Unix timestamp that is incorrect. This suggests that my system clock might be adding 1024 milliseconds every second, rather than the expected 1000 milliseconds.

Could you confirm if this is the case?

Thank you!

[RUGE]

I found that the system automatically created another PPS device. Although my GNSS signal from the INS ($GPRMC GPS NMEA) is indeed received from /dev/ttyTHS4, I didn’t make any other configurations. How did the system create a PPS signal through /dev/ttyTHS4 on its own?

Here’s the relevant part from the dmesg output:

nvidia@adu550:~$ sudo dmesg | grep pps
[    1.419729] pps_core: LinuxPPS API ver. 1 registered
[    1.424691] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti giometti@linux.it
[    3.998856] pps pps0: new PPS source ktimer
[    4.003159] pps pps0: ktimer PPS source registered
[    4.008077] pps_ldisc: PPS line discipline registered
[    4.013328] pps-gpio pps: failed to request PPS GPIO
[    4.018417] pps-gpio: probe of pps failed with error -22
[   20.798692] pps pps1: new PPS source tegra_hsuart4
[   20.798723] pps pps1: source "/dev/ttyTHS4" added

Could you help explain how this happened?

[RUGE]

I found the issue. I noticed that dmesg shows the pps-gpio driver was loaded 4 seconds after the kernel started, and it reported an error -22 indicating a failure to get the GPIO. I suspect this might be due to the GPIO driver not being loaded yet. So, I compiled the pps-gpio module as a kernel module (.ko) and manually loaded it using insmod after the system boot. It is now working correctly.

[  194.505433] pps pps1: new PPS source pps.-1
[  194.505486] pps pps1: Registered IRQ 303 as PPS source

The first PPS source in the system is based on ktimer, with a cycle of 1024ms. The cause of this is still unclear to me.

[    3.988032] pps pps0: new PPS source ktimer
[    3.992330] pps pps0: ktimer PPS source registered

The PPS bound to /dev/ttyTHS4 is generated by gpsd. You can verify this by checking the logs:

[   20.798692] pps pps1: new PPS source tegra_hsuart4
[   20.798723] pps pps1: source "/dev/ttyTHS4" added