[bluenone]

Dear Bobs,

Thanks for your responses.

I couldn't understand some of your comments

Your data grab seems to start with a data value of 10101010 for synchronisation then have about 4 data values of 00000000

When I look at the picture I see 11001100 first not 10101010 Do I miss something.

Also what do you mean 4 adata values of 00000000 ? There is no back to back eigth zeros there ?


You see I attached a general serial port pics and The baudrate it mention is calculated with one bit not with 2 bits. And plus When I set the baudrate to 4MHz on embedded side datas dumped datas were not stable But When I set it to 8MHz dumped datas were pearly Actually I could not get precise datas with any Baudrates except 8MHz on embedded side. So I may insist that the baudrate is 8MHz ? Do you have any comments ?

- When You look at the signal can you be sure it is manchaster ? I have no knowledge about that. I think you have ?

I update the osc. screen with period explanation

[bluenone]

Dear Bobs,

Now I understood what you want to say. You looked at the bits as they are manchaster coded.

I frame the bits as they are manchester. Please see the attached file. I think it is more comfortable than before to understand the bits now.

In addition there are some mismatch with your comments I guess. Can you repeat your comments with the new framed and colored datas ?

best regards

[bluenone]

Dear Bobs,

- I guess start and stop bits are also manchester coded. Am I right ?

- I want to add one information. When there is no transmission I mean that DE pin is low, servo processor continuously sends 10101010 without start or stop bits.
With manchaster way it means 10101010= 11111111

So If I see a transmitted data like 10101010 ==> I think that it means a
delay between transmitted bytes. Am I right ?

Extra question:
When you get the datas from MRJ2S What is the UART data format (
8bit = ?
Stop bit = ?
Parity = ?

[bobs bots]

Hi Bluenone.
OK I see you found the wikipedia entry for manchester encoding?
Manchester code - Wikipedia, the free encyclopedia

With most synchronous data transmission methods , you would transmit a clock signal on one wire (say at 4MHz) and data on a second wire say at 4mbits/sec.
With manchester encoding you use just one wire, and EXOR the clock and data together
so now you are transmitting symbols at 4million symbols per second. so a data value of 1 is represented by a 1 for 125ns, followed by a zero for 125ns, likewise a data value of 0 is represented by a 0 for 125ns, followed by a one for 125ns .
So if I want to send a data byte of 1 .. 0 .. 1 .. 0 .. 0 .. 1 .. 1 .. 1
I would send symbols of...............10 . 01 . 10 . 01 . 01 . 10 . 10 . 10

The problem with receiving manchester coding is, that it you could possibly resynchronise your clock on the wrong edge of the symbol. hence it is customary to start a block of manchester data with data values that only have edges in the middle of the symbol.
A data value of 10101010 does this. Normally you would not try to interpret the synchronising part at the beginning of a transmission as "bytes" you could have 40 or more of these synchronising symbols

The IEEE 802 format just inverts the original definition, as it is easier to understand:
An up transition in the middle of a symbol is a 1 and a down transition is a 0.

I've attached a marked up version of your picture, I've reconstructed the clock as red lines, so you are looking for a positive edge at the clock for a 1 and a negative edge for a zero.

My interpretation looks different from yours,
it looks like you have not sampled the data at exactly the right rate as it seems to slip.
Your colored interpretation has blue bold 1's that I would have called zeros

You data seems to have alternating ones and zeros , then goes to several frames that look like 100000 , I would normally guess this as a start bit and a zero data byte, but you dont have 8 bit data so it's a bit odd.


re your query:
When you get the datas from MRJ2S What is the UART data format (
8bit = 8
Stop bit = 1
Parity = none

Cheers, BobT

[bluenone]

Thanks bob,

It is a hand made oscillocope screen because my osc doesn't support a PC connection.So I did it in mspaint. Because of that the datas are not at exactly the right rate But you can trust the picture I control everybit nearly ten times

Actually The servo asks too many things to encoder and encoder replies are confused the datas. So I made this pictures with the basic command. This datas are sampled when there is no encoder and when the servo search the encoder if it is there or not. So this is the smallest command on the communicaton line.

I'm reading your comments now. I used RS232, I2C or SPI to many times on my boards but manchester is strange to me. So I have to read your comments deeply


thanks and wait for my new replies

[bluenone]

Bobs,

You really change the structure in my mind. You mean I should not look at the 10 for 1 and 01 for 0 .

I should look at the clock edges as a reference and I'm confused at this point

Can you make a new picture explains the bits detail.
Just for first six bytes will be enough. I couldn't understand the edge passings

best regards
Ertan

[bluenone]

Ok here is the result. I give it up

I found a device named JZDP-xxx for yaskawa servos. It is a serial converter device for old style linear encoders. It converts A-B standart encoder signals to suit yaskawa servopacks like mine SGDH servopacks. I could't find its own datasheet but I found its technical properties. Please see the attached files

This device is directly connected to CN2 connector. CN2 is the motor encoder connection to yaskawa. In its technical properties output type says
"HDLC (High-level data link control) protocol format with Manchester codes"
I'm pretty sure that the servomotor encoders is the same format too. Servomotor encoder connection is made to CN2 like this device. Because of that Servomotor encoder outputs and this JZDP output must be the same format.

I give it up becaue "HDLC + Manchester encoding" is a big challenge I guess. I catch something from HDLC documantation like there must be a 0x7E('01111110') as a frame delimeter but there is no 0x7E on oscilloscope datas I get. I'm really stuck. I found everything but to built such a converter is a big challange.

My conclusion:
1. Data format is : HDLC with manchester encoding
2. Baudrate is 4MHz
3. To built such a communication system FPGA should be needed

I want to share my motivation why I'm struggling with these serial datas. We are a technician group supports machines that have yaskawa servos and encountered with AC.9 error too many times up to now. It is an encoder communication alarm code and believe me 100 servo comes within one year with AC.9 error. We can solve the general noise problems or IC damages but there were two servopacks make me crazy with their unique AC9 problems. Here is what I got from these damaged servopacks

When I look at the communication line with an osciloscope I see that
1. the servopack sends "are you there" command to encoder. (The command I share in previous posts)
2. Encoder sends a reply.
3. Servopack accepts the reply and sends other commands to encoder like give me your datas
4. Encoder replies to
5. Within 100 msn servopack gives AC.9 error and start to send are you there command to encoder
6. Encoder replies like article 1
7. But servo didn't accept the replies. It still sends the are you there command continuously
8. If you just unplug the encoder and plug again routine from 1-7 repeats but again servo gives AC.9 error
9. Summary: Although servo and encoder is communicating, servopack gives AC.9
19. I compared with the worked servopack+encoder with damaged one and datas are the same. So there shouldn't be an AC.9 problem

The AC.9 problem motivated me and I thought that I can make an encoder simulation win32 program that runs on a PC and shows me raw communication datas.
- First I thought that it is a serial data
- Second I see that it is a manchester serial data
- Now I see that it is a HDLC with manchester encoded.
- If I continue believe me this will go to the anchient encoding techniques

[bobs bots]

Hi Bluenone,
I've actually only used manchester encoding once myself in a radio link, But i've been aware of it for a while.
OK I think your HDLC + Manchester looks promising.
If I look at my earlier data, and invert the ones and zeros , it looks more like this:
<sync characters> ...<HDLC flag> <5 ones + stuffing bit> <5 ones + stuffing bit> <5 ones + stuffing bit> <HDLC flag>
0101010101010 .....01111110 .......111110...... 111110...... 111110...... 111111
So the data frame is 15 ones ?
Seems a very small frame? I'm guessing this is a broadcast message " hello anyone out there"

OK If I read your whole response in the last post , it seems that what you can observe on the connector pins is what you expect, therefore my guess is that the problem occurs between the connector pins and the internals of the servopack controller, so the controller doesn't see exactly what's on the pins. This is most likely ESD damage of some sort

PS I Use an LA1016 logic analyser that plugs into a USB , it can also decode protocols like UART, SPI , IIC, CF cards, manchester, miller, modbus, 1 wire , SSI, wiegand

Cheers, BobT

[bluenone]

Dear Bobs,

Thanks for your last explanations. You know the HDLC ! Do you have any unskilled topic

OK I understood it but need help to built a communication system plan.

1. What is the purpose of the sync signal. Will I use sync bits in my embedded side for syncronization purpose. Can you explain this like explaining for a beginner.

2. Can you repeat the manchester signal conversion routine that you did in older posts with my Osc datas. I couldn't follow it there are too many lines red and blacks for the clock creation and I didn't understand it Sorry for this. Just for first bytes will be enough.

3. In your opinion which method should I built on the embedded side

I do my embedded works on one of my own design that has Texas new Microcontroller Stellaris LM3S9B92 on it.
It can run at 50MHz and plus a powerful MC. I could send RS232 datas at 10MHz baudrate.(checked with an oscilloscope)

I have something in my mind. Please see below;

First method
- Connect this data to a standart I/O of a microcontroller. Do not connect
it to an UARTG or SPI port.
- Dump all of the bits to a huge array
- After that run an analyze tool like you do on the paper and show the results

Second method
- Connect this data to a standart I/O of a microcontroller. Do not connect
it to an UARTG or SPI port.
- First make a syncronization with sync chars (I didn't understand from your mails how I
can built a sync routine)
- After that dump the datas and analyse them in real time for HDLC+manchaster
- show the results

Third method
- Your suggestion ???

thanks again

[LBodnar]

bluenone,

I have tried to replicate your signal on a Yaskawa servo motor link and have not received any response from it. I have tried inverted signal as well but also got nothing. Is it a full frame? Timing is 4Mb/s.

Any help in getting encoder to reply with some info is appreciated.

Thanks
Leo

[smnv]

Anybody decoded format of Yaskawa encoder protocol?

Example of log data in HEX that encoder sending to driver:

7E 01 DF 15 6C C5 31 05 14 B0 C1 19 7C 3B D4 F9 0D 0 0 0 0 0 0 0 55 55 3E DF F7 F5 51

7E 01 DF 15 58 C8 1D 08 14 B0 C1 19 7C 5F 21 F6 1B 0 0 0 0 0 0 0 55 55 3E DF F7 F5 51

7E 01 DF 15 48 CB 0D 0B 14 B0 C1 19 7C 9F 12 F5 1B 0 0 0 0 0 0 0 55 55 3E DF F7 F5 51

7E 01 DF 15 38 CE 7D 1B 28 60 83 33 F8 AE CA F6 1B 0 0 0 0 0 0 0 AA 2A 9F EF FB FA 28

BF 80 EF 0A 92 E8 74 08 0A D8 E0 0C BE 1B 42 FC 06 0 0 0 0 0 0 0 AA 2A 9F EF FB FA 28

BF 80 EF 0A 0A EA EC 09 0A D8 E0 0C BE F1 1D FA 0D 0 0 0 0 0 0 80 AA 2A 9F EF FB FA 28

BF 80 EF 0A 80 EB 62 0B 0A D8 E0 0C BE 95 5D FC 06 0 0 0 0 0 0 0 AA 2A 9F EF FB FA 28

BF 80 EF 0A F8 D8 B5 19 14 B0 C1 19 7C AB C6 FA 0D 0000000 80 55 55 3E DF F7 F5 51

7E 01 DF 15 DC DC A1 1C 14 B0 C1 19 7C 17 0A F9 0D 0 0 0 0 0 0 0 55 55 3E DF F7 F5 51

7E 01 DF 15 CC B7 23 5F 50 C0 06 67 F0 4D 13 E9 37 0 0 0 0 0 0 0 AA 2A 9F EF FB FA 28

BF 80 EF 0A 5C F1 3E 22 14 B0 C1 19 7C 17 9A F9 0D 0 0 0 0 0 0 0 55 55 3E DF F7 F5 51

[rene-dev]

We manages to figure this out, STMBL now supports Yasakwa encoders. implementation: https://github.com/rene-dev/stmbl/bl...a.comp#L90-L98

Rene