Preliminary Data Format For Kuper Streaming Serial Generated Position Data:


The data format consists of a single character "commands" followed by a varying number of data characters. command characters are recognized by being the only characters in the data stream with their high order bit set to one. All other characters always have the high order bit set low, which limits the data capacity of each single character to 7 bits.

The low order 7 bits of the command character identify the type of data to follow in the data character stream. Seven bit data "bytes" must be concatenated at the receiving end into data of the appropriate size.

This format can transmit performance capture, motion control data, etc. in real time to CGI packages.

Speeds can run from 38.4KBaud up to megabaud rates. Higher speeds will allow data at up to 120Hz, with 32 axes. RS-422 is required for higher data rates.

16650 UARTs are preferred for transmission because of their 32 byte buffer.

Initially, the following commands will implement a minimal scheme.

  • 0x80: The data will assign a numeric handle to an object, and provide an object name in ASCII format.
  • 0x81: The data will contain a frame number. Frame numbers correspond to visual frames of film, video fields, or other "whole" recorded images.
  • 0x82: The data will contain an object's handle number, followed by X, Y, Z, Pan, Tilt, Roll in real-world camera coordinates
  • 0x83: Images are being recorded
  • 0x84: Images are not being recorded
  • 0x85: The data will contain scene number, take number, and optional operator comments. 
  • 0x86: The data will contain time of day information. This could later be temporally interpolated and offset to a frame number starting at zero.
  • 0x87: The data will contain the frequency at which the data is being collected. This could later be temporally interpolated and offset to a frame number starting at zero.
  • 0x88: The data will assign the types of units being used, whether inches, meters, degrees, radians, etc.

Up to a total of 128 commands may be defined, for instance to represent object positional data in local, world, parent-related, or other coordinate systems. 


In practice, the sending device first uses the "0x80" command to assign a numeric handle to an object, and to give its ASCII name. This is vaguely similar to opening a file handle, except that the sender provides the handle. The sending device may then optionally use the "0x81" command to identify the current visual frame number, which will apply to all subsequent positional data until another frame number is sent. The sender may then repeatedly send object positional data using the "0x82" command. "0x81" commands may be periodically sent to identify the next frame number for which subsequent positional data will be sent.



The following examples show the contents of each character in the data stream, separated by commas. 



0x80, low 7 handle bits, high 7 handle bits, `N', `A', `M', `E' 

The low and high command bytes are assembled by the receiver into a 14 bit handle, which the receiver will subsequently associate with the object whose name is "NAME". The name may contain any reasonable number of characters. The characters must be limited to values of 0..127, to prevent them from aliasing as "bit 8 high" commands. Note that there is no end-of-line character, because the name will be terminated by the arrival of the next "bit 8 high" command. 

The sender must provide a handle and name for each object before positional data commands are sent for that object. This will normally be done only once per session, unless the sender wishes to re-assign the handle or rename the object.



0x81, frame number bits 0 to 6, frame number bits 7 to 13, frame number bits 14 to 20, frame number bits 21 to 27, frame number bits 28 to 31 

To calculate the frame number, the receiver concatenates the data into a 32 bit word, and divides by 3600. This provides a frame number resolution of one part in 3600, which aids in resolving time base differences between different devices. Frame numbers are inserted only as necessary. The last frame number sent remains valid for all subsequent object positional data, until a new frame number is sent.



0X82, low 7 handle bits, high 7 handle bits, (
4 byte packet of X position data), (4 character packet of Y position data), (4 character packet of Z position data), (4 character pack of Pan position data), (4 character pack of Tilt position data), (4 character packer of Roll position data). 

It is the assumed that the handle refers to an existing object previously defined by the "Assign Object Command". Each position data packet consists of four, seven bit characters that the receiver concatenates into a 28 bit word. The highest order bit is the mathematical sign. The concatenated, sign-adjusted word is then divided by 2048 to obtain the position in real-world units. This provides a dynamic range of plus or minus 65536 real-world units (such as degrees or inches), with a unit resolution of one part in 2048. When the receiver detects "roll-overs" above and below this range, it must do modulus math as necessary to keep track of the actual object position. 

In motion control applications, the object position command will normally supply X, Y, Z, Pan, Tilt, and Roll coordinates. If fewer than six coordinates are sent, they will be assigned in the order above, and unsent coordinates will considered to be the same as the last coordinates sent. 

Special object names may cause the receiver to interpret the data in special ways. For instance, objects whose first six characters are "CAMERA." will be regarded as cameras. "CAMTARGET001" will be regarded as the tracking target for "CAMERA001". For camera tracking targets, it will only be necessary to send the X, Y, and Z components of the positional data.




This notifies the receiver that the imaging device is recording images. The receiver may use the data supplied by the "Frame Number Command" to index the positional data.




The imaging device is not currently recording images.



0x85, bits 0 to 6 of scene number, bits 7 to 13 of scene number, bits 14 to 20 of scene number, bits 0 to 6 of take number, bits 7 to 13 of take number, (any reasonable number of free-form ASCII operator comment characters). 

The receiver concatenates the scene number into a 21 bit word (up to 2,097,152 scenes), the take into a 14 bits word (up to 16384 takes per scene), and optionally records operator comments. When notified that images are being recorded, the receiver should associate the most recently received scene number data to the recorded positional data.





Some systems, such as flight simulators, quantize the data at a variable number of samples per second. The receiving software would receive this "frequency" data and interpolate the associated position data into a standard film frame file. The intention of this command is to record data "on the fly",where the sending software operates continuously, without a specific start frame.


Speed issues

Each axes takes up 4 bytes. Thus, each 6 channel object requires 24 bytes, plus 3 for the start of line header. To get bits, you multiply not by 8, but by 12, for stop bit overhead, etc. So, an object takes up 324 bits.

  • At 30fps, 115kBaud, about ten objects can be transmitted, along with the commands.
  • At 30fps, 38.4kBaud connection, about three and a half six channel objects can be transmitted.
  • At 120 fps, 115kBaud, 2.5 six channel objects can be transmitted.