Tested: JDM and GM 3 Bar Map Sensors
Jun 20, 2007, 09:43 AM
#31
Jun 20, 2007, 10:09 AM
#32
Thanks. I was able to compare your Logworks log to my EvoScan log. Below are your log compared to one I just grabbed this morning using EvoScan. Notice that Logworks and EvoScan are both creating about 10-15 entries/sec (which is plenty fast for logging even in 3rd gear). However, Logworks seems to be reusing the same readings many times before showing a new value while EvoScan is reading new values from the ECU at every entry. As I was suspecting, its not the ECU that slow, its Logworks thats slow at reading from the ECU. Now hopefully, we can be past the statement that the ECU is slow for recording data.
Jun 20, 2007, 12:55 PM
#33
Thanks. I was able to compare your Logworks log to my EvoScan log. Below are your log compared to one I just grabbed this morning using EvoScan. Notice that Logworks and EvoScan are both creating about 10-15 entries/sec (which is plenty fast for logging even in 3rd gear). However, Logworks seems to be reusing the same readings many times before showing a new value while EvoScan is reading new values from the ECU at every entry. As I was suspecting, its not the ECU that slow, its Logworks thats slow at reading from the ECU. Now hopefully, we can be past the statement that the ECU is slow for recording data.
), then how come it is logging the JDMMAP as fast as Evoscan from outside the ECU. If it was slow logging boost, then it would be slow logging it from the ECU and from outside the ECU. You can see it clearly from the charts that you posted. When boost is logged independently of the ECU it is plenty fast. When it is logged via the ECU it slows down. So how can you say it is Logworks?It is entirely possible that the plug-in for the Tactrix cable is not logging @ a fast clip. That I cannot comment on. But saying that Logworks does not log as fast as Evoscan is a distortion of reality.
Also could you please post the entire csv file of your log.
Last edited by nj1266; Jun 20, 2007 at 01:16 PM.
Jun 20, 2007, 02:23 PM
#34
That does not make sense. If Logworks is slow and cannot keep up with the ECU or Evoscan (Don't let Klaus hear this ), then how come it is logging the JDMMAP as fast as Evoscan from outside the ECU. If it was slow logging boost, then it would be slow logging it from the ECU and from outside the ECU. You can see it clearly from the charts that you posted. When boost is logged independently of the ECU it is plenty fast. When it is logged via the ECU it slows down. So how can you say it is Logworks?
It is entirely possible that the plug-in for the Tactrix cable is not logging @ a fast clip. That I cannot comment on. But saying that Logworks does not log as fast as Evoscan is a distortion of reality.
Also could you please post the entire csv file of your log.
), then how come it is logging the JDMMAP as fast as Evoscan from outside the ECU. If it was slow logging boost, then it would be slow logging it from the ECU and from outside the ECU. You can see it clearly from the charts that you posted. When boost is logged independently of the ECU it is plenty fast. When it is logged via the ECU it slows down. So how can you say it is Logworks?It is entirely possible that the plug-in for the Tactrix cable is not logging @ a fast clip. That I cannot comment on. But saying that Logworks does not log as fast as Evoscan is a distortion of reality.
Also could you please post the entire csv file of your log.
With that said, I don't see any evidence that Logworks can log more entries per second that EvoScan even when sensors are routed directly to the Innovate hardware. If you look at the time between entries in your Logworks log and my EvoScan log, you'll see that EvoScan is actually logging more entries per second that Logworks. With Logworks in its current condition, I'd say that for best accuracy, its more preferable to read the data from the ECU using EvoScan or Mitsulogger.
My log is attached.
Last edited by mrfred; Jun 20, 2007 at 04:44 PM.
Jun 20, 2007, 04:19 PM
#35
I was trying to be specific in my previous post by saying that "Logworks is slow to read from the ECU". Its pretty easy to see by comparing the logs. Logworks does seem to do a much better job of reading sensors that are routed directly to the Logworks hardware.
With that said, I don't see any evidence that Logworks can log more entries per second that EvoScan even when sensors are routed directly to the Innovate hardware. If you look at the time between entries in your Logworks log and my EvoScan log, you'll see that EvoScan is actually logging more entries per second that Logworks. With Logworks in its current condition, I'd say that for best accuracy, its more preferable to read the data from the ECU using EvoScan or Mitsulogger.
My log is attached.
With that said, I don't see any evidence that Logworks can log more entries per second that EvoScan even when sensors are routed directly to the Innovate hardware. If you look at the time between entries in your Logworks log and my EvoScan log, you'll see that EvoScan is actually logging more entries per second that Logworks. With Logworks in its current condition, I'd say that for best accuracy, its more preferable to read the data from the ECU using EvoScan or Mitsulogger.
My log is attached.
From the Logworks manual:
The data logging speed (samples per second) is dependent on what data is to be logged. When logging engine data, 99% of the data changes no faster than about 5 times per second (one state to another and back). The engine state is ultimately controlled by the driver’s right foot. The fastest external muscle in
humans is the eye-lid muscle. It goes through one blink-cycle in about 100 milliseconds.
humans is the eye-lid muscle. It goes through one blink-cycle in about 100 milliseconds.
A mathematician named Harry Nyquist found out (in 1928), that for anything that you want to record, you only need to record at twice the maximum frequency contained in the recorded signal. So, for the human eye-lid, the required minimum logging speed is 20 times/second. The human foot, controlling a gas pedal, is much slower. Remember, the frequency is not measured from idle
to WOT, but from idle to WOT and back. The second parameter determining the logging speed is the statistical nature of the combustion process itself. No two combustion events in an engine are identical. Therefore, to get meaningful
data, multiple combustion events must be averaged to see the overall effects. If each combustion event is analyzed and recorded, meaningful tuning data can’t be seen in most cases. At 6000 RPM an engine goes through 50 engine cycles per second (a 4-stroke engine cycle requires two rotations per cycle). At a logging speed of 12.5 samples per second this would mean that the resulting data is the average of 4 engine cycles.
The above means that data logging engine data needs to be done at 10-15 samples per second. Anything more creates only more data points which do not contain any additional information, but are harder to analyze.
The Innovate Modular Tuning System samples engine data at 12.2 samples/second.
Just because Evoscan is faster than Logworks and log 14-15 samples/sec does not mean that it is better. Yeah it has a slight edge, by 1-2 samples/sec.
Now, about your log. I noticed a descrepency between the chart that you posted and the log itself.
In the chart the "LogEntrySeconds" column begins @ 0.00 seconds with a corresponding 2281 rpm and 0.58 psi. But in the log the same column begins @ 8.14062 seconds with the same 2281 rpm and 0.58 psi. Why are they different?
With your permission, I would like to post your chart on the Innovate forums and see what Klaus says.
Jun 20, 2007, 04:41 PM
#36
Originally Posted by nj1266
Just because Evoscan is faster than Logworks and log 14-15 samples/sec does not mean that it is better. Yeah it has a slight edge, by 1-2 samples/sec.
Now, about your log. I noticed a descrepency between the chart that you posted and the log itself.
In the chart the "LogEntrySeconds" column begins @ 0.00 seconds with a corresponding 2281 rpm and 0.58 psi. But in the log the same column begins @ 8.14062 seconds with the same 2281 rpm and 0.58 psi. Why are they different?
With your permission, I would like to post your chart on the Innovate forums and see what Klaus says.
Yeah, 1-2 sample per sec difference is not significant. Logworks is fine for reading data directly from Innovate hardware, but it is lacking in speed when it comes to reading data from the ECU. The point I want to make is that logging data from the ECU is not laggy. Its something going on with Logworks.
No prob with showing my log to Klaus. I'm interested to see what he says about why Logworks is so slow to read data from the ECU.
Jun 20, 2007, 07:21 PM
#37
I do precisely that when I log rpm via the ECU, because it acts the same as the boost getting logged in this instance. When I smooth out the rpm the numbers become different. I attached a log for you to see the rpm smoothed and unsmoothed.
I suspect that Evoscan applies smoothing to the data prior to spitting it out and that is why you do not get the repeated data from the ECU. Basically, IMO the ECU is slow, but the way Evoscan logs filters out the "slowness" of the ECU.
This is the only explanation that I have, while I await Klaus's
Jun 21, 2007, 06:48 AM
#38
Because of the digitizing process, the analog values calculated from the digitized values will have specific values. Staying with the RPM example, if EvoScan reads a value of 100, then that becomes 3125.0 rpm. 101 becomes 3156.25 rpm. There's nothing between 3125.0 and 3156.25 rpm.
If EvoScan is not performing an on-the-fly data averaging scheme, then the descrete analog values should be apparent in the data logs, and they can be divided by the conversion factor to get back to the original digital integer value. Take the first twenty RPM entries in my log:
Code:
2281.25 / 31.25 = 73 2250 / 31.25 = 72 2250 / 31.25 = 72 2312.5 / 31.25 = 74 2312.5 / 31.25 = 74 2343.75 / 31.25 = 75 2375 / 31.25 = 76 2375 / 31.25 = 76 2406.25 / 31.25 = 77 2437.5 / 31.25 = 78 2468.75 / 31.25 = 79 2500 / 31.25 = 80 2531.25 / 31.25 = 81 2531.25 / 31.25 = 81 2562.5 / 31.25 = 82 2625 / 31.25 = 84 2625 / 31.25 = 84 2656.25 / 31.25 = 85 2687.5 / 31.25 = 86 2718.75 / 31.25 = 87
Code:
2281.25 / 31.25 = 73 2293.75 / 31.25 = 73.4 2318.75 / 31.25 = 74.2 2343.75 / 31.25 = 75 2362.5 / 31.25 = 75.6 2387.5 / 31.25 = 76.4 2412.5 / 31.25 = 77.2 2437.5 / 31.25 = 78 2468.75 / 31.25 = 79 2493.75 / 31.25 = 79.8 2518.75 / 31.25 = 80.6 2550 / 31.25 = 81.6 2575 / 31.25 = 82.4 2600 / 31.25 = 83.2 2631.25 / 31.25 = 84.2 2662.5 / 31.25 = 85.2 2700 / 31.25 = 86.4
Jun 21, 2007, 07:39 AM
#39
Try this. Log RPM and ONLY rpm using Evoscan and you will see how many repetitive entries you will get. Why do you think that is? It is porbably the ECU unable to keep up with the requests from Evoscan and giving back repetitive entries.
When you log a significant number of parameters you do not get this probably because Evoscan slows down and the ECU can keep up with the requests from Evoscan.
When you log a significant number of parameters you do not get this probably because Evoscan slows down and the ECU can keep up with the requests from Evoscan.
Jun 21, 2007, 07:55 AM
#40
nj,
If he only logged RPM, he would definitely get repeated entries. This is because of the resolution of RPM with a range from 0-225, since it is a 1-byte MUT request....it has nothing to do with either logger.
Mrfred isn't talking about this. Both loggers will do this. He is referring to data that inherently has better resolution, like the map sensors, but LogWorks isn't showing that better resolution in subsequent samples in your log. I'm actually curious as to why, also. Perhaps Logworks has implemented the MUT-III protocol differently and it is slower.
Post #32 above and the highlighted columns is demonstrating what he is talking about.
Eric
If he only logged RPM, he would definitely get repeated entries. This is because of the resolution of RPM with a range from 0-225, since it is a 1-byte MUT request....it has nothing to do with either logger.
Mrfred isn't talking about this. Both loggers will do this. He is referring to data that inherently has better resolution, like the map sensors, but LogWorks isn't showing that better resolution in subsequent samples in your log. I'm actually curious as to why, also. Perhaps Logworks has implemented the MUT-III protocol differently and it is slower.
Post #32 above and the highlighted columns is demonstrating what he is talking about.
Eric
Last edited by l2r99gst; Jun 21, 2007 at 07:59 AM.
Jul 14, 2007, 05:10 PM
#41
EvoScan does not perform any running averages.. it is RAW and is Super Fast data from the ecu.
I spent hundreds of hours analysing the data streams with expensive electronics tools to make EvoScan the fastest Datalogger for Mitsubishis, I doubt anything out there compares to the speed of EvoScan.
I spent hundreds of hours analysing the data streams with expensive electronics tools to make EvoScan the fastest Datalogger for Mitsubishis, I doubt anything out there compares to the speed of EvoScan.
Last edited by evo4mad; Jul 14, 2007 at 05:14 PM.
Jul 16, 2007, 09:51 AM
#43
Evolved Member
iTrader: (6)
Join Date: Jul 2005
Location: Charleston, SC
Posts: 1,228
Likes: 0
Received 0 Likes
on
0 Posts
Rummaging around www.delphi.com and came across another option from GM-Delphi....a combined MAP/MAT sensor logs to 3.5 bar and does up to 125C temp ... in one sensor
http://www.delphi.com/manufacturers/...ors/et/mapmat/
This could be used to determine both the boost and the post IC temps if placed on a bung on the upper IC pipe, just before the TB. Coupled with a separate second sensor on the LICP, this would provide a solution for those companies or people who wish to test both temps and pressure drop across intercoolers. This would end the debate about flow and heat soak.
In relation to this thread, there are issues with the JDM 3 bar MAP, not with accuracy, but in throwing codes. The sensor is also part of the EGR routine and using the JDM 3bar appears to throw a SES at random times on the VIII. mrfred is still chasing down the location in the code for EGR tables on it IIRC.
As Naji referred to above, the GM one takes more to install, but can be logged in Logworks ( free ) . At some point here, i plan on tapping the UICP and placing one there and on the custom LICP I'm having made. Logging will be Logworks, not OBD2, as Naji explained for the higher data rate..along with my LC-1
As an additional teaser, a simple differential circuit to compare in/out temp and evaluate boost can have an output routed to a relay to power an ic sprayer to come on automatically at 15 psi and a temperature higher than " X" ...doesn't need to be hooked to ECU....for those road racers and HDPE guys who want to stay cool without thinking about it.
Milburn
http://www.delphi.com/manufacturers/...ors/et/mapmat/
This could be used to determine both the boost and the post IC temps if placed on a bung on the upper IC pipe, just before the TB. Coupled with a separate second sensor on the LICP, this would provide a solution for those companies or people who wish to test both temps and pressure drop across intercoolers. This would end the debate about flow and heat soak.
In relation to this thread, there are issues with the JDM 3 bar MAP, not with accuracy, but in throwing codes. The sensor is also part of the EGR routine and using the JDM 3bar appears to throw a SES at random times on the VIII. mrfred is still chasing down the location in the code for EGR tables on it IIRC.
As Naji referred to above, the GM one takes more to install, but can be logged in Logworks ( free ) . At some point here, i plan on tapping the UICP and placing one there and on the custom LICP I'm having made. Logging will be Logworks, not OBD2, as Naji explained for the higher data rate..along with my LC-1
As an additional teaser, a simple differential circuit to compare in/out temp and evaluate boost can have an output routed to a relay to power an ic sprayer to come on automatically at 15 psi and a temperature higher than " X" ...doesn't need to be hooked to ECU....for those road racers and HDPE guys who want to stay cool without thinking about it.
Milburn
Hmm.... Could this be possible?
Jul 16, 2007, 09:58 AM
#44
Evolved Member
iTrader: (6)
Join Date: Jul 2005
Location: Charleston, SC
Posts: 1,228
Likes: 0
Received 0 Likes
on
0 Posts
Rummaging around www.delphi.com and came across another option from GM-Delphi....a combined MAP/MAT sensor logs to 3.5 bar and does up to 125C temp ... in one sensor
http://www.delphi.com/manufacturers/...ors/et/mapmat/
This could be used to determine both the boost and the post IC temps if placed on a bung on the upper IC pipe, just before the TB. Coupled with a separate second sensor on the LICP, this would provide a solution for those companies or people who wish to test both temps and pressure drop across intercoolers. This would end the debate about flow and heat soak.
In relation to this thread, there are issues with the JDM 3 bar MAP, not with accuracy, but in throwing codes. The sensor is also part of the EGR routine and using the JDM 3bar appears to throw a SES at random times on the VIII. mrfred is still chasing down the location in the code for EGR tables on it IIRC.
As Naji referred to above, the GM one takes more to install, but can be logged in Logworks ( free ) . At some point here, i plan on tapping the UICP and placing one there and on the custom LICP I'm having made. Logging will be Logworks, not OBD2, as Naji explained for the higher data rate..along with my LC-1
As an additional teaser, a simple differential circuit to compare in/out temp and evaluate boost can have an output routed to a relay to power an ic sprayer to come on automatically at 15 psi and a temperature higher than " X" ...doesn't need to be hooked to ECU....for those road racers and HDPE guys who want to stay cool without thinking about it.
Milburn
http://www.delphi.com/manufacturers/...ors/et/mapmat/
This could be used to determine both the boost and the post IC temps if placed on a bung on the upper IC pipe, just before the TB. Coupled with a separate second sensor on the LICP, this would provide a solution for those companies or people who wish to test both temps and pressure drop across intercoolers. This would end the debate about flow and heat soak.
In relation to this thread, there are issues with the JDM 3 bar MAP, not with accuracy, but in throwing codes. The sensor is also part of the EGR routine and using the JDM 3bar appears to throw a SES at random times on the VIII. mrfred is still chasing down the location in the code for EGR tables on it IIRC.
As Naji referred to above, the GM one takes more to install, but can be logged in Logworks ( free ) . At some point here, i plan on tapping the UICP and placing one there and on the custom LICP I'm having made. Logging will be Logworks, not OBD2, as Naji explained for the higher data rate..along with my LC-1
As an additional teaser, a simple differential circuit to compare in/out temp and evaluate boost can have an output routed to a relay to power an ic sprayer to come on automatically at 15 psi and a temperature higher than " X" ...doesn't need to be hooked to ECU....for those road racers and HDPE guys who want to stay cool without thinking about it.
Milburn
Hmm.... Could this be possible?
