[vasillalov]

Originally Posted by dzenno

When was the last time you looked into clock frequency of microprocessors...100Hz wasn't hard to match for a LONG time now

True, but we are not talking about any microprocessor, but rather an embedded one. Probably with a much more limited instruction set, pipeline, and memory compared to a x86 CPU. ...and chances are it is not the latest that's out there on the market for cost reasons.

Now add some highly complicated, highly advanced proprietary autotuning logic that has to deal with not just 1 sensor but an entire CAN bus, and I can easily see a delay there.

But, like I said before, I am not sure if such a delay is of relevance at all.

I've mentioned this before: I am really big fan of how DIRECT mechanics are. You push on one end of a lever and you get immediate effect on the other end of the lever. This is something electronic will never be able to achieve.

In my opinion, and again this is personal preference, I'd rather have less electronics and more direct mechanics.

[scalbert]

Originally Posted by vasillalov

In my opinion, and again this is personal preference, I'd rather have less electronics and more direct mechanics.

A Mad Linux Guru On The Loose who wants a carburetor.

[vasillalov]

Shiv,

A side question:

Does procede employ sensor multi threading or frame logic. Let me clarify what I am asking here:

does procede wait for ALL sensors to provide say 10 sample values before it sends a frame output to the DME, or is every single sensor signal received, decoded, modified and retransmitted to the DME independently of the rest of the sensors?

[vasillalov]

Originally Posted by scalbert

A Mad Linux Guru On The Loose who wants a carburetor.

Yep, ain't that weird?

[OpenFlash]

Originally Posted by vasillalov

Valid point!

Here is what my current understanding is of how piggy back tunes work:




It is a very oversimplified diagram that relates to engine control only, obviously. Basically, when it comes to engine control, the piggies intercept the signals produced by the stock engine sensors. Then they process those signals according to proprietary algorithms and they feed the resulting signals to the stock DME.

Correct.

The DME does additional processing of those signals using proprietary BMW algorithms and then finally issues signals that control directly the N54 engine hardware components.

Correct.

To me, two things come out as obvious:

1. All piggies try to guess what the DME will do with their signal. I don't like guesswork

Incorrect. With CAN integration, the Procede knows the actual value of all output data. No guesswork.

2. All piggies add an additional processing layer that takes time and slows down the effectiveness of the DME. This is not optimal.

Say the engine is running full boost, full load at 6000 rpms. This means that the engine turns 100 times EVERY second. 1 second = 1000 miliseconds.

This means that there is one revolution every 10 miliseconds.

I am not sure what embedded processor each one of these piggies is running on board, but chances are, they will cause a signal delay long enough for the engine to complete one full revolution before the sensor signal is actually fed for DME for adjustments.

Incorrect. If the Procede CPS replication were off just 1 tooth (and there are 60 teeth that need to be replicated per single engine revolution), the DME would protest and the engine wouldn't run. The Procede is capable of changing output signals well within the duration of 1 tooth. Which makes sense since 1 tooth is equivalent to 3 degrees of timing. So to get just 1 degree of retard, the Procede phase shifts the pattern just 1/3rd of 1 tooth. 60 teeth per engine revolution. With the DME needing to count all 60 teeth (actually 60-2) every rotation. You get the idea.

Don't forget, autotuning has been marketed as highly advanced and complex proprietary algorithm, so it will take a shit load of CPU instructions to get proper output.

Incorrect. The computation overhear required for Autotuning is minimal. For what it's worth, it takes far less processor work than it takes to regenerate a high freq CPS waveform. The alogorithms behind autotuning are simple and very elegent. Which is why it is patent pending.

I don't know if this is relevant delay or not, but I'd rather not have it.

If you'd rather not have a delay that can be quantified to be unquantifiable, then that is certainly your perogative. But I encourage you to base your conclusions on fact rather than misinformed fear.

Shiv

[Mike@N54Tuning.com]

Originally Posted by shiv@vishnu

The Procede generates a new crank position signal based upon the original one. The dme uses this signal to time the ignition event. Phase shifting this signal in either direction changes the DME'd reference point. Which effectively changes the timing advance setpoint/target. The procede is capable of firing the could directly as well as reference its own temp compensated timing advance table. Buy that would eliminate the factory knock control system and make Procede autotuning impossible.

The short version is the CPS offset moves the maximum timing set point down 2-3 degrees and the DME moves it down the rest of the way. Normally another 2-3 degrees is required. Even more at peak torque. If you're riding the reactive system 2-3 degrees you might as well be riding it 5-6 degrees IMHO. The impact is the same -- the ECU is sensing knock at the same frequency and pulling back timing based on that activity. In practice what happens when you're riding it 5-6 degrees is a big chunk of that gets thrown in to a long term octane adaption trim.

Mike

[Mike@N54Tuning.com]

Originally Posted by vasillalov

Say the engine is running full boost, full load at 6000 rpms. This means that the engine turns 100 times EVERY second. 1 second = 1000 miliseconds.

This means that there is one revolution every 10 miliseconds.

I am not sure what embedded processor each one of these piggies is running on board, but chances are, they will cause a signal delay long enough for the engine to complete one full revolution before the sensor signal is actually fed for DME for adjustments. Don't forget, autotuning has been marketed as highly advanced and complex proprietary algorithm, so it will take a shit load of CPU instructions to get proper output.

I don't know if this is relevant delay or not, but I'd rather not have it.

At 6000rpm you have 100 revs per second, each rev triggers around 120 high/low pulses, for a sampling frequency of around 12khz required. Well within even the 8-bit processor used by the current JB3. The problem with CPS isn't latency it's that the factory knock system is operating on top of it negating timing changes unless you happen to have the timing curve maxed out. Which only happens on race gas or meth when you will want as much timing as possible given the compressor limitations.

The only current method to set timing absolutely is with a flash tune and that isn't disputed by anyone in the know on this platform. But BMS is playing with some new alternatives.

Mike

[Ilma]

Originally Posted by Mike@N54Tuning.com

The short version is the CPS offset moves the maximum timing set point down 2-3 degrees and the DME moves it down the rest of the way. Normally another 2-3 degrees is required. Even more at peak torque. If you're riding the reactive system 2-3 degrees you might as well be riding it 5-6 degrees IMHO. The impact is the same -- the ECU is sensing knock at the same frequency and pulling back timing based on that activity. In practice what happens when you're riding it 5-6 degrees is a big chunk of that gets thrown in to a long term octane adaption trim.

Mike

You always are presuming the worst-case scenario.

But what if you only need a degree or two to prevent the knock from occurring in the first place?

[stren]

Originally Posted by vasillalov999

Say the engine is running full boost, full load at 6000 rpms. This means that the engine turns 100 times EVERY second. 1 second = 1000 miliseconds.

This means that there is one revolution every 10 miliseconds.

I am not sure what embedded processor each one of these piggies is running on board, but chances are, they will cause a signal delay long enough for the engine to complete one full revolution before the sensor signal is actually fed for DME for adjustments. Don't forget, autotuning has been marketed as highly advanced and complex proprietary algorithm, so it will take a shit load of CPU instructions to get proper output.

I don't know if this is relevant delay or not, but I'd rather not have it.

As an indepedent electrical engineer who has worked with fpgas pld's and now does IC design, Shiv is absolutely correct on this. The procede would have the ability to process a signal extremely quickly relative to milliseconds. A *properly* designed piggy with the right hardware should have no problems being *way* faster than is necessary to manage the engine. Engines are relatively slow compared to the processing power you can get these days. The advantages of flashes are mainly the cost to the flash provider - you don't have to buy an fpga, board harness etc. Piggy's such as the procede also offer other features that flashes can't. Advances in progammable logic devices and fpga's are such that the arguments you could make against piggy's ten years ago are no longer valid. Of course if the piggy design is poor, then you're going to have problems, but theoretically 99% of arguments I've heard on here against piggy's are outdated and not based on facts.

[Ilma]

Originally Posted by Mike@N54Tuning.com

If you're riding the reactive system 2-3 degrees you might as well be riding it 5-6 degrees IMHO. The impact is the same -- the ECU is sensing knock at the same frequency and pulling back timing based on that activity Mike

If I get knock at 5000 rpm @ 10 degrees advance, with no CPS offset....ie stock timing curve.

And if 10 Degrees represents the upper threshold of the timing curve, then pulling out 1-2 degrees via cps retard may avoid the knock event and the DME will still think it is at the top of it's threshold...ie 10 degrees.

So it can't add any more timing to ride the knock sensors because it thinks it is at the top already. So I can avoid that knock event.

That is the point here.

You seem to be arguing what happens once a knock event occurs.

It's not the same argument.

I think I showed this previously in my datalogs in this thread...how I avoided a knock event by adding in some retard.

You can talk all you want about how wrong this concept is...but maybe you should try posting some evidence to gain more credibility.

I have a hard time believing you based on my own datalogs.

[vasillalov]

Originally Posted by stren

As an indepedent electrical engineer who has worked with fpgas pld's and now does IC design, Shiv is absolutely correct on this. The procede would have the ability to process a signal extremely quickly relative to milliseconds. A *properly* designed piggy with the right hardware should have no problems being *way* faster than is necessary to manage the engine. Engines are relatively slow compared to the processing power you can get these days. The advantages of flashes are mainly the cost to the flash provider - you don't have to buy an fpga, board harness etc. Piggy's such as the procede also offer other features that flashes can't. Advances in progammable logic devices and fpga's are such that the arguments you could make against piggy's ten years ago are no longer valid. Of course if the piggy design is poor, then you're going to have problems, but theoretically 99% of arguments I've heard on here against piggy's are outdated and not based on facts.

Thanks for the clarification! I appreciate it. It's just that I've never dealt with piggie before (coming from the VW/AUDI world). Its logical for me to be extra cautious and asking questions.

[vasillalov]

Originally Posted by shiv@vishnu

Correct.
Incorrect. With CAN integration, the Procede knows the actual value of all output data. No guesswork.

True, but you still don't know exactly what happens in the DME and why it happens this way. Correct me if I am wrong here, but all that you get from the CAN bus is ability to read and write commands to its members.

Originally Posted by shiv@vishnu

Incorrect. If the Procede CPS replication were off just 1 tooth (and there are 60 teeth that need to be replicated per single engine revolution),

Are you talking about the teeth count on the cam sprocket? I am not sure what you mean...

Originally Posted by shiv@vishnu

The computation overhear required for Autotuning is minimal. For what it's worth, it takes far less processor work than it takes to regenerate a high freq CPS waveform. The alogorithms behind autotuning are simple and very elegent. Which is why it is patent pending.

Thank you for this clarification!

[stren]

Originally Posted by vasillalov

Thanks for the clarification! I appreciate it. It's just that I've never dealt with piggie before (coming from the VW/AUDI world). Its logical for me to be extra cautious and asking questions.

NP, I don't know anything about the VAG piggy's and I'm still learning a lot about turbos too Maybe the VAG piggy's are old or just poorly designed. You really have to look into the piggy design in question to see if it seems reasonable. If you can get an image of the board with the chip in question, you can then google the datasheet and see the specs on it, then at least you know what the hardware is capable of and that can help see through some of the marketing BS. Of course to see if the programmer is an idiot (rather than the board/system designer) is more complicated

[vasillalov]

Originally Posted by stren

NP, I don't know anything about the VAG piggy's and I'm still learning a lot about turbos too Maybe the VAG piggy's are old or just poorly designed.

There aren't any to my knowledge with the exception of dumb boost controllers which noone buys anymore. I do know of several 1.8T engines running close to 450 bhp (at which point the crankshaft starts twisting) on completely stock internals with just ECU reflash and bigger injectors. We are talking about an engine that comes from the factory with 180 bhp.

You should also see what APR, GIAC and RevoTechnik are doing with the turbo engines in VW/Audis.

So yeah, I have extremely high opinion of proper ECU tuning.

[ar design]

Originally Posted by vasillalov

There aren't any to my knowledge with the exception of dumb boost controllers which noone buys anymore. I do know of several 1.8T engines running close to 450 bhp (at which point the crankshaft starts twisting) on completely stock internals with just ECU reflash and bigger injectors. We are talking about an engine that comes from the factory with 180 bhp.

You should also see what APR, GIAC and RevoTechnik are doing with the turbo engines in VW/Audis.

So yeah, I have extremely high opinion of proper ECU tuning.

Cranks twisting at 450bhp? I have buddies making 800+ whp on stock cranks, not sure where you are getting that. Rods are weak after about 350whp..... I am using an OEM crank on my 72mm S372 build.....

[CASHBY]

Originally Posted by vasillalov

There aren't any to my knowledge with the exception of dumb boost controllers which noone buys anymore. I do know of several 1.8T engines running close to 450 bhp (at which point the crankshaft starts twisting) on completely stock internals with just ECU reflash and bigger injectors. We are talking about an engine that comes from the factory with 180 bhp.

You should also see what APR, GIAC and RevoTechnik are doing with the turbo engines in VW/Audis.

So yeah, I have extremely high opinion of proper ECU tuning.

crank shaft twisting? Where did you hear this?

445awhp on stock 1.8T crank (stock bore) with 3071r turbo.... no issues. Plenty of A4's running 400whp and a few over 500whp with no crank issues.

[vasillalov]

Originally Posted by CASHBY

crank shaft twisting? Where did you hear this?

445awhp on stock 1.8T crank (stock bore) with 3071r turbo.... no issues. Plenty of A4's running 400whp and a few over 500whp with no crank issues.

Long time (about 6 years ago) there were several cases that popped up on the 1.8T technical board on the vwvortex.

[CASHBY]

Originally Posted by vasillalov

Long time (about 6 years ago) there were several cases that popped up on the 1.8T technical board on the vwvortex.

ahhh. Damn. Ive been doing these motors a long time but havnt seen it happen..

[lyndon_h]

Originally Posted by vasillalov

There aren't any to my knowledge with the exception of dumb boost controllers which noone buys anymore. I do know of several 1.8T engines running close to 450 bhp (at which point the crankshaft starts twisting) on completely stock internals with just ECU reflash and bigger injectors. We are talking about an engine that comes from the factory with 180 bhp.

You should also see what APR, GIAC and RevoTechnik are doing with the turbo engines in VW/Audis.

So yeah, I have extremely high opinion of proper ECU tuning.

The success that they have had is largely a result of the strength of the engines internals and less to do with the delivery vehicle of commands.

[Clap135]

Originally Posted by Mike@N54Tuning.com

The short version is the CPS offset moves the maximum timing set point down 2-3 degrees and the DME moves it down the rest of the way. Normally another 2-3 degrees is required. Even more at peak torque. If you're riding the reactive system 2-3 degrees you might as well be riding it 5-6 degrees IMHO. The impact is the same -- the ECU is sensing knock at the same frequency and pulling back timing based on that activity. In practice what happens when you're riding it 5-6 degrees is a big chunk of that gets thrown in to a long term octane adaption trim.

Mike

You opinion of 2-3 degrees and 5-6 degrees is just that "your opinion"
Backed by nothing factual.

IMO you are wrong, if you need facts let me know.

[cstavaru]

Originally Posted by stren

As an indepedent electrical engineer who has worked with fpgas pld's and now does IC design, Shiv is absolutely correct on this. The procede would have the ability to process a signal extremely quickly relative to milliseconds. A *properly* designed piggy with the right hardware should have no problems being *way* faster than is necessary to manage the engine. Engines are relatively slow compared to the processing power you can get these days. The advantages of flashes are mainly the cost to the flash provider - you don't have to buy an fpga, board harness etc. Piggy's such as the procede also offer other features that flashes can't. Advances in progammable logic devices and fpga's are such that the arguments you could make against piggy's ten years ago are no longer valid. Of course if the piggy design is poor, then you're going to have problems, but theoretically 99% of arguments I've heard on here against piggy's are outdated and not based on facts.

Unfortunately, the processing speed is not the issue with the piggybacks.

The big issue is that they need to alter things which are not easy to alter because there is no direct or even indirect way to properly alter them. Take the Air-Fuel ratio for example. The (N54) piggybacks truly suck at AFR targeting because there is no easy way to make the ECU change it's AFR target without throwing tuner codes or even other error codes. They use alot of hacks to alter the AFR. That's why you will never see 11.1-11.5 AFR on piggybacks at higher psi but only on flashes. And that is critical to engine safety and longevity.

And there is one other issue: the output signal quality. The piggybacks take the sensor signals (many are linear signals) and output altered signals. The altered signals are not truly linear like the inputs, they are made from digital signals via a digital-to-analog conversion process. Many times, instead of the infinite range of values that an input sensor can give to the ECU, the output signal generated by the piggyback can only have 256 to 1024 separate values in the same range (most of the microcontrollers have 8 to 10-bit DACs or PWMs). So you really lose on signal resolution.

[enrita]

look at my AFR under channel CAN knock and the boost plus timing, looks pretty ok to me in respect to your comments .