Troubleshooting: Missing Multi-Frame Responses (Dropped Frames)

If you are querying a PID that returns a large, multi-frame response and notice that frames are frequently dropping or missing, the ECU might be sending the data faster than the WiCAN buffer can process it.

The Cause

By default, ELM327-based devices (including WiCAN) send 30 00 00 as the Flow Control (FC) frame. This dictates how the ECU should transmit the data:

• 30 = Continue to Send (CTS)
• 00 = Block Size 0 (Send all frames without stopping)
• 00 = STmin 0 (Send as fast as possible)

Because of that final 00, the ECU blasts all frames with zero delay. If the vehicle network is busy or the response is massive, the WiCAN's buffer might not keep up.

The Fix: Set STmin in the Flow Control Frame

To fix this, you can customize the Flow Control data the WiCAN sends to force the ECU to add a small delay between each frame.

Run the following AT commands before sending your PID query to manually set the STmin (Separation Time minimum):

ATFCSH 7E8       # Set the header to the CAN ID the ECU replies on (e.g., 7E8)
ATFCSD 30 00 19  # Set FC frame to: CTS, BS=0, STmin=25ms (0x19)
ATFCSM 1         # Force WiCAN to use this custom FC instead of the default

STmin Milliseconds Reference

Any hex value from 0x01 to 0x7F directly translates to that many milliseconds of delay. Start with a smaller delay like 25ms (0x19) and increase it if frames are still dropping.