From: jdb9608@cs.rit.edu (John D Beutel)
Message-Id: <9110200307.AA16559@junior.rit.edu>
Subject: sampling techniques and response time
To: glove-list@karazm.math.uh.edu
Date: Sat, 19 Oct 91 23:22:16 EDT
I've been thinking about continuous polling (via interrupts)
versus polling on demand.  There may be a problem with
synchronizing.

The way to increase the sample rate that Dave Stampe found
(thru excellent investigation--you're really helping, Dave!)
was by polling a byte every 2 to 4 ms, and watching for the A0.
(I haven't tried it yet.)  The samples per second range from
17 (= 58 ms) for open hand to 12.5 (= 80 ms) for closed hand.
The more samples per second, the better.

The problem may be the increase in time from when the sample
is taken to when the glove_data is utilized.  Someone mentioned
a figure like 100 ms as the maximum response time for coordinating
motion and vision.  Can anyone elaborate (I know there was an
expert on this out there...)?

If the calculation and rendering of the cursor is not synchronized
with the sampling of the glove, then in the worst case with
continuous polling the data could come in just after the program
begins to calculate the cursor's position, and sit around for
79 ms before being used to calculate the cursor's next position.
If the cursor's something complicated (like a picture of a glove),
or if the glove's own sample time (40 ms) gets in the way,
or especially if the data is used for something more complicated
like rendering the whole viewpoint (e.g., homemade eyephones),
then that pushes the delay way beyond the 100 ms limit.

On the other hand, if the glove can be polled on demand
(within certain constraints, like at least every 100 ms),
or even if the graphics are synchronized to the continuous
polling, then that eliminates the 79 ms lag time and
brings the picture that much closer to the motion.

The trick to the polling on demand (theoretically)
is to not sample the glove until you're ready to use
the glove_data, and then return as soon as you've
got the important data.  The juicy part of the packet
is the first 7 bytes (if the packet is in the right order),
which take less than 1 ms to sample!  The last 4 bytes
of the standard 12 byte packet take about 70 ms to sample,
but they're not needed and can be handled by an ISR
following the return of the main call, just to keep
the timing right.  Whether the data was freshly sampled
when it comes from the glove is another important question.

I'm assuming that the CPU time needed to handle the graphics
will expand to approximate whatever sample time is achieved
with the glove.  Any slower frame update rate than 13 fps
will look choppy, and any faster would be pointless since
if there's no new input sample then the picture won't need to
change anyway.  So, if it is possible to do the graphics
faster than the input sample rate then the programmer will
just make the graphics more complicated (hidden line removal,
polygon filling, polygon shading, more polygons... ad infinitum).
Since each graphics cycle will take about as long as
each glove sample, it'll be important to synchronize them
and avoid a doubling of the best-case delay time.

Whether to sync the glove to the code or the code to the glove
depends on how the glove makes its clicks.  I suppose the
glove must start its sample click 40 ms before it sends the
data to the computer, which means it must do so 39 ms before
the computer asks for it, which means that it must do so
whether the computer asks or not.  In that case, continuous
sampling would be best and the code must be sync'ed to the glove
(which is a pain, considering that there may be other devices
also being delt with, including another glove).  On the other hand,
if the glove always starts its clicks approximately 30 ms after the
last time the computer asked it for data, then sampling on demand
is best so the glove will be syncronized to the code.

Can a hardware guru look into this, please (Dave Stampe?)?

The time it takes to do the graphics rendering each frame
is independent of whether the glove's fingers are open or closed.
So, if continuous sampling is used and the graphics rate is
not syncronized to the glove, then as the glove sample rate
varies from 58 ms to 80 ms the graphics routines will
get out of sync and introduce an additional 80 ms lag time
(at worst) between movement and feedback (which is probably
unacceptable).  If the graphics rate IS synchronized to the
glove, the graphics routines will have to be designed to the
shortest interval (58 ms) and the additional 22 ms which
may or may not be there will be wasted every frame (i.e.,
wasting 27% of the CPU time).  On the other hand, if the
glove times its clicks according to when the on-demand sample
is made, then the graphics code can be designed to the
worst-case time (75 ms or however long it is), the CPU
will be fully utilized, and an additional 17 ms lag time
(at worst) will be the cost.  But, if the glove clicks away
at its own speed regardless of when on-demand samples are made,
then the lag time will be occuring as the data sits around
in the glove's internal buffer instead of in the computer's,
but the results will be the same (up to 80 ms as the glove
and computer become unsynchronized at their worst).
I think this would be a big performance problem.

I don't know enuf to find out myself which way the glove works.

--
J. David Beutel  11011011  jdb9608@cs.rit.edu  "I am, therefore I am."