CODEWITHSUNDEEP
binaryserial-porthextranslate
Alex
Alex

Reputation: 1101

How to interpret output of COM port?

I have a device outputting through a COM port. When I read it in a COM interpretter, such as PuTTY, I get a nice-looking output such as

+0.000E-3

However, when I try to read it through C, I get some binary which I don't know how to interpret. For example, the above output comes out to 0aa6 b52a0925. Another output of +1E+9 comes out to 0a 6aad2aa5. I don't know how to interpret anything in between, because I can't get a stable enough output to be 100% sure that's what it means. For example, 0a6a09 d4a669a5 is either +9.303E+0 or +9.304E+0. Also, +0.0139E-3 likely maps to either 0aa6b52a 534c0925 or 0aa6b52a a64c0925 or 0aa6b52a 264c0925. I don't even understand why some outputs are 5 bytes, some 6, some 7, some 8, and some even 9 bytes. But when an output is longer, then the output tends to be shifted to the left. In other words, if

  0aa6 b52a8925  is +0.000E-3, then
0a6a69 54a60925  and
  0aa6 b52a094b  and
0a6a69 54a6094b  and
  0aa6 b52a2925

are values close to it -- probably -0.000E-3, +0.001E-3, -0.001E-3, and something else, respectively.

How can I convert the binary output of the COM port into something nice like the PuTTY output? Alternatively, is there a utility that works in Windows 10, where I can switch between the binary view and the formatted view, so I can try to find the pattern that's used?

I am using the standard settings:

Parity: none (parity bit 0)
Number of data bits: 8 (7 data + 1 parity bit)
Number of stop bits: 1

EDIT: I found another reliable reading: +0.015E-3 -- however, its binary output is also 0aa6 b52a0925, same as the +0.000E-3. So, there is something else going on here, which I am not aware of.

---- my analysis of it ----

Because the first bit of the next-to-last byte varies so much, I guess that it is probably a check bit. Based on the 7-data-bits setup, this would place the first bit of every byte as a check bit. In other words, I would have to take away the most significant bit of every byte. In this case, 0a 6aad2aa5 goes through the process of:

0000 1010 0110 1010 1010 1101 0010 1010 1010 0101
x000 1010 x110 1010 x010 1101 x010 1010 x010 0101
000  1010 1101  0100 1011   0101 0101  0010 0101
        ad         4b          55        25

And without seeing something close to it, it's still hard to figure out how this could become +1E+9. Similarly, 0aa6 b52a0925 goes through the process of:

0000 1010 1010 0110 1011 0101 0010 1010 0000 0101 0010 0101
x000 1010 x010 0110 x011 0101 x010 1010 x000 0101 x010 0101

At this point, I realize that the last bytes (other than the check bit) in both of these are identical: 010 0101. But in the check bit in the second case is a 0, and in the first case it's a 1. So clearly I am doing something wrong.

Also I tried the other way around. I know that 9 is 1001 in binary. So if I know that the value comes out to +1E+9, then I looked for a 1001 in the binary, and tried to make sense of what the rest of it would mean; but that didn't come up with useful results. I thought, maybe the bytes are little-endian? Maybe the bits are in reverse order? And still I couldn't figure it out.

And I am having trouble finding COM communication standards on-line to help me resolve this question.

Upvotes: 1

Views: 60

Answers (1)

Alex
Alex

Reputation: 1101

Thanks to @Mark Ransom's comment, I realized that the Byte size = 8 setting in C meant that, there are 8 data bits, and one parity bit; on the other hand, on my machine the Number of data bits: 8 explicitly said 7 data + 1 parity bit. As a result, some data bits counted as check bits, and vice versa, with the bytes that don't match the parity getting omitted. This was the reason that some outputs were 5 bytes, some 6 bytes, some 7 bytes, some 8 bytes, and some 9 bytes -- when the actual length should be a bit longer -- 11 in Mark Ransom's example, and longer yet in other cases.

So I changed the code to say Byte size = 7, at which point the output started looking a lot more familiar. It turned out that what Mark Ransom said was correct, other than an added 0d 0a on the end. And my output was in fact reversed -- so the 0a at the beginning of every line in my output corresponded to the 0a at the end of every line in the real output. (and in fact, my intuition of the first bit of next-to-last byte being a check bit was correct -- just it did not translate to first bit of every byte being a check bit).

Upvotes: 1

Related Questions