How to read information from RS-422 protocol

[constructionworker]

 BertMcMahan I tried sniffing the data with the ready program. I am trying to interpret this data with Labview but I cannot read the data clearly, so 2 different button information corresponds to the same index and a general noise emerges.

[RavensFan]

It looks like the first 2 bytes tell which buttons are pressed.

1 00 08   would be 00000000 00001000 binary

2  00 10   would be 00000000 00010000 binary

3  08 00   would be 00001000 00000000 binary

4  01 00   would be 00000001 00000000 binary

5  10 00   would be 00010000 00000000 binary

6  02 00   would be 00000010 00000000 binary

7  00 04   would be 00000000 00000100 binary

8  00 02   would be 00000000 00000010 binary

9  20 00   would be 00100000 00000000 binary

10 00 01  would be 00000000 00000001 binary

11 40 00   would be 01000000 00000000 binary

12 04 00   would be 00000100 00000000 binary

So the order is not obvious to me, but if you take the first two bytes, type cast them to a U16 integer, then AND them with the values above (U16 constants set to hex display), you'll detect if each button is press if the result is greater than 0.

For the axes, it looks like 2 bytes relate to X and 2 bytes relate to Y.  I don't understand the write up you have on the one picture.  Particularly "the income is reset".  Could that be "input"?   Or is your salary reduced to 0 when that happens?  It talks about index and sub-index.

Here is what I think is happening, it is using two bytes of 7-bit values to indicate an integer.  One is high one is low.  If you took the one called "sub-index" and multiply by 128 and add to that the value of "index", you'll get an integer that ranges from 0 to 2047.  Basically an 11-bit integer that has to be broken up between the 7 data bits within the 2 bytes.  It is not obvious to me how those bytes indicate whether the joystick is moved left or right in the Y axis, or up or down in the X axis.

(And why is the up/down axis the "X" axis?  Seems backwards from normal math graphing rules!)

[AeroSoul]

You seem to be on the right path, 0x0D character is carriage return and is often used to end transmission in RS protocols.

If you look at the data in binary you can see that when you move joystick all the way to the right the second to last byte seems to be the highest, same with forward movement the 6th byte seems to be the largest.

Try moving it all the way down and left, then diagonally and see which bytes go up or down. Same with the button presses, check which bytes change. From the looks of it the most you can get is 2^7 from one byte, since the MSB is always empty. That bit might be then used for some button presses. 

There may also be some form of error correction, such as XOR.

[constructionworker]

By the way, the problem with X-Y axis drawing is due to confusion 🙂

thank you for the answers. I am using the attached lab view code to read the information. I do not know if I interpret the information correctly because when you press the 2 buttons on the joystick, there is noise and there is a problem in reading the values of the other button and joystick. There is no problem when reading with a different application.
It needs some help on how to interpret it.

There are two buttons on the joystick, if I press those buttons. As in the photo, an icon is created in the middle of the array and at the same time there is a quick change in values in the string array. What is the cause and solution for this? The same mark appears when I move the joystick.

[AeroSoul]

I think the second to last byte might be error correction code, since it's the same in both cases. The values might be in different places but are the same.

Can't be XOR correction tho, the values don't match.

[constructionworker]

I don't quite understand what you mean by Mr. AeroSoul. Can you explain this a little more? Now I am reading the joystick axis information and button information, but only 2 buttons cause problems because I read the same values from 2 buttons. There is a situation like noise in general. I cannot read the values properly. Could this be due to speed synchronization?

[constructionworker]

mr.RavensFan 

So the order is not obvious to me, but if you take the first two bytes, type cast them to a U16 integer, then AND them with the values above (U16 constants set to hex display), you'll detect if each button is press if the result is greater than 0.-ok

For the axes, it looks like 2 bytes relate to X and 2 bytes relate to Y.  I don't understand the write up you have on the one picture.  Particularly "the income is reset".  Could that be "input"?   Or is your salary reduced to 0 when that happens?  It talks about index and sub-index.-For a little more explanation in the attached picture.

I think it will be a little revealing.

[constructionworker]

Problem not solved. There is still no clear answer to the question I asked for serial reading. Finally, when reading information from the joystick, a mark appears as shown in the picture. I think this is a problem with my reading method, Or should I put resistance in front of the signal pins? please someone help with this.

[rolfk]

---

@constructionworker wrote:

I think it will be a little revealing.

---

From this picture it seems that each axis is split across two bytes, the first byte contains the lowest significant 7 bits, while the second byte contains the highest significant 5 bits. The whole represents a 12-bit integer in two-complements format.

So there are two things to do here:

- combine the 7 bit and 5 bit into a 12 bit integer

- preserve the sign bit correctly in the integer

Since LabVIEW (and most any other programming language I know of) does not support 12 bit integers natively we have to work in the next higher integer space which is a 16 bit integer.

This is one possible way to convert the two bytes for each axis into a counter value between -2048 to 2047 which is the range a 12 bit signed integer can cover. The remainder are the left over 2 bits which may or may not have any meaning in any way.

[RavensFan]

---

@constructionworker wrote:

Problem not solved. There is still no clear answer to the question I asked for serial reading. Finally, when reading information from the joystick, a mark appears as shown in the picture. I think this is a problem with my reading method, Or should I put resistance in front of the signal pins? please someone help with this.

---

That picture doesn't make sense.  Is the mark you are talking about the wide flat circle in the middle of the byte array?  There is no way that LabVIEW could ever show something like that as an element of an array of numbers whether there is noise or no noise.  If there is some sort of electrical noise, it has to exist only within the joystick.  Since the communication is all digital, if there was electrical noise on the serial wires, you would get communication errors on the serial line, not strange but otherwise valid bytes.