Partner joystick communications protocol

VEX V5 General Discussion Technical Discussion
#1

One of the things I really enjoy is figuring out how things work. A question was asked about the partner joystick communications and so (although I’m sure JVN will give the official answer) here is what I have found after an hour or so of poking around.

The partner joystick connector is a 4 pin RJ-9 (or is it RJ-22, not sure) and uses a 4P4C telephone handset cable to connect to the partner joystick.

Connector pinout

Pin1 GND
Pin2 Tx Data from the joystick
Pin3 Rx Data to the joystick
Pin4 GND

The connection uses RS232 communication at normal RS232 levels rather than the TTL levels used on the programming port.

Communication is 8 bit No Parity (I think) 1 stop bit at 115200 baud.

The Master joystick sends a message to the partner joystick roughly twice per second, the message is 4 bytes (shown below in Hex) and seems to be used to keep communication alive.

AA 55 3B 01 (This is inconsistent with all other VEX messages, should be 1 more byte if it followed the normal format )

The partner joystick responds with a message similar to the following (again in hex) at a much more frequent rate (to lazy to time it).

AA 55 39 0A 7F 7F 7F 7F 00 00 65 7F 7F A1

the breakdown of this is as follows

AA 55 39 - header, nearly all VEX messages start with AA 55
0A - data length, including checksum
7F 7F 7F 7F - the values for the 4 analog joysticks
00 00 - the buttons as bitmapped data. ie. one button per bit
65 7F 7F - accelerometer data
A1 - checksum, the sum of all data bytes and the checksum byte will be 00 (mask sum with 0xFF )

I will leave it to others to add more detail on switch bit positions, I did decode this for one of the other communication protocols but to be honest I’m too lazy to type it out here.

I had the joystick hooked up to a PC through a USB serial adapter, it would be very simple to create a partner joystick simulation if needed.

This is obviously unofficial information so use at your own risk :slight_smile:

Enjoy

1 Like
#2

Im thinking that the data that the Master sends out is for the lights on the partner stick. One byte per light and then the color within the byte.

Edit: Perhaps the normal start byte and the light value and then a checksum.

#3

Perhaps, I did not monitor an actual exchange between two joysticks, I only have one. I posted this for the students at KTOR to have something to get them going with their custom partner controller. If I have any time in the next couple of days I will throw together a demo application that can simulate the partner joystick.

1 Like
#4

Thanks Jpearman. It’s a great place for us to start from as you said. Right before worlds we’ll post our control box if all goes according to plan (ie we can actually figure out how to get it to work).:smiley:

#5

PM me if you need help, you could use something like this to make the cables easier if you need to. I hope JVN will post the full protocol so we don’t have to do any more experiments.

1 Like
#6

I thought you just said you enjoy figuring out how things work? :slight_smile:

1 Like
#7

We are actually using a phone jack at the moment to achieve the same principle and JVN while we are trying to figure this we would never turn down additional help/information.

#8

Absolutely I do, but there is always a trade off between time invested and the reward it supplies. I am skeptical that you will ever release any significant technical details based on past requests for this type of information. I recently tried to get more insight into the changes in the latest master firmware and, although receiving a polite reply, still feel short changed when asking about these things. Here are a couple of (admittedly very old) posts from the FAQ that seem to express the general attitude.

https://vexforum.com/t/programming-module-protocol/12267/1

https://vexforum.com/t/programming-protocol/12382/1&highlight=protocol

There are many of us who would like access to schematics and communication protocols, not for any particular reason but just to educate ourselves. I have looked into many things, both HID and CDC USB protocols used for connection of the cortex to a PC (I have OSX drivers for both), certain aspects of downloading and uploading firmware, the whole ROBOTC communications protocol, internal mapping of IO ports on the STM32 processor, lots of stuff, nothing used for destructive purposes and most of this I keep to myself unless asked about it. Next on the list I guess will be the new I2C interface, what’s the clock frequency, how does the address auto-negotiate work as I’m used to static addresses. One day perhaps I’ll take a crack at the WiFi protocol, although that will take a little more effort and I’m not that interested.

So I hope you will surprise me John and let out a few secrets :slight_smile:

1 Like
#9

I was just joking with you.
We will release as much as we can. I’m on the road right now but when I get back to the office I’ll discuss in more detail with my team.

As you know there are reasons to keep some things proprietary, and reasons to make things public. We try to find the balance between these two…

-John

1 Like
#10

I know, but it’s always an opportunity to jump on the soapbox.

Any information on any of the protocols would be appreciated.

I understand and face this situation on a regular basis.

In the mean time…

Here is a silly little app I threw together this evening that simulates a partner joystick on a PC or Mac. Not very polished, just a bunch of sliders and buttons, but I have no real use for it so don’t plan to develop it any further. You can use the prolific serial adapter or any other serial port available (needs to be there before launching the app under windows). Obviously, a custom 4P4C to DB9 cable needs to be made, use the pinout from the first post in this thread.

https://vexforum.com/attachment.php?attachmentid=5173&stc=1&d=1327386671

OSX version available for download here.

Win32 version available for download here.

Enjoy
joysim_grabosx.jpg

1 Like
#11

Official information here:

1 Like
#12

Thanks john for releasing such detailed information. Jpearman, how’s that foot taste? :stuck_out_tongue:

1 Like
#13

Yummy, yes I am surprised, I hope it’s the beginning of a new trend. I will, however, have some questions for John as there are some minor discrepancies between what he has published and the observed messages.

The partner joystick protocol is one of the simpler ones, so now how about releasing official details about something more complex, perhaps the cortex USB CDC protocol so we can release OSX and linux drivers for it, or should I post that here first as well :slight_smile:

1 Like
#14

Ok, a few comments on what John posted yesterday and we can put this to bed for good. I would post in the other thread but am not allowed to.

Presumably a typo, I assume it should be 115.2k or is it really a non standard baud rate.

I will double-double check this weekend with an oscilloscope, but I see an extra 0x01 at the end of each message. Any thoughts? Perhaps 0x01 was data length and the checksum is missing.

This may be a ROBOTC bug but byte 10 is detected as accelerometer Y (not X) and byte 11 as accelerometer X (not Y).

So really no checksum with this message?

Why do we have an inconsistent use of the data length byte and checksum byte? Why do the commands from the master joystick not use data length 1 and a checksum? I guess it doesn’t matter but it makes writing a symmetrical message parser harder than it needs to be. Other messages using the same header (0xAA 0x55) on other ports all seem to use the data length and checksum unless they are the crazy 0xC9 … messages.

None of the above is meant to be criticism, I do appreciate the official posting, just looking for feedback on the differences between observations and the spec.

1 Like
#15