Tuners Rejoice! Free Tuning For M4.4!


Recommended Posts

    Well, after 5 years (of which 3 the car was unused because a tree fell over the top), the wideband ordeal IS OVER !!! I want to personally thank each and everyone of you that tried to help me out of this ! You guys are awesome !!!

    Ttoday, after fixing all vacuum related issues, and still didn't manage to obtain the right AFR, I decided to pull the ECU out and take it apart as I've forgot what I've done 5 years ago.

    The wiring was like this :

    - The AEM UEGO has 4 wires - black (-) / red (+) / white (0-5V output) / blue (serial output)
    - The + wire of the controller was connected to the +15 relay (yellow in the fusebox) to be able to shutdown the controller when I turn off the engine.
    - The white wire was tied to the Signal (+) wire of the Rear O2 sensor harness.
    - Because I didn't have two ground wires, I decided to tie the black (-) wire to the Rear O2 sensor harness. In the ECU i've cut the A19 pin (Rear O2 signal -) and tied it to ECU GND (pin A42). This way I would have the same ground for both the ECU and the AFR controller.

    But this seemed to have been a bad decision, as I've re-read almost all of the 500 pages here and I think that only by chance I've seen that the ADC in the microcontroller has a 0.2V offset in respect to ECU GND. Because of this, ECU measured +0.2V more than the wideband controller's output and hence a leaner measured AFR and thus enriching the mixture which in turn made the wideband read a richer mixture.

    Knowing this now, I've disconnected the Rear O2 sensor Signal (-) pin A19 and tied it to pin A18 (sensor ground), and tied the AEM controller directly to battery minus pole.

    The offset seems that's gone now, and the formula in the ADX (X*10/255+9.6) now reports exactly the same AFR as the wideband gauge. I also calibrated the injectors and now the AFR sweeps from 14.4 to 15.0 at idle.

 

I still have to understand how Piet's wideband mod works.
In the VE MAP, at 800-1000RPM and 0.4-1 load, I've set an AFR of 14.9->15.6 (see attached image)

Still, even if in the dash I see requessted AFR of 15.1, when looking at the STFT, when AFR goes over 14.7, STFT goes positive up to 3%, and when AFR goes back under 14.7 the STFT goes negative to -3%, and the cycle repeats.
I wonder how does this wideband mod work after all, if ECU does not target requested the values in the VE MAP ?

I've also attached a small movie of the TunerPro dashboard :

image.png.1905ffad117e9e179e30f924106371ea.png

Edited by Midnight Caller
Link to post
Share on other sites
  • Replies 7.5k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Attention: The first 30 or so pages of this thread are outdated. Please refer to the M4.4 Wikia article where all the relevant information is currently being collated. Before asking any questions p

Crush it.

After alot of testing and rewriting code, we finally got a useful new mod working. As we all know, some time ago my dad Piet found out how to convert to bigger maf housings with the maf factor. Conver

Posted Images

From what I could deduce, the wideband mod is more of a hack that uses existing narrow-band control. So the control-mechanism is identical to the original narrowband idle control, just with tighter thresholds. It does not seem to be classic PID in that sense.

Original narrowband control only knows about "rich" or "lean". A narrowband O2 gives "lean" at 15-ish, and "rich" below 14.4-ish. Between that, it's black-box, and the control system has been designed with that in mind. All fuel adjustments are made with the STFT. The STFT is the control mechanism. Switching rich to lean, the ECU knows it really was at 15+ rather than 14.7, so it immediately adds a few % to the STFT and then slowly adds more % till it hits 14.4. At that moment, it knows it's overshot 14.7 again, and it will pull an initial amount of STFT %, etc. The nature of this control mechanism is oscillatory by design because it was designed for a sensor with high hysteresis. It will never 'target' 14.7.

The wideband mod simply altered this algorithm to always have this control mechanism on (hence the 12.24 open loop thresholds, meaning "never off"), and is coded to interpret wideband >14.7 as "lean" and <14.7 as "rich" without hysteresis. This "rich" or "lean" signal is then input in the original narrowband algorithm, which you can verify in the datalogs btw - that way you can also verify that the lean/rich flip occurs at the correct AFR measured. The algorithm itself is the same. So as soon as it switches from rich to lean, it will immediately add or take the first 'pulse'. Thus it will always overshoot the other way and be oscillatory in nature. It is not true PID.

That said, there are some tables to be found that adjust the magnitude of the "initial pulse" and the ramping speed of the subsequent fine adjustments. I achieved relatively good results but it is a pain to tune, to the point where I decided to just go with a standalone ECU with proper PID. For all intents and purposes, you can get it good enough by fiddling around with these tables. They are labeled in some bins as "P factor", "I factor" and i believe "D factor" too. I have made a detailed post about this a few years ago.

Link to post
Share on other sites

Hello ! Thank you for the detailed answer !

Basically shouldn't the wideband mod's purpose be to "move" the oscillation of reach/lean around the point set in the VE map ? If we set an AFR of 15 at the correesponding RPM/LOAD columns, shouldn't STFT flip point be around there ?

As you are in the short clip I posted, It seems the changing STFT point îs around 14.7 not 15 (requested AFR, IT seldomly reaches that value). Thats's why I question If the mod is really working as expected.

 

Edited by Midnight Caller
Link to post
Share on other sites
3 hours ago, Midnight Caller said:

Hello ! Thank you for the detailed answer !

Basically shouldn't the wideband mod's purpose be to "move" the oscillation of reach/lean around the point set in the VE map ? If we set an AFR of 15 at the correesponding RPM/LOAD columns, shouldn't STFT flip point be around there ?

 

That’s correct

Link to post
Share on other sites

Heeeey ! Piet, I've been trying to reach you for a long tine ! Everything ok ?

As I was writing earlier, it seems like the WB mod ignores what is set in the VE map.

Could you lend a hand please ?

I had some issues with the modded BIN from the first release you sent me (car didn't start), and then the second file worked. Maybe You missed something in there ? Can I send you the BIN to take a look ?

Link to post
Share on other sites
7 hours ago, Midnight Caller said:

Hello ! Thank you for the detailed answer !

Basically shouldn't the wideband mod's purpose be to "move" the oscillation of reach/lean around the point set in the VE map ? If we set an AFR of 15 at the correesponding RPM/LOAD columns, shouldn't STFT flip point be around there ?

As you are in the short clip I posted, It seems the changing STFT point îs around 14.7 not 15 (requested AFR, IT seldomly reaches that value). Thats's why I question If the mod is really working as expected.

 

Your mod should flip around the requested point, yes. If you use the default formula for AFR in your ADX (which is, i believe, the flat 0-5 = 10-20 AFR, linear) you should see it flip exactly around the internally logged requested AFR regardless of what your AFR gauge shows. Log both, and verify. If they match, the mod is working as intended and your Gauge/ECU mismatch stems from either a voltage offset or a hardcoded input calibration mismatch. If you use AEM X-series Uego and use the default bins, then for sure you have the wrong input calibration.

Edit// It's not quite clear to me, what AEM Uego do you use? X-series, or otherwise? The post you sent me in DM regarded my X-series, some (older?) versions of the AEM Uego seem to actually have a 0-5v = 10-20AFR calibration, so that should be good. So then you're just looking at a voltage offset. I remember that being the case when using the O2 input or the gas tank input (? unsure, it's been a while)

Edited by Boxman
Link to post
Share on other sites

I'm not having any differences between the gauge and the logged values anymore, I fixed that yesterday. I am using the right formula which also Piet/venderbroek suggested when they sent me the modded BIN

The issue now îs that the logged AFR isn't oscillating around the requested AFR in the VE map (15)  but rather around 14.7 (maybe a coincidence ?)

I'm.using the AEM UEGO 30-4100 or 30-4110 with Bosch LSU4.9 which outputs 0-5V for AFR 10-20.

Edited by Midnight Caller
Link to post
Share on other sites
  • 2 weeks later...

Ok got my cop setup running. And on the first flashing this happened.

Already had forgotten they must be disconnected. At this time this was cyl 2. Will it affect them randomly or was i lucky others didn't get hit?

Whats the best way to prevent this? Say i dont want the cop wires to be visible to disconnect them every time.

20210415_085725.jpg

Edited by versus
Link to post
Share on other sites

I have had this same issue and fried a Cyl 2 coilpack when flashing the very first time I installed COP. In my case this was due to a 10k SMD resistor on the B10 line missing from old outdated instructions I have used, without those instructions mentioning to disconnect the coilpacks during flashing.

That is to say, I believe the new instructions simply say not to flash with the coilpacks connected, but on my ECU it was fixed by adding that 10k resistor on the B10 line - it mitigates the 5v output to Cyl 2 during flashing.

Unfortunately, and even when looking through my backups, I have since lost the picture that shows exactly which resistor it is. But until that time; just flash with cyl 2 disconnected. It will not happen on other cylinders.

Edited by Boxman
  • Like 1
  • Upvote 2
Link to post
Share on other sites

Welp feels like my ECU doesn't want to be flashed in the car, I'm a bit lost rn.

I wired up a step up converter as shown on the wiki, into pin B8, set it up to 14.5V. The ECU goes into flashing mode as the fan starts and the lambda light is flashing.

But it always(*) end up this way: erasing works but flashing fails.
1466003452_flashingbank0failed.PNG.7bbea96d0a78119f77b38dbe3609f153.PNG

*what's messing really hard with my mind is that out of the 25 attemps I've made, it flashed successfully once with absolutely no changes made to anything compared to the previous or next attempt.


I've tried uping the voltage 0.5V by 0.5V up to 16, no changes.
896307424_ecuflashing.thumb.PNG.7005b3d1a86a0629ecde93f675d748a8.PNG
I unplug the laptop & ECU, bring them inside, plug the ECU on a power supply set at 14.5V and it flashes first try.
Same ECU, same laptop, same VAG-KKL cable (plugged on the same USB port), same bin, same xdf...

Am I missing anything ?

 

Edited by Goupil
Link to post
Share on other sites

I don't know what to say here but.... I always disconnect the fan when flashing (I disconnect the black wire connector that goes on top of the fan shroud).
When flashing, the lambda sign should stay lit ! If it's flashing, it's gonna fail so you could just stop the process and start over again, no need to wait.

Try disconnecting the fan as that draws pretty much current from the battery and (could) influence the flashing process. I myself have like 3 failed flashes on every 10 flashes I do.

Edited by Midnight Caller
Link to post
Share on other sites

I did disconnect the fan today (mostly because of the noise 😅), didn't make a difference.

The lambda sign is flashing when I turn the key to pos II, but it stays lit when I start the flashing process (as it should).

Everything acts like it's working, but it doesn't want to flash, that's really odd...

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.