Baud rate to Hz help.

Hi,

I have an RS232 string which will be constantly printed as fast as possible, the string is constructed as

XX.XX<CR><LF>

an example is

10.15<CR><LF>

This will be transmitted at a baud rate of 19200. What I need to calculate is how many times a second the value will arrive at the terminal, like Putty or Hyperterminal etc.

I believe that baud rate is the number of character changes per second, or bits transferred. In my example string would the 1 of 10.15 count as one character, and therefore 1 bit? Or would it be 8 bits? 00 00 00 01?

Do you need to factor the carriage return and line feed in as characters?

The equipment in question is a Red Lion Controls PAXP panel meter, setup to use abbreviated transmission which according to the manual is:

BYTE DESCRIPTION
1-12 12 byte data field, 10 bytes for number, one byte for sign, one byte for decimal point
13 carriage return
14 line feed

thanks,

14 characters plus parity and stop bits per transmitted string.
So 14x8 + 1 + 1 = 112 bits per string.
Thus up to 19200 bps /112 bit per string = 171 strings per second.

JesperMP said:

14 characters plus parity and stop bits per transmitted string.
So 14x8 + 1 + 1 = 112 bits per string.
Thus up to 19200 bps /112 bit per string = 171 strings per second.

Click to expand...

thanks.

If it is setup with no parity would it be (14x8) + 1?

Also, the panel meter is a 5.5 digit display. The half digit shows a minus symbol when required. If so the full field would xxx.xx. If you were transmitting a shorter number xx.xx would this in theory reduce the 12byte data field, or would it remain 12bytes regardless?

thanks

I believe the data will be transmitted as ASCII you need to study your ASCII table

If I remember correctly (Decimal49=1, Decimal50=2, Decimal51=3, Etc. Decimal-LF=10, Decimal-CR=13.

So the number 1 would actually be "00110001" this is 49.

DLMUK said:

[..]If so the full field would xxx.xx. If you were transmitting a shorter number xx.xx would this in theory reduce the 12byte data field, or would it remain 12bytes regardless?

Click to expand...

My guess is that they transmit the all 12 data bytes no matter what the length of the value is.
It is possible that thy transmit leading spaces or zeroes if the value is less than xxx.xx long.
The way you describe the format:

10 bytes for number, one byte for sign, one byte for decimal point

Click to expand...

I am guessing that the decimal point value somehow tells where the decimal is supposed to be.
But you absolutely must investigate the manufacturers documentation.
Devices that transmit ASCII strings don't seem to follow any common standard.

JesperMP said:

14 characters plus parity and stop bits per transmitted string.
So 14x8 + 1 + 1 = 112 bits per string.
Thus up to 19200 bps /112 bit per string = 171 strings per second.

Click to expand...

I don't know where 14 characters came from ?

XX.XX<CR><LF> ? if you took the <CR> and <LF> as 4 each, there's still another 5, that would make 13.

But <CR> and <LF> are notations for "Carriage Return" and "Line Feed", each is only one ASCII (control) character.

So the string XX.XX<CR><LF> is only 7 characters long.

but a 5.5 digit display, with sign, would need 7 characters, ( -123.45 ), plus the 2 control characters = 9 per string.

The fastest way of transmitting that using ASCII protocol is by using:-

1 start bit
7 data bits (5,6,7,& 8 are possibilities, but 5 and 6 are very rare)
no parity
1 stop bit

... a total of 9 bits per character !

19200 / 9 (bits per character) = 2133 characters per second
2133 / 9 (chars. per string) = 237 strings per second

It's not quite as simple as that though, the "Stop Bit", between characters, is usually 1.5 or 2 "bits" in length. Worst case scenario is it 2 "bits" long, each character would take 10 bits.....

19200 / 10 = 1920 characters per second
1920 / 9 = 213 strings per second

daba said:

I don't know where 14 characters came from ?

Click to expand...

From this:

BYTE DESCRIPTION
1-12 12 byte data field, 10 bytes for number, one byte for sign, one byte for decimal point
13 carriage return
14 line feed

Click to expand...

It clearly says 12 bytes data plus CR and LF = 14 characters.

You are right about the parity and stop bits being per character rather than per string.

I still say that DLMUK absolutely must get the information from the manufacturer, rather than we speculate about it.

Is the A/D conversion of the meter even fast enough to make 150+ readings a second any more valid than 5 or 10 readings a second?

There is more to this than simple bit transmission time. Will the device serve up values cyclically without prompting or does it need to be polled? It it will serve them up cyclically I really doubt that it will put the head of one string right on the tail of the previous string. There is likely some dead time in there also. It will not be completely straightforward to calculate this value. If the string was 2000 characters long you might have a chance to calculate a transmit repeat rate to within a couple percent. With only 14 characters total the "other stuff" becomes a huge percentage of your total time and is much harder to nail down.

Keith