RomRaider

Hello all!

With the recent discovery that K-Line based ECU's probably aren't going to support any form of CAN-BUS logging outside of reading the raw bus data, I decided I wanted to make a separate post to have some discussion over K-line logging. To begin, K-line logging is s*** compared to CAN-Logging. Like, they're not even close. But it seems like we're gonna have to make do with what we have, unless somehow CAN-logging could still be possible via some currently untested method. But even if that does occur, it would still be nice to have ways to improve K-line logging to the best of our abilities. As I don't know much about communication logic, most of what I'm going to say is probably extremely idiotic. So bear with me

Currently, here are a few possible ways to improve K-line logging. Using a mixture of the following (IFFF possible) would be the goal.

- CID Hacking. Replacing CID RAM addresses with predetermined RAM parameters based off your logger profile. The only real use for this is if you have a preset list of RAM parameters that you know for certain you're going to be datalogging. To follow up with CID hacking, is it possible to have ONE CID request return an entire set of RAM parameters? Since for CID hacking to work as intended, you'd already have to be using a preset list of RAM parameters. So would you be able to have it request CID #X, then have it output an entire set of RAM parameters? This would save tons of space I'd presume, but I'm not sure if it works like that or not.

- Using "Broadcast Parameters", aka, reading the raw CAN-bus. This would probably not be something universal. So not much real potential here for the general public, but definitely the main thing for those who want to dive into optimal logging. This would allow you to datalog the core parameters (RPM, coolant temperature, IAT, MAF V, APS V, etc) without adding to the K-line packet size. Is it possible to sniff CAN-bus while datalogging K-line? No clue! But just something that would be great if it works.

- Creating Custom RAM Parameters. Currently, there are tons of RAM parameters required for many of my calculations. I datalog all the necessary parameters, then use MegaLogViewerHD to calculate everything needed + for me to personally analyze the data. Technically, we could incorporate some of those calculations within the ECU itself. While this would be a very niche thing, it would at least allow more space for other RAM parameters.

If anyone has anything to add, correct, or so forth, feel free to share!

My presumption is that many ECUs that have K-Line diag only may already have the code for CAN diag but just need it enabled via a switch/flag in the ROM.

What’s odd is the wiring diagrams for 06 and 07 in regards to the ECU -> OBD2 port are practically identical. Technically K-line is still connected for 07 Z’s. But obviously dumping and flashing got moved to CAN. But I wonder… Even if K-line ECU’s don’t have the proper code, couldn’t we just add the required code to these ECU’s? There’s plenty of space at the end of most SH7058 ROM’s, so I don’t see why you wouldn’t be able to just patch in CAN logging, as the CAN lines are already hooked up and would work the same as CAN-based ECU’s probably.

No need to hack anything, RR already supports RAM parameters, set a list of params, and then request the results of the param list. The limitation is the k-line bus speed.

For CAN, first you need to know each CAN ID on the bus and the params each contains. Then you need to know the scaling. With this info, a CAN listen mode can be added to RR to Logger the params.

FYI, Subaru tuners have successfully tuning for years with a k-line speed of only 4800 baud. You should be very happy with more than double that, which Nissan supports. Just don't be greedy, log only with is necessary. Be focused and purposeful in your tuning goal each step of the way.

Are you sure? For what I know, ssm init is done with 4800 baud, but kernel upload and flashing is done with much higher speed.

Edit: with ecuflash

Hmm. So are you saying that there's little space to gain from patching RAM parameters into CID spots? That's definitely what it sounds like at least. But if there's little to save in terms of our request size (since you request the result of the list), then there really isn't much to look into in terms of CID hacking.


I'll have to do some personal testing with this. But as long as RomRaider Logger can handle it in the future, that's all that really matters Especially because finding the basic parameters will be a breeze. RPM, APS V, TPS V, MAF V, etc all will be a breeze to find and figure out proper scalings by comparing the bus data to their actual RAM parameter data. I definitely feel like this will be the best route, as it basically takes the CID parameters to the next level. Increasing accuracy, while also increasing logging space for the K-line parameters that wouldn't necessarily benefit from any sort of increase in logging speeds.


Don't get me wrong, K-line is more than fast enough for proper tuning. But as I'm starting to become a data freak, the more data I can gather, the better. It allows for more custom filters, custom calculations, etc. Given how I only tune my personal vehicle, I can afford to spend as much (or as little!) time on all this as I want. But you're definitely not wrong that you can properly tune a vehicle through JUST K-line logging. Hell, all K-line Z/G's are tuned exclusively off K-line logs I suppose haha

Quite the opposite, broadcast parameters are universal. In fact the same broadcast parameter for wheel speed for a 2003 350z is exactly the same as on a 2019 Titan. It shouldn't matter what ROM you have, they should be shared between everything.

The bus doesn't shut down when you send it a request, that's the point of the bus to begin with. So you should be able to sniff the bus while k-line logging at the same time.

Huh. Well, that's extremely convenient then haha So it could be setup similarly to CID's, except minus any check for compatibility. Guess the next step is to start on figuring out CAN ID's haha

Edit;
Anyone have some good recommendations for a CAN sniffer? OpenPort 2, K+CAN, or even ELM327 would work for the cables. I just currently don't have a good way to sniff the bus due to my inexperience lol

That's excellent. Do you know where we might find this info? It would save a lot of trial-and-error with CAN sniffing. I've got a few people wanting to run a Link G4X ECU which has fully customisable CAN but I need to get the CAN IDs to work with the gauge cluster first.

This looks handy

https://www.dropbox.com/s/cfpzb2mpj42q6 ... 20CAN.xlsx

Logging for tuning and Flashing are two different things! Yes I'm sure, very sure.

So here's where things don't make much sense. RR logger is maxing at three 32-bit RAM address parameters. Which is, 12 bytes. K-line packet size is 255 bytes, and even the smallest limit is a massive 64 bytes or so. So clearly there IS room to improve, as we should at MINIMUM be able to datalog ~16 32-bit RAM parameters. Not with stock code, but with custom code for certain. I honestly think setting up a custom SID to report predetermined RAM parameters would make the most sense.

Example;
$FF 0x01 = Return values for A, B, C, D, E, F, G, H..... (Would require the parameters to be defined within the code already, rather than being able to select RAM parameters freely) Hell, even just properly implementing $23 might be enough. Given how I'm not aware of how $23 works compared to $A3, I can't say whether that one is a viable option or not. But having a preset array would work flawlessly for certain. (Unless there's something I'm missing here )

As I recall the limit isn't the amount of data being logged, but rather how many bytes it takes to *specify* all that data.
SID AC requires 5 bytes to describe each logged byte : 1 for field_type, 4 for the full address. Plus headers and checksum, you can describe a max of 12 bytes with a 63-byte frame size. See nisprog code np_cli.c: dump_fast() .
I don't think I ever managed to use full iso14230 headers to benefit from 255-byte frames but maybe it can be done.

I believe RR can mix and match field_types to dump random bytes as well as CID/LIDs ? Not sure.

If you were really adamant about logging a ton of data, you could also modify the SID AC code to recognize extra fieldtypes. Probably less work than implementing a new SID from scratch IMO.

That's what I was starting to think, but was getting confusing responses haha I'll have to read through that bit of nisprog code for sure. But if you can only specify 12 bytes within a single request, what's stopping you from just sending multiple requests and having the ECU return just the values? Outside of the SID just not being setup that way of course.


The SID response RAM address block leaves more than enough room for 255 bytes, but I don't know if that means much at all really. But if we could utilize 255-byte frames, that would be extremely beneficial.


So what exactly does field types refer to?


Actually, I already have a custom SID that returns an array of 32 8-bit RAM parameters (PRE-DETERMINED!!!). The issue would be being able to actively specify RAM parameters, as you would then have to include the addresses, field types, etc etc. The thing about adding SID code is that you have to jmp to the end of the stock ROM data. There's just no room for custom stuff anywhere else in massive chunks really. So adding a custom SID makes it much easier to handle things, as you have all the necessary code right there, minus the extra noise you'd have from hacking a pre-existing SID. But I do agree that keeping these things within a minimal amount of stock SID's would be preferable. So if I can make a setup that works well, I could just add it the $AC code.

Honestly, a potentially good idea would be writing the RAM addresses + field type (if it's related to byte size) to a certain section in RAM, then having a SID return JUST the values (plus header and checksum). So that way you can have the ECU return the maximum data possible, without being limited by your request.

It definitely seems that the current limitation is having to request the parameters each time with $AC. The $AC code is gibberish to me, so I'm not quite sure on how difficult it would be to implement storing the RAM addresses tbh. But the the only way we'll improve logger capabilities without using the 255-byte limit (if possible) is by storing the RAM addresses within RAM, then calling their values with a separate ARB ID. If I recall correctly, $AC does store RAM addresses to an extent, see 0xFF9984-0xFF99B3. But it's limited to 12 RAM addresses in my RAM dump, so not sure why that is, as it has plenty of space for even more. On top of this, not including 0xFFFF would give you 24 RAM addresses, assuming you can just add the address to 0xFFFF0000.