For what it's worth, I got rid of the secondary air enrichment, and set the whole Warmup Fueling table to be just that of the 20 degC + cell and it maintained good startup fueling while not totally smoking the garage out.

If you 0 out the tables (at least on E85) the car hates trying to stay running when at 25 degC ambient haha!

 

Is there a need to change ignition timing if warmup fueling is reduced?
Is there specific ignition map for cat warmup for the secondary air pump system?

The car seems to have a different exhaust note on cold starts(could be just in my head

 

Yes. During cold starts ignition timing is retarded to -25deg for a short while. I deleted the entire bullshit around CAT warmup, this timing included, rich fueling included. I now start with a timing of 15 degrees and an AFR of 13, and the car no longer sounds terrible when starting.

 

By any chance could you point out to ignition tables that define cold start retarding?

 

Typically more retarded timing = higher EGT (burn is starting closer to the exhaust stroke, so less time to cool off), so I would think that on cold starts retarded timing would aid in cat warmup. I am not sure if that wold be required for anything other than that.

 

Not entirely sure where he's getting the -25deg from, but different ROMs may have different logic.

From what I understand, these tables are what is going to adjust timing (at idle) for a cold start:



Following the logic as written out above:

Idle Base Timing Final = (Idle Base Timing - (Idle Base Timing Load Compensation * Idle Timing Load Compensation Multiplier))

Basically, anything above 0 degC won't get any idle timing adjustment based on the multipliers, and when it's really cold.. depending on engine load, you will have more OR less timing.

 

I’ve changed all the values below 40c to be the same in all three fuel cat warm up maps and it doesn’t have any affect on afr.What am I doing wrong?

 

If you still have secondary air active, it would saturate to the secondary air enrichment value.. that could be one thing.

That or the O2 sensor is just unable to read the rich condition.. not sure without any sort of log.

 

I’ve removed the secondary air pump long time ago.The o2 sensor reads 0.750 lamda until 35c ECT

 

I believe is that is the max sensor rich the OE sensor will read, or pretty close to it. Likely what is happening.

 

Decompile the timing path long enough and you'll get to uncover the cat warmup path. I use N3ZHEC so I cant speak for others, but there are load/ect/iat limiters in place that enable it. I set coolant temp threshold to -50degC so it never ever does the cold start cat warmup thingy, and the car never ran or sounded better when cold.

On a separate page I dug up some fuel cut related business, and am wondering if anyone else found something in this area because following through with this down to injector output stage is a nightmare.

 

I was curious about checksum protection in ROMRaider. I know rx8man doesn't verify the rom checksum after you edit it in ROMRaider. Would editing the ROM not change the checksum? Does that create a potential for bricking when writing to the ECU? I might just be acting paranoid, but I'm curious if the proper/normal procedure is simply to read your stock rom, edit it in ROMraider, and then just straight flash it to the ECU. I have a N3ZBEH ROM ID, and am using the most updated rx8defs.xml Any input is greatly appreciated!

 

The RX8 ECU doesn't care about a checksum, and thus Romraider does nothing to do with the checksum.

 

I seem to be missing cooling fan control definitions for my ECU's rom. I saw this was kind of talked about earlier in the thread but I'm just curious why they're not showing up. They show up on a generic ROM I downloaded online, but not for my ECU's image. I have a N3ZBEH ECU, 6 port US manual.

Edit** I just copied values for those tables from the N3Z2EU section of the definitions to the N3ZBEH section. That seems to have worked because those tables are populating in ROMraider now. I'm just curious what else might be missing though? My knowledge is pretty limited on this stuff.

 

They are likely not in the defs for your specific ROM.. someone would need to go into the dissassembly and confirm their addresses to in order to add them to the defs... which anyone can do and modify defs.

 

Just as an FYI, just because it's defined at one address in one ROM doesn't mean the addresses are the same in the other ROM. I would be careful doing this as what populated in the Romradier tables are just going to be a parsed version of whatever values are at that memory address.

It's likely the two values are at the same address if they have the same values as other ROMs, but it's also very possible they aren't. The right way would be to verify in the disassembly.

 

Okay thanks. I guess I still don't understand why those fan definitions aren't in the N3ZBEH to start with. I see that the N3ZBEH is included in the supported ROM id's but it doesn't have its own tables in the definition file. When I open my rom in ROMraider it changes the title of the rom to N3ZDEH, is that normal?

Edit*** I opened up the rom in hexedit and verified that the fan values I wanted matched the address location values in float for the locations I copied to the N3ZBEH tables, everything mapped over just fine. Thanks for the advice!

 

The reason is because the definitions aren't super complete. I haven't really had anyone else provide any def updates, and if it's not a ROM that has common addresses with the stuff I am working with, it's tough for me to update those defs with any sort of confidence they are correct. I have worked on a few scripts to help define non-defined ROMs, but the desire is a little low on my end just because it's a lot of work for an application I am personally not vested in, and I am just one dude. If anyone has modified the defs for their own use, and wants to merge those into the git repo, I am more than happy to get those uploaded!

It's also very possible that your ROM does have the same addresses, they are just not in there due to a copy and paste error, or literally they were just forgotten haha.

 

Ok that makes sense. I appreciate all the work you've done making this open source and saving me about 500 dollars. I've just been trying to learn a lot so I appreciate you answering all my questions. I'm still verifying the defs for my ECU ID, but I'd be happy to upload those especially if I find other things missing!

 

Has anyone tried to use something other than a tactrix with Rx8Man yet? With the prices of those cables, its almost just as reasonable to go standalone. This looks like fantastic work though, and it would be great to be able to make the car a bit more reliable with these features.

 

Rumor has it, and there are not guarantees here (it's not my software), that support for other devices may be coming.

 

Interesting. I'll be looking forward to that. Thanks for getting this information compiled and making it so easy to read. Ive never tuned a car before, so all the software and information is daunting, especially with the high price tag. Withh how well laid out this documentation is, I'm quite inspired to learn.

Do you mind if I ask why Rx8Man is needed if similar software (such as forscan or ecuflash) to pull info is already there?

 

So, that's an easy question with a complicated answer, but I'll try to explain it very simply.

Basically, each program has it's own bits that make it fairly specialized, and each ECU sorta has it's own things that require it to be specialized in order to reflash it. Being able to use a tool to reflash a particular ECU only works when both the tool and ECU specializations agree with each other and match, and that's just not the case with the RX8 ECU and the existing tools you've mentioned.

Expanding on that, those existing programs also being closed source (no source code readily available to modify to broaden the specializations simply) make it just easier to write your own program from scratch for your specific ECU needs.

I hope that makes sense!

 

Yeah, that makes enough sense. I have messed with microcontroller before, but never had to communicate data between two computers before.

 

FYI: RX8Man released a simple romraider-esque configurable logger that also supports RAM reads on stock ECUs which is awesome because my bashed in romraider build never could!

You should definitely check it out: https://github.com/Rx8Man/Rx8ManData...ses/tag/v1.0.6