XDF Progress
- Thread starter Jake@MHD
- Start date
Specifically second HPFP directly controlled by DME without a secondary controller. Preferably not overdriven.
Single barrel the ECU controls the HPFP same as OEM except the pump now has greater headroom. Justin may shed some light on tuning changes required for that -not a lot of tuners out there are used to it.
For the Double Barrel system, the ECU controls the overdriven pump and we control the second pump (in OEM location) with a Split Second controller -same/similar to Port Injection, except when the ECU turns off an injector that's it.... no more fuel in that cylinder.
The OEM HPFP turns at about 1/2 a rev for every crank rev, so if you want a belt driven HPFP that isn't overdriven, you'd have to use some sort of transmission to gear it down. It's doable, but costly. Another option is to make a transmission in the OEM location and run two HPFP's off of that, perpendicular to traditional orientation. Either of these may be more palatable to those who are concerned about overspinning the pump. If spinning the same speed (i.e. same capacity) you might be able to control the two pumps as one as-is. Lots of conditions though.
I'm looking forward to running the single barrel on my car and seeing how it performs. I might leave TBI on just to keep valves clean from time to time.
Chris
6/19 XDF Update:
Added some tables to support aftermarket coil kits (adaptations, and disable multi-spark)!
Added some tables to support aftermarket coil kits (adaptations, and disable multi-spark)!
So, define multi-spark. What exactly does that variable do in relation to how the spark fires.
IJ is fixed.
It fires the spark...multiple times lol. It's mainly used for start, idle, lower loads. With it enabled, dwell will not follow the base table in those areas, and instead uses a very complex 60+ table logic path to determine multispark timing and dwell. So, turn it off.
It fires the spark...multiple times lol. It's mainly used for start, idle, lower loads. With it enabled, dwell will not follow the base table in those areas, and instead uses a very complex 60+ table logic path to determine multispark timing and dwell. So, turn it off.
The BMW engineers never stop amazing me with how they prefer their systems to run..
A majority of it is actually done for them by Siemens, Conti, Bosch etc whoever makes the ECU. Then BMW adds / customizes on top of that.
Seems like you could edit the DME to control just about anything at this rate, it's just quantifying and applying it in a useful manner
So do they all work together, or do you think there is a central designer of the firmware which they all load onto their hardware based off some reference design?
I'm not following what you're asking here, but will take a stab at it lol. I do not think they work together w/ BMW for instance. I think BMW can look at their OEM offering of the MSD81 for example, and decide if it is "close enough" for them. Then they take that back, with all it's code, documentation, and calibration hints/suggestions, and expand / add in / customize whatever they want.
this is almost always the case. And i believe you answered what he was asking. When it comes to Processors and ECU framework as stated the ECU producer fills a particular ecu with a certain pack of features and logic. Along with Chipset documentation of what is supposed to do what and what certain features will support certain functions. The OEM (BMW) then adjusts whats there and typically adds some custom stuff in the logic or rewrites part of it to make it do what they want it to do.
