Car/Truck Sensors - Sampling Rate?

Thread Starter

Fran3

Joined Mar 28, 2019
46
Probably varies depending on which sensor and what conditions... but not sure.

Can anyone give me some idea of how often a car/truck ECU/ECM samples various vehicle sensors.
  1. Mass Airflow Sensor
  2. Knock Sensor
  3. Manifold Absolute Pressure Sensor
  4. Oxygen/O2 Sensor
  5. NOx Sensor
  6. Engine Speed Sensor
  7. Throttle Position Sensor
  8. Crankshaft Position Sensor
  9. etc
For example:
At 6,000 RPM... that's 100 Rotations Per Second.

So if we sampled a sensor once per Rotation that would be 100 Samples Per Second
And if the ECU/ECM is monitoring 50 sensors at that rate...
then it would be taking samples 5,000 Per Second.

Or if we sampled the sensor 10 times per Rotation that would be 1,000 Samples Per Second.
And if the ECU/ECM is monitoring 50 sensors at that rate...
then it would be taking 50,000 Samples Per Second.

But of course the sample rate may vary for various sensors... but I'm not sure...
So thanks for any help on researching the typical sample rate for various vehicle sensors.
 

crutschow

Joined Mar 14, 2008
34,468
Generally sensors are only sampled as often as they need to be, depending upon their function, to minimize the load on the engine microprocessor.
Thus things like temperature or throttle position would be sampled less often than crankshaft position or knock sensor.
As to what those sample rates actually are, that would be from the car manufacturers, if they publish that info.
 

nsaspook

Joined Aug 27, 2009
13,315
Search for ECU/ECM patents. There's usually a section that have various timing requirements for sensors for a typical ICE. You can use that to derive sample rates for X type of sensor.
 

Irving

Joined Jan 30, 2016
3,897
Here's a brief overview from a CANHUG discussion document regarding diesel engine control. The rest of the article isn't really relevant as its all about mapping from the J1939 spec to another but this table gives you an idea. Most engine parameters are relatively slow, but those directly related to speed/performance would appear to work on a basic timebase of 100 samples/sec or 10mS message rate or slower with some 'on change' or ad-hoc messages.

1707502157134.png
 

nsaspook

Joined Aug 27, 2009
13,315
Here's a brief overview from a CANHUG discussion document regarding diesel engine control. The rest of the article isn't really relevant as its all about mapping from the J1939 spec to another but this table gives you an idea. Most engine parameters are relatively slow, but those directly related to speed/performance would appear to work on a basic timebase of 100 samples/sec or 10mS message rate or slower with some 'on change' or ad-hoc messages.

View attachment 314841
Those are likely close for some but the CANBUS message rate is not directly a sensor sampling rate as many of the messages depend on several sensor samples (at the controller device DAQ level) for a triggered message response of a polled and conditioned value.
 

Irving

Joined Jan 30, 2016
3,897
Those are likely close for some but the CANBUS message rate is not directly a sensor sampling rate as many of the messages depend on several sensor samples (at the controller device DAQ level) for a triggered message response of a polled and conditioned value.
Agreed those are not the actual sensor sample rates, but they are indicative of the rates needed for the wider control loops.

My experience on even the latest models is that most sensors are not CANBus but direct connect to the ECU so the only source of actual data is the CANBus. The CANBus OBD2 port on my car shows eg MAF data as derived by the ECU. The MAF output is actually a pulse whose frequency is related to airflow as this is a much more noise-tolerant signal. The actual F-to-V and ADC sampling is internal to the Bosch ECU. When we did a bit of engine mapping all the data the tuner used was off the ODB2 port, no connection to any sensor was made apart from their own exhaust gas sampler.
 

geekoftheweek

Joined Oct 6, 2013
1,221
The ECU is going to register every pulse from both the camshaft position sensor and crankshaft position sensor since they are used to calculate the base timings of everything that needs to happen to make the engine run. After that most data can be sampled relatively slow since the actual change is going to take place over several revolutions. I would say the throttle position would be the next most important as you can calculate and estimate a lot of information based on where the throttle is now compared to what it was the last time it was sampled. You could actually run and engine just off those readings with the right programming although I wouldn't suggest it.

As far as gas engines go the manifold vacuum and / or mass air flow will help a lot with overall driveability, but they will need averaged out over a span of a few cylinders to compensate for variations in readings. Knock sensors get exponentially more important the more lean you try to run the engine. If you program it on the rich side knock sensors aren't very important.

Diesel engines should be at zero manifold vacuum (idieally) and mass air flow wouldn't be nearly as important as boost pressure.

Everything else is more or less emissions related and used to tweak the fuel and timing maps for emissions related reasons.

Since passenger cars and light trucks have all drive line functions controlled by a single controller (with the exception of ABS) it really doesn't make much sense to develop a bunch of CAN based sensors. It will just make things more complex, cost more in wiring (since for the most part it will take more wires to do the same job), cost more in parts, and cost more in development. I'm sure somewhere out there is someone or a group of someones that would love to do it that way, but luckily they haven't prevailed yet.

As far as J1939 and large diesels go there are a few CAN sensors on them, but the basic engine sensors are the same as a passenger vehicle. The turbo actuator, exhaust after treatment controller, NOx sensors, and some exhaust temperature sensors are CAN based, but that is about all. The transmission, engine, and exhaust all have separate controllers as opposed to a single unit which makes the message rate a bit more important. The latest standard I belive is 500k bits/second so it's actually capable of moving a lot of data quickly.
 

geekoftheweek

Joined Oct 6, 2013
1,221
The latest CAN standards are up to 5mbps so message speed is not a problem.
https://www.csselectronics.com/pages/can-fd-flexible-data-rate-intro

A good controller can easily handle 50,000 mixed analog/digital Samples Per Second. More important IMO is precisely timed deterministic processing of the sensor data into a engine control model.

They will eventually make it there. The bad part of individual controllers is everyone needs to redesign to meet the new speeds. The new Freightliners look like they have a server rack built in behind the glove box. Common powertrain controller by Daimler, ABS and stability control by Wabco, adaptive cruise and collision mitigation by Continental, and if I remember correctly a WiFi and GPS unit, and one more. Add in the engine, transmission, and aftertreatment controllers scattered about and you have quite the network.
 

nsaspook

Joined Aug 27, 2009
13,315
They will eventually make it there. The bad part of individual controllers is everyone needs to redesign to meet the new speeds. The new Freightliners look like they have a server rack built in behind the glove box. Common powertrain controller by Daimler, ABS and stability control by Wabco, adaptive cruise and collision mitigation by Continental, and if I remember correctly a WiFi and GPS unit, and one more. Add in the engine, transmission, and aftertreatment controllers scattered about and you have quite the network.
There is a new CAN standard for backbone applications but it's in competition with a few industrial Ethernet based standards like SPE.
https://www.can-cia.org/can-knowledge/can/can-xl/
https://www.electronicdesign.com/ma...etween-can-and-spe-in-the-automotive-industry
 
Top