[Yozh]

On my drive to work on Friday I have played with some parameters. Here are a few interesting ones that may be useful with diagnosing some of the vacuum turbo control system. By this I mean that one can monitor the DDE requests to the actual vacuum output of the controllers and also see how fast they react. I have done this experiment on a compressor bypass where DDE switches the EUV valve within fraction of a second and the vacuum response was instantaneous as well.

The first one is a Turbo Switchover Valve, or rather the DDE control of the pressure converter that controls the vacuum actuator. This is marked in parameters as STAT_LADEDRUCKSTELLER_ANSTEUERUNG_WERT = Boost Pressure Plate - Output Duty. It is expressed as a percentage from 95% to 10% where higher value is a closed plate (more exhaust is channeled to the HP turbo) and lower value is a progressively open valve (switches to an LP turbo). Here is just a raw graph as a snapshot from my drive.


I have found that the behavior of the control is dependent on many variables such as requested boost, rpm, pedal input etc. BMW documents describe the progressive switchover past 1500rpm, I see an earlier opening of the valve in normal driving. However, when suddenly more boost is required the valve will close rather rapidly to shift to HP turbo. In an example below you can see that with application of a throttle turbo switchover was closing for more boost.

-red = pedal value
-green = turbo switchover output (peaks = 95%, lows = appx 50%)
-blue = requested boost
-purple = rpm



Or Here at about 60mph, where RPM only changed from 1600 to 1800, turbo switchover closed to provide more boost.



Second is a Compressor Bypass Valve. DDE controls the EUV either on or off. Parameter for this value is found as STAT_CByVlv_st_WERT = High Pressure Compressor Bypass Valve - Status. Closed value is "0" and open value is "1".



I have also found this not to open at exactly 3000 rpm, but it seems to be variable. On my drive to work, I only had it pop open twice, once at just past 2700rpm and another just past 2900rpm.

I have also found that Turbo Switchover fully opens to LP turbo when Compressor Bypass activates. Of course this may vary with other conditions, but this is what has happened in my short drive.





And the last parameter that I thought may be useful for diagnostics is the one that shows the control of the vacuum controller for the engine mounts. This is a parameter STAT_EMDmp_rPs_WERT = Engine Vibration Damper - Output Duty Ratio. Its value is zero when there is no vacuum and engine mounts are hard, and its value is "100" when engine mounts are soft for starts and low rpm/speed operation.

Below graph shows the function against the RPM.



And finally, I'm still looking for the Wastegate parameter as I feel it would be useful to see how it's controlled from the point of view of parameter monitoring.

[DWR]

Just be aware that some of the parameters are lookups, as pheno mentions.
Engine torque obviously one of those. Then you need to be careful with any speed or acceleration parameters that come from the drive train. Even with the traction nannies on, the wheels can and do move faster than the pavement.

I spent considerable time trying to do this via Testo. Have no intention of curbing anyone's enthusiasm and would love it if someone could get a reliable method working. I concluded the sampling rate and accuracy of the accelerometers in my phone (not all phone are created equal) surpassed anything I could do thru the OBDII port. IMO, the method used by TDIwyse is a good one to model.

If I really wanted to get serious about it, I would intercept the signals from the driver's side front wheel speed sensor with my high speed data logger. For straight line performance, that is even better than an accelerometer.

[TDIwyse]

Originally Posted by DWR

...
If I really wanted to get serious about it, I would intercept the signals from the driver's side front wheel speed sensor with my high speed data logger. For straight line performance, that is even better than an accelerometer.

I like it. It would eliminate the "pitch" fudge factor that the accelerometer method requires to approximate the vehicle suspension/tilt behavior during acceleration.

[pheno]

If the wheel speed sensor is available for tapping in semi-easy location. I could see myself using Arduino or STM32 to read signal and streaming it to high speed serial port and make it read in TestO as an external source. There are a few small size STM32 boards that are also inexpensive. Anybody interested?

One possibility would be to read CAN bus and find wheel speed from there but that would require more HW than plain microcontroller board.

Another possibility would be to make small Android program that streams acceleration into TestO as external source via wlan for example.

What kind of signal is it ?

EDIT: DWR, I was thinking also that maybe the OBD2 port speed is not just enough. I can get speeds of 50-60ms per reply if I log only a few values. Acceleration comes calculated from DDE and I don't know what sensor data it uses for that.

In my logs acceleration graph looks a bit funny as it makes small movement back and forth. Any idea what is causing this ? I'll need to log the other acceleration param also. DWR, if you have logged and tried these same params then I think there's no sense to continue with those anymore. Accuracy is near the ballpark but maybe not just quite there. Also it was very slippery and in the log you can see many 'negative acceleration' spikes due to traction control kicking in.

[DWR]

I made many attempts at this - too many to remember them all. None of the obvious methods would work. Just as you are finding the out, the data was too ragged.

If you want to design your own circuit, I would suggest starting with a precision frequency to voltage converter IC. That with a couple of capacitors and some resistors, you could output a voltage signal to Testo. I still think there might be sync issues, but it would be interesting to try.

[DWR]

Originally Posted by TDIwyse

I like it. It would eliminate the "pitch" fudge factor that the accelerometer method requires to approximate the vehicle suspension/tilt behavior during acceleration.

Exactly! That has always bugged me.

[pheno]

Originally Posted by DWR

I made many attempts at this - too many to remember them all. None of the obvious methods would work. Just as you are finding the out, the data was too ragged.

If you want to design your own circuit, I would suggest starting with a precision frequency to voltage converter IC. That with a couple of capacitors and some resistors, you could output a voltage signal to Testo. I still think there might be sync issues, but it would be interesting to try.

That would probably be the solution with ultimate resolution. Sync issue would be evident as data from OBD2 would lag behind converter circuit. But could be fixed within the program.

Based on your experience what resolution is good enough ? I'll try getting data straight from CAN Bus

EDIT: looks like resolution for wheel speed sensors is roughly 35-40 samples / seconds. Is that good enough to get accurate acceleration info ? This might be even faster if I filter in only this ID and take load off from USBTin hardware. Currently it reads all messages from the CAN bus. USBTin has only 115200 baud rate which I find somewhat limiting. In the following log I'm turning to left. Seems to have 2 bytes per wheel, PID 0xCE

EDIT2: enabled filter for USBTin and now I seem to get steady 50 samples / sec from CAN Bus for wheel speeds. I'll try to gather some data later.

this data is logged within 1 second:

Line 97683: 105035 0ceh 8 3a 01 61 01 3b 01 5f 01
Line 97701: 105051 0ceh 8 3b 01 61 01 3e 01 60 01
Line 97721: 105066 0ceh 8 3c 01 64 01 40 01 61 01
Line 97738: 105097 0ceh 8 3f 01 67 01 3f 01 64 01
Line 97777: 105129 0ceh 8 41 01 68 01 42 01 66 01
Line 97794: 105160 0ceh 8 43 01 69 01 43 01 66 01
Line 97813: 105175 0ceh 8 45 01 6a 01 43 01 68 01
Line 97831: 105191 0ceh 8 45 01 6a 01 45 01 68 01
Line 97868: 105238 0ceh 8 47 01 6c 01 48 01 6a 01
Line 97887: 105253 0ceh 8 4a 01 6e 01 4a 01 6a 01
Line 97906: 105269 0ceh 8 4a 01 6f 01 4a 01 6d 01
Line 97925: 105285 0ceh 8 4b 01 6f 01 4c 01 6e 01
Line 97962: 105331 0ceh 8 4e 01 71 01 4f 01 70 01
Line 97978: 105347 0ceh 8 4f 01 73 01 52 01 72 01
Line 97997: 105378 0ceh 8 51 01 75 01 53 01 72 01
Line 98014: 105394 0ceh 8 52 01 76 01 54 01 75 01
Line 98051: 105441 0ceh 8 55 01 7a 01 58 01 78 01
Line 98069: 105456 0ceh 8 56 01 7a 01 5a 01 78 01
Line 98107: 105487 0ceh 8 58 01 7c 01 5c 01 7b 01
Line 98144: 105534 0ceh 8 5b 01 7e 01 5d 01 7f 01
Line 98178: 105565 0ceh 8 5d 01 81 01 61 01 81 01
Line 98197: 105597 0ceh 8 5f 01 81 01 63 01 83 01
Line 98216: 105612 0ceh 8 61 01 83 01 64 01 83 01
Line 98233: 105628 0ceh 8 61 01 84 01 65 01 84 01
Line 98252: 105659 0ceh 8 63 01 85 01 67 01 85 01
Line 98273: 105675 0ceh 8 65 01 86 01 68 01 86 01
Line 98289: 105690 0ceh 8 67 01 88 01 6a 01 89 01
Line 98328: 105737 0ceh 8 69 01 8c 01 6d 01 8c 01
Line 98346: 105753 0ceh 8 6a 01 8c 01 6f 01 8d 01
Line 98365: 105784 0ceh 8 6d 01 8e 01 73 01 8e 01
Line 98383: 105799 0ceh 8 6e 01 8e 01 73 01 8e 01
Line 98418: 105831 0ceh 8 71 01 8e 01 78 01 93 01
Line 98456: 105877 0ceh 8 75 01 93 01 7c 01 96 01
Line 98473: 105893 0ceh 8 77 01 94 01 80 01 98 01
Line 98491: 105909 0ceh 8 79 01 96 01 83 01 9b 01
Line 98508: 105924 0ceh 8 7c 01 96 01 85 01 9d 01
Line 98526: 105955 0ceh 8 7f 01 9a 01 86 01 9e 01
Line 98544: 105971 0ceh 8 82 01 9d 01 89 01 a0 01
Line 98561: 105987 0ceh 8 83 01 9e 01 8c 01 a3 01
Line 98597: 106033 0ceh 8 88 01 a3 01 91 01 a7 01

[pheno]

STAT_ActMod_trqClth and MOTORMOMENT_AKTUELL seem to be almost exactly the same on my car.

Also it's quite evident that the acceleration sensors (FAHRZEUGBESCHLEUNIGUNG) are not that accurate. It follows motor moment parameter but not quickly/accurately enough.

Next I'll try to log wheel speed sensors from CAN Bus and hope to get 50 samples / sec. Might be enough to calculate acceleration and combine that log with TestO log.

[TDIwyse]

Originally Posted by pheno

...
Based on your experience what resolution is good enough ? I'll try getting data straight from CAN Bus

EDIT: looks like resolution for wheel speed sensors is roughly 35-40 samples / seconds. Is that good enough to get accurate acceleration info ? This might be even faster if I filter in only this ID and take load off from USBTin hardware. Currently it reads all messages from the CAN bus. USBTin has only 115200 baud rate which I find somewhat limiting. In the following log I'm turning to left. Seems to have 2 bytes per wheel, PID 0xCE

EDIT2: enabled filter for USBTin and now I seem to get steady 50 samples / sec from CAN Bus for wheel speeds. I'll try to gather some data later.
...

If the time samples are accurately linked to the speed at the specific sample time, then I think you would be getting to the region of enough samples/sec. A 4th gear pull takes longer than a 3rd gear pull, so as a percentage the delta time would be smaller for the 4th gear type of test.

As a comparison, yesterday after work I did a "Timed run" test with PerfExpert. Here is an example of its raw data. It's time steps are not perfectly uniform and seem to run between 3.3 millisecond and 5.6 millisecond.

[pheno]

Originally Posted by TDIwyse

If the time samples are accurately linked to the speed at the specific sample time, then I think you would be getting to the region of enough samples/sec. A 4th gear pull takes longer than a 3rd gear pull, so as a percentage the delta time would be smaller for the 4th gear type of test.

As a comparison, yesterday after work I did a "Timed run" test with PerfExpert. Here is an example of its raw data. It's time steps are not perfectly uniform and seem to run between 3.3 millisecond and 5.6 millisecond.

Thanks. Well, I have to admit I didn't know accelerometer sensor on a smartphone could be that accurate! 5ms vs 20ms makes a difference. I wonder if the sensor really outputs data that accurately or if they are using some averaging function before writing log to file.

Yes, I get can read wheel speed exactly every 20ms. I just have to find out a formula to convert that raw value first to m/s and then into m/s^2. Anybody happen to know exact number of bearing ring teeth count ?

[DWR]

Like I said, high speed data logging from the wheel. Ultimately, you want to be able to count the pulses. CAN is not going to do that. The fast sampling and accelerometer accuracy is what makes PerfExpert a decent tool. There is a reason why automotive journalists use fifth wheels to measure straight line acceleration and braking. It is an accurate, robust and dependable method. We can use front wheel sensors in exactly the same way.

[pheno]

Originally Posted by DWR

Like I said, high speed data logging from the wheel. Ultimately, you want to be able to count the pulses. CAN is not going to do that. The fast sampling and accelerometer accuracy is what makes PerfExpert a decent tool. There is a reason why automotive journalists use fifth wheels to measure straight line acceleration and braking. It is an accurate, robust and dependable method. We can use front wheel sensors in exactly the same way.

The data I posted is the pulse amount per every 20ms for each wheel. But I still find it not accurate enough, it should be around 1000samples to get nice curve without smoothing :-) the wires are going in DSC box and available in easy place... hmm..

[DWR]

[QUOTE=pheno;21284723]The data I posted is the pulse amount per every 20ms for each wheel. But I still find it not accurate enough, it should be around 1000samples to get nice curve without smoothing :-) the wires are going in DSC box and available in easy place... hmm..[/QUOTE

I would have thought counts would be whole numbers. Maybe I am misreading the graph?

[pheno]

[QUOTE=DWR;21293667]

Originally Posted by pheno

The data I posted is the pulse amount per every 20ms for each wheel. But I still find it not accurate enough, it should be around 1000samples to get nice curve without smoothing :-) the wires are going in DSC box and available in easy place... hmm..[/QUOTE

I would have thought counts would be whole numbers. Maybe I am misreading the graph?

Ah, sorry, the graph does not contain data from can bus. It's a log from TestO. But the log in post #29 with hex values is the raw data from can bus.

Check the attachment! I converted another log from can bus raw data into decimals. There are 4 columns - one for each wheel. First one is system time stamp (millisecs from epoch time). At around line 2940 I did a short acceleration. I haven't had time to try convert that data into acceleration.

[DWR]

Sorry, my misunderstanding. That is very good. We may find the sample frequency can be less with wheel speed because the accelerometer method has some amount of jitter due to road irregularities. Besides, the torque curve should be relatively smooth enough to be discerned by 100 data points. A high gear pull should allow that.

If I remember correctly there is a speed parameter that has high resolution. It is not the OBDII PID. That could be logged with wheel count to get a conversion factor for your vehicle. Matching wheel count with true speed would seem to be best practice for calibration. I bet the conversion may change with speed.

[TDIwyse]

Originally Posted by DWR

... We may find the sample frequency can be less with wheel speed because the accelerometer method has some amount of jitter due to road irregularities. ...

Agreed. When going to low smoothing of the raw data, even small irregularities of the road surface are showing up on the accelerometer data I've been recently taking.

[pheno]

Originally Posted by DWR

Sorry, my misunderstanding. That is very good. We may find the sample frequency can be less with wheel speed because the accelerometer method has some amount of jitter due to road irregularities. Besides, the torque curve should be relatively smooth enough to be discerned by 100 data points. A high gear pull should allow that.

If I remember correctly there is a speed parameter that has high resolution. It is not the OBDII PID. That could be logged with wheel count to get a conversion factor for your vehicle. Matching wheel count with true speed would seem to be best practice for calibration. I bet the conversion may change with speed.

It looks like conversion factor into km/h for my car/tires is around 15.9. I recorded TestO log and CAN Bus log with other program simultaneously.

1142/71.7922 = 15.9

TestO log: 4th column is speed in km/h

1487317867958;16.1008;-0.441;71.8838;1349.96;1705;33.3102
1487317868070;15.405;-0.457;71.7922;1345.94;1698.5;31.5936
1487317868137;15.2829;-0.372;71.6594;1339.98;1696.5;29.4192

Raw CAN bus log:

1487317868011 206  77 4 7c 4 7e 4 76 4
1487317868031 206  76 4 7a 4 7e 4 76 4 --> 4*256+118=1142
1487317868051 206  78 4 77 4 7c 4 75 4
1487317868071 206  79 4 77 4 7d 4 75 4
1487317868091 206  75 4 76 4 7e 4 76 4
1487317868111 206  74 4 78 4 7c 4 75 4
1487317868131 206  75 4 77 4 7a 4 75 4
1487317868151 206  75 4 75 4 79 4 75 4

DWR: What kind of calculation formula would you suggest to use to get acceleration in this case ? Any good smoothing algorithms you have you can suggest or are they needed ?

[DWR]

Originally Posted by pheno

DWR: What kind of calculation formula would you suggest to use to get acceleration in this case ? Any good smoothing algorithms you have you can suggest or are they needed ?

Maybe you would like to go directly to an HP calculation? You can have different accelerations for the same HP, depending upon speed/gearing. But RWHP can be directly calculated if you know speed, change in speed/time, weight of the vehicle.

I would try it first without smoothing. As long as the data is at a high wheel count/speed (gear), it should be fairly smooth, without resolution error.

Also, there maybe some wheel diameter growth at high speed. So, I would verify whether the conversion constant is indeed a constant or slightly speed dependent.

[pheno]

Originally Posted by DWR

Maybe you would like to go directly to an HP calculation? You can have different accelerations for the same HP, depending upon speed/gearing. But RWHP can be directly calculated if you know speed, change in speed/time, weight of the vehicle.

I would try it first without smoothing. As long as the data is at a high wheel count/speed (gear), it should be fairly smooth, without resolution error.

Also, there maybe some wheel diameter growth at high speed. So, I would verify whether the conversion constant is indeed a constant or slightly speed dependent.

To get HP/Torque is the target of course so yes.

Originally Posted by DWR

As long as the data is at a high wheel count/speed (gear), it should be fairly smooth, without resolution error.

I'm sorry could you elaborate on what do you mean with 'data is at a high weel count/speed'.

I can believe I can get also (high resolution) vehicle speed from can bus in addition to single wheel speeds. And you're right there might be variance due to wheel diameter growth.

Is there anything else that should be logged, RPM maybe ? In any case I'd need some help from you regarding calculations in excel and further in getting it work in (almost) realtime :-) Thanks.

[TDIwyse]

Originally Posted by pheno

...

Is there anything else that should be logged, RPM maybe ? In any case I'd need some help from you regarding calculations in excel and further in getting it work in (almost) realtime :-) Thanks.

I'd suggest adding the rpm, at a minimum. This would be helpful for plotting the results on a dyno-like graph (rpm as X axis).

And you'd really want to know the ambient pressure and temperature (ideally you'd want humidity as well, but I don't think the car's sensors measure that) to apply correction factors if you wanted to compare previous or future modifications to one another (although this could be accounted for in post processing steps).

[pheno]

Originally Posted by TDIwyse

I'd suggest adding the rpm, at a minimum. This would be helpful for plotting the results on a dyno-like graph (rpm as X axis).

And you'd really want to know the ambient pressure and temperature (ideally you'd want humidity as well, but I don't think the car's sensors measure that) to apply correction factors if you wanted to compare previous or future modifications to one another (although this could be accounted for in post processing steps).

Thanks! Yeah, RPM is always good to have. I'm looking at to get RPM from can bus so we get high resolution data for that also.

Yeah, I'm planning to add these CAN bus messages available in TestO as 'external source'. Some of the params that are available from can bus could be logged in high resolution and some other via TestO as separate requests like temp and ambient pressure.

[TDIwyse]

I was just playing with the data from post #31 above, and looking at back calculating the measured acceleration from the measured mph and time step data (this is essentially what we would be trying to do with TestO data).

I see more "noise" in the data if I try to go to too small of a time step size/resolution. I think this is because the resolution of the speed data is too course for the resolution of the small time step... going to larger step sizes, where the resolution of the recorded speed is better, actually produces more accurate results...