RomRaider

Test logger is here

Sweet! Will be testing this out over the weekend.

O wow, interesting news!

Things are working OK for me. One issue I've run into regularly is trying to log too many parameters and maxing out the K-line packet size. It seems I'm only able to get 5-6 RAM parameters at once. The SID parameters are better but seem to max out around 15 or so.

I also noticed an issue with the tooltips (hover over text descriptions) of the lists don't update if you sort the list differently than the default view.

I still need to give the definitions some polish. Its just so mundane...

Well, the addressless packets are max 64 (or 65 ?) bytes; the request has 4 bytes overhead and RAM addresses need 5 bytes per parameter, it should be possible to fit 12 addresses per request. That's what I do for the non-kernel ROM dump in nisprog. CID/LIDs should be 3-4 bytes per parameter IIRC, a bit shorter.

The limit is the number of bytes in the CID/LID request packet. RR Logger will warn you when you have exceeded this limit and suggest you un-select a parameter to make the request small enough to be registered with the ECU. No issues on the response size from the ECU once the addresses are registered.

Under normal tuning conditions, logging of too many parameters just takes away from the focus of the item being tuned. There's a few How To's on logging and focusing on one issue at a time.

Actually, I usually incur a timeout response error, not a packet size error, sorry for the confusion. This behavior is repeatable, I've uploaded a log file to my shared Drive folder. I did also manage to get a packet size error, but without as many parameters as expected. Sorry, I'll try to record some specific occurrences. Overall things are fairly stable. I've run into some lock-ups where I've had to both unplug the Tactrix from the car and restart the logger. I'm not able to reset the connection from the logger itself.

I agree that with logging focusing on a specific task with the necessary parameters is preferred. If I were logging for tuning purposes, that would absolutely be what I do. At the moment I'm primarily trying to verify ECU parameters to supplement RE of the code.

Does this happen while the car is moving? Any chance that it's a loose cable, USB or OBD?
Then there's ground loops that can occur if you are powering the laptop from a different ground than the OBD ground. And of course electrical noise can cause issues on the USB line. This is when things get fun!


BTW: I see nothing in the log except a bunch of ECU Def table parsing errors and an instance of no OP2 connected.

When adding/removing parameters with Fast Polling enabled I usually encounter a response checksum match failure. The logger will reconnect to the ECU, sometimes right away, other times I have to wait over a minute.

When too many parameters are selected, I get a readMsg error: timeout expired waiting for 4 more bytes. This happened when:

a) I selected more than 23 SID parameters (mixture of 1100 series and 1200 series)
b) I selected more than 12 ECU parameters

I also replicated the "Request message too large" error, this occurred with 15 switches selected, 4 1100 series and adding a 2nd 1200 series parameter.

I've uploaded the relevant debug log. Let me know if there are specific conditions you would like me to replicate.

As I previously explained, if you are constantly toggling and or adding/removing parameters to log, Fast poll mode is not your best option as it takes over a second to interrupt the ECU communications, de-register the current parameter set and register your new parameter set.
If you will be switching between many parameters, disable Fast poll and the switch is almost unnoticeable. You will get a reduced query rate, but if you are not tuning then it shouldn't matter.

As for the number of items you can poll, there's nothing I can do about that as it's a limitation of the ECU and the message format being used. The error messages are expected when you exceed the various limitations that the protocol and message format imposes.

The message parameter count warning is not an exact sicence as there are variations of request sizes, so some cases you will get the error expecting 4 more bytes (which means your parameters didn't register) or you get the Too many parameter warning and the Logger will not attempt to register them. The Logger tries to detect the possibly that your will get a registration error before the registration request is built. I can look at possible ways to detect this case better.

For the instance when it took a long time to regain Logging control, your system log shows that the ECU didn't stop sending traffic, so I couldn't hear that the Logger was trying to interrupt it. This is a hard case to detect. Eventually toggling some parameters on/off did interrupt the ECU and logging resumed normally. I find it's harder to interrupt the ECU when logging only a few parameters which causes a high query rate and a busy ECU. To bad we can log CPU utilization...

BTW: When you are not actively looking for communications issues you should set the LOGGING LEVEL back to INFO, much easier on your laptop.

RE: fast polling. Yes, I get that, I'm just trying to be a useful guinea pig and am reporting what I see. I was going to run the same test in slow mode but had to go get the kids from the bus.

Hmmm, I'd hoped that the message format was somehow more efficient. Like, "Hey ECU, send me all the supported values for the 1100 series CIDs" and it would reply with a single data packet "Sure! 01-7B, 03-32, etc..." I see now how quickly that packet gets used up with the long addresses for each parameter. I wonder what NDS2 does via the VAG cable and how many parameters it maxes out at...

Since these CIDs are unchanged up until at least 2011, what would need to be known to enable CAN logging? Be nice to expand support to CAN models. Then fenugrec can write another kernel for dumping and flashing

CAN logging for CID 11xx 12xx is straight forward for 1 item per request.
I am almost sure CID's are the same for k-line and CAN request.
Petrol\Diesel CID's are different.
I do not know for sure if a set parameters via list may be requested for Nissan.
Any MY08+ petrol ecu should reply to CAN data request for logging.

Hello, i want say about my work with this RR logger with my ecu JU01A. All good except for some parameters - its id="P4387" name="Short Term Fuel Trim B1"
id="P4389" name="Learned Fuel Trim B1", i dont see data in % (75-115). I see only range 0.35-0.43. any idea? cid address right. if i log with another program and use 22 11 25 04 01 or 22 11 23 04 01 with formula x-100 - i see in % range 75-115.

Add the appropriate conversion formula to these parameters in the logger.xml file.

I see in the log that Accel & Throttle values are most likely mV not V, or an incorrect conversion to V.

Yes, I have noticed the scaling is incorrect and have updated the CID spreadsheet but the logger defs have not been updated. You can update your def yourself to fix the scaling for now.

dschultz, do the CID 1100 responses always give a single byte response? This data is actually stored in the ECU as a word value, that's why the scaling conversion was "x/256". However if the response is a single byte, the conversion should just be "x".