Maker Pro
Maker Pro

Self-Clocking Data?

F

FyberOptic

Hiya, I've recently taken an interest in interfacing with floppy disk
drives just for the heck of it, and while I've learned a good amount of
stuff from much reading and a topic I posted elsewhere, there's still
something that confuses me, and since I would assume it's a more basic
concept, I figured I should just ask it here!

The thing I'm curious about, as the subject line reveals, is
self-clocking data streams. I keep hearing that encodings such as MFM
are of this sort, but I don't understand how it works. I've read that
it supposedly means the data can be decoded without an external clock,
but I simply can't grasp at the moment how that would be possible. The
data bits would be seemingly random, and in periods where no fluxes
took place on a floppy, there'd be a lack of a clock cycle, and you'd
surely miss bits.

The only thing that comes to mind for capturing every bit is having a
constant seperate clock cycle from an oscillator or whatever, and
dumping the floppy's data stream into a shift register or something on
each clock cycle. But obviously there's no sort of self-clocking by
the data stream happening in that sort of setup that I know of.

If someone could set me straight on this, I'd surely appreciate it!
 
E

Eeyore

FyberOptic said:
Hiya, I've recently taken an interest in interfacing with floppy disk
drives just for the heck of it, and while I've learned a good amount of
stuff from much reading and a topic I posted elsewhere, there's still
something that confuses me, and since I would assume it's a more basic
concept, I figured I should just ask it here!

The thing I'm curious about, as the subject line reveals, is
self-clocking data streams. I keep hearing that encodings such as MFM
are of this sort, but I don't understand how it works. I've read that
it supposedly means the data can be decoded without an external clock,
but I simply can't grasp at the moment how that would be possible. The
data bits would be seemingly random, and in periods where no fluxes
took place on a floppy, there'd be a lack of a clock cycle, and you'd
surely miss bits.
http://en.wikipedia.org/wiki/Manchester_encoding


The only thing that comes to mind for capturing every bit is having a
constant seperate clock cycle from an oscillator or whatever, and
dumping the floppy's data stream into a shift register or something on
each clock cycle. But obviously there's no sort of self-clocking by
the data stream happening in that sort of setup that I know of.

If you have a local clock oscillator 'phase locked' to the incoming data stream,
that works too.

Graham
 
J

Jenalee K.

FyberOptic a écrit :
Hiya, I've recently taken an interest in interfacing with floppy disk
drives just for the heck of it, and while I've learned a good amount of
stuff from much reading and a topic I posted elsewhere, there's still
something that confuses me, and since I would assume it's a more basic
concept, I figured I should just ask it here!

The thing I'm curious about, as the subject line reveals, is
self-clocking data streams. I keep hearing that encodings such as MFM
are of this sort, but I don't understand how it works. I've read that
it supposedly means the data can be decoded without an external clock,
but I simply can't grasp at the moment how that would be possible. The
data bits would be seemingly random, and in periods where no fluxes
took place on a floppy, there'd be a lack of a clock cycle, and you'd
surely miss bits.

The only thing that comes to mind for capturing every bit is having a
constant seperate clock cycle from an oscillator or whatever, and
dumping the floppy's data stream into a shift register or something on
each clock cycle. But obviously there's no sort of self-clocking by
the data stream happening in that sort of setup that I know of.

If someone could set me straight on this, I'd surely appreciate it!

A self-clocking code contains regular level changes that can be used to
synchronise a PLL to. The PLL output is the clock for the data. See
here:

http://r.empstudios.com/Techdoc/Hardware/rll.txt

Thanks,
Jenalee K.
 
E

Eeyore

Jenalee K. said:
FyberOptic a écrit :


A self-clocking code contains regular level changes that can be used to
synchronise a PLL to. The PLL output is the clock for the data. See
here:

Another interesting example is the digital audio SPDIF format ( also the AES/EBU
professional version too ).

Graham
 
P

PeteS

Eeyore said:
Another interesting example is the digital audio SPDIF format ( also the AES/EBU
professional version too ).

Graham

Yet another interesting example is 8B/10B encoding and 64B/65B
encoding. An interesting point about overhead encoded channels is
channel status and control can be sent in-band, called 'comma codes' in
Fibre channel and ethernet, AFAIR and sometimes known as violation
codes in earlier communications equipment.

The basic principle is simple: As a valid code is mapped to 256 of the
1024 possible codes (8 bit data in a 10 bit field), any code not in the
map of 256 data codes is a control/status code.

Another place to look is at EFM (used in CDs) - Eight to Fourteen
Modulation - maps 8 bit data into 14 bit fields.

http://en.wikipedia.org/wiki/Eight-to-Fourteen_Modulation

Something to keep in mind with self clocking data is the notion of
average DC and it's prevention.

Cheers

PeteS
 
B

Bob Eld

FyberOptic said:
Hiya, I've recently taken an interest in interfacing with floppy disk
drives just for the heck of it, and while I've learned a good amount of
stuff from much reading and a topic I posted elsewhere, there's still
something that confuses me, and since I would assume it's a more basic
concept, I figured I should just ask it here!

The thing I'm curious about, as the subject line reveals, is
self-clocking data streams. I keep hearing that encodings such as MFM
are of this sort, but I don't understand how it works. I've read that
it supposedly means the data can be decoded without an external clock,
but I simply can't grasp at the moment how that would be possible. The
data bits would be seemingly random, and in periods where no fluxes
took place on a floppy, there'd be a lack of a clock cycle, and you'd
surely miss bits.

The only thing that comes to mind for capturing every bit is having a
constant seperate clock cycle from an oscillator or whatever, and
dumping the floppy's data stream into a shift register or something on
each clock cycle. But obviously there's no sort of self-clocking by
the data stream happening in that sort of setup that I know of.

If someone could set me straight on this, I'd surely appreciate it!

There are all kinds of self clocking codes. Self clocking codes have at
least one transistion for every bit cell. For example a "one" might be
represented by a transition at the cell edge and another transition at the
cell center while a "zero" would be represented by a transition at the cell
edge only but not the center. In this way, every bit whether zero or one has
a transition that can be used to synchronize a local clock. Long strings of
zeros will not cause lack of sync as it can with non-clocking codes. That is
a simple explanation, there are many variations on the theme.
Bob
 
J

jasen

The thing I'm curious about, as the subject line reveals, is
self-clocking data streams. I keep hearing that encodings such as MFM
are of this sort, but I don't understand how it works.

with MFM (as I understand it) a "0" is like 010 and a "1" is like 101

So, In the middle of the data stream for every bit there are two changes
of value. those changes can be used to keep the clock synchronised.

PCs use special hardware that decodes the data and writes it into the memory.
the Commodore Amiga used less-specialised hardware and did the decoding
using the CPU, I think a 12MHz machine was needed to read HD floppies.
\
Bye.
Jasen
 
P

PeteS

Bob said:
There are all kinds of self clocking codes. Self clocking codes have at
least one transistion for every bit cell.

Only some codes do this - Manchester encoding in particular. A more
general statement is that the average number of line transitions per
unit time is directly related to the data rate - it may be 1/2 (the
most common), 1/4 or whatever one desires. What matters is there is a
periodic signal at some known rate and it's relationship to the data
rate is known.
Of course there's run length issues between transitions, but that's
related to PLL lock requirements (shorter run lengths permit a faster
PLL loop).

Cheers

PeteS



For example a "one" might be
 
V

vic

FyberOptic said:
The thing I'm curious about, as the subject line reveals, is
self-clocking data streams. I keep hearing that encodings such as MFM
are of this sort, but I don't understand how it works. I've read that
it supposedly means the data can be decoded without an external clock,
but I simply can't grasp at the moment how that would be possible. The
data bits would be seemingly random, and in periods where no fluxes
took place on a floppy, there'd be a lack of a clock cycle, and you'd
surely miss bits.

Actually the clock and data streams are embedded in a single stream.

Imagine a 50% duty cycle square wave high low high low etc ...

Now take one low-high sequence and modify it to have 67% low, 33% high
instead of 50-50. This will be '0'

Modify another one to have 33% low, 67% high, this will be '1'.

You now have two events marked as '1' and '0' which can be used to
create a data stream, the falling edges will give you the frequency, and
the low/high ratio the bit values.

This encoding is used in some infra red television remotes.

vic
 
A

Aristotle Eisenglas

PeteS said:
Yet another interesting example is 8B/10B encoding and 64B/65B
encoding. An interesting point about overhead encoded channels is
channel status and control can be sent in-band, called 'comma codes' in
Fibre channel and ethernet, AFAIR and sometimes known as violation
codes in earlier communications equipment.
The basic principle is simple: As a valid code is mapped to 256 of the

Maybe it's your military bearing that makes you prone to giving
out with these bluff statements. It might be quite interesting
to measure.

Cheers, Phil Hobbs Um, buy her book? John hi im azeem from
dubai my profession is techinician i need a circuit diagram for
vcd player dvd player the model no is prs 603 and prs 699 can
give me some explanation about this and how P-channel mosfet
works in general.
 
Top