Skip to content

Fix: STN (OBDLink SX/EX) KWP Session Drops & Implement Software Keep-Alive#35

Open
RK392 wants to merge 3 commits into
mattiasclaesson:masterfrom
RK392:master
Open

Fix: STN (OBDLink SX/EX) KWP Session Drops & Implement Software Keep-Alive#35
RK392 wants to merge 3 commits into
mattiasclaesson:masterfrom
RK392:master

Conversation

@RK392

@RK392 RK392 commented Jun 10, 2026

Copy link
Copy Markdown

Problem:
When using STN-based adapters (specifically the OBDLink SX and OBDLink EX), users frequently experience KWP session drops and "NO DATA" communication timeouts in T7Suite and TrionicCANFlasher when the application idles. This occurs because the software keep-alive timer was previously left uninitialized, and the adapter initialization sequence did not properly permit the 8-byte keep-alive payloads to pass through.

Changes in this PR:

  1. Properly Initialized Software Keep-Alive: The stateTimer inside KWPHandler.cs is now correctly instantiated upon startSession(). This ensures that a 0x3E (TesterPresent) keep-alive packet is automatically broadcast to the ECU whenever the application idles for more than 1000ms, preventing the ECU from closing the diagnostic session.
  2. STN Configuration Fix (ATAL): Added the ATAL (Allow Long >7 byte Messages) command during the adapter initialization. This is a critical fix for OBDLink SX/EX adapters, allowing them to bypass ATSP6 ISO-TP limits and successfully transmit the 8-byte keep-alive payload.
  3. Centralized Session Recovery: Improved error handling in KWPHandler to elegantly handle connection hiccups. KWPSessionDroppedException is now caught directly within the sendRequest pipeline, allowing the software to automatically recover the session and re-send the failed message seamlessly without crashing the active process.
  4. Response Parsing Adjustments: Modified the waitMessage terminator check from OK\r\r> to > and refined the 8-byte capability check. This prevents false timeouts, as STN adapters often format their serial terminators slightly differently than generic ELM clones.

Impact:
These changes drastically improve connection stability for OBDLink users during live reading, parameter editing, and flashing, fully resolving the issue where users previously had to restart the software to regain connection to the ECU.

@roffe

roffe commented Jun 11, 2026

Copy link
Copy Markdown

Just some notes:

  1. Session timeout in trionic 7 is 10 seconds
  2. ATAL is not needed afaik, i don't use it in txlogger or gocan, TesterPresent is a 4 byte message not 8. [0x40, 0xA1, 0x01, 0x3E]

Did you use chatgpt for this?

@RK392 RK392 force-pushed the master branch 2 times, most recently from 2912365 to b885877 Compare June 11, 2026 08:58
@RK392

RK392 commented Jun 11, 2026

Copy link
Copy Markdown
Author

Just some notes:

  1. Session timeout in trionic 7 is 10 seconds
  2. ATAL is not needed afaik, i don't use it in txlogger or gocan, TesterPresent is a 4 byte message not 8. [0x40, 0xA1, 0x01, 0x3E]

Did you use chatgpt for this?

Hi Roffe, thank you for the insightful feedback!

  1. Session Timeout: I actually didn't alter the original 1000ms keep-alive interval in KWPHandler.cs. I had no idea that the session timeout in trionic 7 was 10 seconds. I just pushed a follow-up commit to my pull request that bumps the keepAliveTimeout from 1000ms to 5000ms. This will reduce unnecessary bus traffic and avoid conflicting with other polling functions.

  2. TesterPresent & ATAL: You are correct that TesterPresent is logically a 4-byte message. While the keep-alive packet (result = sendRequest(new KWPRequest(0x3E), out reply);) isn't explicitly hardcoded to 8 bytes on that specific line, TrionicCANLib typically pads KWP requests into 8-byte CAN frames in KWPCANDevice (CANMessage msg = new CANMessage(0x240, 0, 8);). I originally injected the ATAL (Allow Long) command because I was trying to use the STPPMA command to offload the keep-alive entirely to the OBDLink STN hardware. That experiment didn't work out, but I kept ATAL in the initialization block because it ensures that supports8ByteResponse correctly evaluates to true on STN chips, preventing the adapter from falling back into the sluggish legacy ELM clone compatibility mode. Does that sound right to you?

And yes, I used the Antigravity IDE to help me navigate the codebase, write the fixes, and test them! Thanks again for taking the time to review it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants