Received: from apple.com by karazm.math.UH.EDU with SMTP id AA15446 (5.65c/IDA-1.4.4 for ); Mon, 21 Oct 1991 19:34:29 -0500 Received: by apple.com (5.61/18-Oct-1991-eef) id AA11160; Mon, 21 Oct 91 17:07:40 -0700 for Received: by motcsd.csd.mot.com (/\=-/\ Smail3.1.18.1 #18.4) id ; Mon, 21 Oct 91 16:53 PDT Received: by roi.ca41.csd.mot.com (smail2.5/CSDmail1.0, Motorola Inc.) id AA12016; 21 Oct 91 16:49:46 PDT (Mon) To: menelli@tellabs.com Subject: PG controller board Cc: glove-list@karazm.math.uh.edu Message-Id: <9110211649.AA12004@roi.ca41.csd.mot.com> Date: 21 Oct 91 16:49:43 PDT (Mon) From: Lance Norskog This is excellent! The software interface provided in high-res mode is pretty weak. For serious work I would much prefer your outboard controller. I have some software that does continuous gesture recognition for mice, based on characterizing two single input streams. It mentions something about doing gloves via multiple streams. I can't use it with the glove because it only does 2 bits. (The software is on emsworth.andrew.cmu.edu in /gestures. It's by Dean Rubine, see the SIGGRAPH '91 proceedings.) A point: the serial port approach does involve delays. A parallel port version would cut that down even farther. Does the Motorola evaluation board include enough parallel lines to make this possible? A parallel version would only involve one interrupt per sample, and short polling loops. Another point: I would want a mode where the controller board did as little interpretation as possible. Just feed the raw counters in and let the big CPU with floating point handle X,Y,Z,rot issues. A third point: does the Motorola chip include timers? A global timestamp, based on the start of the sample cycle in the board, would be very useful for doing synchronization work. There are algorithms for dealing with irregularly spaced input streams; a prediction algorithm would need accurate timestamps to operate properly. Lance Norskog