Embedded clocks

You do not have to know (except to within a very broad range) the clock rate for a manchester encoded (or many other techniques) to lock up to it.

A Manchester encoded stream is guaranteed a transition every bit, and two transitions per bit for a logical 1 (some schemes did this for zero instead).

That means the minimum transition rate on the line is clk/2 [zero bits] and for (statistically) 50% of the time, clk * 2 [ 1 bits]. Obviously, that means that *on average*, the transition rate of the line is the clock rate. This requires the loop filter of the PLL/DLL to be appropriately set, but within a pretty wide margin.

Self clocking schemes abound, some with inherently wider bandwidths than others, although the issue is more usually the application than the technique.

What was the application (clock rate variation in particular)? We may be able to suggest a suitable technique.

Cheers

PeteS

I'll correct my own mistake: (Blame the cold ;)

For 50% of the time in a manchester encoded sheme, the transition rate is clk/2 and for 50% it's clk. By setting the loop filter at 3/4 clock (or even 5/8) we can lock in on the clock quite easily. (Nowadays - when it was first invented, it was quite a breakthrough and not easy at all).

Certainly there are schemes that are wider band - 8b/10b encoding comes to mind for instance.

Cheers

PeteS

Which means what, exactly ? fs ?

Idealy the decoder would not have a clock, but rather the data

The closest to this would be PWM modulation, widely seen on 1-wire BUS designs. Intel have a SST bus, that has up to 2MBd PWM, but info is sparse.

To demodulate PWM, you need only a dual monostable (or, a Single gated RC Osc + small divider ), and that Osc can Auto-start, so can idle in very low power states.

Normally two time-slots are used, one monstable at 50% bit time, samples the data, and another is set to timeout after no-edges for XX time, which does the frame operations.

With a CPLD, you control both, and can send using SPI with a good fifo ( you need to ensure no false frames, due to host pauses )

-jg

As Jim wrote, the one-wire bus can do this. With this concept you need only one wire (and ground) to power and communicate with a device:

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Thanks to everyone for their posts. Each of the above solutions require timing of the signal and so will not work without a clock (or timer) of a specified rate. The key is "specified". To decode a machester stream you need a time interval of about 3/4 of the bit time in order to blank the edge detector on the edge between bits. That interval can be somewhat broad, but must be known to at least better than 33%. So I can't read a Manchester stream at 10 Mbps and one at 1 Mbps with the same timer. Of course I can design a circuit that will synchronize the clock to a fixed rate bit stream. But that is a lot more complex. I am looking for something that will just plain clock the data across the interface without a requirement to know the frequency whether by measuring it, or a priori.

With one pin you need a clock, or you can use 3 voltage levels: 0, 1/2 and

1. Should be easy to generate with an op-amp and to detect with another one. But I think it is easier to use a clock and normal digital signals.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Why do you need such a loose frequency spec ?

ALL schemes will clearly need some time-element.

What you need is to reduce the Clock _tolerance_ and _power_ costs, to minimal levels.

The one-wire (PWM data) designs change from a classic clock (which draws power all the time ) to a more async-based monostable ( so can idle at very low powers ). It also drops the clock tolerance to quite slack levels, met by the cheapest components. The overhead, is slightly less bandwidth efficency than other modulation methods.

With one wire, the master provides the edges, and the slave the data (sometimes), and the slave can use very cheap / low power / fast wakeup RC oscillator.

one-wire designs are implicitly duplex, and so are better suited than manchester to low cost slave nodes.

They also work well with CAN transcievers, as that is a 'OR' BUS

-jg

I'm not sure I understand this.

Give me an oscillogram of a Manchester-coded signal and I can tell you its clock rate by inspection - unless the data stream is all-1s or all-0s, and that's a corner case that we easily know how to avoid. I need only one different bit in the entire oscillogram and I can work out what's going on with no _a priori_ knowledge of the data rate.

To achieve this I need only two things: (a) some means to measure the time between transitions, to a good enough precision; (b) enough memory to remember what's going on until I see a bit transition from 0 to 1 or back. Condition (a) means, in digital-land, some kind of oversampling and so it implies a *minimum* sampling clock rate; but measurement of edge-to-edge times imposes no lower limit on the data rate.

I suspect rickman is looking for a scheme in which the data line can provide its own clock using some method other than oversampling. Pulse-position or pulse-width modulation does that well enough, as do a whole raft of PSK techniques, but all of them require some kind of phase-locked loop or related means to act as a "flywheel" so that you can detect deviations of the line signal from an average clock that's also delivered by the line.

Once you've introduced a PLL you are, of course, in something like analogue territory; and once you're there, a whole world of modulation techniques opens up. Amplitude-shift keying sounds about as self-clocking as it gets; there are ternary codes (positive-going pulse for 1, negative-going to 0), ....... And in the absence of any interfering signals these schemes are, trivially, self-timed. Of course, as soon as you have other signals present on the same line, the obvious way to sort out one from another is by prior knowledge of the clock frequency. Ask the radio guys about that - they are probably likely to speak of a "carrier" rather than "clock", and they may talk about "tuning" to choose a given signal!

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Actually, that is not correct. Here are two sequences sampled at 1 MHz. Please tell me the clock rates.

0101010101010101 0011001100110011

But I acknowledged that you could "measure" the data rate as long as the bit stream allows for that.

Pulse position and pulse with modulation still require a time measurement which requires me to have a time reference on the receiver.

If I am going to require a time reference at the receiver the simplest scheme I know of is just async serial data with a start and a stop bit. No point in using Manchester encoding if I am transferring the data over a wire just a few inches long.

The problem is lack of pins. We are looking at a situation where we don't want to make a connector any larger. We need to multiplex two separate bidirectional serial data streams and four discrete signals over four or less pins. I was thinking about ways of doing this and realized that I had to provide a clock in the decoder. So I either have to use a pin or I have to add an oscillator to the decoder. Since the decoder will be in a cable, I need to keep it minimal.

Actually, decoder is a misnomer since it will have to both send and receive. So I don't see any way to get around the need for a timing reference, either on a pin or by supplying an oscillator. Most likely it will be on a pin. Right now I like the idea of using I2C, but I will need to perform a detailed analysis of the tradeoffs vs. standard async with separate clock, I2C, SPI and Manchester encoding. I see there are some very small packages for CPLDs, but they don't have much logic in them. I don't know if I can design such a transceiver in 64 logic cells.

What about a synchronisation pulse or word at the begin of every transmission? The fast clock sources a counter, that has to be active, while synchronisation pulse / word is been received. (In other words: The length of the sync pulse / word is measured - the reference time interval.) After this you know (with some error) the frequency of the incoming data stream.

All you need is a short time stable (long time unstable) oscillator (RC oscillator). For every transmission a new sync pulse / word is needed.

This kind of sync pulse / word is used for RFID transmission from interrogator to tag.

With a manchester encoded data stream it is furthermore possible to stay synchronized. During reception the sync machine may work too and if a data symbol is received that has equal length to the reference time interval the new measured length of this symbol may be used as new (re-synchronized) reference time interval.

The disadvantage: You need a fast clock - fast enough for even your highest data rates.

Ralf

A serial data protocol like RS232 needs exact timing on sender and receiver side. With the 1-wire protocol you need only one exact clock from the master, the slave can use inexpensive RC components for timing and clock.

I've just implemented a VHDL program for reading the unique id of the DS2432, which sits on my Spartan 3E starter kit. Some real-time logic analyzer data:

As you can see, the timing precision of the device can varying by nearly a factor of 2 and it would be still possible to communicate with it.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Maybe you could use a microcontroller, like the MC9S08 from Freescale, which I've used in a project: It is inexpensive, has A/D converters integrated, so you don't need to use extra analog pins for the discrete signals, I2C is implemented in hardware on the controller and it is about

1cm^2 wide, so it should fit in a cable (no other external components are required, because it has lots of flash integrated and can generate the system clock internally, if you don't need crystal precision). Then the four pins of the cable would be: Vdd, Vcc, I2C data, I2C clock.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

I can't because (a) I don't know whether the data stream is too fast for me to measure with 1MHz, and (b) assuming there is no aliasing going on, both streams have no data transitions in them. I carefully pointed out in my post the need for (a) sufficiently fast sampling, and (b) a variety of bits in the data stream.

And surely, if I can measure it, I can then demodulate it?

[...]

I don't really know what you mean by "a time reference". My point about measurement is that you can demodulate ANY data rate up to some upper limit determined by the time resolution of your receiver, however that may be determined. (There was an interesting discussion about the relationship between that limit and the resolution - is the maximum data rate 1/3 or 1/4 of your clock rate??? - but that doesn't affect my argument.) You don't need any prior knowledge of the data rate whatsoever, except to be sure that it's slower than your upper limit.

Do I infer that you're looking for a scheme in which the clock can be extracted with NO timing components at all in the receiver, i.e. by combinational decoding of the data line? If so, I'm pretty sure it can't be done with any 2-level line discipline; but as soon as you permit 3-level signalling, I think it's possible.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

I've added it, with some more explanation, to the Wikipedia page:

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

If you *know* it's Manchester coding, and have *no idea* of the clock rate, the problem can be solved if you can afford to spend some time framing up. It's harder if you instantly need to decode the first bit.

Basic approach is to measure the times between transitions, compare several successive transition intervals, and classify them as "long" or "short" compared to each other. THEN take a mean value, apply blanking (clock recovery), and start framing up.

(If you need to retroactively decode the first bit, you'll need to store and re-visit the first few transition times. This may be easier with the assistance of an embedded CPU)

There will need to be some constraints on data, otherwise an infinite sequence of '0's or '1's would take infinitely long to decode. In SP/DIF or EBU/AES digital audio for example, this comes in the form of an extra-long transition interval (1.5 bit times) during a preamble, the trailing edge of which is guaranteed to correctly sync the clock recovery circuit.

This approach should allow that - given some quiet time between different streams, to enable you to recognise a switch in rate.

- Brian

Where are the "different" bits specified by Jonathan in that sequence? These are both sequences of *identical* bits - all 1's or all 0's (when stripped of their clock), which Johnathan already covered.

- Brian

I am familiar with how to recover Manchester data. The problem is that you *do* have to measure the clock rate or know it.

The thread has broken into two discussions. One is about how to recover Manchester data and the minimum rate clock to use. The other is about self clocking data encoding and whether you can decode it without a time reference. In reality there is not a practical way to do that. I had not given the question much thought when I posed it and I see now that all the "self clocking" schemes are framed in some rate and the clock is recovered given a reference.

Yes, you can in essence construct a very wide range PLL to decode a Manchester signal. It still uses a time reference and a very complex one at that. I was actually looking for a simple way to decode a combined data and clock signal without having a time reference. For most practical purposes this is not doable.

An analog of what I would like to do is the I2C bus. It is designed to work at any rate down to 0 Hz. Of course it uses a clock separate from data. It would be nice if that could be done on one digital wire rather than two. But I see that this is not practical without going to multiple voltage levels or adding a reference clock.

This is not quite the simplest.

It imposes clock tolerance requirements, and is half duplex, so the Transmit has to generate it's own clock.

If you want to ease that, you can do something like the LIN bus, which gives a auto-baud pre-amble, but that is getting complex for CPLDs.

Many TV remote's use manchester, and they do that to allow the use of RC clocks, and straight from battery operation.

If you want the simplest scheme, in a CPLD, use one-wire, because that is duplex, and does not need to generate a TX clock, just a Tx time slot ( which can be monostable derived ).

If you can get up to 2 wires, then i2c & variants are a widely used standard, and it does not take too much CPLD resource.

There is something of a flurry of PowerControl busses being released at the moment, some are one wire, and some are 2 wire. Geberally, they try to be faster, and more low voltage tolerant, than i2c.

-jg