Message-Id: <199110222259.AA22487@karazm.math.UH.EDU>
Date:    Tue, 22 Oct 1991 18:51 EDT
From: LEEK@QUCDN.QueensU.CA
To: glove-list@karazm.math.uh.edu
Subject: Standardization Ideas....

Here is my 2 pennies worth of ideas on standardization of similiar glove
inputting device...   I think standardization is a good thing.  I would like to
suggest to move away from the powerglove data structure as it seriously limits
the possible type of performance for future devices. Some  obvious limitations
is the # of bits per finger and the rotational angle resolution.  One  can
easily get 6-7 bit of resolution if one simply replaces the Glove CPU and add
$3.00 worth of hardware.  At the moment, the glove data structure might seem
more convient.  I just think it is worth while to set a proper standard.

I would also like to add a new function for the glove.  This function is to be
called after initialization.  This informs the host program of the capabilities
of the input device.  The host program can then perform the necessary
transformation(s) required to the input packet stream.

Inquire_Glove();

This function returns a pointer to a structure that contains the following:
count - this tell the program how many words are there in a packet
wordsize - the word size used in packet:byte,int,long
tags  - this points to an array of tags that describe what each of the
        words in the packet are for and what is the maximum ranges of data to
        be expected.

Tags array:
Name - a char string with ASCII text identifying the corresponding word
in the packet eg. "Finger 1", "Receiver 1", "Distance X", "Rotation" The ASCII
text would have to be standardized.  New tags can be added for future devices
as they becomes 'available'.  Programs would only read off tags that they
understands and ignore the rest. Try to make it obvious and understandable by
someone else. Avoid using obscure short form for tags as they make guess at it
difficult and some programmers (like me) likes to use the tag as part of the
items on menus (when they make sense)

Max - The maximum upper limit of the corresponding word in the packet.
(eg. Max = 12 for the rotation from the glove.   For others, it might
     be 360 for 1 degree resolution. )

The function Read_Glove() would now return a pointer to a packet of size
count*wordsize bytes.

If any of the data in the packet is > than their corresponding Max values, that
means that piece of data is unavailable for the current sample.  (eg.  One of
the receiver misses)

It might also be possible to have the inquire function return a second tags
array describing the possible operating modes available from the glove.  eg.
possible modes:  "Joystick", "X,Y,Z,Rot,Fingers", "Raw", "Sample on demand",
"Sample rate".  An extra function is used to set the glove into one or more
operating modes.  The program might also ask the glove to only include a
selected list of data in each packet. (ie.  The program get what it wants, not
everything the glove gets. This is to lower the overhead of data communication
between the host and the glove.)

I hope I have not gone way of tangent here.    I feel if we are going
to have a standard here, then we should do it right ie. not to limit ourselves
to a particular product or model (eg to save 5 machine cycles) , allow for
expansion in terms of new devices and/or higher resolution. Some of the hard
coder there might want to argue efficiency with me about the extra processing
required...

To me programming in bare metal refers to laying out the transistor connections
in a custom chip that performs the equivalent software function.  :)  If I want
speed, I'll build some hardware for the task.

As for the interrupt/poll, leave it to the particular machine.  I like the
device model on my Amiga that provides both sync & async I/O.  Why force your
particular model (TSR, Interrupt, Polling, Multitasking) on others ???


K. C. Lee
Elec. Eng. Grad. Student