From: sonix@schunix.uucp (Duane Morin)
Newsgroups: comp.human-factors
Subject: "baseline" II (was re: How would you explain this...)
Date: 7 Oct 92 12:45:32 GMT
Distribution: na
Organization: SCHUNIX Public Access Unix for Worcester County, Massachusetts, USA

First of all, thank you for the responses.  I didn't expect to see nearly as 
many as quickly as I did.  However, I think I may need to clarify a point 
or two, as some of the people that are trying to help are confused.

A yellow "envelope" of tolerances is drawn on the screen.  On top of this 
is put a red line representing the data that was just gathered.  Now, in the 
most basic terms, if any red falls outside the yellow, the test should fail.

Now, here are some problems with this graph:

	1) There is a certain "drift" tolerance allowed in the trace.  Over
	   time, our gathering equipment might become a little less tolerant
	   and the envelope will "shift" downward, say.  So a red line that 
	   just barely misses the envelope will still be ok, just a special 
	   case.

	2) Other than case (1), it's straight forward.  For example, a red 
	   line horizontal across the bottom of the screen represents "Hey,
	   you don't have any power going to the device", for example.  Some
	   (read: most) of these problems would require the replacement 
	   of certain parts, and therefore would require us to be able to 
	   read the characteristics of the problem.

Special Case:  Since some drift is expected over time (read, 3-5yrs) there 
is a system maintenance option that allows users to recalibrate the baseline
trace.  They gather a trace as usual, but when asked to verify, the yellow
envelope reshapes itself around the red line.  This is a very difficult 
point for the user - they've been told that if the red is out of the yellow,
then the red is bad. Then, when trying to fix it, instead of moving the red
into the yellow, they're redefining what the yellow is.  

If the problem sounds confusing to explain, that gives one an idea of how 
many different areas there are for the practitioners to misunderstand.

The "bull's eye" idea - Several people mentioned this, but I have a question
of my own.  I can see developing a "score" based on the average distance of 
the points from the ideal curve, but placing this score on a bulls eye would
require some sort of 2dimensional representation, wouldn't it?

If we could keep some sort of characteristic information about the trace, it
would be great.  Let me try my hand at drawing a few "bad" traces to show 
you how we'd diagnose a problem:

A "good" trace:  (using someone else's notation, . represents the envelope 
	 	  and * represents the gathered trace.  Thank you!)

             ...............
        .....***************     (forgive the bad art, but I hope you see the
       .*****...............      general idea??)
   ....*.....
...****.
***....
...


Here, they've accidentally left something in the tank that shouldn't be there:
(Note: This would be a problem that is correctable by them)

             ...............
        .....                    (Basically a consistently low, jagged curve.
       .     ...............      It would also take as much x-length room as
   .... .....                     the baseline, but I got tired...)
...    . 
   ....   *   *
...  *   * * * *
  * * * *   *   *
 * *   *
*


Here's one that would not be correctable by them - a tranducer that spikes 
high at a certain frequency:

             ...............
        .....                    (A "spike" right now does not show on the 
       .******..............      graph, but it does mean that the remainder
   ....*.....*                    of the graph gets zeroed out and not 
...****.     *                    collected)
***....      *
...          *
             *
             *
             *
             ****************

Hope this added information helps.  Thank you again to all that have responded,
I'll be bouncing some of the ideas off of the boss this morning!

Duane Morin
 Software Development manager
 Walker Sonix
 Worcester, MA 01604
 sonix@schunix.uucp
Newsgroups: comp.human-factors