Supporting Member
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Tightmopedman9

  1. I wouldn't say that. I have tuned cars which produce up to 22ms of load. For those cars I'm definitely programming a different ignition angle at 22ms vs 12.24ms. Also, if you want to run target load you won't be able to if you're hitting the load cap.
  2. I really appreciate the work, I've been working on a routine to log the cam angle, but haven't made much progress - this will really speed things up since cross referencing the DAMOS gets pretty tedious after only a few lookups. I'd like to monitor cam angle for VVT purposes. NVM on the following stuff, P1.6 is the external clock output. I'm assuming that the cam signal is tied to P1.6. In Reset_0 the status of P1.6 is moved into r_FLAG1.7 (camshaft level with status 'found_located' (PH_OLD)). In the crankshaft triggered interrupt, IEX3,there is a JB based on r_FLAGBM.4 (phase change not yet recognized. (ZDGVERB)), if this bit is set then the status of P1.6 is checked. Since P1.6 is tied to IEX6 and IEX6 isn't used, I assume you could write a bit of code that moves the crank angle to a spare XRAM when IEX6 is triggered. Based on the sab80c517a datasheet it looks like the interrupt would fire at the rising and falling edge, so you could poll the status of P1.6 and have a separate XRAM depending on which edge triggered the interrupt. This would allow you to see the relative motion of the cam angle when triggering the VVT solenoids. I'm having trouble finding the variable that contains the crank angle in .75º degree increments, if it even exists.
  3. Thanks very much for that! I've spent a lot of time in IDA and I tried for a little while to import RAM variable names, but couldn't figure out an automated way to do it so I gave up on it. Did you write a script, or is there some easy way I'm totally missing?
  4. That cable you linked is the incorrect cable. You need a VAG-COM cable, which is a 'dumb' cable which does nothing to the signal between the OBDII port and computer. Make sure that you get a VAG-COM cable with FTDI chip.
  5. Saw Brandon off today, I'm glad to see the car finally leave, but a little sad that I won't be able to work on it anymore. Really makes realize how much I miss my own car. Who's up next?
  6. Sorry for the confusion, I typed up that response hastily and didn't really pay attention to what I posted. I was able to find my notes from the 'fix' and the problem was that the compressor would click on once, and immediately turn off, never to turn on again until the car was restarted. Maybe it was just a problem with their AC pressure sensor malfunctioning, but they did mention that they tested high and low side pressure when the problem was occurring and both were in spec. Probably disabling the pressure error shut off isn't the best course of action, but if you want to do so you can set 0xCAC6 & 0xCAC7 to 00. It could be that you need to increase the cold start factor at higher coolant temps, while leaving the lower coolant temp values the same.
  7. Reduce your acceleration enrichment at low coolant temps, there is another accel enrichment table at 0xCFA4, same size and axes as the other tables. Also, reduce the values in afterstart enrichment at 0xD8B4, single axis table, 16 values long. It is impossible to get the 850 MAF to sit in the center of the 540i housing, it is off by more than .75". I stopped recommending this housing because it is a pain in the ass to tune. Avinit, I like the hole in your board so that you can solder the pins to the board in situ, very smart.
  8. I hate how the engine always rotates when using the harbor freight support straight across the engine. That's a good idea for the center support. Where'd you get it?
  9. @ejenner2004 is ME7. None of this thread pertains to your car.
  10. Why not use the ACT disc? That's what I used and it is a much beefier disc than the SD693.
  11. This LDR routine talk is exactly why I created the 'boost quickener' mod. Any time you floor it and the current load is 1.25ms (can be defined) below the target specified in the target load map the TCV is held shut and the P and I factors of the LDR routine are set to 0. When the load is within 1.24ms of the target load the LDR routine resumes. This guarantees maximum spoolup and minimal overshoot. Regarding the MIL flash due to knock, I need to update the patch file as I made some mistakes in the code. I've reworked it and will upload a new file soon.
  12. That was just a quick idle and throttle blip from my car. Clutch still isn't working so I can't get running drive logs from it. I shouldn't have posted that, because it really makes the control look much more ineffectual than it is. The new routine directly replaces the stock I factor RPM vs load lookup. I quickly ditched the single axis, non RPM dependent lookup and replaced it with a AFR deviation vs RPM lookup map. The AFR deviation axis is in units of AFR and the scale of the axis is determined by your AFR gauge. I still need to play around with the AFR deviation axis and tuning of the factor, but the above map seems to give pretty good control of the AFR, even if the tuning of the 'VE' map isn't so spot on. At idle I find that with an I factor of 1, and the P,D variables set appropriately, the AFR will stay within .1 of the target. I think the next step in wideband control would be feeding the AFR into the ECU via serial input instead of analog 0-5 voltage. I'll send the code to Piet and Venderbroeck if they want to incorporate it into their wideband regulation mod. I'd appreciate any feedback for tuning of the map.
  13. I'm going to redo the map lookup with a better map lookup. I'll use an interpolation factor and the axis will be the AFR deviation in .15 increments. I'll include a ROM variable that is equal to the slope of the wideband curve so it will be easy to port to different tunes. I'm starting to wonder about the effects of exhaust gas velocity though; maybe I should create a 8x8 RPM vs AFR deviation map?
  14. It worked. I just need to figure out how best to tune the map. The AFR swings look over exaggerated in that shot, but I have the axis set to a pretty narrow range, from 10-16. Right now the lowest I value is 8, but I bet I could set that even lower, perhaps even to 0.
  15. Have you looked in the DAMOS? A quick search and I found TVSA0G,{Verzögerungszeit für Schubabschalten 0. Gang (LL)}. 6x1 map located @ 0xCAD9 in 608. Conversion = 11.9040 * X, 1=12ms. X axis is 0,1,2,3,4,5. There appear to be other fuel/time related tables in the SA_WE map group as well.
  16. I investigated those XRAMs a while ago, but found no references to them outside of that function. I added F814 and F815 to the logging stream, but never found the values to change. Thinking about these values made me investigate them some more and I looked at some old XRAM logs I have. Looking at the values I found for F814 and F815 in those logs, F814 corresponds to the values from the I factor map and F815 the P factor map; not much of a surprise there I guess. I traced the logic (and probably failed, lol) and I think the easiest thing to do is to change the MOV DPTR @ 0xBB57 to an LCALL of a new function which takes the difference between the current AFR and target AFR, uses it as the variable for a single axis map lookup, then places the value in F814 instead of the 2AEF routine. PUSH ACC MOV DPTR, #07FEFh ; Adaptive I-part setbit MOVX A, @DPTR JNZ RUN_ROUTINE ; If setbit = 0 jump to end of routine POP ACC SJMP REPLACE_DPTR RUN_ROUTINE: MOV DPTR, #0FDAEh ; Target AFR XRAM MOVX A, @DPTR MOV B, A MOV DPTR, #0F962h ; Rear O2 Voltage MOVX A, @DPTR CLR C SUBB A, B JNC NEXT ; If result is negative complement and +1 CPL A INC A NEXT: MOV B, #0Ah DIV AB ; Divide result by 10 for use in single axis map lookup MOV B, #0Fh CJNE A, B, NEXT2 ; A = AFR Deviation/10, B = 16 NEXT2: JC SKIP ; If A >= 16 no carry is set, skip setting A to 16. MOV A, #0Fh SKIP: MOV DPTR, #07FC0h ; Dynamic I factor map location MOVC A, @A+DPTR REPLACE_DPTR: MOV DPTR, #0F814h ; The DPTR we replaced RET This is the routine I came up with real quick. The divisor by 10 is to scale the deviation so that we can have a 16 byte length map lookup. You would probably need to change the divisor based on the absolute output range of your AFR gauge. I based 10 on the AEM UEGO which ranges from 7-20. I'll give this a log and see how it goes.
  17. I've been trying to figure out the map lookup and logic for the PID control of lambda regulation, but haven't been having much luck. I've tried to find where the maps are referenced in code, but I can't find them addressed in any manner which I'm familiar. I thought about looking at other maps of similar 7x6 size for the way they're referenced, but the 3 P, I, TV maps are the only ones this size. I've cross referenced every .bin and can find no MOV DPTR to a location even close to the location of the maps, even in the 570 .bin. I've also tried looking at where the other lambda regulation parameters are referenced, but that didn't help. Also, Piet and Venderbroeck, where did you find any reference to F1C2 and F1C3? If I cross reference them to the 449.bin I see the same parameters are located at F114/F115, and are referred to in the DAMOS as FTEADMN - 'Minimalwert der Beladung des AKF's' and FTEADMX - 'Maximalwert der Beladung des AKF's' and they are under the category 'Tankentlüftung beladungsabhängig'. I can't find any references to them in the actual code. The reason for the curiosity is that I think the wideband lambda regulation routine could greatly benefit from a dynamic I factor. AFRs could become much more stable if the I factor was a dynamic variable related to the absolute deviation between the target and current AFR, vs a static map based on RPM and load.
  18. Same thing on my injectors, I lowered my rail about 1/4" with new stand offs.
  19. Hey Greg, could you e-mail about these problems? No need to clutter this thread. Thanks
  20. The LDR routine is LCALLED from the running loop. At 6000RPM the running loop is fully executed only 3 times a second. Compound that with the change limitation on the I factor and the boost regulation routine is actually pretty damn slow. With that said, I still think it has a lot of practical use. On most TD04H turbos a properly setup target load map can prevent boost spikes and keep boost equal through gears. The difference in driveability between boost controlled via an MBC vs M4.4 is huge. With throttle position controlling target boost you gain a much more linear, naturally aspirated feeling torque output. To maintain a constant acceleration you don't have to roll off the throttle as the RPMs rise like you do with an MBC. The power output with an MBC is nearly binary, very much all or nothing. You don't have to run the target load setpoint routine, you can just run a straight TCV duty cycle map. Even this yields a much better driving experience than an MBC. Without an adaptive routine the ECU is changing the TCV duty cycle in response to TPS and RPM many times faster than would be needed to avoid a boost overshoot. Boost overshoot using this tuning method would only happen due to poor tuning. @Boxman Have you seen this thread? Many of the boost routine stuff you talked about are covered in there, and in the first 45 or so pages of this thread. I always start a tune without any input from the LDR routine. Once boost is tuned to an acceptable range throughout the RPMs I then build a load map based on logs from the TCV map. I don't think it's a revelatory idea, and I don't know why anyone would tune any other way (although ARD still seems to do it this way, lol). To turn off the LDR routine just set KFP and P-Part to 0. Once I implement the LDR routine I usually never increase the P or I values above 50% of stock. For large turbos I designed a routine which holds the TCV fully shut above 60% throttle, if the current load is 1.3ms under the setpoint in the target load map. While doing this it also zero's out the P and I factor, avoiding adaptive overshoot for when the LDR routine turns back on. I've only used this on larger than TD04 turbos, but it might work well with them as well.
  21. No, not easily at least. In order to move it back I started from a factory .bin and changed the location of many RAM variables. I deleted/re-coded the majority of Mercuric's code as well and spread it throughout the .bin since there wasn't a continuous section of free ROM space available. You could try decreasing the diameter of the outlet of the EVAP canister so that the venting of the canister wouldn't be as significant a portion of the total intake charge.
  22. Sorry, the routine wasn't entirely deleted, but it was truncated. The code used for the EVAP diagnostics was removed and was replaced with the code that was executed when the EVAP diagnostics check bit was disabled. I had similar issues with rich spikes while idling on my own car and a few customers' (not all though). I moved the EVAP code back and the issue seemed to never come back.