Simply Volvo

Members
  • Content Count

    2,542
  • Joined

  • Last visited

  • Days Won

    32
  • Feedback

    0%

Posts posted by Simply Volvo


  1. 2 hours ago, VulvaS40T4 said:

    Flow tested new modded intake manifold. Same result with + - 0hp difference. Cannot understand this but will have to test on dyno next if flow bench does not tell hole story. :)

    Is it possible the the inlet from the diffuser to the plenum is causing a restriction?

    What is the flow on the edelbrock manifolds, that other s40 users use?

    Did you end up flow testing the stock manifold?  Im very curious to know the flow.

    ~Matt


  2. I'm a bit surprised by your choice for the ACT clutch, normally you would say that the 707 in combination with the R disk can maintain the right amount of torque for your setup. Any specific motivation tgat you went with ACT? Would be interesting to know, as I am dropping in my 707 next weekend with R disk.

    He has a m66, he can't use a R disc, different spline count...

    707 + 850R disc is fine for 700NM.

    • Upvote 1

  3. Such a shame, sorry to hear that Marko :(

    I know you'll get it up and running though again, stronger and faster than ever. Looking forward to future results.

    Will you have to shave the head 0.1mm now? Im assuming you can reuse the pyramid rings, but will need a new modified composite head gasket?

    I tried emailing ProEngines, but they never responded to me.

    ~Matt


  4. Your fuel lines look very professional.

    Quick question,

    How did you secure them to the chassis? Did they fit under the stock fuel line carrier? Or did you use some sort of hose bracket with self tapping screws.

    Thanks.


  5. IMHO it might be wiser to just rewrite MAF ADC function to use full 10 bit resolution for low values and place additional translation curve for that (for example for 0-1,25V range additional 255 values for better resolution). If M4.4 is in fact based on SAB80C517A/83C517A microcontroller it should be capable of 10 bit ADC... For example my M2.8.1 does use 10 bit resolution for some channels in stock form.

    Ah yes. Didn't even notice that...

    According to the data sheet...

    The MCU has two reigsters for the ADC, a high and low byte.

    ADDATH(D9) and ADDATL (DA).

    The other two bits are in ADDATL (DA).

    Great info...

    My only concern is how would I go from a lower resolution to a higher resolution curve without physically testing the flow data.

    I should be able to calculate the polynomial equation in excel and then just plugin in voltage values to get air flow...

    I think piet saying its probably a 3rd or 4th order polynomial.

    EDIT ok found the equation of a 6th polynomial for the stock curve. I then used 10 bit adc reoslution in .0048 steps and plugged it in, this gave me my new curve in .0048 resolution. I then multiplied that curve by 3.8 for a 5in OD housing. Then converted to .125 steps. Resolution is a lot better... Did i do that correct?


  6. Really nice work on the speed density, certainly from a mathematical and programming point of view !!

    But I'am not really sure about the necessity of it though.

    The 16 bit resolution of the normal MAF routine is more then sufficient enough for a bigger  MAF, even a 5" OD MAF would not give any problems I guess. 

    For a 5in OD MAF, I used the multiplier of 3.8. This gave about 2-3 kg/hr per .0196V. That doesnt seem too bad. I think with a higher idle (due to cams and big injectors), the low end resolution wont cause too much of a problem.

    Maybe Ill give it a try then, before I go through all of the extensive work of converting to speed density.

    The 5in OD will support 3100+ KG/HR or 110 lb/min, which i think should be plenty for my goals.


  7. Nice! Be interested in seeing how it plays out, especially over a wide range of load and ambient temps. 

    You are going to keep the 12.24ms load table though? That doesn't make much sense since you will be maxing that out very early on.

    Well fueling, ignition and boost would use MAP vs RPM, so I wouldn't need to rescale load table. Since the fueling is based on 16 bit load which doeskin max till quite high number (90 ms I think), I wouldn't need to.

    Simply Volvo, IMHO you are trying to reinvent the wheel ;)

    There are already devices on market which do what you are trying to achieve with your Arduino (for example polish Ecumaster DET3 is capable of MAP to MAF translation after getting proper data using something very similar to your history table) but that is not so important as you are only going to use it temporaily.

    If I were to code something like that into ECU I will just try to find Bosch Motronic ECU using MAP sensor as main load source in stock form. AFAIK there were M1.5.4 used in Ford/Mazda which depending on engine used were using MAP or MAF. I have not disassembled that code but checked how MAP linearisation looked in those MAP based ECUs - it was still like a MAF linearisation curve (256 16 bit values written same way as in M2.8.1/M4.3/M4.4). To simplify your work I would just try to reuse Bosch load calculation code as it seems it is well tested and might be just more efficient (you will not have to recalculate pressure into air mass which is further recalculated into load).

    You can find M1.5.4 bins I was taking about here - Mazda 1.4 engine and here - Ford 1.3 engine. Both are 8051 microcontroller based, so should be quite easy to transfer load calculation into M4.4.

    I have to admit I am still against removing MAF sensor from daily driven car as MAP will make it much more lambda correction dependent.

    Perhaps it would be better to move to HFM5 MAF (which requires 5V reference voltage supply), those have higher measurement capabilities. The only downside is you are loosing 0-1V range as HFM5 measures reverse flow in that range. If you are sure about exact Infineon controller used in M4.4 you can always try to use 0,9625 as lower reference voltage for MAF ADC but it seems newer 8051 derivatives does not allow changing reference voltage in code (at least Infineon C517A user manual state's so).

    Very interesting, thank you for the references. Time to do some disassembling.


  8. Hi everyone.

    For my power goals I decided MAF would not be appropriate for me as I would require a 4.5-5" OD MAF. I decided to start working on my m4.4 speed density conversion I posted a while back. I made some progress this weekend.

    Basically my method uses the ideal gas law to estimate air flow in KG/HR based on boost, displacement, IAT and RPM. It then plugs that KG/HR value right into the stock load equation (which i see no reason to change or modify).

    I figured out all of the math I have to do on the ECU as well as all the conversion factors for boost, displacement, R constant, IAT, RPH, etc ,etc. I then planned out the entire calculation routine and its 100% possible to perform the ideal gas law equation on the ECU using the MULT/DIV Unit. And for IAT I will use the stock ambient temp sensor channel and for MAP I will use the MAF channel. This will open up the whatever channel you use for your map sensor, for another sensor such as EGT or EBP.

    Before jumping right in and coding the routine, I decided to do a little test. This test consisted of an arduino, with a map sensor hooked up to it and the RPM cluster signal hooked up to it. I didnt use a baro or IAT sensor and simply calculated the airs density that day.

    The arduino then put out a 62500 PWM signal to the maf connector (MAF ADC must have some filtering built in because there was no PWM ripple issues). I modified the table for 1kg/hr increments for a max of 255kg/hr, this made it easy to output KG/hr because as long as it wasnt above 255, i could just write the byte out.

    Right now the arduino is using a 1x14 2D VE table. I got the car idling and driving and took it for a cruise through my neighborhood. Tapping the gas more than 10% usually caused it to stall and when slowing down, it would shut off.  It needs work though. The 2D VE map is way too small. For instance, when starting the car usually the RPMs go up to 1500 then drop down to idle. This is a problem with a 2D VE table because when tapping the gas from idle, the air mass increased a lot, so you need a higher VE value, but when starting the throttle is closed so you dont need a big VE. This means when starting the car would run very rich and start hunting, but you would be able to give it gas from idle. Vice Versa.

    My next step is to create a history table of boost vs RPM and fill it with MAF data (KG/HR). Then I will do the same thing for the arduino, boost vs RPM filled with calculated KG/HR. I can then perform MAF/Estimated MAF and start building a 3D VE Map, which will consist of boost vs rpm filled with a multiplier (VE).

    Eventually once the system is running using the arduino I will simply write the code for M4.4 and it can be plug and play for everyones enjoyment.

    The good part is this will be a true speed density conversion, looking at evo and subaru conversions, they usually just correlate MAP to a load value, then use crazy RPM vs VE modifiers. Not really what i see necessary due to the fact our load calculation already takes in air mass, so why modify it? That will just require to rescale / remap every single thing that uses load. Load will still exist, it will just be used for fueling, and for compatibility reasons so I dont need to rescale every map that uses load.

    I plan on making fuel, ignition and boost maps MAP vs RPM.

    • Upvote 1

  9. Looks great! No more copper gasket?

    When the rings bite into the cylinder head to make the seal, does this mean you can only use the cylinder head once?

    Any custom machining?

    Any information on where you purchased that from? I'm considering making some changes with my head gasket setup.


  10. ​Thanks.

    This was at about 27psi in 4th :)

    The load table will be revised, not sure if the RPM scaling can be altered globally without serious work, I'll ask them about that.

    Yeah, not sure about the MAF housing. But, not going to say no, since that hasn't worked in the past :)

     

    ​Ahh okay 27 psi, that makes sense then. You should be making some pretty decent power at this point, probably very very fast.

    It should be the same procedure as a rescaled load axis. Create a new axis with the new scaling factor, then have the major maps (VE, IGN, BOOST), use the new axis instead of the old one, this will allow for all of the other maps (both know and unknown) to still utilize the stock axis and scaling factor.

    I bought the 4.00 OD MAF housing from mrpmachineshop, I contacted them and they said they can make a 4.50 OD housing, im considering exchanging mine.

    Im a bit worried about idle with the 4.50 housing. That would be close to 1.2kg/hr resolution, combined with 1720cc injectors and aggressive cams, I dont think idle would be very smooth / cruising (unless i idle'd very high 1500 ish). How is your idle and cruising with the 4.00 OD MAF?


  11. ​This is correct!

    Maarten already saw this when developing load 24.48.

    I made a subroutine witch put the outcome of the new RPM calculation into $FABF wich can be added to the logging frame.

    Maximum RPM that can be measured with it is 10200 RPM with a resolution of 40 RPM

    As for having a higher rev limiter.
    Converting the rev limiter code should be quite easy.
    Converting some maps to make them use the new rpm variable is child's play.
    I also did this for my load mod.

    ​Very cool. Looking forward to using these new methods when I get my car running.

    And yes browsing through the rev limiter code, looks very simple, just a matter of swapping a few bytes. Same with the Major RPM axis.

    M44 is starting to become quite the EMS.

    Also, have either of you experimented with the idea of using this new scaled rpm variable in the load calculation? It could help with people revving above 7650 rpm. Ill have to browse around and see where load is calculated. It doesn't look like the 16bit rpm is stored anywhere long term, so i would assume the load calculation uses the 8 bit value.


  12. Im trying to reverse engineer the RPM calculation logic. I've made a decent amount of progress, but need some help from some fellow VS'ers. Im looking for a way to increase the max rpm limit from 7650.

    If anyone has time, could they replace their MAF logging with 0x3D and 0x3E, and record a short 10 second log or so of their engine idling and then giving it a rev.

    These bytes seem to correspond to some sort of 16bit floating point number, maybe the time between teeth or the time it takes for 120 degrees, i am not sure.

    3D - /UMP,%UR_RAM1,TN_M,{tn-Mantisse: 6zyl: 120gradKW},$003D,1,9,DEZ,2,$00FF,K;
    3E - /UMP,%UR_RAM1,TN_E,{tn-Exponent: 6zyl: 120gradKW},$003E,1,9,DEZ,2,$00FF,K;

    If i had actual values it would really help with me running through the MULT/DIV unit logic.

    EDIT: Found some more stuff in the damos:

    /UMP,%UR_RAM1,TN6E,{corresponds to TN6_E aus Syncro},$009D,1,9,DEZ,2,$00FF,K;
    /UMP,%UR_RAM1,TN6M,{corresponds to TN6_M aus Syncro      |=Zeit für 1.5°KW; timer2-},$009C,1,9,DEZ,2,$00FF,K;

    This seems to be a 16 bit IEEE754 floating point number that corresponds to the time for 1.5 degrees of rotation. Im 99% sure that TN_M and TN_E is a IEEE754 half precision floating point number of the amount of time (in seconds i assume) that it takes for 120 degrees of rotation. This means that the RPM is only updated every 120 degrees, which make sense, because that will eliminate any flicker or extremely rapid changes in RPM.

    Been doing more research, I think Bosch is using a modified version of IEEE754, or maybe just a form of floating point representation.

    It looks like they're using 8 bits for the exponent and 8 bits for the mantissa with no bit for signed numbers (time can't be negative, so theres no need).

    Here's what I'm thinking it looks like, Lets say the motor is running at 840 RPM, thats 14 RPS. So 1 rev would take 0.07 sec. Since it stores time for 120 degrees we can simply divide 0.07 by 3, to get 0.023 sec for 120 degrees.

    In order to represent this in binary representation we have to multiply this by 2 until we reach one, then take decimal part and multiply by 2, continue.

    Exponent     Mantissa

    00000000   00000000

    0.023 x 2 = 0.046 = 0     0.046 x 2 = 0.092 = 0     0.092 x 2 = 0.184 = 0     0.184 x 2 = 0.368  = 0     0.386 x 2 = 0.736 = 0     0.736 x 2 = 1.472 = 1     0.472 x 2 = 0.944 = 0     0.944 x 2 = 1.888 = 1     .888 x 2 = 1.776 = 1     .776 x 2 = 1.552 = 1

    So since we have nothing before the decimal point we leave that as a 0, then put in all of the x2's in order.

    0.0000010111, now lets move the decimal point and put it into binary scientific notation, 1.0111 x 2^-6

    So the exponent will be -6 + 127, and the mantissa whatever is after the 1.

    Exponent     Mantissa

    121              0111

    01111001 01110000, so hopefully this is what the bytes look like at idle (around 840 rpm).

    We can check it by doing 2^-6 x 1.4375 aka ((1/2^2) + (1/2^3) + (1/2^4)) = 0.0224

    Here is some more stuff I found:

    Some sort of exponent, includes an exponent and Mantissa. Maybe some sort of floating point representation?
    Looks like bosch never renamed this for the 5cyl or reused 6cyl code?
    (360 * 2) / 6 = 120
    (360 * 2) / 5 = 144
    
    3D - /UMP,%UR_RAM1,TN_M,{tn-Mantisse: 6zyl: 120gradKW},$003D,1,9,DEZ,2,$00FF,K;
    3E - /UMP,%UR_RAM1,TN_E,{tn-Exponent: 6zyl: 120gradKW},$003E,1,9,DEZ,2,$00FF,K;
    
    From my findings, 3D and 3E are only populated in 0x3D72 0x1BF5A, once, using MOV iram addr,A.
    
    I need to find more information on what tn-exponent and tn-mantisse are and what they do.
    
    Here is some annotated code :
    
    code:00003D41
    code:00003D41 code_3D41:                              ; CODE XREF: RESET_0+E33j
    code:00003D41                 clr     C
    code:00003D42                 mov     A, R6
    code:00003D43                 subb    A, R4
    code:00003D44                 mov     A, R7
    code:00003D45                 subb    A, R5
    code:00003D46   
    code:00003D48                 mov     A, R4
    code:00003D49                 mov     R6, A
    code:00003D4A                 mov     A, R5
    code:00003D4B
    code_3D4C:              ; Multiplication/Division Register 0
    mov     MD0, R6
    mov     MD4, #0         ; Multiplication/Division Register 4
    mov     MD1, R7         ; Multiplication/Division Register 1
    mov     MD5, #0x18      ; Multiplication/Division Register 5
    nop
    nop
    nop
    nop
    mov     ARCON, #0       ; Arithmetic Control Register
    clr     C
    mov     R4, #0x10
    mov     A, #0x1F
    anl     A, ARCON        ; Arithmetic Control Register
    xch     A, R4
    subb    A, R4
    mov     R4, A
    mov     A, MD2          ; Multiplication/Division Register 2
    rlc     A
    clr     A
    addc    A, MD3          ; Multiplication/Division Register 3
    jnc     code_3D72
    mov     A, #0x80 ; 'Ç'
    inc     R4
    code_3D72:
    mov     RAM_3D, A
    mov     RAM_3E, R4
    
    Two main RPM variables are populated, 3B and 3C:
    
    /UMP,%UR_RAM1,NMOT,{Drehzahl               |umr:nmot, 30 [1/min]|},$003B,1,120,N,2,$00FF,K;
    /UMP,%UR_RAM1,N10,{Drehzahl               |umr:N10, 10 [1/min]|},$003C,1,121,N10,2,$00FF,K;
    
    120,/REG,N,{Drehzahl},6,0,{1/min},4,6,  0., 7650.
    /REP, 1.,  0.,  0., 30.,  0.,  0.;
    
    121,/REG,N10,{Drehzahl in 10 Umdr. Quantisiert},6,0,{1/min},4,5,  0., 2550.
    /REP, 1.,  0.,  0., 10.,  0.,  0.;
    
    You can see the obvious difference, 3B's conversion factor is 30 (byte * 30) and 3C's conersion factor is 10 (byte * 10).
    
    Also 121 seems to be a quantized meaning it must be reduced from a larger variable.
    
    I found this... 
    
    /UMP,%UR_RAM1,NFI,{antiruckel: Drehzahlfilter HOB    |umr:N|},$008A,1,120,N,2,$00FF,K;
    
    Some sort of speed filter high order byte, its related to 120 (3B), so I wonder if the crank signal is filtered (quantized) 
    aka reduced.
    
    OK So now onto how 3B and 3C are populated.
    
    3B and 3C are populated at 0x1434D and 0x1434A using MOV iram addr,A and MOV iram addr,B respectively.
    
    Code runs from 0x14303 - 0x1434D
    
    Here is some annotated code:
    
    ROM:14303                 setb    RAM_29.3
    ROM:14305                 clr     A
    ROM:14306                 mov     MD0, #0         ; Multiplication/Division Register 0
    ROM:14309                 mov     MD1, #0x6A ; 'j' ; Multiplication/Division Register 1
    ROM:1430C                 mov     MD2, #0x18      ; Multiplication/Division Register 2
    ROM:1430F                 mov     MD3, A          ; Multiplication/Division Register 3
    ROM:14311                 mov     MD4, RAM_3D     ; Multiplication/Division Register 4
    ROM:14314                 mov     MD5, A          ; Multiplication/Division Register 5
    ROM:14316                 mov     A, RAM_3E
    ROM:14318                 setb    ACC.5           ; Accumulator
    ROM:1431A                 nop
    ROM:1431B                 nop
    ROM:1431C                 nop
    ROM:1431D                 nop
    ROM:1431E                 mov     ARCON, A        ; Arithmetic Control Register
    ROM:14320                 nop
    ROM:14321                 mov     A, MD1          ; Multiplication/Division Register 1
    ROM:14323                 jz      code_4328+2
    ROM:14325                 mov     B, #0xFF        ; B-Register
    ROM:14328                 sjmp    code_432D
    ROM:1432A ; ---------------------------------------------------------------------------
    ROM:1432A                 mov     B, MD0          ; Multiplication/Division Register 0
    ROM:1432D                 mov     MD0, MD0        ; Multiplication/Division Register 0
    ROM:14330                 mov     MD1, MD1        ; Multiplication/Division Register 1
    ROM:14333                 mov     MD4, #3         ; Multiplication/Division Register 4
    ROM:14336                 mov     MD5, #0         ; Multiplication/Division Register 5
    ROM:14339                 nop
    ROM:1433A                 nop
    ROM:1433B                 nop
    ROM:1433C                 nop
    ROM:1433D                 mov     A, MD1          ; Multiplication/Division Register 1
    ROM:1433F                 jz      code_4343+2
    ROM:14341                 mov     A, #0xFF
    ROM:14343                 sjmp    code_4346+1
    ROM:14345 ; ---------------------------------------------------------------------------
    ROM:14345                 mov     A, MD0          ; Multiplication/Division Register 0
    ROM:14347                 jnb     RAM_29.3, code_4301+2
    ROM:1434A                 mov     RAM_3C, B       ; B-Register
    ROM:1434D                 mov     RAM_3B, A
    
    
    Steps:
    1. 0x00186A00 / RAM_3D, result stored in MD0 MD1
    2. Move RAM_3E to A
    3. Set ACC.5 (shift direction right)
    4. Move A to ARCON to start the shift
    5. If acc is zero jump go to sjmp
    
    

    Based on all of this if 3D and 3E do turn out to be time in seconds for 120 degree rotation it should be very simple to calculate a new variable with say 40 resolution instead of 30 in which the max rpm will now be 10200.

    I tried running my made-up 3D 3E through the code, not much success i dont think.

    E               M

    01111001 01110000

    0x14309 - 00000000000110000110101000000000 / 01110000 = 11011111001101

    0x14318 - Shift answer to right 1001 (9) = 11011 = 27 * 10 = 270.

    0x1432D - 11011  / 11 = 1001 = 9 * 30 = 270.

    Maybe i made a mistake somewhere.

    I may have figured it out...

    Basically the ECU actually represents rpm in 16 bit (with 10 rpm increments) and divides by 3 to create a scaling factor of 30 so it can fit 7650 rpm in 1 byte.

    Basically all you need to do is modify this piece of code

    ROM:1432A                 mov     B, MD0          ; Multiplication/Division Register 0
    ROM:1432D                 mov     MD0, MD0        ; Multiplication/Division Register 0
    ROM:14330                 mov     MD1, MD1        ; Multiplication/Division Register 1
    ROM:14333                 mov     MD4, #3         ; Multiplication/Division Register 4
    ROM:14336                 mov     MD5, #0         ; Multiplication/Division Register 5

    Change that move MD4, #3 to MD4, #4 for a scaling factor of 4.

    Lets say the 16 bit number (which keep track in 10 rpm increments), is 800 dec, if you div by 4 you get 200 * 40 = 8000 rpm.

    • Upvote 1

  13. Wow. That's some crazy acceleration.

    How is that KTS hx40 wheel going? Is it out of breath at 2.8 bar? Any plans to crank it up to 3 bar? Estimated horsepower / torque right now?

    Any clutch slip?

    I'm really looking forward to tuning this turbo, especially on e85.

    Is your EGT reading still off?