Well in european roms that function doesnt look like that...

 

I only posted the relevant function (the floating to fixed point conversion of the value), so yes. That function for the PID you have posted will be the same.

You may want to have the function not return a pointer it it may recompile more correctly as well

 

I think you're missing pretty much everything I have posted, which I do need to make a correction to. The max engine load is also scaled by an IAT multiplier, which is a lot more heavily used, thus making the maximum load allowed to be used a function of the RPM based load limit, and the IAT scalar. I made them into a 3d table just for easy viewing ignoring the baro multiplier as it can only scale the max load down, in practice.




As you can see, the ECU math limits this value to these maximums at a given IAT, making the max engine load something extremely reasonable to have on the timing/fueling lookup axis. I am not entirely informed on why these corrections are there, however I would imagine it has to do with linearizing the MAF sensor, as they are very non-linear sensors and need correction to be applied to get a valid reading for load at higher MAF voltages as it's quite difficult to tell between 200 and 240 g/s during sensor saturation.There is likely also some filtering factor to this during APV/SSV switchovers too as there are bump ups for these points. That is speculation on my end though.

Calibrating these values in a table for what is essentially only WOT and near WOT values was likely done using extremely sensitive and expensive equipment on a dyno during engine development, and so it will clip the sensor reading to reality for good engine combustion. When the sensor is not being saturated, the MAF values become useable, and are more important for closed loop anyways.

 

To rant on about the MAF non-linearity:

Based on the MAF scaling in the module, at lower flow rates, you get a ~.5V differential for 12g/s delta. At higher flow rates, you have a ~.2V differential for 40g/s delta. The voltage per g/s is very small at these higher airflows, about a factor of 10 less sensitive, and it is not simple to detect small changes during sensor saturation.

You can also see that they have very fine points of tuning in the linear sensor region at low airflows, this is likely to focus on closed loop airflow accuracy for fuel economy/emissions. The rest is less important.

 

Look at the SAE I posted.. it has to be normalised to 25° ect.. (I'm exhausted so i might be writing jiberish)
Thus if you have a 200g/s at 50°C its much different than 0°C..

As for saturating the MAF its far from there.. i wouldn't assume that is it... even before nearing clipping its capable of measuring >350g..

Ok I see your second post.. but think of it also as a % error... At low flow you need high sensitivity.. at high flow a larger error will pose same % error.
I would argue accuracy is more important on open loop than close loop where it autocorrects

 

On the topic of data logging, has anybody been able to read factory ride height sensor data?
I presume these were used for leveling the premium trim headlights. Obviously it's not Formula One spec, but it's there from factory and could be of use to cheapies like myself.
I have a base model car with simple headlights, no DSC, and no ride height sensors - but it is wired for them (albeit the mounting points are missing). Forscan shows me nothing for this parameter, but I'm wondering if that's because my BCM is flashed for a base model car w/o the sensors.

On another note, ordered a Tactrix cable today. Can't wait to give this a shot and hopefully replace Versatuner

Thanks for sharing your work, it's incredibly generous!

 

I could try to connect to mine and look if data is provided and forscan can read it.

 

Ride height sensors go directly into the level control unit, and are not broadcasted out via CAN, or diagnostic line.

You could plug the pots directly into something to read them, though if you change the OEM suspension out at all, it's essentially making the height sensors useless in their operational range.. so you're better off just getting aftermarket shock pots to measure stuff with in my opinion.

 

Working flawlessly on h&r -2" springs...
Also very easy to change linkage length if needed
Also easy to tap in to them on the interior with existing lines..

 

Bummer it's not sent out on the bus. Knowing that keeps me from chasing my tail though.

 

Adding my currently unsupported rom here. It's an N3ZBEJ - 2005 USA 6 port MT, completely base model car with no stability control.

Are there any known hardware differences in the ECU between different years and trim levels?
What risks are associated with flashing roms different from our car's factory one?

 

I've flashed a few different ROMs on different hardware and run into a few issues, but those were totally different market ECMs (USDM ROM on JDM ECM). I have flashed various USDM 6 port ROMs on 6 port hardware and had good success.

I can't find a reason why any USDM S1 6 port MT ROM wouldn't work on any ECM of similar engine/trans/market.. but haven't tried all the combos.

tl;dr give it a shot!

 

What is a consequence/ symptom of running a wrong ECU.

So far I came across a car that wont achieve different afr to the stoich no matter what.

. Does the rx8man read the full bin or just partial?

 

RX8Man will read the full ROM, so bootloader is included. If something is different about the hardware that interfaces with the bootloader, you may run into issues and softbrick a module. You'd need to shboot mode the module back in this case, which is described in the posts I've made. Not entirely sure what the differences there are, but I have run into that issue before.

You'd have to look at what the differences in hardware to the car are. The JDM ECU I flashed a USDM ROM on to ran totally fine on the bench, but wouldn't actually allow the car to start (even with an immobilizer delete). I assume there was some starter relay wiring difference, but didn't dive into the IO outputs to compare.

As far as a car not achieving a different AFR to stoich... not sure what you mean by that.

 

I can't wait to see how this gets developed and used by everyone here. It's pretty cool to see this much development into a relatively old car at this point.
Personally, I'm still on Versatuner until there's an open source option for launch control. I'd happily donate $50 to see a patch with that feature. Versatuner's 2 step is built off the factory rev limiter which sucks in practice because the rpm bounce is incredibly slow. I already see a rev limit debounce variable defined in these roms which rocks!

 

Making a patch for that would be pretty simple. I've reverse engineered mostly what will call for a fuel cut, so it would be as easy as modifying that function to add your own call for cut, and then making your own condition detect function. Most of the sensors needed for that are known.

I just don't see the benefit in a 2 step or launch control on a RWD car without a turbo aside from just making a bunch of noise.

There are also some ignition cut functions as a result of DSC, so yeah. The world is your oyster.

 

From my perspective running rallycross events it's pretty useful. I've found it extremely helpful to get consistent starts and focus my attention on things besides the tachometer. The wrong rpm off the line can definitely hurt times. Too little and it will bog, too much and the tires just get roasted. I'm also on dirt - there's often bumps from other cars getting wheel hop, so it can be unforgiving. Having a more controlled start is not necessarily a game changer, but I'm always going to choose it over my foot. Maybe my foot needs calibration but I'd rather play with the car lol. More refined launch control would be a feature I'd certainly enjoy, and based on other's complaints with versatuner launch control (it slowly surges nearly +-250rpm) , I assume I'm not the only one. I bet a lot of autocrossers would too.

Back to existing tuning stuff:
As suspected, I can confirm the 60E0FC00 N3Z2EU rom worked with my 05 USDM N3ZBEJ. Nothing exploded, car runs and operates normally, woot. I chose this rom because of the immobilizer bypass definition Equinox has provided, but I'm not sure I'm doing things properly. With (only) the immobilizer delete for cars with rke modules enabled, nothing seemed to change. The vehicle would not start without a chipped key. I assume I'm missing something here. Do any physical changes need to be made for this option to work?

 

That's odd, I'll have to look into that. I didn't have any issues with my RKE plugged in and that patch working. Past that, the only thing I would think would make that interaction weird is if you did not do a key off powerdown after the ECM reflash (I believe the RKE may not give you a new code if it was powered on during a reflash), and it would not allow a start.

If you do NOT have the RKE plugged in and this patch applied, I would expect it not to work. In that cause, you would need to the use the patch switch for the RKE NOT installed.

All of that also being said: I have not tried to car without a key with a chip present, only a mismatched chip to the ECM. If the RKE doesn't send out the right sequencing due to not finding a code in the key, that could be the issue. I'd really recommend you run the patch without the RKE present and unplug it if you've got a race car. Would also love a CAN log if you could provide with a non-chipped key and I can patch the patch if that condition is different :D

Hope this helps!

That aside, If you change the rev limit debounce in Versatuner (not sure if gives you that cal, don't have it open in front of me) I would expect that to also change the launch control debounce since they are probably just offsetting an RPM value going into the control register like most LC patches end up doing.

 

Hello everyone.Dom from Australia!Im new to this software but its extremely interesting.I have yet to read an ecu as mine are currently locked! Im looking forward to not having to spend $420aud to change my idle speed!

 

Wow I am loving this thread and the idea of Flex Fuel patching! Great stuff Equinox.

 

Hi everyone,

Adding my contribution to the shboot topic.
I noticed a small mistake in the pinout description for the CN400 connector thanks to the following post (https://www.rx8club.com/new-member-f...0/#post4940212)

Here is my proposed fix:
Pin 3 - WDT - Watchdog timer - 5V 150Hz 50% DC Square wave signal
Pin 6 - FWE - Flash Write Enable - Needs to be set to 5V through a pull up resistor (1k-10k is probably fine), this tells the MCU that it is ready to accept a flash write
Pin 8 - MD1 - Mode Select 1 - Needs to be get to ground through a pull down resistor (1k-10k is probably fine), this is one of 3 mode select pins (the other 2 are already wired correctly) to put the MCU into BOOT mode on power up
Pin 9 - TX - Module transmit - Connect to the RX pin on the USB to serial device, a 1k inline resistor should be used, but in my experience isn't necessarily required. Mileage may vary.
Pin 10 - RX - Module receive - Connect to the TX pin on the USB to serial device, a 1k inline resistor should be used, but in my experience isn't necessarily required. Mileage may vary.

and an enhanced photo of the backside


Finally, if FTD fails to connect to the ECU with the following error
This means your ECU is a HD64F7055S (a revised 7055F) and you need to select the "Generic boot method" during project configuration


Many thanks to Equinox who helped me in pm

 

This may have some truth to it if the MCU runs at 3.3V and the UART/USB converter is at 5V only. If you apply 5V directly on the MCU, it can fry itself, last time I checked the MCU runs at 3.3V I/O. Though I'd explain why/when you need those 1k in line(just a primitive level shifter... or current limiter).

 

I can confirm RX8man and RomRaider worked for my EU RX8 ECUflash with the provided rx8_defs.xml.

Outcome: First read the Stock-ROM. Opened it with the RomRaider. Then with the RX8man ECUflash wrote the Stock-ROM as a test and then wrote a modified ROM.
Managed to disable secondary air-pump and secondary-O2-sensor DTCs monitoring(P0410, P0420, P0139 and P2096), raised Idle RPMs and increased OMP delivery.

Setup: Tatrix+Openport2.0-driver, Win7, RomRaider 1.0.0 and Java JRE8 32bit from Temurin.

Question: Can you change the cooler on-off Temperature settings on these EU RX8s? I do not see that listed as a feature in RomRaider-tree.

 

Thanks to all who made it possible for this opensource ECU flash. Worked so far for my RX-8 S1 2004 for Airpump DTCs, OMP and Idle control.
Request: Is there a possibility to have updated definitions with radiator fan control temperature limits available? (if those are managed by the ECU)

 

Here are the addresses for N3Z2EU