Partner joystick communications protocol

  1. 4 years ago

    jpearman

    23 Jan 2012 Moderator, ROBOTC Tech Support Rockstar, Los Angeles 8888

    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 :)

    Enjoy

  2. tutman96

    23 Jan 2012 Duluth, GA 675A

    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. jpearman

    23 Jan 2012 Moderator, ROBOTC Tech Support Rockstar, Los Angeles 8888

    @tutman96 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.

    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.

  4. Imnotabot

    23 Jan 2012 Philadelphia, PA KTOR

    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).:D

  5. jpearman

    23 Jan 2012 Moderator, ROBOTC Tech Support Rockstar, Los Angeles 8888

    @Imnotabot 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).:D

    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.

  6. JVN

    23 Jan 2012 Moderator, VRC Q&A, OLC Q&A, League Play, Teachers/Coaches, Event Partner, Worlds Q&A, VEX Tech Support Greenville, TX VEX Robotics, Inc.

    @jpearman 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.

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

  7. Imnotabot

    23 Jan 2012 Philadelphia, PA KTOR

    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. jpearman

    23 Jan 2012 Moderator, ROBOTC Tech Support Rockstar, Los Angeles 8888

    @John V-Neun I thought you just said you enjoy figuring out how things work? :)

    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.

    http://www.vexforum.com/showthread.php?t=24

    http://www.vexforum.com/showthread.php?t=172&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 :)

  9. JVN

    24 Jan 2012 Moderator, VRC Q&A, OLC Q&A, League Play, Teachers/Coaches, Event Partner, Worlds Q&A, VEX Tech Support Greenville, TX VEX Robotics, Inc.

    @jpearman So I hope you will surprise me John and let out a few secrets :)

    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

  10. jpearman

    24 Jan 2012 Moderator, ROBOTC Tech Support Rockstar, Los Angeles 8888

    @John V-Neun I was just joking with you.

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

    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.

    Any information on any of the protocols would be appreciated.

    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

    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.

    -image-

    OSX version available for download here.

    Win32 version available for download here.

    Enjoy

  11. JVN

    24 Jan 2012 Moderator, VRC Q&A, OLC Q&A, League Play, Teachers/Coaches, Event Partner, Worlds Q&A, VEX Tech Support Greenville, TX VEX Robotics, Inc.

    Official information here:
    http://www.vexforum.com/showpost.php?p=253945&postcount=3

  12. Thanks john for releasing such detailed information. Jpearman, how's that foot taste? :P

  13. jpearman

    25 Jan 2012 Moderator, ROBOTC Tech Support Rockstar, Los Angeles 8888

    @greyhybrid Thanks john for releasing such detailed information. Jpearman, how's that foot taste? :P

    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 :)

  14. jpearman

    26 Jan 2012 Moderator, ROBOTC Tech Support Rockstar, Los Angeles 8888

    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.

    The following is the interface protocol between the Primary and Secondary Joystick. The baud rate is [COLOR="Red"]119.2k[/COLOR] with 8 data bits, no parity, 1 stop bit and no flow control.

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

    The Primary Joystick sends this 3 byte message to the Secondary Joystick @ ~250ms rate:

    Byte 0 0xAA - Sync byte 1
    Byte 1 0x55 - Sync byte 2
    Byte 2 0x3B - Status

    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.

    Byte 10 0x?? - Accelerometer X
    Byte 11 0x?? - Accelerometer Y
    Byte 12 0x?? - Accelerometer Z

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

    Byte 0 0xAA - Sync byte 1
    Byte 1 0x55 - Sync byte 2
    Byte 2 0x3B - Status Reply
    Byte 3 0x02 - bytes to follow
    Byte 4 0x?? - Version Number
    Byte 5 0x?? - Calibration Info (0xDE Calibrated

    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.

 

or Sign Up to reply!