Tightmopedman9

Supporting Member
  • Posts

    3,949
  • Joined

  • Last visited

  • Days Won

    33

Posts posted by Tightmopedman9

  1. On 11/18/2021 at 12:24 AM, Turboforslund said:

    Hi,

    24.48 is only better resolution afaik. I run GTX3076 (with pressurized 3" MAF) and 12.24 ms Software without issues.  Approx. 450hp.  

    // Turboforslund

    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. 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. 

    On 12/11/2018 at 1:26 PM, lowkeyturbo said:

    My car idles rich if its completely cold on startup tats fine.

    BUT it idles lean if I start it and it has not fully cooled off (Lets say coolant temp of 40C). I dont get it??? Do the warm-up maps not take dead times or injector constant into account?

    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. 

  4. Please refer to this post for correct information

    Spoiler

     

    Regarding the AC issue, I ran into this problem on a '97 850 once and through a XRAM dump I found F96F.4 was being set.  I believe this is an expected current draw too low error, but I can't find my notes from the diagnosis of the problem so I'm not sure. 

    I removed the error check for this bit in the AC routine, and changed a few other bytes. Honestly, I'm not sure why I changed the other bytes, but I attached a screen shot of the differences made between the two .bins. The .bin on the left had functional AC, while the one on the right did not, and had the stock 608 AC routine. 

    AC fix.jpg

     

     

    • Upvote 1
  5. 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. 

  6. 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. 

    • Upvote 2
  7. 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.

    4-RH

    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. 

    • Upvote 1
  8. 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?

  9. 1 hour ago, Boxman said:

    I'm interested to see how your wideband adaption works out. I think it's a very solid idea, actually making it more PI-control-like.

    Something different; do we have variables somewhere that control fuel cut when lifting off the throttle completely? Like RPM thresholds etc. It consistently re-engages at 2000 RPM but I'm not finding a variable for this anywhere, and if possible I'd like it to kick in sooner when I lift off the throttle. Seems to take about a second currently.

     

    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. 

  10. On 11/20/2017 at 12:41 PM, Piet said:

    The result of these calculation are put into:

    F814  (Reglersteigung)             in case of R2 is #0        (F12C is read in routine_2AEF)

    F815  ( Reglersprunghoehe)   in case of R2 is #1        (F12D is read in routine_2AEF)

    F81C  (         ??                 )              in case of R2 is #3        (F12F is read in routine_2AEF)

    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. 

  11. 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. 

  12. 9 hours ago, gmsgltr said:

    ugh. i gotta get back in touch with Aaron... i STILL cant seem to connect and log and i had a few flashing CEL's this weekend with knock. i do need to stage 0 and or go to his COP system asap too. Not his fault - all mine lol... i am an absent parent to my R lately :(

    Hey Greg, could you e-mail about these problems? No need to clutter this thread. Thanks

  13. 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.

    1 hour ago, Vykis199009 said:

    remind me please, why none uses MBC and all waisting so much time on boost control via tetris ecu ? not like ecu will be fast enough to prevent overboost with huge turbo or anything... only advantage of it would be boost target via map sensor or if you wanna make to spool turbo later than it could. just my 0.25$

    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. 

    • Upvote 2
  14. 23 hours ago, Boxman said:

    Can the EVAP code just be moved back without harm to the rest of the bin (e.g. what code exactly did it replace), and is there a bin online somewhere that still has this code?

    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.  

  15. 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.