4

I am trying to listen to a device which communicates via a serial port. I've built a monitoring adapter and set up a python script, which works really well. I just don't know the exact length and shape of the data stream. The problem is:

  • I don't have any technical documentation on this device
  • I don't know how the data I am receiving is supposed to look, therefore I can't do it using trial and error until the data makes sense

So I have to figure out the parameters of the serial port some other way. I have access to an old oscilloscope. Is it correct that I could do this by analysing the voltage signal in a way similar to the following picture?

enter image description here

I got this idea from my old notes on serial communication, where I wrote:

"The stop bit has a value of 1 and can always be detected, even if the preceding value was 1, because of the stop bits duration of 1.0, 1.5 or 2.0 bit periods."

Is this even correct? And would I be able to do it myself? I would hope to connect the oscilloscope to my computer and look at the signal through sigrok or a similar freeware software. Before I try do to that (the oscilloscope is from 1994 and uses some parallel port unknown to me) I hoped you could give me some input whether this is anywhere near the right approach. Of course I hope that I'm missing something easy to figure out the parameters.

EDIT: thanks to Jot and Tut I was able to measure my baudrate: 19200. However, I am having a hard time dealing with the type and length of bits. I tried to view the incoming data and a serial terminal program, but after altering the settings I am still not able to tell what the correct bit-parameters are.

EDIT2: It's two things my monitoring script in Python reads. Hexadecimal values and ASCII-symbols in between, where the value of a byte equals the value of a printable ASCII-symbol. However, this means that I always get 8 bits at a time, doesn't it? Shouldn't I get at least 9 bits for each byte of data, if at least a stop bit is included? For example for the simplest action of my device I get: "\xf2\xa3", which is 11110010 10100011 in binary. Even if I rearrange the space the start and stop bits or an optional parity bit aren't there

EDIT3: I have to say this is a project for which the main purpose is to learn stuff, therefore I have to linger a bit on the details. I now tried to match the data I've monitored with the raw signals I get from the oscilloscope, even though it's a bit difficult to see the data on the small screen. I've chosen a very simple action for my device and the result is the following picture:

Screenshot (literally) from the oscilloscope

These signal would then, analogous to my first picture, translate to

00100111111011000101

however, as I wrote in Edit2, the data I get by using my Python script (I checked with Realterm as well) for 19200 8N1 is "\xf2\xa3" (Python uses the "\x" to indicate hexadecimal values), which is in binary

1111 0010 1010 0011

This still doesn't add up even if I theoretically include start and stop bits as well as parity bits. If I try 19200 7N1 I get

r# = 0111 0010 0010 0011

which isn't better. Also confusing for me: if I change the setting to include a parity bit (whether it's Python, Realterm or putty) the data I'm receiving doesn't change. Why is that? Shouldn't it change?

Tobitobitobi
  • 53
  • 2
  • 9
  • 1
    Today it is mostly 8N1 (8 databits, no parity 1 stopbit), but old equipment can be 7E1 or something else. Try to measure the baudrate, and after that, just try a number of settings with a serial terminal program. When looking at the data, you should be able to tell if the highest bit is a parity. There are devices that have non-standard 9 bits of data. Let's hope you don't have one of those. – Jot Apr 27 '17 at 10:49
  • 1
    In general, if you take the reciprocal of the minimum pulse width, that will give you the baudrate. – Tut Apr 27 '17 at 10:55
  • Measuring the baudrate was a great idea, now I can be sure of one the numbers. Thanks! The device is from the early 90s, therefore I'm expecting something like "7E1 or something else". – Tobitobitobi Apr 27 '17 at 11:21
  • @Jot: how can I tell of the highest bit is a parity or not? I've tried some settings in TeraTerm, however, because the data is displayed in ASCII, they are all of equal value to someone who doesn't know what to expect. When doing the same in Python, it's the same with hexadecimal values, I just don't know what to expect – Tobitobitobi Apr 27 '17 at 12:08
  • You can't be sure, but if you can capture lots of different characters and see if they all have odd or even parity that would give you a good clue. Early 90s I'd expect probably 8N1, we weren't that prehistoric back then :) – Finbarr Apr 27 '17 at 13:06
  • 1
    And now that you know it's 19200, just read it as 8N1. That will allow you to se the values without needing the scope. – Finbarr Apr 27 '17 at 13:10
  • assume 8N1 capture/log the data as raw hex values then examine them to see if they make sense you can for example post process that data and see if it all has the same parity, if not then there wasnt parity, it is all data. – old_timer Apr 27 '17 at 16:17
  • You know the bit rate. You know that every character is framed by a start bit (known value) and a stop bit (known value and at least 1 bit time but possibly 2 bit times or even much longer.) It should be trivial to just eyeball a sequence and find the number of bits. You will later have to figure out if one of them is a parity bit, though. – jonk Apr 27 '17 at 17:22
  • Thanks for the answers! I think I almost got it. One thing that is still confusing though: it's two things my monitoring script in Python reads. Hexadecimal values and ASCII-symbols in between, where the value of a byte equals the value of a printable ASCII-symbol. However, this means that I always get 8 bits at a time, doesn't it? Shouldn't I get 10 bits for each byte of data? For example for the simplest action of my device I get: "\xf2\xa3", which is 11110010 10100011 in binary. Even if I rearrange the space the start and stop bits or an parity bit aren't there (similar text in edit) – Tobitobitobi Apr 27 '17 at 17:31
  • The stop and start bits are stripped out. Your program only sees what data bits. – JRE Apr 27 '17 at 17:41
  • Ah! I understand, thanks. So, I got the above line with the setting 'no parity bit'. Would this now mean, because I get real values and complete bytes, that this setting is correct? – Tobitobitobi Apr 27 '17 at 17:50
  • It looks like you may have it now. The real test is whether you keep getting reasonable values no matter what the device sends. – JRE Apr 27 '17 at 18:11

0 Answers0