I am trying to use the OPB9000 (there is actually an article on it here). I am trying to wrap my head around Manchester code. I get that we are looking at transitions, but what I do not get is how the clock is determined. I keep seeing references to a clock, but how does the device know what the clock is if it is simply XORed with the data? On my end, what do I need to do to ensure the data gets sent correctly? How does the device know what the actual clock frequency is? how do you ensure the data is always read on the edge?

 

You derive a clock from the transitions with a phase locked loop. The number of time slices you can go without a transition limits the bandwidth of the required phase lock loop. Inserting extra transitions in the bit stream is called "bit stuffing". Once the loop is locked, it makes small corrections by continuing to look at the incoming transitions.

https://en.wikipedia.org/wiki/Clock_recovery
https://en.wikipedia.org/wiki/Bit_stuffing

 

There's a good article on Manchester decoding here. Another article here. Googling "manchester decoder" gives lots more references.

 

OK, i think I get it. It is easier to think about when you just tell yourself to ignore what the previous state it and just do the needed transitions. I am guessing that the clock is never completely consistent? Kind of glad i would not have to come up with a circuit to decode this. Even though there are lots of circuits out there, it seems like a beast to come up with and test. I am guessing that with advent of digital comms, the uses are few and far between?

 

Rather than guessing, I recommend reading and making an effort to understand. It's really quite simple.

Contrary to your guess above, Manchester coding is widely used. Here's the datasheet for an HD-6409 Manchester Encoder/Decoder chip, which has seen wide usage. Page 6 has a very clear explanation of how Manchester works.

 

I was just saying that when you look at the logic diagram flow, its gets confusing because you see state transitions and try to correlate everything just by seeing a pattern/waveform. In reality, that mind set gets you more confused because all you care about is the actual transitions and not what the previous state was.

You are correct, it is simple once you get the hand of it. I would have never guessed that this was still widely used, though. What industry is this used a lot in?

 

I would have never guessed that this was still widely used, though. What industry is this used a lot in?

Self-clocking data transmission codes such as Manchester are used practically everywhere, in some form or other.

The attached contains some additional good reading.

 

OK, i think I get it. It is easier to think about when you just tell yourself to ignore what the previous state it and just do the needed transitions. I am guessing that the clock is never completely consistent? Kind of glad i would not have to come up with a circuit to decode this. Even though there are lots of circuits out there, it seems like a beast to come up with and test. I am guessing that with advent of digital comms, the uses are few and far between?

It's not that difficult to decode. I used to work for Hewlett Packard as a technical consultant when they were a test and measurement company. I designed automatic test systems for all kinds of customer products. One of these was an aicraft emergency radio beacon which was driven by a battery that was activated by contact with water.
It transmitted a radio signal that was modulated with Manchester code.
The problem that I ran into was that when the battery was activated, the voltage increased from 0 to full voltage over about 20 seconds. During that time, the code was transmitted and the frequency of the code started at round 5 bits per second and ramped up to over 500 bits per second.. The first 20 seconds of the transmission contained the beacon's identity and had to be read and decoded.
I had to be very creative to read the code with such a dynamic clock but I succeded, using Instrument Basic. As far as I know, that test system is still being used regularly.

 

The first 20 seconds of the transmission contained the beacon's identity and had to be read and decoded.

Seems like it would have been simpler to delay the transmission until the battery is up to voltage.
Or is that first 20 seconds somehow critical?