RomRaider

Show me what the problem is.
Enable TRACE level logging, make your request and post the rr_system.log file.

PM'd ya

It is working correctly.
34817 TRACE [Thread-7] - Write Msg: [protocolID=4 | rxStatus=0x00 | txFlags=0x00 | timestamp=0x0 | dataSize=64 | extraDataIndex=0 | data=3EAC8183FFFF210C83FFFF210D83FFFF210E83FFFF210F83FFFF210883FFFF210983FFFF210A83FFFF210B83FFFF210483FFFF210583FFFF210683FFFF210775]

Due to the 63 byte packet size limitation of the protocol method that Nissan uses you will not be able to log more that three 32-bit parameters at a time.
It's best to find a different format for these parameters. In the Subaru world many 32-bit parameters (mostly float) have scaled down 16-bit or even 8-bit equivalents. These would be better options to log due to this protocol limitation.

Thanks for confirming that the limitations are due to the operation of the stock SID's rather than something else dschultz! Any ideas on the 64 byte packet limit vs 255 byte packet limit?

Here's my current idea. Using a custom RAM write SID, you would send just the RAM address portion (rather than 0xFFFF as well), the size, and then write it to a block in RAM. You could fill up three blocks of RAM and have extra ARB ID's used to clear the entire block or read the entire block. To handle oversized values, it would use the specified size (dt loop) so that if you reached the packet limit before reaching the end of the block, it would just not log any of those parameters. Then if my understanding of RR logger using $21 and $22 is correct, you should be able to request the results from all three blocks (in three separate requests), effectively tripling your maximum logging parameter size.

Currently, the way I want to setup the custom SID would max at 19 RAM addresses per RAM write request. So a total of 57 RAM parameters could be datalogged via the three block setup. Technically, there wouldn't be any wasted space in blocks either. By having the software handle the requests, it could automatically calculate the total size of your requests and shift any request that would exceed the packet size to the next block. So if you request 16 32-bit parameters, rather than only returning the value for 15 of them, it would return the values for 15 of them, and have the 16th one moved to the next block. As long as the multiple ARB ID requests don't slow down logging too significantly, this should work just fine. But if having to constantly go $XX 01 then $XX 02 for two blocks causes a significant decrease in logging speed, then the limit might stay at one block.

There's only 6 bits in the protocol header for the length value. 6bits = 0x3F = 63 bytes long.

In the Nissan environment when you make a SID 22 request the response will be 1 or 2 bytes long. To support anything else probably means custom code in the ECU and the Logger.

BMW has different request modes that return a pre-defined list of parameter values. Subaru has an array in RAM that can be requested with a list of pre-defined parameter values. This is what Nissan needs.

Hello. Recently I came across a video (https://youtu.be/Wa_LNdU3NlY) of how a person controls an ECU online, because he also has an SH705x series processor. Has anyone ever wondered how this can be done on Nissan?

The ECU code needs to be modified to support real-time tuning, then an application built to work with the ECU code to allow user changes to be applied to selected tables.

That is, you believe that Dmitry rewrote the engine operation program, and then wrote the control program?
But he writes that it is possible to control any Subaru ECU on the sh705x microcontroller. Are they really that much different from Nissan ECUs?

Real time tuning requires custom code for all Nissan K-line ECU’s, ask me how I know You have to write the ROM maps to RAM, change the storage addresses for said map to their respective RAM addresses, then either add or utilize a stock RAM write SID to write to the map’s storage address in RAM. To solidify changes, you still need to reflash the ECU’s ROM. So there’s no way to do this without adding a decent bit of custom code.

Well, then the question arises, whence, when diagnosing, it is possible to correct the ignition timing and idle speed? As I understand it, this is an intervention in RAM and in the future saving these changes in the EEPROM. And my assumptions are that all adaptations are also stored in the EEPROM. Or am I thinking wrong?

Yup! The SID commands write to RAM addresses, which go on to be written to the EEPROM. Not exactly sure on the EEPROM writing procedure, but it's sending the consult adjustment value RAM parameter to an EEPROM writing buffer address.

I have two more ideas that potentially might work.

- Create multiple parameter groups using $AC, then just poll each group in separate commands. (It'll result in slower logging speeds, but would allow for an OEM incorporation of logging reasonably large quantities of parameters.)

- Create a custom $AC ARB ID handler that would assume you're requesting a RAM address, allowing you to forego having to enter "0xFF 0xFF 0x12 0x34" and instead, could just enter "0x12 0x34". (This would effectively double the request limit and would implement the same code as the current $AC ARB ID handler, with the exception of including the 0xFFFF from the code itself rather than from the ARB ID.)

Anyone see any flaws in either of these approaches? While the first one is the most beneficial universally, not a lot of people datalog extended parameters and would have a need for more parameters being loggable at once. So the second option would work best for those wanting to retain the same logging speeds while increasing the parameter quantity.

Not going to work with the standard AC handler. There's just room for one group and each AC request overwrites it.


Yes, that would work. It would make sense to just extend the standard handler to recognize a special "fieldtype" for RAM address shorthand like you describe.

If you going to write a custom handler like this then I also suggest that you include a length byte so you don't have to request x12 0x34, x12 0x35 to get a word of data. Just use x12 0x34 0x02. This saves even more when requesting 4 or even more bytes starting from the specified address.

Oh for sure! It's actually how I've always envisioned it haha Didn't even realize that the current $AC functionality forces you to specify each RAM address if you have a word or dword parameter until a couple of months ago. While I haven't spent any more time on this, I'll keep the thread updated when I resume work on it.