Announcement

Collapse
No announcement yet.

OBC fuel consumption change?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Originally posted by terra View Post
    Any updates? Did the modification work?
    So what exactly did that string change? It looks like the hex value is exactly double which makes sense but I ran into an issue I’ve never even seen. The flash went though successfully but somehow it completely bricked the dme and every bus in the dme network went haywire cycling nonstop with the key out of the ignition until I unplugged the battery.

    I had to overnight my dme to Kassel for a bench flash recovery and now I’m trying to figure out if any of the modules fried because of this. Pretty much every

    I’m now running the csl 2300 bootrom on my spare hp dme and Hassan ported over my tune to that dme for now but the car is slightly misfiring and we’re trying to figure out what’s going on.

    If I had known any of this was a possibility, I absolutely would not have even tried it. This is an absolute disaster and might have just ruined my trip. The car was running absolutely perfect before. 🤦‍♂️

    Shawn and I were chatting and we both think the fact that mssflasher doesn’t correct checksums that could be the primary problem. Still doesn’t explain why the dme started spazzing out instead of just not being functional.


    Sent from my iPhone using Tapatalk
    2003 E46 M3 TiAg/Cinnamon 6MT
    2005 E46 330i ZHP Imola/Sand



    | Karbonius | Schrick | Supertech | Volk | Recaro | FCM | SuperSprint | Turner | Hyperco | GC | PFC | VAC | OMP | Radium Engineering | MPRacing |

    Instagram:@thegenius46m

    NorCal DME Programming and Coding Expert

    Comment


      #17
      Sounds like a failed flash rather the code itself breaking anything specifically. All the program change does is load the parameter as a word instead of a byte (allowing you to use values above 44 lbs).

      To be clear, MSSFlasher does correct program checksums when flashing a full binary. What it doesn't do is correct parameter space checksums when flashing via full binary (this is apparently intentional for... reasons that didn't really make sense to me when I asked paffy). I can't explain the modules on the can-bus freaking out. Even if you flooded the bus with messed up messages, that does not typically cause that sort of behavior.

      Edit: fuck, I think I see an issue. It should have been 12 39... to 32 39.... 36 ends up loading the word to the wrong register, which depending on what's supposed to be in that register at the time, may cause the DME to crash. That doesn't seem sufficient to necessarily brick other things, but who knows.

      I changed the posts prior with what should be the correct change, but I know that doesn't help you now. I am sorry.

      Comment


        #18
        Originally posted by terra View Post
        Sounds like a failed flash rather the code itself breaking anything specifically. All the program change does is load the parameter as a word instead of a byte (allowing you to use values above 44 lbs).

        To be clear, MSSFlasher does correct program checksums when flashing a full binary. What it doesn't do is correct parameter space checksums when flashing via full binary (this is apparently intentional for... reasons that didn't really make sense to me when I asked paffy). I can't explain the modules on the can-bus freaking out. Even if you flooded the bus with messed up messages, that does not typically cause that sort of behavior.

        Edit: fuck, I think I see an issue. It should have been 12 39... to 32 39.... 36 ends up loading the word to the wrong register, which depending on what's supposed to be in that register at the time, may cause the DME to crash. That doesn't seem sufficient to necessarily brick other things, but who knows.

        I changed the posts prior with what should be the correct change, but I know that doesn't help you now. I am sorry.
        Yup I have never seen a brick cause these kind of issues. It sounds most likely that the checksum not being corrected after the hex change is what caused the corruption. The flash completed successfully without any errors via mssflasher, but when Kassel got the dme he said over BDM it was pretty fucked up. Luckily was able to get the dme back in time and tested all the engine bay components that the dme powers via an autologic and everything passed so we are good, but I'm hesitant to try this again.

        My shop told me that you have a checksum correction tool and I just downloaded it but wanted to confirm if it is still a current tool that works given its 10yrs old? I'm just really hesistant to touch a full bin flash again after this because at least with a partial I can fix that corruption.
        2003 E46 M3 TiAg/Cinnamon 6MT
        2005 E46 330i ZHP Imola/Sand



        | Karbonius | Schrick | Supertech | Volk | Recaro | FCM | SuperSprint | Turner | Hyperco | GC | PFC | VAC | OMP | Radium Engineering | MPRacing |

        Instagram:@thegenius46m

        NorCal DME Programming and Coding Expert

        Comment


          #19
          MSSFlasher does correct the program checksums. I've flashed program changes literally hundreds of times. Sometimes close to that in the same day. The only thing it doesn't do is correct parameter (data/tune) checksums when flashing from a full binary. The tool I wrote years ago probably can also correct them, but I haven't looked at that in ages.

          Now that you mention Kassel's comments, I have run into a couple situations where MSSFlasher fucks something or another up resulting in a semi-brick (even if simply flashing a stock program). I've never had that personally happen to me, but I have had to repair a couple DMEs in such situations. No idea what the trigger is.

          I suppose that's all the more reason for me to make my own alternative to MSSFlasher akin to my MSS6x flasher... but that requires me to dedicate some time I don't currently have.

          Comment


            #20
            Originally posted by terra View Post
            I *think* you can edit K_KVA_NORM (It's a multiplier with formula x/128, higher would mean more fuel consumption I believe). Stock value is 1.03125, maxes out at 1.99. Assuming the stock injectors are 24 lb, that would imply the largest injector your could correct the readings for would be ~46 lb (without doing a program modification that is).
            Do you know if the ecu accounts the fuel pressure from a hardcoded constant somewhere? I‘m asking because most with SC or turbo use 3.5bar instead 5bar fuel pressure. And the 24 or 25.5lbs (different values going on, but most sources say 268ccm/3bar or 340/5bar). Most will probably run 630cc/3.5bar from ESS kit. Taking the pressure also in account, the 630cc should work within the 1.99 limit.
            …under construction.

            Comment


              #21
              Originally posted by S54B32 View Post

              Do you know if the ecu accounts the fuel pressure from a hardcoded constant somewhere? I‘m asking because most with SC or turbo use 3.5bar instead 5bar fuel pressure. And the 24 or 25.5lbs (different values going on, but most sources say 268ccm/3bar or 340/5bar). Most will probably run 630cc/3.5bar from ESS kit. Taking the pressure also in account, the 630cc should work within the 1.99 limit.
              I don’t believe it does. I think you would just need to take into account the pressure yourself. I wasn’t aware that most kits use a 3.5 bar regulator, so you’re right, the 1.99 limit may be fine.

              Comment

              Working...
              X