[etiliko]

Here in europe many professional tuning tools can recover the writing session on MSD8x, so yes it is possible. But if you can avoid making use of this feature is better...

[packinDSS]

Did MR 5 wake up on the wrong side of the bed today? His posts seem a bit sharp? Im not use to seeing that but it does feel that way.

COBB, please send MR 5 an AP so we.can get a good GIAC comparison and credit worthy review from him.

[techlogik]

Originally Posted by etiliko

Ppppfffffttttt....when you write the MSD80/81 you have to write all the maps, even if you haven't changed any parameter.
Probabily GIAC writing protocol is slow...

I believe it is a standard protocol used to communicate/write/read with the DME.

[Glowin]

Originally Posted by shifterboy45

while we are at it, will this software leave traces in the accumulated FASTA data ?

Bump for info on this?

[etiliko]

Originally Posted by techlogik

I believe it is a standard protocol used to communicate/write/read with the DME.

I also believe this, but if GIAC flash (writing) take LONGER than 12 minutes it's slow! The entire flash can be done in about 12 minutes.

[shifterboy45]

Originally Posted by Glowin

Bump for info on this?

hmmm....

if I were tuning on this platform i'd be thinking of HOW this is taken care of, especially if there are operational parameter codes being generated...

most people think these are only stored in the DME... ive said quite a few times this is not a notion, but a fact. ISTA provides a record of vehicle operation, so if a lot of bells and whistle are going off-- clearing the fault memory is good for turning off the warning light, but does nothing to keep the other module(s) from retaining information.

dont get me wrong, im not trying to down-rate the tune .. just asking a legitimate question....

[Glowin]

Originally Posted by shifterboy45

while we are at it, will this software leave traces in the accumulated FASTA data ?

Originally Posted by shifterboy45

hmmm....

if I were tuning on this platform i'd be thinking of HOW this is taken care of, especially if there are operational parameter codes being generated...

most people think these are only stored in the DME... ive said quite a few times this is not a notion, but a fact. ISTA provides a record of vehicle operation, so if a lot of bells and whistle are going off-- clearing the fault memory is good for turning off the warning light, but does nothing to keep the other module(s) from retaining information.

dont get me wrong, im not trying to down-rate the tune .. just asking a legitimate question....

That's what I was trying to get at as well, in my post in another thread, but it wasn't answered as far as I can tell:

Originally Posted by Glowin

What about (and forgive me if I'm speaking in layman's terms) what we've heard that not even dealers have access to certain information that is pulled off the ECU when they connect to it, and that info is sent directly to BMW headquarters, so they don't even see it? Included in that info is supposedly the details they'd need if they were investigating something like a turbo failure.

Someone who knows what I'm talking about can hopefully chime in with the details of the systems.

[OpenFlash]

BMW AG being able to extract diagnostic info that the Dealership cannot see is not a myth as many of us have found out. Among other things, this info includes:

-The last 12 DME codes triggered (even if they were cleared by a diagnostic tool)
-Max RPM (to protect themselves agains failures caused by mis-shifts)
-Max MPH (to protect themselves against liability in the case of an accident/mechanical failure
-Max Engine Load (to protect themselves against any engine failures caused by tuning)

A while back this DME info was only extracted in the case of a non-routine failure. Followed up by a district field advisor coming out to the dealership with their "special laptop" to verify information.

However, this DME interrogation has become routine as many techs will attest to. It's now common for BMW AG to inform the techs what steps, if any, to take in response to any non-routine mechanical issue/recall.

Absolutely no one will claim that a reflash tune is non-traceable. All they can say is that it cannot currently be detected by a tech during a basic diagnostic scan. However, this "basic diagnostic scan" is not becoming so basic anymore. And once your car is hooked up to the BMW AG network (which is now the case during regular scheduled visits), all bets are off. If the folks in Germany look for it, they will see undeniable evidence of running a tune. It's simply a matter of looking at the Max engine load value. Very cut and dry.

Shiv

[atlharry]

Originally Posted by shiv@vishnu

BMW AG being able to extract diagnostic info that the Dealership cannot see is not a myth as many of us have found out. Among other things, this info includes:

-The last 12 DME codes triggered (even if they were cleared by a diagnostic tool)
-Max RPM (to protect themselves agains failures caused by mis-shifts)
-Max MPH (to protect themselves against liability in the case of an accident/mechanical failure
-Max Engine Load (to protect themselves against any engine failures caused by tuning)

A while back this DME info was only extracted in the case of a non-routine failure. Followed up by a district field advisor coming out to the dealership with their "special laptop" to verify information.

However, this DME interrogation has become routine as many techs will attest to. It's now common for BMW AG to inform the techs what steps, if any, to take in response to any non-routine mechanical issue/recall.

Absolutely no one will claim that a reflash tune is non-traceable. All they can say is that it cannot currently be detected by a tech during a basic diagnostic scan. However, this "basic diagnostic scan" is not becoming so basic anymore. And once your car is hooked up to the BMW AG network (which is now the case during regular scheduled visits), all bets are off. If the folks in Germany look for it, they will see undeniable evidence of running a tune. It's simply a matter of looking at the Max engine load value. Very cut and dry.

Shiv

As far as the procede is concerned, how are the above examples handled? I think the previous DME codes are basically 'pushed' out of the memory space by populating it with benign codes. Are the others just masked by the nature of the piggyback intercepting the signals?

I guess load would be the only one (listed above) really related to tuning... unreasonable RPM and MPH can be achieved stock.

[Glowin]

Originally Posted by shiv@vishnu

BMW AG being able to extract diagnostic info that the Dealership cannot see is not a myth as many of us have found out. Among other things, this info includes:

-The last 12 DME codes triggered (even if they were cleared by a diagnostic tool)
-Max RPM (to protect themselves agains failures caused by mis-shifts)
-Max MPH (to protect themselves against liability in the case of an accident/mechanical failure
-Max Engine Load (to protect themselves against any engine failures caused by tuning)

A while back this DME info was only extracted in the case of a non-routine failure. Followed up by a district field advisor coming out to the dealership with their "special laptop" to verify information.

However, this DME interrogation has become routine as many techs will attest to. It's now common for BMW AG to inform the techs what steps, if any, to take in response to any non-routine mechanical issue/recall.

Absolutely no one will claim that a reflash tune is non-traceable. All they can say is that it cannot currently be detected by a tech during a basic diagnostic scan. However, this "basic diagnostic scan" is not becoming so basic anymore. And once your car is hooked up to the BMW AG network (which is now the case during regular scheduled visits), all bets are off. If the folks in Germany look for it, they will see undeniable evidence of running a tune. It's simply a matter of looking at the Max engine load value. Very cut and dry.

Shiv

Thanks for the super informative reply Shiv.

Are the variables you mention above, like max engine load, also recorded in the DME when using the Procede as well, or b/c of how a Piggy works, the DME doesn't see abnormally high loads, let's say, vs. with a flash?

[OpenFlash]

Originally Posted by atlharry

As far as the procede is concerned, how are the above examples handled? I think the previous DME codes are basically 'pushed' out of the memory space by populating it with benign codes. Are the others just masked by the nature of the piggyback intercepting the signals?

Correct, the Procede's CANclear system constantly purges the DME code memory (which is FIFO) by populating it with benign codes (exhaust fume flap, fuel pump plausibility, etc,.).

As for Max engine load with the Procede, it still looks stock to the DME. So stored diagnostic data will look normal.

[boom]

Can't wait to hear cobb's reply on this...

[atlharry]

Originally Posted by boom

Can't wait to hear cobb's reply on this...

+1

This'll be interesting. Also, assuming that the AP has nothing currently to address this, even if you give COBB a try just once and go back to a Procede... your max load value is already going to be screwed. I hope there's a workaround for this.

[OpenFlash]

Originally Posted by atlharry

As far as the procede is concerned, how are the above examples handled? I think the previous DME codes are basically 'pushed' out of the memory space by populating it with benign codes. Are the others just masked by the nature of the piggyback intercepting the signals?

I guess load would be the only one (listed above) really related to tuning... unreasonable RPM and MPH can be achieved stock.

I have yet to see evidence that the vMax data stored in the DME (viewable by BMW AG) comes from the stability control system. I am led to believe that it comes from the roadspeed sensor signal going to the DME. If this is indeed the case, running the Procede speed delimiter will not cause any issues. But anything is possible which is why the default setting for the speed delimiter is OFF i the user adjustable menu.

The on-board computer does store last x seconds of data that can be extracted (usually in the case of an accident leading to a lawsuit). But this anything BUT routine. And I believe it even requires a legal action from the law to extract this information. Once extracted, they can view actual road speed from the stability control system(not clamped by the Procede). As well as steering wheel angle, brake force, lateral Gs, suspension compressions, pitch, roll, etc,. But if circumstances led to that level of investigation, I'd guess that warranty voiding is the least of the concerns.

shiv

[atlharry]

Originally Posted by shiv@vishnu

I have yet to see evidence that the vMax data stored in the DME (viewable by BMW AG) comes from the stability control system. I am led to believe that it comes from the roadspeed sensor signal going to the DME. If this is indeed the case, running the Procede speed delimiter will not cause any issues.

The DME does store last x seconds of data that can be extracted in the case of an accident. But this anything but routine. And I believe it even requires a legal action from the law to extract this information. Once extracted, they can view actual road speed (not clamped by the road speed sensor). As well as steering wheel angle, brake force, lateral Gs, etc,. But if circumstances led to that level of investigation, I'd guess that warranty voiding is the least of the concerns.

I don't mind the RPM and MPH values. In fact, I would be disgusted if someone were to die (or even be critically injured) due to street racing (or something like that) and used your technology to mask the causes.

[OpenFlash]

Originally Posted by atlharry

+1

This'll be interesting. Also, assuming that the AP has nothing currently to address this, even if you give COBB a try just once and go back to a Procede... your max load value is already going to be screwed. I hope there's a workaround for this.

At the risk of sounding like a doom-monger, it is unlikely that there will be a practical workaround for this. It's more than highly likely that this memory location isn't flash-able. Which would make sense given its intended purpose.

[vasillalov]

Yes, but with COBB, all you need to do is reflash back to stock and all of those stored values and increased load limits are gone...

That is in case you need to visit your dealership for whatever warranty work you are hoping to get.

[Alan l.]

Originally Posted by boom

Can't wait to hear cobb's reply on this...

+2

Now my question is for those like myself who already installed the Cobb AP. I would assume my FASTA data is already showing signs of running a tune. What happens if I flash back to stock or install my V5 back and run the car for awhile before it sees the dealer? Lets say I have a dealer friend that has access to pull up all data from my ecu/car. What would the FASTA data show since i'm either fully stock for awhile or utilizing the Procede's Canclear feature?

Alan

[Imperator]

Originally Posted by atlharry

+1

This'll be interesting. Also, assuming that the AP has nothing currently to address this, even if you give COBB a try just once and go back to a Procede... your max load value is already going to be screwed. I hope there's a workaround for this.

I want to think those values are cleared and/or overwritten by the AccessPORT once the flash is UNINSTALLED. I'm not sure switching to Map 0 "stock" will clear all active and pending codes but I do believe the adaptations routines are reset.

[Alan l.]

Originally Posted by vasillalov

Yes, but with COBB, all you need to do is reflash back to stock and all of those stored values and increased load limits are gone...

That is in case you need to visit your dealership for whatever warranty work you are hoping to get.

Sounds like from what Shiv is saying its not the load limits that is the problem. Its the FASTA data store elsewhere in the car that shows max load, rpms, miles since last flash counter etc... that could be detected by the dealer if they looked hard enough for it.

[gidiup]

Originally Posted by atlharry

+1

This'll be interesting. Also, assuming that the AP has nothing currently to address this, even if you give COBB a try just once and go back to a Procede... your max load value is already going to be screwed. I hope there's a workaround for this.

This BMW stuff is new to me and I have been reading this site to update myself on mod'n a BMW but this seems to mean......The AP is Detectable. WTF???

I'm sure I'm not the only one but I'm not looking to loose my warranty. When I got the car I got a very clear impression if you mod it and we catch it, we will void it.

[atlharry]

Originally Posted by shiv@vishnu

At the risk of sounding like a doom-monger, it is unlikely that there will be a practical workaround for this. It's more than highly likely that this memory location isn't flash-able. Which would make sense given its intended purpose.

Everyone re-read this. If this is the case, flashing back to stock wouldn't help as those values wouldn't be overwritten or updated. Realistically, the guys at COBB would be only ones that would be able to answer this.