When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Durametric Logging Live Values – Having Trouble, Help please
2009 C2S Manual Coupe
Why am I getting what appears to me as bogus values from live logging?
Given the cold temperatures we had last week and my pesky geek gene expressing itself, I wanted to see how the water and oil temperatures rose with time and engine speed. So, some questions:
1 – What variables should I be reading to obtain simple water and oil temps from?
2 – My car’s dash read temp at 8:00 AM in Bridgewater NJ to be about 25F but the data pulled shows the car water to be 32F and the intake air temp at 39F. The car sat in the driveway, outside all night and I confirmed the historical, hourly temp data from WeatherUnderground. Why the discrepancy?
In the dump above, you will see the actual variable ID Number and description denoted in the Durametric tool. Note that there are many variables that appear to contain the same data.
Below is a list of each variable I tracked and what I believe was the response from the DME:
"Time" - This appeared to work, returned time of day
A020 Engine Speed" - This appeared to work, returned RPM
"A100 Vehicle speeed from PSM" - This appeared to work, returned KPH
"T010 Engine temperature" - This appeared to work, returning Celsius, however it was 25F and the returned value was 0C (32F) with highest temp stabilized at 85.5C (185F); maybe it does not record negative values?
"T020 Engine temperature (measured)" - This appeared to work, returning Celsius but what is the difference as T010 & T020 numbers were the same?
T030_Engine oil temperature” – I have no clue what was returned… started off with 721, then was blank values, and then a block of -24.92 and more blank … just bizarre.
“T040_Intake air temperature” - This returned values around 3.7C (39F) but again, I it was 25F that morning.
“T050 Ambient air temperature (via CAN)” – This returned the same bizarre valued as T030 oil temps.
“T090 Engine temperature (sensor)” – This returned values around 32F… it appears to be measuring some sort of ambient temp but again, the ambient temp was 25F.
“T100 Engine oil temperature (sensor)” – returned a pretty consistent, bizarre value of 02.08.2003
“T110 Intake air temperature (sensor)” – returned a pretty consistent, 36F
Some history with the Durametric tool…. It didn’t work out of the box for live value logging and took them ….. I can’t remember exactly….. but say 8 months to a year to debug the software. They had a problem with some models but finally fixed it. I worked with them over the phone beta testing some fixes etc.. .troublshooting etc. In short, Durametric is a hack. It is back engineered. Porsche is not telling anyone how to access let alone interpret their systems. Also, Durametric is the USA distributor for HEX Microsystems of South Africa, the real author of this software. http://www.hex.co.za/
I am going to cross-post this on the turbo forum.... they seem to have more experience with this over there.
Below is my water temp chart over time..... Notice it took about 9 minutes for water temps to come up to full. What you don't see is the oil temps..... I ran the data collection while I was driving (obviously) until I saw the dash oil temp gauge stabilized at full tempurature.... this implied that it took about 20 minutes for oil temp to get to normal.... but as I noted above, I collected bogus values.
By the way, if you doubt that it was 25F, here is the Weather Underground temp chart for the adjacent town...
Hmmm... I just noticed.... the water temp rise is really linear..... it doesn't seem to be affected by revs. Higher revs would generate more heat. It also doesn't seem to be affected by vehicle speed either as faster movement runs cold air over the radiators. Hmmmmmm
1 – What variables should I be reading to obtain simple water and oil temps from?
Coolant temperature is PID (parameter ID) 5. It is offset by -40C. Thus a reading of 0 is actually -40C. However, Durametric should normalize this data: Reading (converted to decimal) - 40C = C. Thus a reading of 0 would be 0 - 40 = -40C. A reading of 50 (hex) would be 80 (decimal) - 40 would be 40C. A reading of 7A (hex) would be 122 (decimal) and 122 - 40 would be 82C or 180F.
There is no standard OBD2 PID for oil temperature. There might be an extended OBD2 PID but if there is I'm not sure Durametric can be directed to query for that. Also, I'm not sure Porsche even supports that PID.
Also, there might be oil temperature flying by on the CAN bus in a packet that could be snagged by the Durametric as the packet passes by. However, not having snooped the CAN bus of a comparable car I'm not sure the oil temp is even present and if it is I'm not sure if Durametric supports doing this.
In fact after reading the rest of your post regarding the confusing or clearly wrong values provided for some data I'd say this isn't working right or the packet format has changed and Durametric hasn't yet got around to updating its firmware.
In Durametric's defense the CAN data traffic they are attempting to use is not documented by Porsche so one has to obtain this CAN bus traffic packet data using a bus snooper and capture/log the data then reverse engineer the data. I have done this for some other data of interest: Mainly odometer data; but oil temperature was not a high priority. (There can be a storm of CAN bus traffic and one can be looking at that is faced with looking at data capture logs that consist of hundreds of packets per second.)
2 – My car’s dash read temp at 8:00 AM in Bridgewater NJ to be about 25F but the data pulled shows the car water to be 32F and the intake air temp at 39F. The car sat in the driveway, outside all night and I confirmed the historical, hourly temp data from WeatherUnderground. Why the discrepancy?
What you observed is what I have observed and really what I would expect. It takes time for the car and its fluids to shed heat and even though the car was outside there was not enough time for this to happen. The car really needs to soak at a constant temperature for for some time but I do not know the time.
Hmmm... I just noticed.... the water temp rise is really linear..... it doesn't seem to be affected by revs. Higher revs would generate more heat. It also doesn't seem to be affected by vehicle speed either as faster movement runs cold air over the radiators. Hmmmmmm
Peace
Bruce in Philly
The water temperature is rather linear (not sure this is the right word to describe the water temperature's lack of volatility but you used it so I will too) but it is linear because the water flow is not linear.
Obviously as engine speed increases the water pump turns faster so more water flows past a spot in the engine in a given amount of time so this gives the water a chance to absorb any extra heat a higher revving engine produces and shed it at the radiator.
Also engine output does necessary increase with engine speed. One needs to plot engine load to see how hard, or not, the engine is really working.
I have read that the dash water temperature gauge is computer driven and the computer is programmed to show 175 all of the time unless it is lower. Figuring simple fluid dynamics under various driving conditions, based upon observations, I am inclined to believe this.
The OBD II is also computer driven. What lies might it be telling you?
Add to that the offsets that are programmed into the hex values and the conversion of units (I have seen errors introduced by units too many times) and you are juggling a lot of *****!
1 - I think there is a bug (s) in the Durametric software... I am going to send them an email. Why? Because the registers are there to pick up the values. The Porsche computer, via the OBD2 port, does so this can be done. My experience with Durametric is that their stuff is buggy (heck it took them almost a year to make the darn software talk to the DME!). When you talk about no standard... of course there is no standard, this is Porsche stuff, or more accurately Siemens stuff. However there is an oil temp PID "5C" if I am reading the chart properly... List of PIDs
2. My point about the linearity of the water temp... what I meant was the temp rise was linear over time. I find this to be evidence that Porsche is controlling the rise to be a steady, controlled event so as to allow the engine internals to accept controlled temp change. My drive had a typical mix of stop signs, lights, quick acceleration etc. Note that I did not start moving the car until 2 mnts after engine start yet the linear rise was happening from engine start. I find this more than chance.
3. While I don't know how the thing really reads data, I do have some insight given the debugging I did with the Dura guys.... The Durametric software definitely issues querry commands to the DME and receives specific responses. During the debugging process, the DME was responding with something like "Invalid command or querry" or something like that. While the bus may have lotsa different data flying by at all times, the software requires some sort of handshaking with the DMA to work otherwise they could just sniff the packets. Also, for whatever reasons to Porsche or Siemens, there are many different DME modules for a given year that are sort of interchangeable. For example, the Durametric software determines the engine type via a DME querry when it connects however if say it doesn't read because you already had the software started, you can force or then override the protocol by selecting a different Engine/DME type. When we were debugging, we could get the DME to respond and provide live values by selecting selecting the Turbo module. The Dura guys said that I shouldn't use this module as some queries may return bogus values... different engine modules behaved a bit differently from one another.
The Dura software has specific parameters to track by ticking off from a very extensive list. This list, I beleive, is just not wishful thinking but the stuff that actually is provided by Siemens DME. The turbo guys and indy mechanics use this stuff all the time but for some reason, a 2009 C2S has just been a problem for Dura. They guys said that they were having trouble with "some models".
Oh well, off to Durametric of some help. If my history with them predicts the future, it may be a while.
Peace
Bruce in Philly
Last edited by Bruce In Philly; 11-23-2014 at 06:21 PM.
I have read that the dash water temperature gauge is computer driven and the computer is programmed to show 175 all of the time unless it is lower. Figuring simple fluid dynamics under various driving conditions, based upon observations, I am inclined to believe this.
The OBD II is also computer driven. What lies might it be telling you?
Add to that the offsets that are programmed into the hex values and the conversion of units (I have seen errors introduced by units too many times) and you are juggling a lot of *****!
It is hard to know exactly how this is implemented but it can be the coolant temperature converted from analog (a voltage level reading) to digital is sent over the CAN bus to the instrument cluster controller. This controller converts the digital value back into an analog voltage value which is used to drive the gage needle. Where the dampening or modification of this actual coolant temperature reading takes place is open for discussion but I suspect it is not in the DME. The DME uses the digital data in various calculations. It makes no sense to burden this processor with the extra work of tweaking this data. (The processor has lots of other work to do.)
Therefore my WAG is the instrument cluster controller modifies this data before converting it back into an analog value.
The other possibility is the gage circuit has some hardware that dampens the needle's action even if supplied with a true voltage level.
My experience is the DME pretty much tells the truth. That is I know of no cases where it lies.
Now this does not mean the data is 100% accurate all the time. But this is not the DME's fault. I know my 02 Boxster's coolant temperature occasionally spikes but I attribute this to a bad connection at the temp sensor: This spiking occurs under a sharp turn on rough roads.
Also, the DME has very important work to do. In some cases it can shed load and one of the things is can shed is servicing OBD2 queries/responses.
In the firmware I wrote for automotive test equipment I always allowed for the possibility the DME failed to receive a query, or failed to respond to it, or responded with a bad frame. In some cases I had to filter the data to catch spurious responses. Coolant temperature is not a real issue -- thanks in part to the fact the output the human sees dampened -- but speed is a real big issue, for instance, when using speed to detect braking/acceleration events that play a role in driver scoring. Might add while I never encountered any problems with speed data from Porsches some other brands were terrible with speed and I had to resort to obtaining speed from these vehicles using brand specific proprietary speed queries.
Might also mention that some vehicles, but based on my experience, not Porsches, had some OBD2 communication problems. They didn't adhere to the specification 100%. I had to adapt my firmware to work with these vehicles.
There is a standard. It is well documented how to talk to DMEs that use PWM, VPW, ISO 9141-2, KWP2000, and CAN (11-bit/29-bit IDs, 250kbs, or 500kbs), heck even J1939 (heavy duty vehicles).
Just because there is a Mode 1 PID 0x5C doesn't mean Porsches support this PID.
While there still exists an oil temperature reading and there is still be a way to obtain oil temperature it is done using Porsche proprietary commands and Porsche doesn't document these.
IOWs, what is not documented in the case of Porsche is how to obtain/interact with the Porsche DMEs to use the proprietary features.
It has been my experience based on my observation even in my 2002 Boxster and my 2003 Turbo (and other brands of vehicles) the coolant temperature rises at a pretty steady rate over time. There is no big jump or pause then a jump.
The only way I know of to possibly affect this, steepen the rise, is to run the engine harder which should cause it to warm up quicker. However, I'm not about to run a cold engine harder. I by habit treat the cold engine as I do to avoid unduly stressing the engine while it is warming up.
The temperature climbing as it does, this is as I would expect. The t-stat is doing its job and that is help the engine obtain its operating temperature as quickly as it can without subjecting the engine to transient temperature spikes or dips events.
Might mention the newer DFI engines have a more sophisticated water temperature control with one main t-stat (which IIRC opens at a much lower temperature, around 160F) and 2 or maybe 3 DME controlled t-stats to help ensure the engine warms up properly.
So I read nothing sinister in what you observed nor do I attribute this to chance. The engine's coolant temperature is behaving as it is because the cooling system was designed to cause it to behave that way.
Working as designed, I think the phrase is.
Ok, the Durametric is relying solely on query/response interaction with the engine DME. That's good news. That bus snooping coupled with query/response is a pain to implement. (I did it to obtain odometer values off the CAN bus on the fly, so to speak.)
That you saw the debugging messages you did is probably just the programmer putting in well debugging messages to note an unexpected, well not entirely unexpected, event to help him ID a possible problem. I loaded the firmware I did with about a zillion of these to catch abnormal events or what have you and log them. Then I could have the customer download the log file and send it to me for analysis so I could figure out what was going on so I could implement a fix at my desk. Much better to work at my desk than have to travel maybe thousands of miles to gain access to a problem vehicle. (I did travel a few times mainly for show as the customer wanted to see a firmware engineer on site. I might note I managed to implement at my desk EOBD support without every setting foot in Europe. It was only afterwards that I went to Europe to test nearly 100 different models and finding only one or two with problems that I had to code around.)
My firmware ID's -- discovers -- the OBD2 bus protocol on the fly using ISO/SAE defined/described protocol discovery steps.
However, I allowed the user to override this provided he knew the vehicle's OBD2 protocol to avoid doing a protocol discovery that upset other controllers on the bus that were sensitive to this discovery process.
For instance, my company director's Lexus used the CAN bus pins for some Lexus propriety function. If the protocol discovery failed to detect the proper OBD2 protocol -- because the DME failed to respond to a discovery query in time -- the discovery process would advance to trying the CAN bus. But this would trigger a dash warning related to the car's stability management system that required my company director take his car to the dealer to have this cleared.
So I revised the protocol discovery to 1) Improve its robustness, but also 2) To implement a feature to allow him (any user actually) to specify the car's protocol so the discovery process would not occur. The firmware would start out using the protocol specified by the user and no other.
11-23-2014, 09:10 AM
Durametric Logging Live Values – Having Trouble, Help please
