Ack. No more discussion of third party tuning solutions (to include mazdaEdit too) in this thread. I'll also repeat that I'm appreciative of you sharing your work and being willing to answer questions.

Would be able to share the code you used or describe more thoroughly how to upload ROMs via UDS? I understand that we use Request Download (0x34) / Transfer Data (0x36) / Request Block Transfer Exit (0x37), but having a reference implementation, even if only in pseudo code, would be immensely useful.
It would also, if I could get that implemented in python correctly, provide an open-source / source-available ELM327 dumping and writing solution to the community, which as far as I know doesn't exist.

I do have code to enter the diagnostic session (0x10) and get security access working (0x27), which primarily came from someone else, as well as my direct memory read (0x23) code working to dump memory but I haven't yet wrapped it to iterate through all the mem and dump to a file.

As an alternative, I'd also be interested in the corresponding upload procedure (0x35) as a dumping solution instead if you had any information on that.

 

Wait, how do you input the signal to ECU to what the E% is ?

The coding is so beyond my head that its insane, so sorry if my questions sound stupid to you.

 

Valid question. I have the module configured to receive a CAN signal containing the ethanol content. I've got hardware that reads in GM flex sensors and then outputs them via CAN. I am also going to be providing this hardware for people to use as well, either open source schematics/boards or will be selling. But nothing is stopping you from making your own as the CAN spec will be released too once I put together an actual release for use. I am still testing.

The rest of the code is mostly just linker bashing to integrate with the factory software, and defining functions in the software for use in my own.

 

Inam happy to pay for a solution. For flex I wanted to see if its some math/algorithmy6 like "fuel trim" which is used as a base for calibration, or an actual sensor.
I love learning but there is a limited time to each day and my priorities are elsewhere. It doesn't help that my programming/designing stops at math/analogue so its a lot of learning for any of this.

 

So im sure this has come up just so much to look trough. How are you getting around this for your catless no more evap system no egr basically race car on the streets . Any info to mask or permanently lock readiness monitors thanks

 

You disable DTC'c (reporting and monitoring)

 

If you are looking to set readiness monitors, it sounds like this might be for emissions purposes since that wouldn't effect much of anything else I can think of.
Do note that most places testing emissions now check the Calibration Verification Number (CVN) and ID (part of "Mode 9" / 0x09 info), which is a hash calculated over the entire binary (I believe it may be CRC16), and which will change when you flash a different ROM that has DTCs disabled or readiness checks set, so what you are trying to do is unlikely to work.
See for example: https://www.bar.ca.gov/arsc/newslett...-modifications

I would be very curious to understand how the CVN is calculated for our ECU, and for example understanding how the ECU receives something like a request for mode 9 data and then processes it.
From my reading, it calculates the hash incrementally in sections (so that other interrupts can be run in between), but seeing that logic in the disassembly would be amazing.

 

so what software are you using on your car mazdaedit versatuner, or even winols

 

Ok well what your saying to me even one on this forum has a car the pass emissions with no problems at all im sure someone can do this. If they cracked it on German car ecu I even know the honda guys with Hondata been doing it also .

 

I have ROM 60E1B800 which is apparently not yet supported (2005 US 6 port MT). It seems to mention two N3* strings:
N3ZBEBWW.T50 and N3ZBEG000.HEX
It would be cool to understand how to get a new ROM, such as this one, supported. Let me know what you'd like from me if I can help at all.

 

Definitely post up the binary and we can go from there.

I don't have any scripts to help define a ROM with the base of another, but I am sure that something can be created.

 

Should be attached here (first time attaching file)

 

Hi, my China market RX-8's rom is also not supported, I will post it here and hopefully we can add definitions of it?

 

Did you get a "pc sw" from Versa that you had to use beforehand that you could install it ? as far as I know, that SW replaces the current ecu map with a stock based on your ECU calibration, and that is later used as a base.

 

@equinox92 , A small correction to the data, which I also see in definitions files (also from rx8man) on engine load. where does the "g/rev" for engine load come from ?
Engine load is defined as an absolute unitless value (either in decimal, or percentage).

although it is corelated to g/rev, it is a value of how much g/rev there is divided by theoretical 100% filling at standardized conditions, ie (g/rev)/(g/rev), ie a 100% load is 100% load irrelevant of engine capacity.

 

Engine load used for actual engine control calculations is in grams/revolution of the engine. You can see this in the math used for air mass and fuel mass (converted to volume for injection). This is also why tables for injection, timing, etc all go above 1.00, which if the engine load was in % (1.00 being 100%), the table axis inputs would make no sense. You really can't have 120% load in an NA application, it makes no sense.

The load in % is used for OBD compliance, and freeze frame/monitor data. There are PIDs for both, and that PID definition looks to be that of the OBD PID. Some of the mode 22 PID request function will report two values for one request. I can't recall as I don't have the software in front of me, but i THINK PID 0x43 is one of those PIDs and reports both %load and g/rev, or that PID definition is not the same as the Mazda PID, and the OBD Mode 4, 0x4 PID will follow this spec.

You are welcome (and should) go into the ECU disassembly to confirm, but I am very certain this is the case here.

Should also note, the scalings in my logger defs are directly from the Mode 22 called functions that turn the values into fixed point integers for CAN transmission, so those values aren't just from thin air trying to make numbers look correct, though some of them are not correct just due to my own error copying stuff over haha

 

Just a short reply from my phone. Can later expand more with references . It is very often that load is above 100% on well tuned NA engines.. We are not speaking about old 100hp 8L V8 engines here that are barely 70% VE... (Thus maximal load will be ~70%)..
The fact is both values (g/rev or %) are correlated and in principle on one engine correlate the same .. one is divided by "engine mass volume"..

By the way, a good rx-8 will have 220g/s at max power.. even if we assume that is at 9000 rpm that is (220g/s)/(9000rpm/60)= 1.47g/rev you can see that the math doesn't really add up. But if you follow that and now devide 1.47g/rev by (1.3L*1.025g/L ) (for 25°C) = 1.1 ie 110%


I would love to help with Sw reverse engineering but its way above my programming skills. However I can help with understanding the formula if it is extracted as I have a lot of experience with that.

I couldn't fond a general description of load (that is not a pid) but all ecus run an absolute load as % of the "theoretical" 100% filling at SAE defined air density (based on temp, moisture and pressure)

 

I would need to see MAF data in order to be able to make sense of that as that's pretty speculative.I do see your point though.

Either way, with quite large confidence, the engine loading calculations for table axis is in fact in g/rev. There is an equation for PID transmission that takes that value as the air mass in g/stroke of that calculation. I can post up some screenshots of the software later as well, and like it said, it's the ONLY way the fuel volume calculations make sense with scaling and unit conversion math that is hard coded in the software, and it uses the value that is also used in all of the typical tuning tables.

 

Here you go.
completely OEM intake system, brand new at the time MAF sensor (oem from mazda) and brand new front O2 sensor, no changes in scaling of the sensor (as many go when VE is incorrect).. I was playing with the tune so you can neglect other values besides RPM and MAF .. if you calculate you will very quickly see its not in g/rev...
Yes, I know load is used throughout the whole tune. But that doesn't mean it is g/rev (that would be the first ecu I would see as g/rev in 15years I've been doing this). Load as % has mostly "simply" replaced MAP in most of the tables we had before on speed density ECU's (which I hate). There are NA engines that reach 50% higer engine filling than the atmospheric pressure would indicate using resonant intake/exhaust systems ( reach 432HP/L NA on 100RON petrol )

Please share a screenshoot or text file with the code.

 

This is the math that sets the engine load variable that is used all over. fVar4 * fVar2 with a min value with 5.0, meaning load can never go above 5.0. This clipping is just for software safety.

fVar4 = MAF in g/s
fVar2 = engine speed in rpm
fVar3 = engine speed in RPM divided by 60, presumably 60 seconds in 1 minute. The divide is a function because of some programming math differences between fixed point and floating point.

That would give us the total equation of: g/s * rpm / 60s/min with ends up with units in g/rev.

There is a scaling per rotor charge (multiplied by 0.6345) to get it into a g/combustion event (stroke). This is the value used in every map that uses engine load, as well as the torque model. I am not showing a full screenshot just because I recently redefined a filter function and it's not populated in this older archive I have on this computer currently, so the whole function disassembles a bit wrong to show, but the math is still there on the signal. There is no other math done on this signal after this that is relevant.




To calculate the load for the OBD PID transmit, the function does exactly what you are saying with some conditionals to just condition it nicely:




For the Mode22 PID 0x43: This is the function it uses, and it just returns the value as we calculated above unless the injectors are off, in which case it returns 0:





I am calling it g/rev because that is what it is in terms of piston engines, which is the basis of this engine control strategy. So yes, while it's a little wrong in terms of the rotor revs.. it's the name that makes the most sense for the signal. It's a hell of a lot more accurate than %, for which it is not.

I can also go into how it's used the in fuel volume math and how it cannot be any other unit if that calculation was in %.

I can also go into how the VE table as defined by versatuner isn't a VE table, but more of like an airloss/fuel loss compensation table if you'd like. The math just doesn't make sense for the control strategy that IS used.

 

This is great discussion though, though I didn't realize the 0.645 scalar was what it was until going through it just now, had assumed it was something like that, and never needed to confirm that math just from other math already confirming my units, so I can label that in the ROM!

 

Yes the math is clear on what you posted (I can understand such code), but the table axis are than highly misaligned..
See the log I attached (or do your own) and you will see that the max g/rev is much more than it is populated in the table.
Also when you log for tuning, the pid reported absolute load exactly matches the values in the tables referenced as %... so no mather if its used in equations as g/rev (if there is no other math) it is not useful to mark it as such for anyone that isn't looking at the back code of the ECU and is missleading (as g/rev is very easy to calculate, and it doesnt align with abs load pid, and tables align with the pid and not the g/rev..
diesel ecu's and some petrol, often have measurements in XY/stroke.
Thus there has to exist some other conversion as the "raw" value ... that part is "static"
The VE table is as on any other ecu.. nothing special about it. and it does exactly what you described. creates a correlation between measured air and burned fuel ...
The rotor volume is 654 not 645

 

in the data log if you calculate, max g/rev is almost 1.6....

 

Max engine load is based on this RPM based table multiplied by the baro compensation multiplier table, and you will never see a value higher than this as the software will clip the input inless you also have a baro multipler for it that is greater than 1 from the baro table, which is a pretty unlikely scenario.






The load in the previous screenshots (and other maximums) are there to keep software happy, more and specifically are typically to keep fixed point math from overflowing. They don't have much to do with what is physically possible or not possible.

Reality and what is used for control often lie, for reasons we may never know. I have boofed in so many squidged values in various things at my dayjob because certain models don't work quite right, or a sensor is only bang on accurate in a specific use case in order to create performance we need. I am sure some of this is a reality of that. I am just reporting what is actually in the software, vs what we think should be the case.

As far as VE goes, that table cannot be a VE table based on this math:




There's a lot going on in this function, including an OBD PID that modifies the requested lambda, but the "VE" table you speak of, is what I am calling the load compensation table as circled in red. The compensation lookup is applied in a way that would make no sense for it to be VE.

 

well in a MAF based ecu's the VE cannot exist in its speed density table form and equations. But for working with it, its easiest to understand and no matter the math behind it. it does exactly what a VE table would do.
same for the load formula vs what is actually usable and there.. for NA it doesn't really matter but we would see huge problems if the actual value in the laod was g/rev.. if NA can hit 1.6 g/rev (and anyone can simply verify this) and table only extends to 1.2 oem... its a huge difference in values looked up and would be a major problem for all of the cars (they would run much leaner than they do, completely different ignition timing ect..)

And there are so many logs already made that I highly doubt the ECU is scaling all of the factors to some fake values just for the pid but uses diferent ones in the engine controll.. But than they again align with external non ECU controlled sensors..
for OBD Afr output .. its bang on with AEM UEGO sensor (less than lambda 0.02 point difference in transient, in static its 0.01)

What I am trying to say is it doesn't matter what the "pure math is" if it is not right.. and I have very simply proven that the math shown in SW is not right so either something is missing, or Ghidra is missing something.. anyone can very simply change the table for example AFR (least dangerous) that at load 0.7 it goes to lambda 0.8 and before it at load 0.78 it is 0.9.. than you increase the laod on the engine untill g/rev matches that value and you see if lambda has dropped, and repeat for actual load as it should be according to SAE definitions..

I work daily with less or more complex math in engineering.. and we always double check if the value obtained makes sence by simply solving one "value" by hand.. which in this case is MAF/RPM and we very quickly see that the Math doesn't calculate... if the math doesnt calculate we have those where the error originates.