Does the rs232 node only process one character per frame?
If so, I would be looking at ~13 frames between position updates,
which would be too much. Is there a buffered rs232 input?
no, the rs232 node outputs a string containing all characters which were received during the last frame. so no need to wait multiple frames.
if you will receive a complete packet or even multiple packets during one frame depends on the frame rate of your patch and the sampling rate of the spaceball. therefore you will like to split the incoming stream of data into so called tokens which resemble the individual space ball commands and not the data arrived in one frame.
One important node for patching these kind of things is the Tokenizer (String) node. it appends all incoming strings each frame until a certain condition is met. See the help patch. From what i see in the C code, the Spaceball sends a 0x0D when a packet is empty. So you can set the Tokenizer to Postfix (the character comes after the packet) and input an ascii character 10 to the separator input (use SpellValue in ASCII mode with an input of 10). Now you will get all sequences which end in an ascii 10 at the output. you may like to attach a S+H and a = like in the help patch to see the decoded output for more than one frame.
The QueueLength output of the tokenizer will report the received characters which were not output yet. This should stay under 13 if the packets would have a maximum length of 13. if it rises forever something in your patch might be wrong - for example if the incoming strings would never contain an ascii 10.
Depending on the ratio between the spaceball sample rate and the frame rate you should decide on the QueueMode of the Tokenizer. Enqueue output always one complete packet per frame - all other packets are saved in the Tokenizer, and get output in a later frame. this is fine if the frame rate of your patch is definitely higher then the packet rate of the incoming data, or if the data arrives only in bursts. Note that data may queue up in the tokenizer (therfore the name) so observer the QueueLength pin, as it will notify you of possible delays. If the Queue Mode is set to Discard all packets, that cant be delivered right now will be discarded. So you would be sure to never get a delay, but certain data packets may be missing. So if your device would send absolute values, this might be the preferable way. The most flexible mode is the Spread mode, which outputs all complete packets which were decoded in one frame as one spread of strings. So you can basically decide what to do with multiple packets which get received during one frame - like if you want them added up (ideal for relative data) or averaged, maxed, parsed separate or whatever.
for first test, the Enqueue mode probably makes the most sense. decoding the incoming data should be easy in principle (depending on the number of quirks the spaceball vendors have built in). The Ord (String) node is your friend.
And: When you manage to interface the spaceball, please do encapsulate the code in a user-friendly module and provide it to the public on the usermodules page will you?
That would be very much appreciated.
ps. very impressed by your raNCHtRonIx site. Puzzled by the fact that there is no physical address, but from the street names on the calöendar page you must be in the San Francisco area?
I was definitely planning on making it into a re-useable module.
The trOnix site is mostly a ratsnest of our own personal notes, though we keep talking about making it more useful for others. We’re in a warehouse in Bayview, San Francisco. If you’re local you’re welcome to come by. We do a weekly thing where people work on projects, hang out, and drink beer :)
Finally had some more time to play with vvvv. I can read the axis data off the spaceball now. There’s some glitchiness (junk on the serial line?) that I have to figure out, but I have a quad responding to all 3 axes :)
yup il upload it tomorrow. what kind of spaceball will you get?
i did a driver for the 5000 flyx. but i got also an onld spaceball 2003 from ibm. but didnt made the driver until now. but i got the protocol description so i think a driver for the 2003 is made very quickly… i also adapted kiilos flying cam to get a suitable camera for the spaceball. post it in the next few days
cool that it works for other devices too, thanks for the info,i take it up in the module description.
im wondering how it differs from the spaceball in the handling? and do all the buttons work?
that driver is quite a hack because i hadnt any documentation at that time and i didnt understand one part that i patched myself but at the end it worked. but there some missing features, some commands to set the device settings like sensivity or null region etc… i havent got documentation for that newer devices protocol. but it should be poossible to listen what the original sneds to the device to set those things.
i got a docu for the spaceball2003 but didnt found the time to patch that thingie.
after my first successful start with the space mouse basic and your module i am encountering some problems.
Initialisation of the the space mouse is very unreliable. Sometimes it works - most of times it is not. The original driver is not running and hitting the “initialize” iobox does not always help. Sometimes the buttons work but the positioning not.
The spacemouse itself does not seem to be the problem as the demos (after starting the original driver of course) are always working without a problem.
Do you have any similar experiences ? any ideas/tips ?
I will try to get a dokumentation for the protocol of the space mouse basic !?
How does the protocol of the spaceball2003 differ from the SpaceBall500FLX ?
SpaceMouse classic could be the same “age” as the SpaceBall 2003 … so may be the protocols could be the same !?
my spacball 5000 works without problems. i had the initialisation problem too but after snedingt the string with onopen and framedelay it worked always. positioning is no problem. its a way ago i patched that thingie but as far as i remember the main difference is that the positioning packets for the 5000 are 4 bytes long, while for the 4000 and 2003 (both slighlty different) the packets are just 2 bytes long. i think this is because of the higher resolution of the 5000.
i got the some orginal protocolpapers from labtec but i dont know if its a good idea to post here, because theyre labeled with highly confidential and do not distribute ;) maybe you can provide your email adress?
Problem with my 3Dconnexion SpaceMouseClassic is solved.
The 3Dconnexion „SpaceMouseClassic“, „SpaceMouse Plus & Plus XT“ „SpaceBall 4000FLX“ and “SpaceBall5000FLX” all seem to use the same protocol.
Main (and big) difference is that the “…Ball-units” use 1 stop bit, the …Mouse-units” 2 stop bits for their serial communication ! GRRR !
After changing from 1 to 2 stop bits elektromeiers module for the 5000FLX works perfect and stable with my SpaceMouseClassic.
This simple solution does not work for the Labtec SpaceBall4000 or SpaceBall2003 as they seem to use a different protocol (although naming and design is very similar).