First, I'm not 100% sure were this thread needs to be, so admins fill free to move if I screwed this up!
Ok. I am TRYING to decode data from a Kawasaki Industrial M21 absolute serial encoder from an AC servo motor. Of course, the protocol is proprietary. The goal is to be able to interrogate these encoders with a 20MHz atmega of some kind. Here is what I DO know about the protocol from various sources:
- 1 Mbaud data rate
- 48 bits sent in total
- RS485 link (dealt with)
- Half duplex
- Data is polled from slave encoder
- 13 bit M-pattern data, 8192 bits per revolution absolute position
- 15 bits signed for shaft revolution potion, +/-32,768 revolutions max
- 2 bit magnetic incremental encoder for armature phasing
- 3 bits of alarm data
With it hooked up to a PC via RS485 I have been able to get it to send out a pulse stream to me that I have captured via logic analyzer. The stream "looks" like this:
From were the flags are located, that is 48us between the start and stop positions, so that does match the timing specs I have found. If I assume that there is a 2us "mark" period at the start (AND that that is counted as 2 bits of "data"), that will give me the 48 bits of data IF the data is Manchester encoded (which it does appear to be). If you add up the list of bits send above, there is only 33 bits of actual data which leaves 15 bits of pad/sync/other stuff.
I've done quite a bit of research into Manchester coding and the basics are not that difficult. The problem I am having is dealing with the speed of this signal with a 20MHz atmega. As I am only trying to figure out this protocol at this point, I don't have any issues in capturing the stream and then decoding it in post processing (either on atmega or on a PC).
Where I have hit a bit of a road block is how can I capture a stream of this speed and buffer everything with only 10 clocks between each ts/2 period? The USART is out as it cannot accept a 48 bit frame of any kind (not even the AT90PWM3 which CAN decode Manchester). Does this need to be bit banged? Can a different peripheral do the job (such as the SPI)? Anyone have any experiences capturing bit streams such as this?
At this point, I'm not really sure how to attack it. My gut says to throw faster MCU at it (high clock rates) such as an xMega or perhaps a PIC32 or ARM. But I suspect there has to be a way to do this with an atmega as well and as I have a bit more experience programming those guys, that is what I would like to stick with if possible. So any help would be greatly appreciated!