ssc scope issue

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • poncho
    Junior Member
    • Jan 2011
    • 3

    ssc scope issue

    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.
    Attached Files
  • Rich Shepherd
    Snap-on D&I
    • Nov 2006
    • 553

    #2
    Originally posted by poncho
    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.
    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.

    Comment

    • poncho
      Junior Member
      • Jan 2011
      • 3

      #3
      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

      • Wheel
        Senior Member
        • Jul 2007
        • 719

        #4
        Originally posted by Rich Shepherd
        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.
        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?
        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. - Wheel

        Comment

        • Rich Shepherd
          Snap-on D&I
          • Nov 2006
          • 553

          #5
          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

          • Wheel
            Senior Member
            • Jul 2007
            • 719

            #6
            Originally posted by Rich Shepherd
            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.
            Hi Rich.
            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. - Wheel

            Comment

            Working...