How to read information from RS-422 protocol

[constructionworker]

Hello everyone.I am trying to read information from a joystick using RS-422 protocol. When I try to read data from this joystick, I get an output like this. If I move the joystick there is a changing data but it is meaningless. .I don't understand what this data means because I don't use RS-422 protocol very much. How read I XY axis information. How do I decrypt RS-422 packet. I need help with this issue. Every idea given is worth respecting.

[crossrulz]

You will have to read the documentation on the joystick to learn how to interpret the data.  RS-422 only defines the hardware bus, not how the signals are interpreted.  So first you need to confirm it is using a UART packet format as well as the baud rate, number of start bits, number of stop bits, parity, etc.  Then you can start interpreting the data in the packets based on whatever the message formats are defined as by the manufacturer.

[constructionworker]

hello Crossrulz.
Baud rate is 115200. I only know this. There is no joystick data plate, only ISL4489E Transciver is used in the electronic circuit. I know it. Baud rate, number of start bits, number of stop bits, parity, etc. Isn't there any way to interpret data without knowing it clearly?

[RavensFan]

Nope.  At this point you are just receiving a bunch of bits and bytes.  The joystick manufacturer as to tell you what they mean.  And perhaps if you need to send it any messages in order to tell it to send data.

Honestly, it is very unusual for a joystick to be using RS-422 serial communication.

[constructionworker]

Using the RS-422/485 transceiver. The baud rate will probably be 115200. I don't think any data will need to be sent. The manufacturer never shared the information. Isn't there any other way to find the stop bit or parity?

stop bit, parity etc. Is there no way to interpret bits and bytes that came unknowingly?

[RavensFan]

You can do some trial and error.  Guess at the settings and see if they work.  Once you are able to read bytes, you can see if there is anything about them that makes sense.

But if the manufacturer does not have or is unwilling to share information about their own product so that it can be usable to you, then I would avoid buying it.  And if you've already bought it, then just throw it away.

[constructionworker]

I'm not sure, but it seems like I've gotten close to solving the problem.Converting hexadecimal to decimal reveals something logical. There is general noise when only one button is pressed, no noise when moving other buttons or joysticks. Do you have any idea what can be done to eliminate the noise?
The other shows 2 button functions in the same index, do you think this is normal?
What can be done to prevent this?
Another problem is that the 2 buttons are in the same index with the same values. How can I fix this?

[RavensFan]

I don't know anything about this joystick to be able to help any more.  All I can do is offer some observations.

It looks like every message ends on 0D.  That might be useful to know.  0D is the ASCII character for carriage return.  However, I don't think you can trust that as a termination character as everything else seems to be binary data, and thus 0D would be a valid byte elsewhere in the message.

Prior to the 0D you have 8 other bytes that seem to change.  Bytes 5-8 seem to change significantly as you move the joystick to the right.  What does the message look like you move it to the left?  But those same bytes seem to change when you move it forward.  What does the message look like when you move it backwards?  Byte 4 seems to change a bit in all cases.  What do the messages look like as you press each button?

I would expect that buttons probably map to single bits within one of those bytes.  I would expect that a group of bytes (2, 3, 4 of them?) would represent a binary value for the X axis, and another group for the Y-axis.  I would also suspect those are signed integers.

Your configuration is 7-space-2.  That is an odd combination I've never seen before.  Is it possible that another combination is more correct?  Like 8-none-2,  or 8-even-1?  Some combination may appear to work, but you wind up truncating off the highest order bit.  Other combinations might work for some bytes, but give you parity areas for others.  I really suspect that 8-none-2 is more likely to be correct than 7-space-2.

As for noise, I assume you are talking about electrical noise when you press that button.  Perhaps something is wrong with the joystick that is causing noise to be induced on the serial wires when that button is pressed.

[constructionworker]

Sir, I tried the combination you said but the best combination is 7-space-2 because other combinations cannot read the logical data.
I also tried to read this data in lab view and got a printout like in the attached photo. How do you think this happened?
By the way, I do not think that the button I pressed has a problem because when I try to read with a ready-made program other than labview, there is no such problem. I only have this problem when I try to read information with labview.

[BertMcMahan]

Try sniffing the data with the ready-made program. It'll tell you what the configuration is. Figuring out the data itself is a tricky job and you'll have to just do a lot of trial and error.

I'd recommend making a spreadsheet or something. With nothing pressed, record the data 10 or 20 times. If any values change, note what they are- these will probably random noise on the X and Y axes.

Next, try pressing a single button and try to identify exactly what changes. Repeat with multiple buttons and with the different axes.

Unfortunately this is a fairly complicated task. I'm very familiar with serial communications and I'd expect it to take at least a full day of fiddling to reverse engineer a protocol like this one. You could wind up with lots of extra data (like a device ID or checksum) that throws you off.

Any chance someone else has been down this road before? What model is the joystick? If you have a ready-made program for it, you should know at least the manufacturer and probably a model number.

Also: to elaborate on why "RS-422" isn't enough to decode the data. RS-422 is a byte-level protocol description. It can be used for basically any device that needs to communicate. You can send audio data over RS-422, or joystick data, or emails, or pictures, whatever. It's completely data-agnostic.

It's like if I had a spreadsheet with a bunch of unlabeled numbers in it, and I asked "It's an Excel file, can't you decode the data that way?"

Good luck. This sounds like a fun reverse engineering effort.