Serial pulse train.

Pierre

Lifetime Supporting Member
Join Date
Apr 2002
Location
Montreal
Posts
1,669
Does anybody has a link to get a description of serial pulses train VS ASCII values.

The pluses below are AA xx xx (x being hiden values)

How could I "read" them values? Chart? Any links for me to get infos on. Thanks!

cnet9md.jpg

IMG%5D
 
I don't understand the start/stop frames.

serial to ASCII I guess could be done with a LUT (look up table)
I could do it with a PC but with a PLC?

Someone has I'll bet

Rod (The CNC Dude)
 
bernie_carlton said:
I make out the three bytes as 'AA', '03', '01'

I also see it as 1 Stop bit and 8 data bits with no parity.

So they say "The proof of the cooking is in the pudding!"

Mister Carlton you have once again proven how great a "Chef" you are. Having even taken the challenge of demonstrating the hiden HEX values without me mentionning it. You are ahead of me by many lengths.

Now that it is said, where did you get the pulses VS values from.

PS: 19200 BPS 8N1, no handshaking, AA 05 01
 
Thanks for the praise Pierre but I only stated the more obvious 'data bits/parity bit' it could have been 7 data bits with 'space' parity but that is much less used.

The method it the 'piece of paper against the CRT drawing lines with pencil' method.

To start, an RS232 signal, when no data is being sent, is in a negative voltage state (the left side of the screen). This is also called the 'mark' state since in early telegraph times the receiving solenoid was activated holding a pen against a slowly unrolling piece of paper making a continous 'mark'. A lack of this meant that the line was down.

The first transition (to the 'space' state) is the beginning of the 'start' pulse. Since you so kindly supplied the code for the first byte ('AA') which is 10101010, it is obvious that the transition which are later in the code form 1 bit time each. So that means that after the 'start' bit is a single '0' (the '0' is the positive or 'space' state, go figure but that's how it is). By the way, the codes are sent 'least siginifcant bit first'. Following are indeed the rest of the bits '1010101' forming the 'AA' as promised. Following this is a transition back to the 'mark' state forming the 'stop' bit.

One bit time later is the beginning of the next 'start' bit. Continuing to decode bits we see '10100000' then '10000000'. Remembering that these are in 'least significant bit first order' we see that this is '05' (thank you for the correction) and '01' expressed in hex.

The check on the 'data bit/parity bit' guess was that the 'stop' bit and 'start' bits occured exactly where they should be for this structure.
 
Last edited:
Well that was obvious :unsure: I only had two problems... that was the start and the end, even after the good explanation, I still don’t see it:confused:

nice job Bernie
 
I use 'A' and the Ascii ahar '5' as they are the inverse of each other.
BUT, I still do not see the framing in Pierre's chart.

Rod
 
1, 'A' but not '5' - remember that the bits are sent LSB first.

2. Framing - this is not incredibly obvious. The 'marking' (negative) state is the resting state. The first negative to positive transition formes the edge of the start bit. Looking at the bits which follow (a thing we get to do because of Pierre's hint) we can determine 1 bit time. So it's evident that the 'start' rise holds two bit times, itself and the first of the dat bits. If you are the receiver and have been set to the expected structure then you can extract the bits and verify framing by seeing that the 'stop' (marking state) bit occurs in the correct place. If you (the receiver) don't see a 'stop bit' in the right place this is a 'framing error'

[digression]
I worked with a Sharp PLC where a communication problem was flagged as a 'flaming error' in the printed manual and on screen. A somewhat poor Japanese to English translation I'd say.
[/digression]

Can you imagine what the 'auto baud rate seeking' routines go through?
 
Bernie, I read the bit stream as AA 05 01, not AA 03 01. typo ? ?
(I had to print the scope graphic out and label the bits one by one.)

Bit stream as it 'appears' on the scope (positives are 1, negatives are 0)

0110101010010101111101011111110000

'Inverted' bit stream where 0 = positive or space state, 1 = negative or mark,

according to Bernie

1001010101101010000010100000001111

Same inverted bit stream broken up with a visual space between data words

(visual space for analysis only, the space does not exist during transmission)

10010101011 0101000001 0100000001 111
1st word 2nd word 3rd word

Bit stream broken up with first data word parsed by inverted nomenclature:
01101010100 scope
10010101011 inverted

reading the inverted bit stream in order for the first data word:
1 = idle mark (not part of the data word)
0 = start bit
0101 = 5 (hex) but LSB is first, so flipping the bit order makes 1010 = A(hex)
(low order nibble)
0101 = 5 (hex) but LSB is first, so flipping the bit order makes 1010 = A(hex)
(high order nibble)
1 = stop bit

first data word = AA (hex)

2nd data word bit stream (inverted)
0101000001

0 = start bit
1010 = A (hex) but LSB is first, so flipping the bit order makes 0101 = 5(hex)
(low order nibble)
0000 = 0 (hex) LSB first, flip to 0000 = 0(hex)
(high order nibble)
1 = stop bit

second data word = 05 (hex)

3rd data word (inverted)
0100000001
0 = start bit
1000 = 8 (hex) but LSB is first, so flipping the bit order makes 0001 = 1(hex)
(low order nibble)
0000 = 0 (hex) LSB first, flip to 0000 = 0(hex)
(high order nibble)
1 = stop bit

3rd data word = 01 (hex)

remaining 1's are idle marks.
 
An ASCII table might be what he's looking for. I don't know what the AAh character is though.

ASCII is 7 bit, and the standard and extended character sets do not have an MSB bit #8, which is what AA (hex) has.

The sequence of ENQ (05h) followed by Start of Header (SOH) (01h) is not unreasonable comm sequence.

Enquiry (ENQ) – initiates a request (from the master) with the slave stations. (from Automation Direct's DirectNET manual)

Dan
 
Please forgive my ignorance on this subject, but I think I got it, but one last question, you inverted the code, is this standard? If not how did you know to invert it.

To all:
thanks for the info
 

Similar Topics

I have 9 field devices, three METSEPM5110 power meters and six ACE949-2 rs285 interface modules. I want to read this Modbus rtu data through rs485...
Replies
8
Views
269
I have lm9030 program on my toughbook CF-29 cannot get my program to hook up with the serial port.
Replies
2
Views
54
I have a project to setup base programs across multiple PLC platforms that can be used for Modbus communications to various sensors that have...
Replies
0
Views
98
Hello all, I am a college student currently working on my senior year engineering capstone project. As part of this project, I have been given an...
Replies
6
Views
202
Hi, I am using M221 reading from 3 different sensors (modbus rs485) sharing same bus (daisy chain). I am currently using READ_VAR (in total...
Replies
0
Views
67
Back
Top Bottom