When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
I have my AEM wideband connected to the ecu pin 73 (evo 9) for direct logging without a serial cable. ROM 88950015
After reading a ton on this topic, it seems there are 2 addresses available that people are using to log in evoscan: using RequestID 12 (mut12) or RequestID 3C (mut3C).
I followed this tutorial: https://www.evolutionm.net/forums/ec...ial-cable.html
After following the steps in the thread, I am using request 12 and it is giving me accurate afr numbers in evoscan, however, it does not show me afr values in real time. It takes at least 10 seconds for the afr value to change so its pretty much useless for logging afr when doing a pull.
I decided to change the requestID in evoscan to 3C to test that. 3C gives me real time values for afr but the values are way off and playing with the formula in evoscan doesnt seem to help get the afr accurate to what the gauge reads. In fact, it never seems to go up or down more than 1 afr even in boost. I also changed the mut3C address to 0x8409 like I did for the mut12 in the tutorial thread but that made no difference.
Why is RequestID 12 logging so slow and 3C logging so inaccurate? Anyone else have these issues? What am I doing wrong?
Im starting to think this issue is caused by my mut table. My mut table seems to be way different than most I see here, specifically all of the rows containing 0xFFFF values. Others have actual defined addresses in them but mine doesn't. This is the stock unmodified 88590015 mut table that came in ecuflash when I downloaded it. Your thoughts?
Im starting to think this issue is caused by my mut table. My mut table seems to be way different than most I see here, specifically all of the rows containing 0xFFFF values. Others have actual defined addresses in them but mine doesn't. This is the stock unmodified 88590015 mut table that came in ecuflash when I downloaded it. Your thoughts?
That's how the MUT table looks on stock ROMs. Tephra ROMs have the MUT table scaled so that all the FFFF rows are removed to make reading the table easier.
You can apply the same scaling to your MUT table, too, by changing the XML for your ROM.
That's how the MUT table looks on stock ROMs. Tephra ROMs have the MUT table scaled so that all the FFFF rows are removed to make reading the table easier.
You can apply the same scaling to your MUT table, too, by changing the XML for your ROM.
Why is RequestID 12 logging so slow and 3C logging so inaccurate? Anyone else have these issues? What am I doing wrong?
Never having tried to use MrFred's O2 simulator patch I can't answer about the Request12 being so slow. I suspect that Request3C isn't showing you what you think - by default this request is for the rear O2 sensor ADC input and in an unpatched ROM just shows raw voltage (value 0 is 0V, value 255 is 5V).
You should be able to log AFR from your AEM without using MrFred's patches on Request3C provided that you use the correct Evoscan formula - it will be something like "10+(x*10/255)" assuming that the AEM reports an AFR of 10:1 for an output of 0V and 20:1 for an output of 5V. To adjust the formula for actual values, change the blue "10" to the AFR matching 0V and the red "10" to the difference between the AFR matching 5V and the AFR matching 0V.
Turns out the mut table format was the issue. Once I changed the mut table xml to remove the FFFF rows everything is working perfectly.
I believe I did the same thing when I started to modify the MUT table. Without the FFFF scaling, the MUT request ID does not correspond with the row and column labels, so you were probably modifying the wrong address. Glad you got it worked out!
I believe I did the same thing when I started to modify the MUT table. Without the FFFF scaling, the MUT request ID does not correspond with the row and column labels, so you were probably modifying the wrong address. Glad you got it worked out!
Correct. With the FFFF columns in the mut table, the addresses were not in the right columns. Thanks
Never having tried to use MrFred's O2 simulator patch I can't answer about the Request12 being so slow. I suspect that Request3C isn't showing you what you think - by default this request is for the rear O2 sensor ADC input and in an unpatched ROM just shows raw voltage (value 0 is 0V, value 255 is 5V).
You should be able to log AFR from your AEM without using MrFred's patches on Request3C provided that you use the correct Evoscan formula - it will be something like "10+(x*10/255)" assuming that the AEM reports an AFR of 10:1 for an output of 0V and 20:1 for an output of 5V. To adjust the formula for actual values, change the blue "10" to the AFR matching 0V and the red "10" to the difference between the AFR matching 5V and the AFR matching 0V.
I had the formula all worked out. The issue was the mut table formatting, the mut addresses were in the wrong columns because of the FFFF
