• Posts

  • Joined

  • Last visited

  • Days Won


Boxman last won the day on April 18 2021

Boxman had the most liked content!

Recent Profile Visitors

6,813 profile views

Boxman's Achievements


Rookie (2/14)

  • Dedicated Rare
  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • Posting Machine Rare

Recent Badges



  1. Definitely possible with Megasquirt, which I now run. However, back in the day when I stilll ran Motronic 4.4.. Also possible:
  2. Here's my previous post about MAF factor in 540i housing, for anyone wondering, showing a raw data plot of an early measurement of the factor across the entire flow range. This was for a 540i housing specifically with default intake setup. I went on to measure and accurately characterize a proper curve for my specific setup. The take-away is that for the meticulous ones, there is a lot of fine-tuning to be found especially on the lower end. High-flow variations are easier to catch with minor VE-table adjustments.
  3. You'd be correct on that one. Even though the air is straightened somewhat by the roster, flow in the middle of a tube is generally faster moving than at the edges. Hence, a sensor placed more in the middle might need a lower factor. ( Idle performance with the default factor is really poor. Like I said, mine went upwards to 2.3 at low idle. It seems you have similar experiences - needing a higher factor at idle than at load. Indeed it's a very fair point to make - the factor isn't a straight-forward plug-it-in-and-it-works. I went with the characterize-my-MAF method since I felt it less work than remapping the entire VE without a dyno. Unfortunately, this kind of discussion was often slammed down by the ones who made the first approximation of the conversion, as an over-confident "it doesn't matter and this is diminishing gains". I think pride played a role - who knows. Fact is, there is a lot to be fine-tuned, even in areas where certain people said there were no gains to be had.
  4. The 1.94 'factor' was intended for a default off-center application of the sensor, no modifications to the housing. It would work 'relatively' well, but it is not a straight factor. Especially in low flow situations (<100kg/hr) the factor was quite variable, possibly since the actual air speed is just a bunch lower and you're working in the area of the sensor where small absolute variations (but very large relative / %-wise variations) are not recorded accurately due to the sensor's resolution. I have characterized it like 5 years back to excruciating detail with bench-setups and 10kHz datalogging, and found that in the lower regions a factor of 2.4 was more accurate, which then slowly settled to the 1.94 reported here. The way 1.94 was derived (i was sent the source data) truncated any low-end accuracy. That said, it doesn't really matter. It 'works', as long as you completely re-map your VE tables to account for these changes. I myself characterized an accurate translation curve for the MAF, but remapping VE would've given the same results. Not sure which one is more work. I wasn't able to find my factor graph just now or I would've posted a picture of mine - it was very oscillatory in the lower end with values between 2.5 and 1.8. tl;dr - 1.94 isn't the whole story, that was a very simple linear regression that assumed ideal single-factor translation and ignored a bunch of low-end data as a result. Depending on how meticulate you are, you have to re-map or accurately characterize your own factor with bench-testing.
  5. 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.
  6. Do you prefer the OEM rubber control arm bushings over well-lubricated poly inserts? Which one gave the better handling, in your opinion?
  7. Then indeed the bin itself may be broken and not use your table correctly.
  8. 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)
  9. 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.
  10. When live data-logging in TunerPro, I assume you adjusted the formula for the wideband to match your AEM. This is why in the datalog, you will see the same values as the gauge. However, this formula does not change anything in the BIN, so it will use the original hard-coded venderbroeck calibration. Internally, the ECU does not even convert to AFR. It just gets a voltage, and will target whatever voltage the ECU deems to be 14.7. So if 14.7 on the original calibration was 2.35v, but the new AFR gauge is 14.2 AFR at 2.35v, the ECU will still target 2.35v and hence 14.2 AFR. Regarding the dump-valve; if you want a dump-valve and do not wish to recirc it, you must use a dual-piston dump-valve, to ensure seal under vacuum and part-load. Normal dump-valves may leak under vacuum and part-load. Even if this is minor, it will still throw off AFR. You can only really run single-piston dump-valve like the FMDV001 when using absolute pressure (MAP) instead of speed density (MAF). If you must have Forge, they offer the FMDV004. However, I also bought the standard double-piston valve from Aliexpress (,searchweb201602_,searchweb201603_) to compare side-by-side, and quality is similar, operation is identical. Forge imo is heavily overpriced, there is nothing special about their twin piston BOV and their tuning spring prices are borderline criminal. Regarding the bin, i've replied to your DM to see if we can frankenstein something between our bins. Unfortunately, with your bin the easy fix of just targeting higher AFR is slightly problematic due to the VE and AFR target tables not being separate. Tightmopedman eventually implemented this in my bin and I loved the versatility it gave me to test things and to fine-tune VE to get a better open-loop response. If you want a flat AFR response, IMO the one-table-fixes-all approach is inherently flawed, as it throws the concept of a VE table out the window entirely and instead solely relies on the wideband control algorithm. Oscillations will be larger than they need to be at the point where you switch from 14.7 to 12, and all open-loop small corrections you could have been doing around your idle and part-load (or even correcting for your open BOV if you so wish) will be lost.
  11. Ostrich completely replaces the ROM chip and is just a ROM emulator afaik, and has capability of live tuning. That would suggest that M4.4 constantly uses flash-rom to get values.
  12. Ah, that helps a lot, I can definitely work with that! I assumed "Ki" was the value in the injector constant field, didn't know it was a lot more intricate. Reverse-engineering it based on logs indeed seems the way to go. Thanks a lot! I'll get on that and will probably deliver ported maps for Megasquirt soon
  13. Been a while - do we know the exact way the ECU calculates load? The formula found in the m4.4 datasheet (Q/(n*Ki), with Q = MAF in kg/hr, n=RPM and Ki=injector constant) doesn't seem to be quite right. I can't reproduce logged values of load from logged parameters and injector constant. Missing a factor 26-27 with a random +- 1 component when just putting that in, so which parameters does the ECU use exactly, and in which units, if anyone knows?