[cstmx_ryder]

Originally Posted by shiv@vishnu

170mph is certainly potential trouble in many ways (public safety and potential jail time being just two). But not in terms of mythical "stored" data in the traction control module. That's pure FUD spread by those who can't offer a native speed delimiter option because a) They don't have a 12v power source in their PnP harness and b) lacking the processing power to accurately replicate a high speed square wave (yes, just like the crank angle sensor wave).

The on board electronics store historical data that could be useful in case of an accident. Vehicle speed being one. But this is only the last several seconds of drive time. Just enough to see what happened prior to the accident. Not what happened four days ago when you took your car to the race track and pinned the speedometer down the front straight.

Shiv

What's FUD?

[OpenFlash]

Originally Posted by cstmx_ryder

What's FUD?

Fear, Uncertainty and Doubt.

You see it a lot in politics.

shiv

[jaza45]

so if the computer or whatever module that records that stuff, doesn't record data from speed to rpm's how do they know when you moneyshift and rev the engine beyond its capabilities...that stuff is stored somewhere I would think.....from rpm's to vehicle speed....??????

[OpenFlash]

Originally Posted by ******

so if the computer or whatever module that records that stuff, doesn't record data from speed to rpm's how do they know when you moneyshift and rev the engine beyond its capabilities...that stuff is stored somewhere I would think.....from rpm's to vehicle speed....??????

Correct. It is stored. As is vehicle speed which, in the case of the Procede's speed delimiter, is clamped to ~130mph. Mike's suggestion was that the unclamped value read by the traction control/abs modules is what is stored in the DME. This isn't true.

Shiv

[scalbert]

Originally Posted by ******

so if the computer or whatever module that records that stuff, doesn't record data from speed to rpm's how do they know when you moneyshift and rev the engine beyond its capabilities...that stuff is stored somewhere I would think.....from rpm's to vehicle speed....??????

Engine speed and vehicle speed are two seperate items from different sensors. If you over rev, that freeze frame data is stored in the DME.

[Mike@N54Tuning.com]

Originally Posted by shiv@vishnu

And the VMAX comes from the speed signal that goes into the DME. Which is clamped to 130mph

You'll also notice that the vehicle speed data floating around in the CAN network is also clamped. See for yourself. You have a BT tool and a PROcede for testing I'm guessing. Rev.1 would be fine.

Shiv

Here is a page from the WDS. Hopefully this isn't a copyright infringement.

It clearly states the road speed signal comes from the DSC via the CAN bus to the DME. Other modules like the "black box" pick up speed from the CAN bus as well. The ECU is the only module receiving the hardwired signal that is ultimately tricked. Even the ECU knows the CAN bus speed and "clamped" hardwire signals don't match.

Also just to reiterate this discussion is about unmolested data being stored in modules OTHER than the ECU. They get the data from the DSC via the CAN bus. Even something as simple your dash module which is a node probably stores the VMAX LOL.

Mike

[Mike@N54Tuning.com]

Originally Posted by Digital.James

how about for the guys who dont have 155mph, why not raise their speed limits to 155...

It follows the same philosophy as if the speed is above factory then there could be an issue. Its not the absolute speed that is a worry, but the value over factory.

The other issue is safety. I really don't understand why you would want to go that fast, so its great that its available as an option for the JB3 crowd and Shiv mentioned that it is off by default in the Proceed which is also great IMO. For the guys that need/want this please ensure your car is setup for such speed, including tires, breaks, etc. Don't want to have something fail at that speed.

Mike

[jaza45]

so the question now is whether the DSC control unit actually stores it or just transfers it to the DME via CAN

[Mike@N54Tuning.com]

Originally Posted by ******

so the question now is whether the DSC control unit actually stores it or just transfers it to the DME via CAN

My understanding is that it's transmitted to every node, like the airbag module, dash module, ECU, etc. Some nodes have a reason to store it and others don't. The DSC module itself stores the information as well. So when something bad happens BMW just interrogates all the modules and can read the information out.

PS. Here is what Shiv had to say about it last thread when this issue came up.

Originally Posted by shiv@vishnu

Mike,
If someone were to interrogate every single module in the entire car looking for legitious data, there is no doubt that something will pop up. Even lowering the car with springs will leave traces somewhere.

http://www.e90post.com/forums/showpo...6&postcount=39

[cn555ic]

Originally Posted by fotios335i

...so am I in trouble? It had to have been close to 170. damn that procede....

Damn 170

[FotiosF90M5]

Originally Posted by cn555ic

Damn 170

It was still pulling.even a stage 1 car is capable of 175+. It gets it done quickly too. Autobahn burner for sure!!

[HPFREAK]

Good info Mike and I was going to have my local tech email this info tomorrow so I can post it but you beat me to it.lol

He did tell me that the data is stored and taken from all the moduals but ca not say how long the data is stored for, but to be honest the chances of having them find the speed manipulation is pretty high even it only stores the info for an hour in the history seeing that pushing the car hard at high speeds is going to be a situation where bad things will happen rather fast and thus they will be able to dig it out of the moduals. I think that if a turbo or an engine is going to fail due to many factors, it will be even more likely to happen at high speeds when the engine is working very hard.

Originally Posted by Mike@N54Tuning.com

My understanding is that it's transmitted to every node, like the airbag module, dash module, ECU, etc. Some nodes have a reason to store it and others don't. The DSC module itself stores the information as well. So when something bad happens BMW just interrogates all the modules and can read the information out.

PS. Here is what Shiv had to say about it last thread when this issue came up.



http://www.e90post.com/forums/showpo...6&postcount=39

[Digital.James]

Originally Posted by Mike@N54Tuning.com

It follows the same philosophy as if the speed is above factory then there could be an issue. Its not the absolute speed that is a worry, but the value over factory.

The other issue is safety. I really don't understand why you would want to go that fast, so its great that its available as an option for the JB3 crowd and Shiv mentioned that it is off by default in the Proceed which is also great IMO. For the guys that need/want this please ensure your car is setup for such speed, including tires, breaks, etc. Don't want to have something fail at that speed.

Mike

Mike. I would never drive that fast on roads, but there's one reason why I want a raised speed limit: the dyno. Not sure how many dynos youve been around on non-sports, but since Terrys 135 is a nonsport, he must know too. You hit the speed limiter when dynoing in 4th gear at about 6200 RPM. Its very annoying

[Jayock]

Originally Posted by Mike@N54Tuning.com

My understanding is that it's transmitted to every node, like the airbag module, dash module, ECU, etc. Some nodes have a reason to store it and others don't. The DSC module itself stores the information as well. So when something bad happens BMW just interrogates all the modules and can read the information out.

PS. Here is what Shiv had to say about it last thread when this issue came up.



http://www.e90post.com/forums/showpo...6&postcount=39

It is sent everywhere CAN, IIC and other busses work this way. Now whether each module is setup to listen to all info is another story.

[adrian@vishnu]

Mike,

All the data you have presented says is that the speed is available on the CAN bus to the DME. It is also available to any other module connected to the PT_CAN bus. This however does not indicate that the data is stored or even used by all modules on the CAN bus.

I believe the reason why the DME has a direct connection to the wheel speed sensor is that any data used to control the engine is pretty much always gotten direct from the sensor. This is why all the engine sensors go direct to DME rather than via another box on the CAN bus. In the case that it gets the same data from 2 sources, it would be more likely to "trust" the data from the direct sensor connection, because this is the logic normally used in these systems.

So it is technically possible that the DME and other modules could store VMAX from the DSC, but I think it unlikely. The data you have presented provides no evidence that this is the case, and I have never seen any data that suggests this is the case, and I am aware of some modified cars that have had turbos replaced under warranty having been driven past the speed limitter.

Until I see evidence that a warranty claim is denied for this, I will assume that this is not happening, as I see evidence of warranty claims not being denied when a test as you suggest would have resulted in denial.

At the end of the day, BMS and Vishnu both have solutions for speed delimitting that work in a similar way. Both companies take a stand that using this speed on public roads is dangerous and advertise that it is off road use only. One disables a builtin default feature, the other offers the feature as a non standard addon. If the warranty risk is too much, the user has the choice to not take the risk. Even with the feature enabled, the user only risks the warranty if they go over the limitter.

Nobody has asked the question, but if you really want to drive your car that fast, which is beyond what the car was designed for (but it is probably fine beyond that) should BMW really be held liable if something fails? You pay to play, and if going that fast is really important to you, you should be prepared to pay if it goes wrong.

[munters]

I don't know why you all talk so much about this speed. you're just not used to it that's all.
It's not THAT fast. if you drive this speed for a few hours it becomes just normal. I don't want to sound like a big mouth, but the general cruising speed on the autobahn is often arround 130.

[marconi118]

155Mph = 250Km/h is a "political agreement" in germany.

BMW AUDI MERCEDES agreed to limit their cars to 250Km/h so that the german government leaves the speed on the Autobahn unlimited.
Why sports cars like ferrari lamborghini etc don't have any limiter?
In fact the german government thinks that the super sports cars are so seldom, who cares about that. But so many BMW AUDI and Mercedes are on the autobahn... so better limit all to 250

BMW M3 got a trick to counter this agreement in europe: if you buy as an option for 7K the safety sport driving course of 4 days and you pass it then they remove the speed limiter...

If the M3 can more than 155 then the 335i with mods can do the same

[jale france]

When the power of two cars are almost identical you must go over 155 mph for make the difference in a run. For me 170 mph it's often and max speed sometime when i go to the run of car

[Mike@N54Tuning.com]

Originally Posted by adrian@vishnu

Mike,

All the data you have presented says is that the speed is available on the CAN bus to the DME. It is also available to any other module connected to the PT_CAN bus. This however does not indicate that the data is stored or even used by all modules on the CAN bus.

I believe the reason why the DME has a direct connection to the wheel speed sensor is that any data used to control the engine is pretty much always gotten direct from the sensor. This is why all the engine sensors go direct to DME rather than via another box on the CAN bus. In the case that it gets the same data from 2 sources, it would be more likely to "trust" the data from the direct sensor connection, because this is the logic normally used in these systems.

So it is technically possible that the DME and other modules could store VMAX from the DSC, but I think it unlikely. The data you have presented provides no evidence that this is the case, and I have never seen any data that suggests this is the case, and I am aware of some modified cars that have had turbos replaced under warranty having been driven past the speed limitter.

Until I see evidence that a warranty claim is denied for this, I will assume that this is not happening, as I see evidence of warranty claims not being denied when a test as you suggest would have resulted in denial.

At the end of the day, BMS and Vishnu both have solutions for speed delimitting that work in a similar way. Both companies take a stand that using this speed on public roads is dangerous and advertise that it is off road use only. One disables a builtin default feature, the other offers the feature as a non standard addon. If the warranty risk is too much, the user has the choice to not take the risk. Even with the feature enabled, the user only risks the warranty if they go over the limitter.

Nobody has asked the question, but if you really want to drive your car that fast, which is beyond what the car was designed for (but it is probably fine beyond that) should BMW really be held liable if something fails? You pay to play, and if going that fast is really important to you, you should be prepared to pay if it goes wrong.

I think we agree on some parts.

The wheel speed sensors are fed into the DSC module which is doing the conversion and computing the MPH. This MPH is then made available to all modules. Certain modules such as the DME, DSC, and airbag module keep their own set of diagnostic data. I've been told by multiple sources the DSC stores VMAX and that is perfectly consistent and reasonable with what one might want to review during diastnocis. If you flip through the modules with the BT you can see each one has its own internal codes and freeze frame data.

As far as what the ECU stores, it isn't relevant to this conversation, but I would be surprised if it did not store CAN bus VMAX and sensor VMAX as unique values. The only reason the ECU has a hardwire input is because it must require a faster sampling rate than what the CAN bus can provide for its mapping.

There is no dispute that the delimit can function and that users should only use it with extreme care. Also no disagreement on users taking responsibility for their actions in the event of a major failure. The only debate here is on the degree to which it can be detected. Which as one would expect given the architecture we've outlined is very easy to detect.

As a side note, while the first BMS delimiter uses an independent 12v source, I've been told they have a unit under development now that does not require an independent 12v source. The ECU input is simply switched to ground and floats up to the appropriate voltage between cycles. Both run off a $.80 PIC12F processor @ 4mhz. Not exactly serious computing power.

Mike

[adrian@vishnu]

Theoretically it is possible that any module on the CAN bus could record VMax, but it is unknown if any unit does. Frankly a BMW tech is about the last person I would trust on giving accurate info about that. Nost would not know and just regurgitate what is presented to them, and what is presented to them is what BMW Germany wants us to think. However one thing that is known is that out of the 100s of people running speed delimitters, there is not a single instance of this causing any issue to warranty or otherwise. So people can assess the risk for themselves.

I suspect the reason the DME has direct sensor access has little to do with the CAN sample rate (which is very fast), and more to do with the fact that the DME must continue to run the car in some drivable form in the event of a CAN bus failure (say CAN_H and CAN_L are shorted togeather).

You are right that it is quite possible to do the speed delimitting function in cheap low end processors. But the issue is that to do it along with other high rate features requires a higher end processor. It would be possible to construct a unit similar to the Procede with several cheap low end processors all doing different things, but it would be a headache, and cost saving would be minimal. Having a single processor to do everything means that we do not have to worry about communications between modules, software upgrades to multi modules etc. We can implement a change to the O2 sims or speed delimitter as a firmware upgrade to the unit which can be done without removing the tray to get to the ECU in a few minutes. We think that our customers value this and are willing to spend a bit more to have a product that does it all without having to get extra modules if desired that end up taking it to similar money. Evidently both approaches have appeal in the market to each others customer base which seem to be characterised quite differently.

I can't remember what the voltage is of the wheel speed signal, so cannot comment on whether it can be done without 12V, but neither do I care. Adding the 12V during a Procede install takes about 30 seconds, and provides significant benefits. My personal engineering take is that to suck 5V from the DME which has not been power budgeted in the DME design has some risks. However BMS has done it successfully, so I cannot deny that it works. I just don't think it is the most robust solution from an engineering perspective, but I am a pretty conservative engineer. The Procede is a very robust design and follows modern electrical engineering practises.

Originally Posted by Mike@N54Tuning.com

I think we agree on some parts.

The wheel speed sensors are fed into the DSC module which is doing the conversion and computing the MPH. This MPH is then made available to all modules. Certain modules such as the DME, DSC, and airbag module keep their own set of diagnostic data. I've been told by multiple sources the DSC stores VMAX and that is perfectly consistent and reasonable with what one might want to review during diastnocis. If you flip through the modules with the BT you can see each one has its own internal codes and freeze frame data.

As far as what the ECU stores, it isn't relevant to this conversation, but I would be surprised if it did not store CAN bus VMAX and sensor VMAX as unique values. The only reason the ECU has a hardwire input is because it must require a faster sampling rate than what the CAN bus can provide for its mapping.

There is no dispute that the delimit can function and that users should only use it with extreme care. Also no disagreement on users taking responsibility for their actions in the event of a major failure. The only debate here is on the degree to which it can be detected. Which as one would expect given the architecture we've outlined is very easy to detect.

As a side note, while the first BMS delimiter uses an independent 12v source, I've been told they have a unit under development now that does not require an independent 12v source. The ECU input is simply switched to ground and floats up to the appropriate voltage between cycles. Both run off a $.80 PIC12F processor @ 4mhz. Not exactly serious computing power.

Mike

[yandy]

This type of discussion I like.. keep it coming guys.. very good info

[onefastman]

Yes please continue