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.