Has anyone noticed the scope recordings don't show rpm when played back? I just spent a considerable amount of time on some testing only to find out later my data recording was useless because the rpm's were missing.
ssc scope issue
Collapse
X
-
When they are displayed live, if you freeze the scope and review back thru the frames of data, you will observe that they do not change. That is because only the last values calculated before the scope was frozen are available to display. If you save a data file and view it in Data Management on the tool itself, the calculated digital values are not in the file and the option to display them is therefore not selectable. This is the reason SSC cannot display them. They are not saved along with the raw data in a movie or frame file. This is the way the digital values in scope have been handled in all the products since the scope was first developed for Modis. If you freeze the scope and digital values are displayed that you would like to keep for reference or documenting a repair, save the screen image along with a movie file if needed.
-
ok
Thanks for the info. I'll have to save a couple screen shots for reference next time I need that info attached. I think I have noticed that in the past, just didn't care because I didn't need it at the time. I was a little annoyed when I opened that up last night and was about to e-mail it.Comment
-
The RPM and the digital values displayed for each channel are basically averages calculated from the raw data and displayed when the scope is live much like a digital meter typically does. They are not instantaneous values related to a specific point in the data. They are continually updated when the scope is live. They are not saved along with the raw data when you save a movie or single frame file because they are not related to any specific point in the data file.
When they are displayed live, if you freeze the scope and review back thru the frames of data, you will observe that they do not change. That is because only the last values calculated before the scope was frozen are available to display. If you save a data file and view it in Data Management on the tool itself, the calculated digital values are not in the file and the option to display them is therefore not selectable. This is the reason SSC cannot display them. They are not saved along with the raw data in a movie or frame file. This is the way the digital values in scope have been handled in all the products since the scope was first developed for Modis. If you freeze the scope and digital values are displayed that you would like to keep for reference or documenting a repair, save the screen image along with a movie file if needed.
diagnostic offerings from Snap On since. I find it handy to see another
signal along with rpm being graphed minute by minute to see if differences in this signal, especially glitches have any influence on
the rpm display, and if so, by how much and when - things like rpm vs
crank or cam sensor, rpm vs backpressure, rpm vs vacuum, rpm vs EGR
position, rpm vs transmission line pressure, and I can go on forever.
What I'm trying to say is a blow by blow comparison of RPM and one of these signals so I know exactly what rpm something happens sure does help, along with being able document it. Is it possible to add this ability to the newer tools, or is there a hardware limitation preventing it?
There are also times I wish the graphing multimeter part of the tool
utilized all 4 channels instead of just 2 in Modis or Verus.
Just a couple of suggestions that I've been curious about the possibilities of for years.You can expect the reputation of your business to be no better than the cheapest item or service you are willing to sell. - WheelComment
-
I sure enjoyed the ability to graph rpm alongside another signal of choice that the original Vantage allowed - a feature I've missed in the
diagnostic offerings from Snap On since. I find it handy to see another
signal along with rpm being graphed minute by minute to see if differences in this signal, especially glitches have any influence on
the rpm display, and if so, by how much and when - things like rpm vs
crank or cam sensor, rpm vs backpressure, rpm vs vacuum, rpm vs EGR
position, rpm vs transmission line pressure, and I can go on forever.
What I'm trying to say is a blow by blow comparison of RPM and one of these signals so I know exactly what rpm something happens sure does help, along with being able document it. Is it possible to add this ability to the newer tools, or is there a hardware limitation preventing it?
It would probably be possible to add the ability to graph RPM From the RPM lead on a Modis, V Pro or Verus. At idle there will be something like 5-7 cylinder firings detected by that lead when its connected to plug wire so the amount of data and processing would be very small. The engineers would have to investigate and make a determination of the possibilities to be certain.
Being able to plot RPM would tend to increase in usefulness the longer the sweep that is selected.
If using a sweep of 5ms to look at a waveform when an engine is at idle, there may only be an RPM event detected something like every 35 frames of data for a total of only 7-8 over the whole buffer. If you throw in some per cylinder timing variation, the instantaneous RPM calculated between each point and the previous point may vary on an engine that appears to be running pretty smoothly. This doesn't provide many useful points in comparison to the waveform being viewed.
When you get to sweeps above 1S and longer, there will be enough RPM events captured over the amount of time displayed on the screen that the relationship between RPM and many of the signals you mentioned becomes more useful. Of course as the engine speed is increased, you will have more RPM points over the same amount of time so that is a factor too.
There are also times I wish the graphing multimeter part of the tool
utilized all 4 channels instead of just 2 in Modis or Verus.
Just a couple of suggestions that I've been curious about the possibilities of for years.
Graphing is limited to 2 channels. Data is captured at a high speed and there is a lot of processing involved. Its not possible to do that on more than 2 channels on a Modis or Verus. This is the same reason that Peak Detect is limited to 2 channels.Comment
-
I sure enjoyed the ability to graph rpm alongside another signal of choice that the original Vantage allowed - a feature I've missed in the
diagnostic offerings from Snap On since. I find it handy to see another
signal along with rpm being graphed minute by minute to see if differences in this signal, especially glitches have any influence on
the rpm display, and if so, by how much and when - things like rpm vs
crank or cam sensor, rpm vs backpressure, rpm vs vacuum, rpm vs EGR
position, rpm vs transmission line pressure, and I can go on forever.
What I'm trying to say is a blow by blow comparison of RPM and one of these signals so I know exactly what rpm something happens sure does help, along with being able document it. Is it possible to add this ability to the newer tools, or is there a hardware limitation preventing it?
It would probably be possible to add the ability to graph RPM From the RPM lead on a Modis, V Pro or Verus. At idle there will be something like 5-7 cylinder firings detected by that lead when its connected to plug wire so the amount of data and processing would be very small. The engineers would have to investigate and make a determination of the possibilities to be certain.
Being able to plot RPM would tend to increase in usefulness the longer the sweep that is selected.
If using a sweep of 5ms to look at a waveform when an engine is at idle, there may only be an RPM event detected something like every 35 frames of data for a total of only 7-8 over the whole buffer. If you throw in some per cylinder timing variation, the instantaneous RPM calculated between each point and the previous point may vary on an engine that appears to be running pretty smoothly. This doesn't provide many useful points in comparison to the waveform being viewed.
When you get to sweeps above 1S and longer, there will be enough RPM events captured over the amount of time displayed on the screen that the relationship between RPM and many of the signals you mentioned becomes more useful. Of course as the engine speed is increased, you will have more RPM points over the same amount of time so that is a factor too.
There are also times I wish the graphing multimeter part of the tool
utilized all 4 channels instead of just 2 in Modis or Verus.
Just a couple of suggestions that I've been curious about the possibilities of for years.
Graphing is limited to 2 channels. Data is captured at a high speed and there is a lot of processing involved. Its not possible to do that on more than 2 channels on a Modis or Verus. This is the same reason that Peak Detect is limited to 2 channels.
First of all, let me thank you for taking the time to answer these questions,
I found the information helpful.
Regarding the 4 channel graphing multimeter: I had mistakenly thought
the newer machines would have had the processing power to handle this,
but perhaps sometime in the future if it is needed. Now that I have a good
explanation, I can be content for now with what I have.
You are right about the rpm graph being more useful with a longer time
base. One of the greatest strengths of the graphing meter is observing trends, which in turn can help expose very intermittent problems.
On the original vantage, I liked looking at the RPM trace, and watching for
either an unexpected change, or looking for an expected change which did
not occur, and then at that point look at the other signal I was graphing to
see what did or did not happen. In the case of an unexpected RPM change, this helps me determine if the other signal I am monitoring may be responsible, or if my time is better spent looking elsewhere (this was why I was interested if a 4 channel graphing meter was possible, as 2 more signals could be observed, greatly speeding up this process).
In the case of looking for an expected RPM response, It helps me tell if
a part is working and how well (for example, on an EGR with a position
sensor, I could tell how much RPM would drop at a given opening of
the valve if I were testing it and I could document it for future use).
Some of this can be done with a scan tool, but scan tools don't always
have the pids or tests to run that you need whereas graphing multimeters
and scopes are limited to the user's imagination and accessories, and they
give raw data and at faster speeds.
I ask for more from my diagnostic tools than many because often I do not
have the information I need to diagnose the car for one reason or another, so I find myself all too often having to use my equipment to
"reverse engineer " the car to figure out the operating strategy or
how it works in order to fix it. This is one reason I may ask my toolmakers
for some off the wall features sometimes.You can expect the reputation of your business to be no better than the cheapest item or service you are willing to sell. - WheelComment
Comment