Help with ECUMate reading.
Discussion
Took the chim for a nice run in the fine Aberdeen sunshine yesterday. On my return, I plugged in the ECUMate for a little post run diagnostics, all seemed fine apart from the RPM reading. upon reving her, it would only read upto 1950RPM ?
No faults shown, and everything else was fine. I did the usual un-plug ECU a few times, but still no joy.
The car runs great. Is this a fault with mu ECUMate? Wich apart from this has served me well.
Ian.
No faults shown, and everything else was fine. I did the usual un-plug ECU a few times, but still no joy.
The car runs great. Is this a fault with mu ECUMate? Wich apart from this has served me well.
Ian.
It is normal. The RPM reading is read directly from the ECU but the ECU treats any request to give information as low priority because it starts to max out as the revs increase. As a result it also stops updating the direct readout at around 1920 rpm as you have seen. There are other locations that can provide similar data but and this is a big but, the calculations are quite complex and can slow the data access down. As a result the data integrity suffers as the data is not fetched as a snap shot but as a series of bits of data which may or may not be related in terms of the time line.
Two bits of information can be displayed simultaneously but could be separated by more than a second which in ECU time is a lifetime. You can get the situation where you think something may have happened at this point but it may have occurred before.
ECUmate actually use some techniques to check the data integrity before it is displayed to overcome this problem.
So in summary it is normal behaviour.
Two bits of information can be displayed simultaneously but could be separated by more than a second which in ECU time is a lifetime. You can get the situation where you think something may have happened at this point but it may have occurred before.
ECUmate actually use some techniques to check the data integrity before it is displayed to overcome this problem.
So in summary it is normal behaviour.
stecozz said:
I have Steves basic fault reader and was wondering if it was worth getting the ecumate,my car seems fine but seems underpowered in my opinion,could the ecu mate show any slight faults like a duff lamba sensor etc which the lesser reader wouldnt show?
Yep it's superior in every way and indeed shows the lambda activity in detail.Have a look at the manual on Steve's page
http://www.ecumate.com/documentdownload.html
I have a fault code reader but it only shows things that (presumably) meet certain criteria that the ECU works to. My fault code reader shows no faults, but ECUmate shows one of my lambdas misbehaving quite badly. Not enough to throw a fault code but sufficient to cause things to run a bit rough.
ECUmate is worth every penny.
ECUmate is worth every penny.
V8 GRF said:
stecozz said:
I have Steves basic fault reader and was wondering if it was worth getting the ecumate,my car seems fine but seems underpowered in my opinion,could the ecu mate show any slight faults like a duff lamba sensor etc which the lesser reader wouldnt show?
Yep it's superior in every way and indeed shows the lambda activity in detail.Have a look at the manual on Steve's page
http://www.ecumate.com/documentdownload.html
V8 GRF said:
stecozz said:
I have Steves basic fault reader and was wondering if it was worth getting the ecumate,my car seems fine but seems underpowered in my opinion,could the ecu mate show any slight faults like a duff lamba sensor etc which the lesser reader wouldnt show?
Yep it's superior in every way and indeed shows the lambda activity in detail.Have a look at the manual on Steve's page
http://www.ecumate.com/documentdownload.html
At its most basic you have just the 2 digit fault code reader. This will only give you data on the ECU fault codes- no sensor data at all.
You have RoverGauge- this software is still being developed as we speak with more functions being added, and gives all the sensor data, long and short fuel trims, (lambda values) and has hardware control over the stepper, fuel pump, it can read and display the fuel maps and copy the Eprom image if you need it. It also has a log facility. It does require the use of a laptop however that might not suit everyone in the foot well of a TVR.
The ECUmate is a great unit as its simply plug and play, and can be kept in the boot of the car for when you need it. It displays much the same sensor data as RoverGuage in text form, and is very much designed around what the majority of TVR owners will need to know, without being over complex with its simple step by step menus. RoverGauge in comparison needs a little more technical understanding to use the additional data it can supply beyond that of that of basic sensor data.
There is also the hawkeye, that is expensive, and provides far less function than either of these units.
All these units simply report back what the ECU sees as and fault code sensor data- there is no level of "sensitivity" of how the data is reported back.
Edited by blitzracing on Monday 12th November 12:37
blitzracing said:
V8 GRF said:
stecozz said:
I have Steves basic fault reader and was wondering if it was worth getting the ecumate,my car seems fine but seems underpowered in my opinion,could the ecu mate show any slight faults like a duff lamba sensor etc which the lesser reader wouldnt show?
Yep it's superior in every way and indeed shows the lambda activity in detail.Have a look at the manual on Steve's page
http://www.ecumate.com/documentdownload.html
At its most basic you have just the 2 digit fault code reader. This will only give you data on the ECU fault codes- no sensor data at all.
You have RoverGauge- this software is still being developed as we speak with more functions being added, and gives all the sensor data, long and short fuel trims, (lambda values) and has hardware control over the stepper, fuel pump, it can read and display the fuel maps and copy the Eprom image if you need it. It also has a log facility. It does require the use of a laptop however that might not suit everyone in the foot well of a TVR.
The ECUmate is a great unit as its simply plug and play, and can be kept in the boot of the car for when you need it. It displays much the same sensor data as RoverGuage in text form, and is very much designed around what the majority of TVR owners will need to know, without being over complex with its simple step by step menus. RoverGauge in comparison needs a little more technical understanding to use the additional data it can supply beyond that of that of basic sensor data.
There is also the hawkeye, that is expensive, and provides far less function than either of these units.
All these units simply report back what the ECU sees as and fault code sensor data- there is no level of "sensitivity" of how the data is reported back.
Edited by blitzracing on Monday 12th November 12:37
I'm not totally sure that RoverGauge is the more technical capable version. It's just 'different'. Let me explain...
One problem I have seen with RoverGauge is that the data update is incredibly slow. If you log information, it only gives a snapshot about once every second — and that is when the ECU is switched on with no additional work load. It can go a lot longer than that when the engine is running. The problem is that the 14cux does not give the data requests priority, so the information comes in 'as and when'. This means that some readings are lost & so you can't be sure how accurate the data seen by the RoverGauge is. In other words you can look at the RoverGauge output and it is quite possible for sensor values to change without those changes being reported. This particularly affects the throttle and other sensor information. I've even seen it fail to pick up lambda switching because of this reason.
I put a lot of work into the ECUmate to keep the data sampling rates as fast as possible and to be able to detect (and report) when the data integrity is lost. Knowing whether or not the data is complete is essential when trying to detect very transient problems and issues, which are often the root cause of many problems. The displays are updated several times a second (or more, in certain cases) so that as much coherent data can be shown as possible. If you are only refreshing the data every second or less often, it is unlikely that transient faults or symptoms will be seen at all. Equally, the data received may not tally or correspond with other data.
ECUmate reports ALL the fault codes and gives them the correct numbers that correspond to the standard code display. It displays actual voltages — which makes setting up stuff very easy to do and also displays the true idle status. I believe that these features are essential when fault finding.
I did look at developing a PC based diagnostic unit some time ago but I couldn't get the accuracy of data I needed to help diagnose the issues I wanted to tackle — which is why I went the separate reader route.
One problem I have seen with RoverGauge is that the data update is incredibly slow. If you log information, it only gives a snapshot about once every second — and that is when the ECU is switched on with no additional work load. It can go a lot longer than that when the engine is running. The problem is that the 14cux does not give the data requests priority, so the information comes in 'as and when'. This means that some readings are lost & so you can't be sure how accurate the data seen by the RoverGauge is. In other words you can look at the RoverGauge output and it is quite possible for sensor values to change without those changes being reported. This particularly affects the throttle and other sensor information. I've even seen it fail to pick up lambda switching because of this reason.
I put a lot of work into the ECUmate to keep the data sampling rates as fast as possible and to be able to detect (and report) when the data integrity is lost. Knowing whether or not the data is complete is essential when trying to detect very transient problems and issues, which are often the root cause of many problems. The displays are updated several times a second (or more, in certain cases) so that as much coherent data can be shown as possible. If you are only refreshing the data every second or less often, it is unlikely that transient faults or symptoms will be seen at all. Equally, the data received may not tally or correspond with other data.
ECUmate reports ALL the fault codes and gives them the correct numbers that correspond to the standard code display. It displays actual voltages — which makes setting up stuff very easy to do and also displays the true idle status. I believe that these features are essential when fault finding.
I did look at developing a PC based diagnostic unit some time ago but I couldn't get the accuracy of data I needed to help diagnose the issues I wanted to tackle — which is why I went the separate reader route.
You simply need to change the scan rate RoverGauge requests the data under the options menu- by default its .5 of a second.So its not really a fault, just mis-set if its running at 1 second :-)
In terms of the extra bits RoverGauge does, it gives you actual and corrected values (as the ECU for calculation purposes) for both the throttle pot and AFM, but lacks the physical voltages the ECU Mate displays, so voltages have to be calculated against percentage values of between 0 and 5 volts representing 0 - 100%. In practical terms the corrected values would not make much difference to trouble shooting as we deal in signal outputs from the sensors as they are- not as the ECU sees them for fueling purposes
It also gives long term fuel trim thats been causing a bit of fun.
The extra logging facility gives you fairly raw sensor that need manipulating into something readable using say Excel, but i doubt this could be used to monitor sensor data at higher RPM due to the lack of ECU power to report the sensor data back.
The ability to read the Eprom and store it in a .bin file format allows you to observe the fuel maps if you have suitable software to interpret it. I do wonder if you could simply observe the live map locations it displays and then add or remove to the value stored in that location. The reason I say this, is typically shunting occurs at around 1700 rpm under a light throttle- so you could simply add more fuel by increasing the load value in the map that's displayed at that instance and then blow an new Eprom- I bet its not that simple however.
Basically what Im saying is these extra little features could be used if you want to get really techie with the ECU, but otherwise the ECUmate will do the same functions in a hand held, its a great trouble shooting tool.
In terms of the extra bits RoverGauge does, it gives you actual and corrected values (as the ECU for calculation purposes) for both the throttle pot and AFM, but lacks the physical voltages the ECU Mate displays, so voltages have to be calculated against percentage values of between 0 and 5 volts representing 0 - 100%. In practical terms the corrected values would not make much difference to trouble shooting as we deal in signal outputs from the sensors as they are- not as the ECU sees them for fueling purposes
It also gives long term fuel trim thats been causing a bit of fun.
The extra logging facility gives you fairly raw sensor that need manipulating into something readable using say Excel, but i doubt this could be used to monitor sensor data at higher RPM due to the lack of ECU power to report the sensor data back.
The ability to read the Eprom and store it in a .bin file format allows you to observe the fuel maps if you have suitable software to interpret it. I do wonder if you could simply observe the live map locations it displays and then add or remove to the value stored in that location. The reason I say this, is typically shunting occurs at around 1700 rpm under a light throttle- so you could simply add more fuel by increasing the load value in the map that's displayed at that instance and then blow an new Eprom- I bet its not that simple however.
Basically what Im saying is these extra little features could be used if you want to get really techie with the ECU, but otherwise the ECUmate will do the same functions in a hand held, its a great trouble shooting tool.
Edited by blitzracing on Monday 12th November 19:05
blitzracing said:
You simply need to change the scan rate RoverGauge requests the data under the options menu- by default its .5 of a second.So its not really a fault, just mis-set if its running at 1 second :-)
I ran it straight out of the box so to speak and the data log is time stamped at around 1 second intervals. I ran it at 50ms to force it to go as fast as possible... and the data log still went at 1 second plus....
Making it slower seems to have an effect but going faster doesn't.
It's not really a fault but more a limitation of the hardware and software that the application has to go through.
Ill have to have another look next time Im plugged in- I did change the settings when trying to pin down why the long trim was displayed for only a moment before it went to zero, that corresponded to the scan time, and that could be changed quite happily. The long trim issue was purely that the water temp has to be high enough to get a sensible reading. Are you running the latest version? 0.3.5 ? The first few revisions had some odd quirks.
^^ yes. People have been able to burn new eproms for the cux for years, see all the chips on ebay from time to time. The tricky bit has always been that we've not been able to determine the lambda trim, so chip burns have traditionally been limited to precat cars or fuel changed once out of lambda control on cat cars. With rovergauge things have moved on a bit. Ive got a friend with an old racelogic emulator which I'm hoping might enable real time mapping whilst under lambda control whilst monitoring the trimming. I'll let Blitz know if it ever works, should add to the knowledge base if nothing else.
Gassing Station | Chimaera | Top of Page | What's New | My Stuff