GPS PPS support for timing applications?

[jstockdale]

What features or library support or other would you like to add?

I see that the L76K has a 1PPS output on pin 4 but it seems like a decision was made not to connect it?

Can I request that the next revision of the T-Display-P4 hardware connect the 1PPS output to any interrupt capable GPIO pin?

If a spare GPIO pin is not available, It could even steal/share one of the GPIO pins from the bottom external connector as having PPS easily available would benefit lots of use cases.

Thanks!

Additional context.

No response

[Llgok]

@jstockdale
Hello, I have communicated your requirements to the hardware engineer. He will consider connecting the PPS pin of the GPS (L76K) to the XL9535 in the next version (interchanging it with the interrupt pin of the power chip). Could you please check if connecting it to the XL9535 meets your needs?

[lyusupov]

duplicates #2

@Llgok

if connecting it to the XL9535 meets your needs?

SD_PWEN signal is redundant in current design.
Switch power ON and supply DC current for micro-SD card can be achieved by ESP32-P4 LDO4 as Espressif P4 Dev. Kit Reference Design does.

SD_PWEN signal can be freed and re-used for some other purpose.

[Llgok]

@lyusupov
In the Espressif P4 development kit reference design, the SD_PWEN pin is also used (as shown in the figure below). The specific reason is that the ESP_LDO_VO4 power supply cannot be actively turned off, so a switch is set up.

[jstockdale]

@jstockdale Hello, I have communicated your requirements to the hardware engineer. He will consider connecting the PPS pin of the GPS (L76K) to the XL9535 in the next version (interchanging it with the interrupt pin of the power chip). Could you please check if connecting it to the XL9535 meets your needs?

Hi! Thanks so much for your reply. I appreciate the consideration of this enhancement.

Ideally the GPS PPS would be directly connected to an ISR capable pin on the ESP32-P4. I would like to use this for timing applications where it's very important to minimize jitter and latency.

I would examine whether it is possible to move the GPS_WAKE_UP line to the XL9535, and directly connect the GPS PPS line to an ISR capable GPIO pin.

Thanks again!

[lyusupov]

@jstockdale

Your binary
https://github.com/jstockdale/T-Display-P4/tree/adsb/firmware/jstockdale-adsb_receiver
is quite usable

• Q. Why is WiFi not working?
• A. ESP-Hosted SDIO DMA on the ESP32-P4 corrupts internal RAM heap metadata. This is tracked in Espressif Issue #17889. WiFi components are commented out in idf_component.yml. The planned fix is to flash the ESP32-C6 with AT firmware for synchronous WiFi.

Issue espressif/esp-idf#17889 says that "SDMMC + ESP-Hosted via SDIO do not work together".
When access to ESP32-P4 micro-SD card is performed by SPI (not SDIO MMC) - no conflict with ESP-HOSTED Wi-Fi was noticed.

[jstockdale]

Thanks! I'm really pleased you like it!!

I just improved it with OLED model support. And also, have implemented runtime detection of the TFT vs AMOLED panel ... so that one unified firmware build supports both devices.

https://github.com/jstockdale/T-Display-P4/tree/adsb

Best regards,
John

[lyusupov]

@Llgok

The specific reason is that the ESP_LDO_VO4 power supply cannot be actively turned off, so a switch is set up.

MIN voltage for any of ESP32-P4 LDOs is 500 mV
https://github.com/espressif/esp-idf/blob/master/components/esp_hal_pmu/esp32p4/include/hal/ldo_ll.h#L28

500 mV is well below the operational limits that any SD card can work on.
Thus, a setting of ESP_LDO4 to 500 mV will effectively cut SD card power and associated current off.

The T-Display P4 deep sleep current is reported as high as 1.2 mA
https://github.com/Xinyuan-LilyGO/T-Display-P4/blob/main/relevant_test/PowerConsumptionTestLog_%5BT-Display-P4_V1.0%5D_20250605.pdf
This means that SD card power consumption @ 500 mV is likely not a first priority factor that needs an improvement.

[Llgok]

@jstockdale @lyusupov
Then I will change the GPIO5 pin of the ESP32P4 from the original XL9535 interrupt to the GPS PPS pin (remove the XL9535 interrupt). Do you think this modification is acceptable on your end? All pins of the ESP32P4 can be used for external GPIO interrupt triggering.

[jstockdale]

@jstockdale @lyusupov Then I will change the GPIO5 pin of the ESP32P4 from the original XL9535 interrupt to the GPS PPS pin (remove the XL9535 interrupt). Do you think this modification is acceptable on your end? All pins of the ESP32P4 can be used for external GPIO interrupt triggering.

Hi @lyusupov! :-)

Thank you so much. I reviewed the XL9535 datasheet in depth and before we decide for sure, let's confirm that my understanding of it's operation is correct.

The XL9535 gpio bus expander gives us one ALL_INT combined interrupt that goes high whenever the data on any of the inputs has changed from the last acknowledged state. The MCU has to service the interrupt by reading the correct register over the I2C bus and then either ACK or NACK the read response.

So it sounds to me like running the PPS signal through the XL9535 will add a lot of delay and jitter to the PPS timing signal as the ESP32-P4 would need to (1) Service the ISR, (2) Read the XL9535 port change register or gpio input status over I2C, (3) Wait for the response, (4) Synchronize a counter or clock

I think your suggestion is actually very astute. Because the PPS line is timing critical while the rest of the GPIOs we have are not. Since the I2C bus is available, it's very easy and not resource intensive to poll the XL9535 for updates over I2C. Since we have to read the changed port over I2C anyway the main thing we'd lose by disconnecting ALL_INT is the ability to wake up from deep sleep based on a signal connected to the XL9535. But that said. I don't see any way to mask which inputs cause interrupts. It seems like any input change causes ALL_INT to go high. So that's not terribly useful anyway.

So!! After some thought and scrutinizing of the relevant datasheets, YES, I think your suggestion to remove the XL9535 interrupt and replace it with the GPS PPS signal, routed to the GPIO5 pin of the ESP32P4, would be an excellent solution. I think this change will make the T-Display-P4 capable of a multitude of timing sensitive applications.

I am very excited to try that out asap. When you are to the point of having engineering samples of the new revision please keep me in mind for testing.

Thank you again!

Best,
John

[lyusupov]

@Llgok

Then I will change the GPIO5 pin of the ESP32P4 from the original XL9535 interrupt to the GPS PPS pin (remove the XL9535 interrupt). Do you think this modification is acceptable on your end?

This does not look for me as a great idea...
You are going to sacrifice 4 important interrupt sources in "favor" of one GNSS PPS only

My opinion is to look at a block of spare P4 GPIOs available @ CON 2.54-2x8

Likely some of them are in use when the T-Display P4 is connected to the keyboard.
GNSS PPS uses an active HIGH pulses once per second.
It makes sense to inspect if the GNSS PPS function can be shared (by a diode connection) with some other INPUT P4 GPIO pin @ CON 2.54-2x8

[jstockdale]

@lyusupov I first want to reiterate that since you have to read the I2C bus to distinguish which of these 4 interrupts have fired, and the wake-from-sleep use case (which you would lose) is hard to imagine working since any other input changes trigger ALL_INT too (ie. you can't mask the interrupt ports). So it's an incredibly noisy interrupt to use. Right?

If you are in any runlevel that you can perform a polling loop, it's going to usually be acceptable to poll for these interrupts from the XL9535 over the I2C bus. No? And in my opinion, none of these interrupt sources are as useful as a high quality time source to discipline the internal clock.

Anyway. That said, I think @Llgok mentioned all the GPIO on the P4 are capable of triggering interrupts. So any of these suggested solutions are equally acceptable to me. I'm down for whatever makes the device most useful. I just need the PPS wired to one of the P4 GPIOs.

If the required trace is easily routable / should be good signal quality, and we can ensure sufficient drive current for the external gpio pin (so the pps can be shared if desired without affecting the signal integrity of the interrupt), then wiring the GPS PPS to one of the EXTEN_GPIOXX pins seems like a perfectly acceptable solution.

Honestly there's a lot of times you'd want to break PPS out of the device to use for projects.

Thanks for the constructive conversation everyone!

[Llgok]

@jstockdale
Unfortunately, I am unable to connect the GPS PPS to one of the EXTEN_GPIOXX pins on my end, because we have already conducted preliminary tests on the new product's physical keyboard, which uses the EXTEN_GPIOXX pins, and all of them are already in use. You cannot even change the arrangement order among them.

[Llgok]

@jstockdale @lyusupov
This is indeed a difficult decision. I have reviewed the schematic again; the SD card can be powered off using the Low_3V3 power supply, which would free up SD_PWEN. Changing SD_PWEN (which independently controls the SD_PWEN power) to GPS_PPS (with the SD_PWEN power now controlled by the Low_3V3 power supply) seems to be a better solution at the moment. What do you think?