From: jdb9608@cs.rit.edu (John D Beutel)
Message-Id: <9110210213.AA18542@junior.rit.edu>
Subject: Re:  sampling techniques and response time
To: dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng)
Date: Sun, 20 Oct 91 22:28:39 EDT
Cc: glove-list@karazm.math.uh.edu
In-Reply-To: <9110200511.AA00440@watserv1.uwaterloo.ca>; from "Dave Stampe-Psy+Eng" at Oct 20, 91 1:11 am
> First, the REAL sampling rate for data is set by the powerglove itself, and
> depends on the sum of all of its sample periods (thus its dependance on the
> finger position).  If you wait longer than the sampleing period before you 
> read the glove, you just get older data.  

That's what I'm wondering.  If the samples are made at a constant
rate (like by the original hi-res routine), then are the samples that
the glove makes itself limited by this?  I've listened to the clicks
that the glove makes while being sampled at a constant speed,
and I can't hear any difference between open and closed fingers.
I'm not sure I can tell the difference between 13 and 17 Hz,
but I suspect the glove has a constant sample rate when polled
with the original method, independent of finger position.

> Second, the interrupt-driven method I proposed (use an interrupt every 3-4 mS
> to poll the glove) actually results in the freshest possible data.  Your
> software can sit in a loop calling get_glove_data() and checking the .new
> flag in the result: the glove doesn't care, and you're just looking at
> the buffer contents until the interrupt gets new data and updates the buffer.

I agree; the quick-polling method you discovered should get
the data the fastest possible way.  I'm worrying about the
graphics routines and how much time they take.  However long
it is, it won't vary according to the polling rate of the glove.
So, there's a trade-off involved with quick-polling.
To keep the response time as fast as possible, the graphics
must be synchronized with the glove polling.  But, if the
fingers are open and there's only 58 ms between polls,
then that's all the time the graphics routines will have,
so they must be able to do their job in 58 ms.  If the
fingers are closed and there's 80 ms between polls, then
the extra 22 ms will be wasted (unless the graphics can
be written to do the minimum rendering in 58 ms and some
worthwhile extra rendering if more time (up to 22 ms) happens
to be available).  Wasting the CPU time on the long intervals
is the trade-off for having a quicker response time.
If the glove sync's itself to the rate it's polled (as it
seems to when polled with the old method) then the
graphics can be written to take a constant CPU time
(e.g., 80 ms), fully utilize the CPU, and still stay
in sync with the glove.  

However, the whole point to sync'ing the code and the glove
is to avoid an average 30 ms extra lag time, so if the
original polling method adds any extra lag time to the
quick-polling method, then it may not be worth sync'ing
(or it may be worth accepting the wasted CPU time).

Maybe I think about this too much.  It shouldn't be
really important unless the glove is being used on
eyephones, and in that case the fingers would be off anyway,
so the sample rate would be constant regardless of method.

I haven't gotten your quick-polling method working (yet)
(I haven't even gotten the original working in the right
order all the time yet), but I'm a little worried about
the "reset after 500 polls of no A0".  That sounds like
a 1 or 2 second interruption of data; how often does it happen?
When and why?

--
J. David Beutel  11011011  jdb9608@cs.rit.edu  "I am, therefore I am."