[adrian@vishnu]

Originally Posted by AltecBX

So would it apply the difference in an variable load real-time or just on a sustained load for a specific amount of time?
Do I make sense or I'm I not following correctly.

Whenever the CAN data is being read (when in performance mode at any time regardless of load), the Procede compares the output pressure it is outputting to that the DME is reading that the Procede has access to via the CAN bus. The Procede than applies an algorithm to work out the error at various boost levels (linearised), and then offsets its output by this error amount until the pressure it sends to the DME exactly matches the pressure read by the DME. This takes a few seconds to stabalise after engine start.

As Shiv stated, we were getting some errors early in V4, but I am amazed how well this algorthm works, and this certainly sorted out the errors we were having, and the result is the DME reads within very small fractions of a PSI of what we are sending to it.

Adrian

[AltecBX]

Got it. So basically is the PID controller algorithm involved here.
If it is, has or will the algorithm table get better or will the D get better at predicting the errors?

[adrian@vishnu]

Originally Posted by AltecBX

Got it. So basically is the PID controller algorithm involved here.
If it is, has or will the algorithm table get better or will the D get better at predicting the errors?

No PID here... nothing is being controlled. Just a mathematical calculation (using some feedforward) that I worked out and then averaging the result over a few seconds to reduce the effect of noise/short term error.

[AltecBX]

Very Nice. So without CANbus, you wouldn't be able to apply this algorithm?
Or would another way of reading give you a different result as shiv explained earlier.

Originally Posted by shiv@vishnu

Correct. we basically compare the DME boost signal the DME is reading and compare it what the Procede thinks it is putting out. The error is the difference. We keep track of this difference via a running average computation and apply it as a real-time offset. Which is why we know our "model" of DME boost is the same as the actual DME boost.
Shiv

[adrian@vishnu]

Originally Posted by AltecBX

Very Nice. So without CANbus, you wouldn't be able to apply this algorithm?
Or would another way of reading give you a different result as shiv explained earlier.

No we couldn't without CANBus.

Other products (I believe JB3 and CP-E) assume a constant error for all cars with a fixed software calibration of boost output to Voltage, but this method cannot compensate for errors from car to car.

It should be said that the tune can still cope with errors if you are still utilising the factory boost control system as used by JB3. The errors just add to the offsets that are already being done and the end result is that the actual boost run is just offset by the same error, and any throttle control logic (bogfix) will work different from car to car (if a car has a low error as its error stackup is similar to the car that the tune was tuned on, the boost error reductions in bogfix performance will be minimal, but if your error is very different to that of the car that that was used for tuning, your boost could vary alot form normal, and you will suffer throttle bog much worse).

I believe the CP-E works similar in boost control to Procede V4. They would need to have a mechanism to work out the boost target to feed the DME since they have effectively cut the DME feedback loop (as has V4). I believe they have done this using a mapped table to contain the boost target as a function of RPM and Throttle. This can work, but would be problematic with under/over boost codes from car to car, and I have seen evidence that this is the case. To avoid under/overboost codes, you would have to add a second added component to the table output that responds to changes in the DME output duty cycle. They may have done this more recently.

But there are two issues related here. One is the avoidance of over/under boost codes (which is achieved in JB3 by keeping the DME closed loop Boost control active, and not sure if CP-E achieves this unless they have changed things recently), and the other is throttle bog management. The DME will close the throttle if the boost it reads is only a fraction of a PSI above its target. JB3 seems to under shoot the target in its bogfix, but this can then cause the DME to open up its boost output and cause over boost periods. CP-E seems to not do any bog fix type throttle management. In the Procede V4, we can give the DME exactly what it wants to avoid throttle bog to within very tight accuracy thanks to our error compensation algorithm. We do not over or under shoot. Even if we did, the Procede controls boost independantly of the DME, so we get no boost variation... just the boost that is targetted with no throttle bog (unless the user chooses so with our adjustable throttle repsonse manager).

Other systems may argue they can achieve as good as V4 which they have to do for marketting reasons, but I think they would have to agree that V4 has the optimal approach.

Note also, that some will claim a flash can get around this, but I have yet to see this being the case. Stock has throttle closures, and every flash we have looked at does also, but V4 does not. Current generation flashes just retune factory DME algorithms. Maybe flashes will rewrite algorithms eventually (Massive job), but certainly nothing done so far that I have seen. So as far as getting predictable and natural throttle response, nothing can get close the Procede V4 at the moment.

Adrian

[AltecBX]

Thanks for clarifying that up. Very interesting. This explains what you've mentioned below.

Originally Posted by adrian@vishnu

The Procede than applies an algorithm to work out the error at various boost levels (linearised), and then offsets its output by this error amount until the pressure it sends to the DME exactly matches the pressure read by the DME.

Thanks