OK, i cancel the way over DLL. It's to hard to get data from a extern DLL. Special thanx to JFK
The next Way is ro handel it over RS232, here is a system on start and i try to use it. I found in the Net the definition of the pack's and try now to read them out.
Just for Fun here ist the definition:
The CyberMaxx tracker interface, and a proposed extension
The CyberMaxx runs at 9600, 8 bit, no parity, 1 stop.
To reset the unit, send it an ascii 'R'; it should respond with a copyright
string. By default the tracker sends data in ascii, so send it an 'F' to go
into binary mode. By default it sends data continuously; if you want to poll
it, send it a 'G', then send an 'S' whenever you want to request a packet.
In binary, the packets consist of 8 bytes. The first two are 0xFF (to mark
the start of the packet). These are followed by 3 16-bit words (sent
high-byte first) giving the yaw, pitch and roll. The top bit of each
16-bit word is zero, so they're really 15-bit words; the fact that the
top bit is zero means that you don't have to worry about two consecutive
0xFF's occurring in the data and looking like the start of a new packet.
The yaw is 0-360 degrees (i.e. 0 is zero, and 0x7FFF is 359.959 degrees).
The pitch and roll are from -45 degrees to +45 degrees (i.e. 0 is -45,
and 0x7FFF is +45).
That's it. Pretty simple.
To summarize, the packet is:
1111 1111 1111 1111 (16 bits of 1's)
0yyy yyyy yyyy yyyy (15-bit yaw)
0ppp pppp pppp pppp (15-bit pitch)
0rrr rrrr rrrr rrrr (15-bit roll)
Software-wise, you send an 'R' followed by an 'F' to initialize the tracker
and put it into binary mode. Your serial interrupt routine should check for
two consecutive 0xFF's; when it sees them, it should reset its buffer pointer
to zero. After the number of bytes in the buffer hits 6, just pick up the
yaw/pitch/roll and convert. *Really* simple stuff.
Here's what I propose to do to extend the packet format:
Add additional 16-bit words (with the top bit clear, for backwards
compatability). In other words, after the "roll" value, just add
more data; old parsers will ignore everything up to the next
double 0xFF, and new parsers can use the additional data. New parsers
should probably check the copyright message, to see if they've got an
old-format device (like the current CyberMaxx), in which case they read
only the yaw/pitch/roll.
The first additional word (after the roll value) would be:
0knn nnnn cccc cccc
where the 6-bit 'n' value is the number of 16-bit values that follow, and
the 8-bit 'c' value is a channel id (in case the serial devices are
daisy-chained). The data for the additional channels would follow, 15
bits for each channel. The first three should be reserved for position
information, the rest will be device-specific (e.g. finger flexion).
If the 'k' bit is set, the software should expect a 16-bit (really 15-bit)
checksum to follow the data; the checksum would be the unsigned sum of all
the data values (not including the 0xFF's).
The next Way is ro handel it over RS232, here is a system on start and i try to use it. I found in the Net the definition of the pack's and try now to read them out.
Just for Fun here ist the definition:
The CyberMaxx tracker interface, and a proposed extension
The CyberMaxx runs at 9600, 8 bit, no parity, 1 stop.
To reset the unit, send it an ascii 'R'; it should respond with a copyright
string. By default the tracker sends data in ascii, so send it an 'F' to go
into binary mode. By default it sends data continuously; if you want to poll
it, send it a 'G', then send an 'S' whenever you want to request a packet.
In binary, the packets consist of 8 bytes. The first two are 0xFF (to mark
the start of the packet). These are followed by 3 16-bit words (sent
high-byte first) giving the yaw, pitch and roll. The top bit of each
16-bit word is zero, so they're really 15-bit words; the fact that the
top bit is zero means that you don't have to worry about two consecutive
0xFF's occurring in the data and looking like the start of a new packet.
The yaw is 0-360 degrees (i.e. 0 is zero, and 0x7FFF is 359.959 degrees).
The pitch and roll are from -45 degrees to +45 degrees (i.e. 0 is -45,
and 0x7FFF is +45).
That's it. Pretty simple.
To summarize, the packet is:
1111 1111 1111 1111 (16 bits of 1's)
0yyy yyyy yyyy yyyy (15-bit yaw)
0ppp pppp pppp pppp (15-bit pitch)
0rrr rrrr rrrr rrrr (15-bit roll)
Software-wise, you send an 'R' followed by an 'F' to initialize the tracker
and put it into binary mode. Your serial interrupt routine should check for
two consecutive 0xFF's; when it sees them, it should reset its buffer pointer
to zero. After the number of bytes in the buffer hits 6, just pick up the
yaw/pitch/roll and convert. *Really* simple stuff.
Here's what I propose to do to extend the packet format:
Add additional 16-bit words (with the top bit clear, for backwards
compatability). In other words, after the "roll" value, just add
more data; old parsers will ignore everything up to the next
double 0xFF, and new parsers can use the additional data. New parsers
should probably check the copyright message, to see if they've got an
old-format device (like the current CyberMaxx), in which case they read
only the yaw/pitch/roll.
The first additional word (after the roll value) would be:
0knn nnnn cccc cccc
where the 6-bit 'n' value is the number of 16-bit values that follow, and
the 8-bit 'c' value is a channel id (in case the serial devices are
daisy-chained). The data for the additional channels would follow, 15
bits for each channel. The first three should be reserved for position
information, the rest will be device-specific (e.g. finger flexion).
If the 'k' bit is set, the software should expect a 16-bit (really 15-bit)
checksum to follow the data; the checksum would be the unsigned sum of all
the data values (not including the 0xFF's).