Boxman

Members
  • Posts

    501
  • Joined

  • Last visited

  • Days Won

    10

Boxman last won the day on April 18

Boxman had the most liked content!

Recent Profile Visitors

6,008 profile views

Boxman's Achievements

Newbie

Newbie (1/14)

106

Reputation

  1. 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.
  2. Do you prefer the OEM rubber control arm bushings over well-lubricated poly inserts? Which one gave the better handling, in your opinion?
  3. Then indeed the bin itself may be broken and not use your table correctly.
  4. 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)
  5. 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.
  6. 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 (https://www.aliexpress.com/item/1547735346.html?spm=a2g0o.productlist.0.0.7b6f2c4bU44ECK&algo_pvid=908ccfa9-a389-4005-abc7-863bba5cdb24&algo_expid=908ccfa9-a389-4005-abc7-863bba5cdb24-0&btsid=2100bdd816172393149013536e9350&ws_ab_test=searchweb0_0,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.
  7. 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.
  8. 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
  9. 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?
  10. You removed the water cooling from a GT3071R?
  11. Bumping this one, summer is around the corner so I'm going to be running into this 'issue' again. 😄
  12. Question regarding the current state of A/C; have any additional maps pertaining to corrections on fueling/ignition/anything engine related when switching A/C been found in the past years? Ever since I switched to M4.4 (Piet's AC mod) from my M4.3 car, my engine will show weird idling behavior as long as the A/C is on. More precisely, with A/C on, as long as I'm still rolling, but with the clutch depressed, the engine will drop down to 2000RPM exactly and idle there. Only after i've come to a complete stop, the RPM's will drop to normal ~900rpm idle after a second or so. Or i'd have to force the RPM down with with shifting to a higher gear, if I force it to 1000 RPM it will stay there. So when driving with A/C towards a traffic light, or in erratic slow traffic where I clutch&roll a lot, I'll be idling at an annoying 2000RPM most of the time. The one A/C correction table I have right now doesn't seem to do much, zeroing it out gives no change, and it seems like something is actively controlling the idler to target 2000rpm. Sound familiar to anyone?
  13. Cool, I'll message you shortly to see if we can figure something out.