Jitter!

How'd I forget Jitter?

This, I'm pretty certain, is not typically specified in most era-datasheets. In fact, as I recall, it's [now] mostly only specified in *receivers*, as in "how much jitter will this serial-data input tolerate?" As opposed to "how much jitter is generated by this serial-data output?"

Wherein, there may be a potentially fatal flaw in my design-intent.

Which might explain why the best I got, last I coded, and recoded and recoded, was a bit of my recorded signal amidst a slew of "static."

Last-coding-status: I was pretty certain my use of C, rather'n inline-assembly, was causing computational-overhead that required more time than the 2us buffers available on either side of the PWM-data edge. So, toward the very end of that coding-endeavor, only a few hours before the deadline, I looked over [most] all the relevant assembly-listings... and... to my surprise, it seemed there should've been at least a few extra CPU cycles that went unused. And, having slept like a sum-total of eight hours in the past three days, chalked it up to... 'k-den' and "not enough time to investigate."

Thus, fate was the composer of my musical scores... Mostly-Static, sounding a bit like a metal band, maybe.

...

So, What is Jitter...?

Simply: It's a slight variance in the time when an edge occurs.

Imagine a perfect oscillator alternating between high and low with perfectly square edges (0ns rise/fall time!) at exactly 1.0000000000000MHz. Jitter is the slight variance around the times when those edges occur. They should occur at exactly 0.50000000us, but more likely they won't, varying by some tiny amount, say it's only 1ps... Then some edges will occur at 0.499999us and some at 0.500001us, and every time inbetween.

Overall, these variances don't add-up; they don't cause the perfect 1.00000000MHz oscillator to drift from 1.00000000MHz. And whatever's clocked *by* the oscillator is still being clocked at a perfect 1.00000000MHz.

So, I guess, Jitter somehow averages out to 0... I'm sure I've read folks' trying to explain it that way. Or, maybe it remains mostly-constant... a constant 1ps shift wouldn't affect the perfect 1...MHz clocking.

But, it's a problem when clocking and data need to be precisely coordinated. If your data edges 'jitter' too much, then they may make it appear the data bit belongs to the wrong clock pulse.

....

I've gotten a bit sidetracked, and it's important to note that I'm certainly no expert on any of this, this is how *I* understand it.

....

OK, so, with the 'constant' idea, earlier, it'd be easy to suggest that jitter could come from, say, slightly different wire-lengths between clock and data wires... And, indeed, that *may* be one source of jitter. Though, I'm not certain it technically qualifies, or whether jitter is some umbrella term encompassing all possible sources of... jitter...

But, as I understand it, 'jitter' is less deterministic. Sources include things like external noise, temperature variances, etc.

And, many sources are, I believe, a result of the driving circuitry.

Now, here's where it begins to apply to my floppy/PWM-data system...

Imagine, for instance, a typical inverter gate, e.g. 7404. Specs usually give things like tplh, tphl, tpd. The rise-time (tplh), the fall-time (tphl), and the propagation-delay (tpd). These numbers are spec'd as mins and maxes... and, for the most-part are considered somewhat stable, given a perfect power-supply, non-varying temperatures, etc. But, say your power-supply sags slightly because another of the six inverters in the chip is switched at the same time as the one you're paying attention to... Now the otherwise relatively-stable tplh of your inverter varies slightly. This gets fed into another inverter, coupled slightly differently to the power-supply, and there's a slight delay between when the first technically considers its output properly-switched, and when the second recognizes its switching threshold is met... Jitter can add up. 1ps becomes 2, and so-forth.

Here's another example I've run into: MIDI. Imagine numerous MIDI devices in a daisy-chain. Each has an input. That input is replicated through a Schmidt-trigger to the device's "Thru" connector. Sure, the output signal of each THRU has nice and square /edges/, but *where* do those edges occur? The Schmidt-triggers toggle high at some position on a shallow rising edge, then toggle low at some other position on a plausibly shallower falling-edge.  (TODO: diagrams!) Further, despite all the efforts, those shallow edges aren't immune to ground-loops and other sources of interference, which may cause triggering at differing times.After doing-so several times (a long daisy-chain), the error adds up. 

Now, say, a high bit surrounded by two low bits is actually skinnier than a low bit surrounded by two high bits. Even though the clock frequency/data-rate remains the same. And, in a system like that, UARTs, bit-widths can make a huge difference (TODO: diagram of start-edge vs. mid-bit sampling?)

That, I'm pretty sure, is also a source of jitter. And... it's pretty hard to spec.

.....

Now, how does this apply to my floppy/PWM-data system...?

Well, the floppy drive manuals I've seen don't spec propagation-delays, rise-times, fall-times, etc... And give even less info about the characteristics of the flux-transitions on the media, and how those correspond to data-output/input, timing-wise.

It's a bit of a black-box once a signal is written and read-back.

So, where does that leave me? 

Because of the existence of write-precompensation, I'm pretty certain the black-box is non-discrete-time.

Similar is the fact that the disk may spin at slightly different speeds in different drives, and how the clocking-system of MFM, and the clock syncing mechanisms of the drive/controller, account for that.

But: An MFM bit is 1us... a slight shift in either direction, due to jitter, wouldn't affect its readability. That "slight shift" might be as much as 1/4 us and still be readable.

But in my PWM-data system 1/4 us is the difference between 0x1 and 0x5.

It may very well be that this hypothetical jitter exists only in the read-back system, or only in the write-system, plausibly not both... but there's really no way of knowing *where* or even *if* it exists without quite a bit of experimentation. And, if it exists (which, realistically it probably does), it'll most-certainly differ from drive-to-drive. And propagation-delays, etc.? Can any of this be characterized more thoroughly than the specs guaranteed for compatibility? Hmmmmmmmmm.....

The cat insists this is where I stop.