[boxter]

Hi Shiv,

Where is the CAN actual Ign Adv?, I imagine that it will be in the next user software.

I data logged valet mode (2º, 3ª since 3000rpm) and I compared with map 7 03 ut=10%( other parameters default), I noticed 1 or 1.2 psi less on valet.

Could I run a map with 0%=ut, I´d would like have a stock but improving other features.

[bren335i]

So is this the new way of dodging answers?

coming into a thread and picking apart data and going off on a tangent about "knock status", theory that has nothing to do with the topic really at hand?

Kudos Michael.

[The Cthulhu]

I think I understand the data itself after reading it over a few times. I don't understand why the DME can or can't learn around the timing changes introduced by the Procede. I'm really not trying to argue (in fact, I ordered and acquired a Procede even though my car isn't even done being built). Rather, I'm trying to educate myself on the subject so I understand how the Procede interacts with the DME logic.

I hope I don't butcher this too bad, but the Procede intercepts a signal from the DME that controls ignition timing advance and modifies it to compensate for the tune, right?. Where does it feed the modified signal to?

Please help me understand this, thanks Shiv.

[chiefsotos]

Incredible job Shiv!
It is very good to know that the procede can reacts before the Ecu does.
I think that this thread should be readen from every user, who wants to enter in the world of tunning....
Thank's again for all that time you are spending in R&D of procede and tunning a Bmw car!

[edo]

Originally Posted by chiefsotos

Incredible job Shiv!
It is very good to know that the procede can reacts before the Ecu does.
I think that this thread should be readen from every user, who wants to enter in the world of tunning....
Thank's again for all that time you are spending in R&D of procede and tunning a Bmw car!

You can send Shiv a present as an expression of gratitude.

Just kiddin'

[munters]

Originally Posted by chiefsotos

Incredible job Shiv!
It is very good to know that the procede can reacts before the Ecu does.
I think that this thread should be readen from every user, who wants to enter in the world of tunning....
Thank's again for all that time you are spending in R&D of procede and tunning a Bmw car!

Its a bit different then what you're saying.
Since the Procede has access to the Canbus he can change every signal from every ECU (could even be the ABS system) feeding sensor he wants.

[OpenFlash]

Originally Posted by Rossifumi

Does the ignition timing control have anything to do with exhaust sound?

I have noticed that my car (equipped with a AC Schnitzer exhaust) drones A LOT less during cruising with the PROcede than it did with my previous tune (AA Active Processor).

A few degrees more advance at cruise can indeed change the exhaust volume for the better. Under-advance usually causes an annoying exhaust drone.

Shiv
iPhone

[nomile]

Originally Posted by shiv@vishnu

Also, I'm a little curious about your findings regarding knock status since the logging rate of the BT tool is what, 20 samples/sec? And the rate of engine events at 6000rpm is 100 events per second. Seems to me that it misses a lot of the action. And I have data that seems to back that up as well.

Shiv,
Since I don't have a 335 I've never had the chance to use your product, but this type of stuff is interesting to me nonetheless - electrical engineer with heavy physics background etc. Anyhow, ALL of the data-logging systems I've ever used that look for critical events (both in labs and products) may only REPORT at a low rate (in this case 20 s/s), but are looking at the critical signal continuously in the interim. i.e. I would expect the knock sensor to 'go high' whenever the knock happens, and stay that way until the BT tool interogates that value, thus resetting it. I'd be surprised if they didn't do it that way in their implementation of the tool. If this assumption of mine is wrong and you know this for a fact, please let us know. However, I would assume that all knock events that are sensed would be reported, event if with a 5ms delay...

[OpenFlash]

No question that the DME monitors knock status at a very very fast sampling rate (several times per single engine event I'm guessing) Much faster than one can log it with an external logging device. The latter issue is one reason that externally monitoring knock status isn't very helpful. Far better to monitor something it has a direct effect on (ignition advance). I've seen obvious occurance of knock (both audible and inducing dramatic knock retard) but with no knock status flag raised.

Shiv
iPhone

[Glowin]

Just for having Mike's responses in context for myself, Mike, are you just an e-vendor or do you have a shop with mechanics, and you tune cars as well as selling products on E90? If so, how many years have you been doing it?

The n54tuning website just seems like an e-store to me, so I wasn't clear.

[scalbert]

Originally Posted by nomile

Shiv,
Since I don't have a 335 I've never had the chance to use your product, but this type of stuff is interesting to me nonetheless - electrical engineer with heavy physics background etc. Anyhow, ALL of the data-logging systems I've ever used that look for critical events (both in labs and products) may only REPORT at a low rate (in this case 20 s/s), but are looking at the critical signal continuously in the interim. i.e. I would expect the knock sensor to 'go high' whenever the knock happens, and stay that way until the BT tool interogates that value, thus resetting it. I'd be surprised if they didn't do it that way in their implementation of the tool. If this assumption of mine is wrong and you know this for a fact, please let us know. However, I would assume that all knock events that are sensed would be reported, event if with a 5ms delay...

The knock sensor is analog signal to the DME. The Knock Status flag is a digital value and is set and reset by the DME internally. It is an internal register controlled by the DME. It is completely independant of the BT interface. The issue with monitoring this flag as an indicator is that the DME sets and resets this register much quicker than the sample rate of the CAN interface.

[scalbert]

Originally Posted by shiv@vishnu

No question that the DME monitors knock status at a very very fast sampling rate (several times per single engine event I'm guessing)

My guess would be at least 10 times per event. Perhaps sampling at about 100kHz with a filter algorithm (FFT perhaps) to isolate the frequencies desired.

[Malek@MRF]

Originally Posted by Rossifumi

Does the ignition timing control have anything to do with exhaust sound?

I have noticed that my car (equipped with a AC Schnitzer exhaust) drones A LOT less during cruising with the PROcede than it did with my previous tune (AA Active Processor).

Yes what you are experiencing is absolutely true and correct.

If the ignition advance is pulled back a bit, you will get a more pronounced drone in your exhaust note. The car will also sound a little bit choked if you have the ear for it.

I could take a video if you like of a car running on a standalone and demonstrate for you what happens when you drop the ignition timing at idle to zero advance vs. around 12* advance.

[lawdude]

Originally Posted by Glowin

Just for having Mike's responses in context for myself, Mike, are you just an e-vendor or do you have a shop with mechanics, and you tune cars as well as selling products on E90? If so, how many years have you been doing it?

The n54tuning website just seems like an e-store to me, so I wasn't clear.

Here's the context - If you heard it from Mike, you heard it from Terry.

[Malek@MRF]

Originally Posted by chiefsotos

I think that this thread should be readen from every user, who wants to enter in the world of tunning....
!

It should be read by every PROcede user. But also keep in mind this thread has merely scratched the surface of engine tuning.

[jpsimon]

Originally Posted by Malekreza11

It should be read by every PROcede user. But also keep in mind this thread has merely scratched the surface of engine tuning.

No not just procede users. It should be read by all those who originally said this wasn't possible. They should then share their own data (not just jibber jabber like always, actual data) if they want to demonstrate their own points... although i have a feeling that won't happen.

[Malek@MRF]

Originally Posted by jpsimon

No not just procede users. It should be read by all those who originally said this wasn't possible. They should then share their own data (not just jibber jabber like always, actual data) if they want to demonstrate their own points... although i have a feeling that won't happen.

I understand. But I am not going to get involved with what he said/she said between tuners or others.

This is a public forum, and unfortunately there are always those who run their mouth extensively with no prior experience or claim to have valid proof but never post it up.

[Mike@N54Tuning.com]

Originally Posted by shiv@vishnu

Sure thing Mike. One of the biggest contributors of the initial timing target is Intake Air Temp. The higher it is, the lower the initial timing target. In the higher boost runs, initial IATs were in the 119-126F deg range. This is because I did several back to back adaptation runs before the logged run. In the stock tune run, initial IAT was under 100F, rising to only 105F (it's really hard to equal IATs when you are only running 6-9psi of boost). It's as if the DME is testing the waters first, and only after that, does it start to roll in the desired ignition advance. And the rate of additive advance seems to depend on a number of things including the acceleration of the engine. And judging by the time stamps, you'll notice that the tuned runs are accelerating a lot quicker than the stock tune run.

But yes, in that particular case, there is probably 1-2 degrees of reactive DME retard in the 5000-5500rpm as suggested by slightly more ign. advance shown in Test 4 (with 200% Ign Correction). Just not the 4 degrees that you suggest.

However, the real point of this exercise was to illustrate the effect the PROcede's CAS offsetting feature had on Actual Ignition Advance. More than once, you/Terry have stated that the DME will run whatever it wants to run, regardless of CAS offsetting. You've even went so far as to say that CAS offsetting doesn't work at all and that the DME will just "learn" around it. I never thought I needed to take the time to prove that such claims were unfounded. But after hearing several people accept this claim as fact, I took the time to prove otherwise and post are the results. And these results can soon be replicated by hundreds of Rev.2 users out there.

Cheers,
Shiv

It gets to be a complicated detail oriented topic. For example, it is well understood and agreed by most that there is a ceiling to how much timing the ECU will add. The ECU will add timing up to its "knock threshold" OR that ceiling, whichever is lowest. It is not well known or understood how that ceiling is determined. Octane adaption is a major contributor and the principle method through which the CPS offsets are learned out. And a major contributor to total timing advance, much more so than IAT.

But your logs really demonstrate one of my points, that even if we ignore all that and use only your model (which we don't agree on), the CPS offsetting is not effective at preserving the "total timing advance" numbers. To achieve "maxed out" timing values, you would need to pull down much more offset than you do currently. From your logs, more than 200% @ 5000rpm. That would destroy performance. It is because you can not pull out enough CPS to hit the ceiling that what you do pull is learned out. As demonstrated in your "Test 2". Again this is pretending the long term learns don't exist.

Total timing advance vs. "actual knock" is an interesting topic that BMS has also spent a lot of time on lately. Looking forward to continuing the discussion once I have a few moments to put together some data in a presentable way.

Mike

[brianhn1]

Are there more "Test 2" results besides the one graph above?

[Mike@N54Tuning.com]

Originally Posted by munters

Its a bit different then what you're saying.
Since the Procede has access to the Canbus he can change every signal from every ECU (could even be the ABS system) feeding sensor he wants.

If that were true why even have a piggyback? Just make an OBDII dongle that communicates on the bus and does the sensor manipulation without having to fuss with going in to the ECU box and wiring, and without having to fuss with encryption/learning/overwriting the ECUs internal tables.

Spoiler alert: It is because you can't change how the ECU reads signals from hardwired sensors. You can only read that data through the interface the ECU provides. So for example the IAT sensor is hardwired in to the ECU. The ECU will always read that as the IAT and always use that as the basis for its engine management. The only way to alter that signal is through physical means. But lets say hypothetically for some reason your air conditioning computer also wants to know IAT, it can request it via the CANbus from the ECU. In theory if the piggyback were wired in a certain way (which it isn't in this case, AFAIK), the piggyback could intercept and alter the CANbus signal going back to the air conditioning computer, or answer for the ECU with a fake value. But the key here is that the ECU does all the tuning using the hardwired signals by design. CANbus signals are too slow for real time engine management.

Mike

[OpenFlash]

Mike/Terry
You are still trying trying to confuse issues here. Either that, or you really don't have a good grasp of the subject. Of course, you could do what many have suggested (including myself) and actually present the hard data you claim to have. I'd imagin that simply doing that would be a better investment of your time than posting what you have been posting.

Truthfully, I do question your honestly/motives when it comes to the subject of timing control. We are all aware of the lies and misinformatin that you have spread (either knowingly or unknowingly as Terrys mouthpiece.). I'd tread carefully if I were you. If you post tweaked or doctored data, I'm not going to go easy on you.

Shiv
iPhone

[Malek@MRF]

Originally Posted by shiv@vishnu

Either that, or you really don't have a good grasp of the subject.
Shiv
iPhone

That's exactly it.