10 Apr
1999
10 Apr
'99
5:16 a.m.
Tim wrote:
I think you're confused as to what I was
disagreeing with, and
that's probably my fault for not explaining myself more clearly. I was
disagreeing with what I believe to be your assertion, Eric, that
you can take any FM data channel, pump about 50% more data through it with
GCR, and pump twice as much data through it with MFM.
I don't think I ever asserted that.
At first glance, this might lead you to believe that
the bandwidth
needed for a FM encoding that gives you a data rate of 250kHz
will also support a MFM encoding at 500kHz. It isn't this simple;
if you do a Fourier transform of the MFM stream you'll see that you
do indeed more bandwidth for MFM.
I thought about this for a few minutes. Ignoring rise and fall times,
for 250 kHz FM, I expect to see spectral peaks at 250 kHz and 500 kHz.
For 500 kHz MFM, I expect to see peaks at 250 kHz, 375 kHz, and 500 kHz.
Therefore, it seems to me that a channel with reasonably flat response from
250 kHz to 500 kHz should be able to handle either 250 kHz FM or 500 kHz
MFM.
However, since you've got me curious as to whether there's some hole in this
reasoning, I've just put together a C program to simulate FM, MFM, and Apple GCR
coding, for all-zeros, all-ones, random, and "6db6" data, with adjustable
resolution and edge rates. (What shape should the edges be, and what are
reasonable edge rates for this analysis?)
Now I just need to find suitable FFT and plotting programs for Linux.
Ptolemy? GNUplot? I'm tired now, so I'll look at it tomorrow.
There are twice as many places in a MFM
data stream where a transition *may* take place, as compared to a FM data
stream at the same data rate. The maximum number of transitions per time
remains the same.
Your last sentence was the point I was actually making, though I didn't explain
it very clearly.