Supporting Member
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Tightmopedman9

  1. Not extremely happy about the dyno results considering the condition of the car and the modification list. However, I did make some adjustments to the boost and ignition shortly after the dyno session that would I think would have netted an additional ~10WHP and 10WTQ.
  2. The original code was probably written in C; modules/maps were added, removed or modified as needed by specific markets and model configurations. When these code changes were made the file was re-compiled, moving a lot of things around. Even though the 607 came on autos, and 608 on manuals, they contain the code necessary for both transmission types.
  3. I forgot to mention, but this patch is only for those running 608 tunes, it will not work on 607. I switched from using both tune variants and now use the 608 exclusively, just changing the 'hardware configbyte' when tuning for an auto
  4. The CEL could also come on during the former situations, if you had single knock events which occurred within 2.5s of each other. I don't think a single, isolated knock event should be sweated over, but if you see that during logging the you have the same single knock event occurring at the same location RPM/load wise then you should probably adjust the tune to compensate.
  5. Don't look at BITS for knock, just look at KRCOUNT, it indicates how many knock events have been detected since the last log frame. You should keep the adaptive and active knock settings unchanged, reducing them is only going to mean that the computer will get rid of the ignition retard quicker, thus having you hit knock again sooner. If you are knocking then you need to address it in the tune, and you should have the ECU pulling timing for as long as possible so you don't hit knock again until the tune is adjusted. There is a measurement window for each cylinder in regards to knock; the ECU listens to every combustion event for each cylinder, regardless of RPM. If knock occurs and the ECU pulls timing, then timing will be pulled in time for the next combustion event. The ECU can't predict knock, it can only react to it. Knock on decel is most likely not actual knock, but rather erroneously detected knock by the engine rocking back and forth. I've noticed that engines with entirely rigid mounts have a much lower propensity to show these erroneous knock events.
  6. Knock is detected on a per cylinder basis, when knock is detected 2.25º of timing is pulled from the cylinder which knocked. There is an adaptive map that remembers this timing pull based on RPM and load, so the next time you roll through the same area of RPM and load the 2.25º of retard will come back on that cylinder to prevent knock from occurring again. The amount of time the timing retard stays remembered for is specified by the two maps adaptive and active knock control. I'm not 100% on this, but I believe these maps specify the number of ignition events required to 'forget' .75º of timing pull. There is a number which is the sum of ignition retard across all cylinders, XFALMIT. The previous routine would toggle the CEL when XFALMIT would go above a certain value as specified in the .bin, the default value is 15º. So, lets say you were driving t 4500RPM and 8ms of load and you hit enough knock to bring the cumulative sum of ignition retard to 20º. Next time you enter the same load range, ~3500-5000RPM and 6-9ms of load, the CEL will illuminate telling you that ignition timing is being pulled, but you don't know if that timing pull is due to knock that was just registered, or from timing retard that's been hanging around from the last time you encountered knock.
  7. UPDATE, PLEASE READ I've re-written the code that toggles the CEL when knock is encountered. Before, the CEL would toggle when the cumulative sum of ignition retard due to knock would go above a certain value, that means the CEL could sometimes (and would usually) trigger when no actual knock was detected. The new routine I've written will actively flash the CEL (not just toggle it) for 3/4 of a second every time there is 2, or more, knock events with 2.5s or if there are 3, or more, knock events within one main loop iteration. A single isolated knock event will not trigger the CEL. I've seen too many people turn off adaptive knock to avoid the toggling the CEL, in my opinion this is just opening yourself up to unwanted engine damage. If you have disabled adaptive/active knock I would highly suggest turning it back on after patching your tune with this file. To install the new code in your tune, and remove the old CEL toggle code, download one of the two files below, depending on your computer's processor type (x86 or x64), browse to your current tune, check the 'Do no validate file name' box and hit start. Your original tune will be backed up as a .bak file. MIL Flash - 608 - x64.exe MIL Flash - 608 - x86.exe
  8. PM me here, I'll give you my email. The contact form on my website has been working for the past few months
  9. Dougy, why don't you just read my sig? EFR7064, R manifold
  10. 4" MAF, I'm at 1700kg/hr which is 4.19V.
  11. When I had a 20G I used that same Jaguar box and fit the largest filter I could in there, and it was still quite a small filter. I wouldn't recommend it... The filter I use is the AEM 21-3059DK which is 6.5" in diameter and 9" long. I think that filter is almost the same size as the Jag canister itself. Granted I don't have a pre-turbo pressure sensor, but I wouldn't want to use any smaller of an air filter.
  12. Yes, much better. Those PLX devices are pieces of crap. Have you found an AFR target of 12.3 to be best for power, or just a good middle road for conservative fueling? I aim for 12.4 on my setup currently.
  13. I don't run a battery tray in the bay, I used a simple rubber cushinon steel screw on clamp and just secured it to the side of the engine bay using an existing tapped hole/nut. You could braze AL, but this is a car... and it would look like shit. I can make you a copy of my intake setup if you want.
  14. Given the baud rate of 125000k, you could theoretically datalog 50 parameters at ~250hz. I redesigned the logging routine and placed it into a timer overflow routine of the ECU, now ever millisecond a single data parameter is sent out. I reduced the amount of logged parameters to 38 (including header and footer), since logging speed is now directly related to log frame rate; I get 15hz irregardless of RPM. I'm working on placing more calls to the routine in other interrupts, which should speed up the routine even more. My goal is 30hz.
  15. I think that 'list' at the beginning of the thread is pretty useless. I was reading another thread about the ECOtrons and someone was saying how the response time was slow as well, I'll see if I can find it again. I have no personal experience with the ECOtrons, so I'm just parroting what others have said. By processed fast enough do you mean reading the serial data on the ECU side? If you setup a serial interrupt and put it at low priority you'd be able to parse the data just as quick as an ADC, if not quicker. Yeah, that would be nice. I have a problem with the MTX-D (oil and temp sensor) and the reading seems to be highly influenced by noise. I was planning on building a simple passive filter to deal with it, but I have yet to scope the signal to determine the best course of action.
  16. The CJ125 chipset is simple to interface with, and it controls all aspects of wideband control according to Bosch specifications, the draw back is that it is slow. The ECOtrons unit may update the analog output at 200hz, but there is no way that it is outputting relevant information at that speed. I believe the CJ125 chip is limited to about 65ms response time (15hz). The MTX-L is a poor choice for comparison, since it has no dedicated sensor ground, and the heater control and LED control all switches from the same 5V rail. It is very sensitive to electrical noise and their non-standard control of the wideband heater doesn't bode well for sensor life. The Yeah, the bias from the moderator in that thread seems off, and Alan seems pretty arrogant and stubborn, but despite that there is a lot of useful information to be gleaned. They make 2 versions, an inline version and the gauge version. Both have dedicated electronics ground. If we are talking about functionality I think the extra cost is easily justified. Why not just convert CAN to serial and then send that to the 2nd serial channel input on the ECU? This is something I am currently experimenting with... For M4.4 WBO2 regulation to approach the accuracy of ME7, the narrowband emulation scheme needs to be abandoned, the fuel regulation must be based on the absolute deviation of the target vs the actual AFR. Also, something I am currently experimenting with.
  17. Regarding wideband selection, I would probably stay away from the ECOtrons unit, or any other unit that uses the CJ125 chip. If you want to spend a few hours reading: http://forum.diyefi.org/viewtopic.php?f=6&t=2267 http://www.hptuners.com/forum/showthread.php?56106-Ngk-Afx-wideband If you don't feel like reading, get the AEM X-series wideband.
  18. While the second stage is engaged do you zero out the adaptive LDR values? It's funny, but just last week I coded a routine which does almost the opposite of your routine. When the throttle is more than 50% depressed the TCV is held shut until XP_IST is 1.25ms under XP_SOLL, while zero'ing out the adaptive LDR values (FFB5, FFB6, FFC0).
  19. I wasn't talking about physically having the sensors on the engine, but rather dealing with the fact that the output from the ME7 cam wheel/sensor ≠ the output from the stock cam wheel. The ME7 cam wheel has three unequal length notches, which allows the ECU to determine where the cam is within a fine range (I'm not exactly sure the exact resolution, but I think it is accurate to 1º). The M4.3/M4.4 cam wheel only has one notch, 180º in length. If you built a VVT circuit you would need to emulate this binary signal from the ME7 wheel. You might be able to do VVT control with the binary M4.X wheel, but I think control would be limited quite a bit in resolution.
  20. The immobiliser is separate from the ECU. To defeat it you need to do more than just flash a non immo .bin to the ECU. To use the tune on the old ECU you would need to desolder the chip and read it using an EEPROM reader, since there is no provision for reading the code in situ. You would then need to do the same on your current ECU to extract the immobiliser code, then write this code into the new tune. If you read the EEPROM chip from both ECUs I could clone the immobiliser code for you.
  21. http://www.ebay.com/itm/TURBOSMART-TS-0203-1261-BPV-Kompact-re-circ-Borg-Warner-Volvo-Porsche997-KKK-EFR-/281852736024?hash=item419fbb7218:g:cmYAAOSwTZ1XnM4M&vxp=mtr I got mine for 134 three months ago, maybe you can do best offer and get the same price.
  22. Nice, that fitting looks very low profile. Are you going with the dual port wastegate and 4 port solenoid? I replaced the CBV on mine with the turbo smart as well; it didn't do anything for performance but the stock CBV made this super annoying (I thought) whine at light throttle.
  23. Checksum is in the same location, so I don't see why it wouldn't. Here is a 960 .bin: https://www.dropbox.com/s/z1qxnllzm5q5gn8/960.bin?dl=0 Here is a .xdf I spent probably less than 5 minutes on a year ago: https://www.dropbox.com/s/w4o1w6h1citki72/960.xdf?dl=0