RomRaider

Neat ! I'd definitely keep P4 at 0, but I wouldn't go much below 5ms for P3, although in my experience the ECU just pipes that data right through with 0ms interbyte, as it should be. 30 queries/sec is decent I think for that case - anyway the 1kB/s link saturates pretty fast.

I've updated most of the scalings https://docs.google.com/spreadsheets/d/ ... sp=sharing

I believe sending break condition on the k-line will stop the ECU from transmitting. I'm not sure how to do that using J2534 though.

Good point. In that case why not just a fastinit ioctl ? The few extra 100ms for the full init shouldn't matter since that only happen when the user stops logging ?

Most probably sending any data from logger\scanner will be a break condition.
Subaru Denso\Subaru Hitachi ecu stops sending logging data while k-line collision takes place.

Yes with SSM I can clear the line by sending to the ECU causing a data collision, this is not working for me with the Nissan ECU.
Fast init doesn't do it.
Sending a full packet of zeros doesn't stop it nor does a packet with all 0xFF.
Setting baud to 5 and sending zeros doesn't work.
I can momentarily ground the k-line and comms is restored. Hence my wish to send a break signal. Probably easier to do with a dumb serial interface cable, but there's no option to IOCTL a break signal in J2534.

Strange. Do you know what the traffic looks like on the bus ? does the J2534 hardware wait for a gap to insert its fastinit or does it just clobber whatever's happening ? And if you sent a regular message like maybe TesterPresent (3E), would it be transmitted in a window between two replies ?

Zero at 5 bps is really long enough to simulate break at any reasonable communication baud rate.
May it be that J2534 ignores your request till k-line activity stops by it's own way ?
Then dumb k-line will be the only solution.

I'll have to trace the K-line to see if there's any attempt to send my J2534 command.
I'm not sure if the J2534 hardware waits for a quiet bus before sending. I would think not as with the SSM protocol I can TX a command and it stops the ECU from sending.
I have not tried a TesterPresent command yet.

I may have this sorted out. The comment about sending between ECU messages got me thinking.
J2534 write will try to send and confirm that the write took place.
Then there's the ISO14230 P2 + P3 timers to account for. So I fiddled a bit and found that a J2534 non-blocking write with a WAIT_P3_MIN_ONLY write flag set will stop the ECU from sending, but only if P3_MIN is under 3msecs.

This is a bit of logging overkill...
My Mongoose J2534 cable can't keep up, it complains about RX buffer overruns. Tactrix OP2 seems to handle it.

hahahaha not too shabby for a lousy 10.4kbps link ! I'm surprised any decent J2534 cable can't keep up... that's really not crazy throughput, compared to CAN...

I think we are getting close to a beta release.
We still need some refinement to the logging parameters, but that's not code related.
Here, we are logging both parameters and switches. A total response length of ~35 bytes with a pretty decent response rate. This is about the most items you can log before hitting the K-line max packet size (including loopback data).

BTW: is there a command that will reset the ECU clearing all learned adaptions in the process?

Awesome! Ready to test out the beta when it's ready.