We are using the Quectel GNSS module Quectel L26-T, firmware version L26TNR01A06V02, and periodically sending the command:
$PSTMPPS,1,7
We noticed that sometimes the module does not return any response to this command. In most cases, the response is received correctly, but occasionally there is no reply at all.
Could you please clarify:
Under which conditions can the module ignore or not respond to PSTMPPS,1,7?
Are there any timing limitations or recommended delays between consecutive PSTMPPS commands?
Could UART buffering or internal task scheduling affect the response generation?
We would appreciate any information about possible reasons for missing responses.
Here are the detailed answers to your questions regarding intermittent responses to the $PSTMPPS,1,7 command.
1. Conditions Under Which the Module May Not Respond
There are several operational states and conditions where the L26-T will ignore or fail to transmit a response to an incoming command:
Low Power Modes (Backup/Standby): If the module has entered Backup mode , its communication ports become completely unresponsive to incoming commands, and no data is transmitted over them. Similarly, in Standby mode , the module operates at minimal power to maintain RTC and RAM, and it typically will not process standard NMEA or PSTM queries until it is awoken (e.g., via the WAKEUP pin).
Data Congestion and Buffer Overflows: The L26-T does not support hardware flow control . If the module is outputting a high volume of data (such as high-frequency 10 Hz or 15 Hz navigation solutions) and the host is not reading the UART fast enough, the internal transmit buffers can fill up. This leads to data loss , where the response message is generated by the GNSS engine but is dropped at the UART driver level because there is no space in the buffer.
Failed Firmware Handshaking: If the module has recently experienced a failed firmware upgrade, it may be stuck in a bootloader or recovery state where standard PSTM commands are not recognized.
2. Timing Limitations and Recommended Delays
While the specific $PSTMPPS synopsis does not list a mandatory delay, Quectel documentation for similar chipset-level commands suggests the following:
Inter-Command Delay: For consecutive commands sent to the GNSS engine, there should be at least a 20-millisecond delay between the end of one command and the start of the next. Rapid-fire polling can sometimes exceed the module’s ability to parse and schedule responses.
Message Processing Time: Status polling commands like $PSTMPPS,1,7 (which queries PPS pulse data) are generally handled as background tasks. It is recommended to maintain a polling interval of at least 100–500 ms for general status checks to avoid interrupting higher-priority navigation tasks.
3. UART Buffering and Internal Task Scheduling
UART behavior and task prioritization are the most likely causes for “occasional” missing responses:
Baud Rate Sensitivity: If the module is configured for a high update rate (e.g., 5 Hz or above) but the baud rate is set low (e.g., below 460800 bps), the UART interface can become a bottleneck. Documentation explicitly warns that messages may be lost under these conditions because the volume of data exceeds the transmission bandwidth.
Task Prioritization: The GNSS engine’s primary task is signal tracking and navigation solution calculation. If the CPU usage is high (which can be monitored via the $PSTMCPU message), the command-parsing task may be delayed or preempted.
Scheduling Latency: Because the module uses a string-based NMEA/PSTM parser, if a command is sent while the module is in the middle of transmitting a large block of GSV or standard navigation data, the UART receiver may experience a synchronization gap if there is significant bus noise, causing it to fail to recognize the $PSTMPPS header.
Recommendations for Debugging
Monitor CPU Load: Check the $PSTMCPU output to ensure the module is not being overwhelmed by high fix rates or too many enabled constellations.
Increase Baud Rate: Ensure you are using 115200 bps (the default) or higher (up to 921600 bps ) to provide adequate bandwidth for both navigation data and command responses.
Check Power Status: Verify that the WAKEUP pin or software control hasn’t accidentally put the module into a low-power state.
Add Delay: Implement a 20 ms minimum delay between sending consecutive commands to ensure the parser is ready.