Spaceball 5000 Serial Protocol -- decoding 'd' packets

[vputz]

I've got an old Spaceball 5000 db-9 serial and updating my little Orbotron widget to use it is... vexing me. I had thought the 5k used the Magellan protocol, but that's not working for me and despite a LOT of searching and digging through what code I can find in various libraries, I can't seem to find what I need.

It seems to be sending me 'd' packets (lowercase d) but rather than being the large magellan-style crunch-the-nibbles 26-byte packets, I'm getting 16-byte packets starting with 'd' and ending with '\r'. That leaves 14 bytes to make six values.

The zero value seems to be

Code: Select all

b'd\xe0\x80\xe0\x80\xe0\x80\xe0\x80\xe0\x80\xe0\x80\xa1\x80\r'

-- and manipulating the ball "towards and away" modifies the first two bytes. So it looks as if we have two bytes each for the axis translation and rotation, but I can't work out what the last two are for unless they're some sort of crc-like check or something.

And decoding the two-byte axes is vexing me as well. The rightmost bits count about as I would expect, but the leftmost are stranger. For example, if I look at the first two bytes (representing the "toward and away" axis) the first one (looks like an MSB, normally

Code: Select all

\xe0

or

Code: Select all

0b11100000

) changes like this when pulling it towards me:

Code: Select all

    # e0 1110 0001
    # a1 1010 0001
    # a2 1010 0010
    # 63 0110 0011 
    # a4 1010 0100
    # 65 0110 0101
    # 66 0110 0110

and like this when pushing it away:

Code: Select all

    # 5f 0101 1111 
    # 9e 1001 1110
    # 9d 1001 1101
    # dc 1101 1100 
    # 9b 1001 1011
    # 5a 0101 1010

It's almost as if the lower X bits are the value it wants to send (they count up or down obligingly) and the upper Y bits are some sort of parity check on the low bits--but not in any way that makes sense to me. The lower byte in the pair varies too quickly for me to note, but it looks like it may follow a similar pattern.

...and either way, no idea what to do with bytes 13 and 14, which change somewhat with everything else.

Does this protocol sound like anything anyone's seen here? I've got the buttons decoded just fine, but the ball packet is completely eluding me; the only code or documentation that references a 'd' packet is the magellan protocol with the nibble-crunching, but that's not what I'm seeing with this. Any ideas?

[jwick]

(Working from really old memory here)
IIRC SB5000 only supported the Spaceball protocol. The behavior may have been simplified from the original.

You needed to init the device by sending it some messages (character strings). I forget if I made some of those optional.
In general, you needed to set the data mode and the timing.
Mode: "MSSV"
Timing (Pulse): "Pmn" ; where m n are two 12 bit numbers in milliseconds. I forget what the typical x values where, but I can try to find the old code. Without this it will send out "d" packets at a very slow rate. I set them the same so it always sent out data at a consistent rate.
Nonlinearity: the data may a curve to make it feel good. There is an "F" packet for that. If you get that far, I can look up all these.

I believe all command packets going to the device use upper case IDs. Packets coming from the device have lower case IDs.

The data packet should be a 15 byte packet (maybe there is also a <CR> added on the end):

'd' <two bytes of period> <two bytes each of> Tx Ty Tz Rx Ry Rz

Where period is the time in milliseconds since the last event. You can ignore that.

This is a very nice sight that contains many details of the old devices.

[vputz]

Man, I'd like it to be that easy. It's killing me! The thing is, the d packet doesn't quite look like that; if anything the first six pairs would be the axis and the last pair would be something, ie I'm getting
```
Packet : bytearray(b'd\xe0\x80\xe0\x80\xe0\x80\xe0\x80\xe0\x80\xe0\x80\xa1\x80\r')
``

That's the packet I always seem to get when the ball is at rest. The last one's different and the rest are all the same (rather than the first one being the timing) but the last is always \xa1\x80 if everything is zero, almost like it's some kind of checksum or something.

The startup string I'm currently sending is actually
```
uart_source.uart.write(b"\rCB\rNT\rFT?\rFR?\rP@r@r\rMSSV\rZ\rBcCcCcC\r")
```
which is from something else. The sb5 isn't beeping as the BcCcCcC should do, but at least that's being sent. The 'd' packets are only being sent right now on ball movement.

I can mangle the packets to get "closer"--ie if I do something like

```
def spaceball_axis(b1, b2):
# result = (b1 <<8) | b2
result = ((b1 & 0b00111111) << 6) | (b2 & 0b00111111)
```
treating the first two bits as some sort of checksum against the other bits, it actually looks like it's doing something; the middle value gets stuck at 2048 and varies from around 1690 to 2442 or so. Narrow range, but at least it looks roughly "right" as I move the ball across the axis.

Chipping away, but this is still frustrating; no idea what I'm really doing or how to proceed.

[jwick]

Do you already have this doc?
That specifically references the SB4000. If that doesn't work, I'll try to dig up a SB5000 to see what we changed.

[vputz]

I didn't have that document and you are an ABSOLUTE HERO now because I've been looking for something similar for quite a while and been unable to find it. And by "quite a while" I may mean "years".

You know, what I'm seeing looks very much like the "d" packet of the "Turbo Spacemouse" in the appendix. I'm going to try that and see what I get out of this.

[vputz]

Worked more or less like a champ; you're a lifesaver. I didn't pursue the earlier bit further because it felt like the range was too small (1690-2442 is roughly +/- 400 from 2048 and with 12 bits I was expecting +/- 2048). But even in the doc somewhere it said expect +/- 400 so maybe that makes sense. I'm depicting the spaceball as a HID device with +/- 512 on each axis (using the hardware adapter I made for the old Spaceball360) so I'm just roughly scaling and clipping at the moment, which works actually pretty well.

At any rate, it's working now as a HID device under Windows, which may answer the mail for this application. Now only if I could find a Solidworks plugin that took in arbitrary HID controller data, I'd be getting somewhere, but that's beyond the scope of this forum.

Seriously though, thanks very much; that's a huge help just having the protocol and test data.