decoding serial stream with unknown protocol

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gents,

 

My on again, off again project to figure out how to "talk" to some Kawasaki Robotics M21 absolute encoders is, once again, on.

 

This are very nice encoders on the motors that came off a Kawasaki Robotics industrial robot.  The protocol is proprietary and they can't/won't give me so much as a hint as to what is required to talk to these things.

 

I do know a bit about them from a few resources I was able to find online and from opening one up and seeing what I could see (mainly RS485 transceiver...):

  • Power specs and power pins
  • Basic serial protocol and data used:
    • 6 bytes of data sent
    • Half duplex
    • 1 MB/s data rate
    • 13 bit M-pattern absolute position data
    • 16 bit signed rotor position data
    • 2 bit rotor position data (IF I have correctly translated what I have read...  Grain of salt needed, but 2 bits are used here...)
    • 3 bit alarm code data
  • RS485 physical layer

 

I have built a little USB->RS485 adapter and I can get the encoder to respond to a command.  From this, I can get a signal that looks like this:

encoder output

 

From 0.0 to 12us, that is the code I sent to initiate a response (dec 99).  The response starts at 18us.  From looking at this (and hundreds others) image, I have come to some conclusions that may or may not be accurate:

  • The bit time is 0.5us as measured by my scope, so the signal rate is 2Mhz, not 1Mhz.  This implies some form of Manchester encoding.
  • It has a start block / mark block that is 2.5us long
  • The first mid-bit transition is 1us from the falling edge of the 2.5us long mark bit
  • There is NO sync stream (all ones, all zeros or some combo) other than that 2.5us mark

 

I've been working on a method of decoding this with an xmega that I THINK should work based on the very consistent timing I get from this thing and the known frequency.  Basically, I will measure the value at 3/4T and then resync on the bit transition to do it again.  But that is all based on my ASSUMPTION that this Manchester encoded data.  The lack of a sync pattern concerns me a bit, but I don't have much (any) experience decoding Manchester, so I can only base this on the assorted things I have read on Manchester encoding and decoding.

 

So, my best case scenario is that there is someone here who has some experience with these M21 (or the H20) encoders that can chime in with a bit of insight in how to make these thing play well with AVRs.  Baring that scenario, does anyone have any experience with Manchester encoding that does not use a sync stream?  Or heck, does anyone recognize this stream as something other than Manchester?  There is a LOT of assumptions built into that second list...

 

Any help would be greatly appreciated.

 

Clint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First question: what did you do to generate this response?

 

First observation: NOT Manchester. You would not have those long intervals at the same logic state if it were. There is a good Atmel ApNote on Manchester coding and with that, you will see why not.

 

This is a pretty odd bit stream. The 0.5us logic high and low times are quite inconsistent with the rest. But, NOT Manchester.

 

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The picture above includes the command I sent it (starting at 0.0us) AND the response back from the encoder (starting at 18us).  From 0us to 18us is what I sent it to get it to talk to me.  In this case, it was just binary 99 (start bit + 01100011 + stop bit).  While trying to get it to chat with me, I basically connected to it at various speeds around 1Mbaud via RealTerm and then sent it binary bytes (1,2,3,4.....) until I hit 255.  Then I adjusted the speed up or down and tried it again. 

 

Eventually, I found it would always respond to 51 and 99 if the speed was within 5% of 1Mhz.  Given that it's signal is at 2MHz and I was connecting at 1MHz, that "99" I sent just happens to have the correct initial bit patterns to get it to talk.  It is interesting to note that both "99" and "51" both contain 01100 in there binary code.

 

After what I sent it (and I have NO idea what IT thinks that is!), it's response starts at 18us with that first 2.5us positive pulse.  After that single long pulse, starting at 21us, everything is either 0.5us or 1.0us long until the end which can be 11, 00, 10 or 01 combos in Manchester. 

 

 

Clint

Last Edited: Wed. Jun 24, 2015 - 11:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It might sync with a code violation - eg a long pulse. Can you decode the data as manchester and see if you can get any sense from it - eg move the encoder shaft and see the data change?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can see the bits on my scope while sending the "99" code and turning the shaft.  Most all the bits can change except the 2.5us first pulse and the last few bits.  If it is Manchester, the first mid-bit transition is definitely 1us after the 2.5us pulse and every 1us thereafter (which matches the stated data rate).  If I line it up at 0.5 or 1.5us, there are places were I DON'T get a mid-bit transition every 1us, but when it is lined up at that 1us after what I am calling the sync pulse, there is ALWAYS a mid-bit transition every 1us to the end.

 

I think my next step is going to have to be to write a program to decode this thing and send it to my PC.  I could then have it constantly (or say, every 1/10 of a second) send the command to respond and then output it back to the PC.  That should make it much clearer with what is going on while rotating the shaft.

 

Clint

Last Edited: Thu. Jun 25, 2015 - 05:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some freaks like puzzles. FM is manchester, correct? one pulse at the beginning of the bit, and another pulse in the center? Then there is FM, and biphase mark and biphase space. Then there is Non Return To Zero Inverted like they use in tapes. Seems like a table of timestamps and edge directions could be published so the various freaks could feed the data into a program that tries each protocol. I think capturing the shaft turning would be a good data set. Ought to see the data increasing by one dontcha think? 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Two problems with seeing it increase by one:

  1. This is a 13 bit position incoder, so there 8,192 positions per revolution, or 1 step per every 0.044 degrees...  I can't turn it that small.
  2. The position data is encoded in M-Pattern.  Follow on problem is I have not found any documentation on exactly how M-Pattern encoding works!

 

As for FM, first, analog is NOT my strong suite (and some would say neither is digital!), but I always though FM was a MODULATION method (aka: How the signal is carried) and not an encoding method (aka: How the data is carried by the signal). 

 

I should be able to export the signal data from the logic analyzer and post it here for others to dig into to there hearts desire.  Heck give me a moment...

 

encoder test data 99.csv

 

I went and edited out the "99" command sent to the encoder and just had it start at the zero before the first response from the encoder.  My server runs 24/7 and I have pretty reliable internet access, but please let me know if there are any issues accessing it.

 

Clint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am happy, happy, happy!  While doing more research on Manchester coding, I came across this website:

 

http://www.pcbheaven.com/wikipag...

 

In the decoding section, he has a trace from an IR remote that looks very similar to my signal with a large positive sync pulse at the start of the signal.  He goes on and discusses two algorithms to decode it and the second method was pretty much identical to the method I had outlined (no, I STILL haven't fired up AS!). 

 

Seeing that signal made me feel MUCH better about what I have.

 

Clint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A kind of stupid question , just to make sure

 

If you don't move the shaft does it then repeat the same answer?

 

A 1  meter long stick on it, give about 1 mm for each count (one turn on a 1mm thread) , then you should have a change to find a pattern.

Last Edited: Sun. Jun 28, 2015 - 07:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With the brake applied and no attempt to move the shaft, it will repeat the response.  But even with the brake applied, if I twist even lightly on the shaft, the response changes.
 

 

Clint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oooooh Oooooh.... it might be the 13bit gray code right from the encoder. This should have 8192 counts, and the msbit of the gray code is the same as the msbit of the binary position, so turn the thing 1 turn and see if you get 4096 0000s then 4096 1111s in the most significant bit. There is a 1 or 2 line algo to cvt gray to binary by xoring bits.

 

 

Imagecraft compiler user

Last Edited: Tue. Jun 30, 2015 - 04:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately, I'm not going to be able to mess with this for a few weeks.  I'm stuck in bed recovering from knee surgery.  Minor surgery, but the whole keep knee above heart and iced thing is getting old...

 

 

Clint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Get a pad of paper and some pencils. You can decode the waveform into Manchester and see if it makes any sense. Get well.

 

Imagecraft compiler user