Feature Request ADX "listen for silence" with invert data line option

[Duckmang]

After getting past the hurdles of getting a cable to communicate with my ecu I have a new issue. My ecu initialization protocol involves holding the data line low for approx 100 milliseconds. I was hopeful that lowering the baud rate really low would allow me to send a byte to drive the line low for long enough. What I have found though is that lowering the baud rate lower than a few hundred baud doesn't work and I can only get a few ms driving the line low with this method. There is also a stop bit at the end that may cause issues, putting another nail in this method's coffin.

A command similar to the "listen for silence" command with the option to drive the data line low would be a life saver.

[Duckmang]

I had a "thinking in reverse" epiphany. I can't send a byte really slow to get the data line low for 100 ms but what if I raise the baud really high and send it a whole bunch of times. The stop bits will likely just be a bit of noise with the line appearing low over the duration. Fingers crossed this works.

[Chatchai]

I ran into the exact same challenge when working on an ADX file for a Honda motorcycle ECU using a non-standard K-Line protocol based on 10400 baud (manufacturer-specific protocol). I tried lowering the baud rate and sending 0x00 at 184 baud to pull the line low, combined with a "Listen for Silence" expecting 65~74ms low for the break condition in init sequence — but no luck. I ran into the same limitation you did: UART just won’t hold the line low due to the stop bit.

I solved this by using an Arduino to directly control the signal lines via the Tx pins connected to the LM339 or L9637 inside a KKL-VAG cable, and wrote custom init sequence code to handle it.

Glad to see you figuring this out too! If you're building your own ADX project and experimenting with init timing, you're definitely on the right track.
Good luck and keep us updated!

[Duckmang]

Thanks for the input. I've been trying my best to not have to program an Arduino to make this work. It seems awfully damned determined that's what it'll take. Are there any pitfalls you navigated that are worth noting?

[Chatchai]

Actually in my case, I didn’t run into any issues. Once I got the first init sequence done manually with the Arduino, everything worked perfectly. After that, I handed over control to the ADX file, which handled the data streaming just fine.

The transition between Arduino and ADX (via UART) was seamless - no glitches or timing problems. So if you're able to get through the init cleanly, the rest should go smoothly too!

[Chatchai]

I am currently learning to develop a plugin for TunerPro RT to handle specific first initialization sequences by directly controlling the FTDI USB device through its driver, referencing examples from the TunerPro SDK.
The main purpose of this plugin is to perform the first init sequence accurately and reliably, as controlling the line states (pull-up, pull-down) through standard UART communication alone via the ADX Editor or connection command in ADX file cannot achieve sufficient results.
Regarding the TunerPro SDK, I’m not sure if calling this a ‘scope document or API’ for plugin development is necessary, as I’m still new to the process of writing code in C++ and compiling with Visual Studio.

[Duckmang]

That sounds like a great project that will benefit a lot of people. I'd offer to help but my C+ programming skills don't go much further than programming an Arduino. Assembler is more my speed. I'd be in as a beta tester.

[lucassinner]

Hi Duckmang, when your ECU expects the data line to be held low for ~100ms, is this strictly a passive wait, or does it require the interface to actively drive the line low?

[Duckmang]

The ECU is expecting the line to be driven low for 100ms.

I've been trying to use an Arduino Mega2560 as a multiplexer between the ECU and PC. It's been kicking my ass. I finally got code written to send my 244 bytes of initialization sequence along with the special timings between certain bytes. Once I got it working the ECU was only sending error bytes and not my live values. Studying the logic analyzer, I noticed that the ECU is actually communicating in 8 bit serial asynchronous without parity or a stop bit. I never could get the logic analyzer to land on a setting that didn't have any parity or framing errors and I finally figured out that is why. It's looking like Imay just end up brute forcing the initialization doing manual manipulation of the tx pin instead of actual serial communication.