Re: MKIV CD noise analysis

[Tom Droege <droege@wwa.com>]

Andrew and all,

Thanks for not finding any 60 Hz, but you were not looking in quite the
right place.  There is a 3.0880 MHz crystal that drives the horizontal line
scan.  It is counted down by 31 to produce the pixel clock.  I compute
9.715 microseconds for the time between pixels.  After the line is read
out, there is a delay before the next line starts of several hundred
microseconds.  This is run from an oscillator chip and a pot, so I don't
know where it was set.  Where ever it was when it first worked, I guess.

I dont know how you go about looking in more than one line with the unknown
delay between lines.  Perhaps you explain this in your write up, I did not
follow what you did.  Note that the between line delay should be pretty
constant.  At least to 0.1% over the time interval of a full frame.
Probably 0.01%.   The above pixel time and a total read out time of about
45 seconds should get you close.   

BTW, I have changed the horizontal and vertical pixels to match Arne's
request.  There are now 2054 horizontal pixels in the read out, and 2036
lines.  This is a change from what you all have.  

>I conclude that either Tom is really running the
>whole thing on batteries somewhere deep in the
>woods away from power lines or he really knows
>what he is doing!
>

Thank you for the compliment.  I like to think the latter.  When you all
see it, you will wonder how it is done.  Just open flat rainbow cables
everywhere and 2 layer printed circuit boards.  No ground plane.  You can
do more harm with a ground plane than good, and I had just come from
looking at a large chip read out that was full of ground plane noise.
However, I place all the wires by hand (no auto router on my layout
program) and worry about how the current is going in each circuit.  I come
in differential from the head and go down a processing pipeline where the
ground is carried along with the signal.  There are no connections (ground
or anything that is not very high impedance) until you come out the end of
the pipeline at the ADC.  

Soon I will have new data for yout to look at where there are stepping
motors running whie the data is being read out.  I too think I can see some
pattern, but it is in the noise for me when I try to look at it.  

I am using linear supplies, but they are within a few feet of where the
delicate analog stuff is done, so there are magnetic fields.  There is also
clock noise around from the scanner.  

Thanks again for the nice analysis.

Tom Droege

At 09:49 PM 3/9/99 GMT, you wrote:
>As promised eons ago, I have finally got power spectrum
>routines working on data from the MKIV. First results:
>
>PERIODICITIES
>The patterns I thought I could see with repeat
>distances of 16 and 4 pixels are not visible in
>the spectra. The best face-saving excuse I can come
>up with is that they were moire patterns involving
>the dot pattern of my monitor. But I'll keep looking.
>
>NOISE
>60Hz noise is undetectable ... or I am looking in
>the wrong part of the spectrum.
>
>(about 50 seconds per image, 40 rows/sec -> 20/sec
>folding frequency so 60 Hz should be aliased to
>somewhere near the folding frequency that way.
>The other way, resolution 40 Hz so 60 Hz ->
>1.5 cycles per row. Right?)
>
>I was so surprised at not finding 60 Hz that I
>artificially added some. 2 digits p-p (0.5 digits^2
>variance) was obvious and 4 digits p-p was prominent
>so the actual amount must be minute. Unless I am
>looking in the wrong place in the spectrum.
>
>I conclude that either Tom is really running the
>whole thing on batteries somewhere deep in the
>woods away from power lines or he really knows
>what he is doing!
>
>Other noise: The dark file d150004 had some blips
>in the spectra:
>about 16KHz  TV?
>      18KHz  ?
>      32KHz  harmonic of TV?
>      34KHz  Monitor? Stereo carrier? TV sound carrier?
>All frequencies assuming 12microsec/pixel. Scale to taste.
>Total power in these blips maybe 3 digit^2 if I have
>got my scaling right. Big deal.
>Quite invisible in the other files examined - these all
>had higher signal levels.
>
>CONCLUSION
>I still haven't found a damn thing to complain
>about. The MKIV is a fine piece of engineering.
>
>***********************
>TECHNICAL DETAILS.
>The programs are single precision floating
>point based on the Hartley transform. Written
>in Borland Pacal 7.0, with a minute amount of
>Assembler to cover BP7.0's abominably slow 32-bit
>integer coding, they handle 1 & 2D transforms with
>dimensions having up to 3 mutually prime factors
>chosen from (2, 3, 4, 5, 7, 8, 9, 16, 25, 32)
>   eg 2016 = 7*9*32.
>There would be no technical problem other
>than laziness in adding a factor of 127 to
>the list if somebody really wanted to do
>2032x2032 rather than 2016x2016. I have power
>of two code too.
>
>2Kx2Kx4B/pixel = 16M image or Hartley
>2Kx1K  8M each = 16M Re + Im FT after splitting
>                  8M 2-D power
>                 16M Re + Im Cross spec
>
>So in my 32M machine I can roll in a batch
>of images and accumulate 2D power spectra
>using 24M work space.
>With the same work space, I can read in the data,
>transform, and convert from Hartley to Fourier
>(the real part of the output FT overlays the
>Hartley transform which in turn overlayed
>the input raw data) which I then write back
>to disc.
>Transform + cross spectrum + 2 power spectra
>as needed for cross correlation spectrum
>needs 48M, which I am too mean to buy. However, I
>have computed the correlation spectrum in two
>halves with disc buffering:
>
>PROBLEMS WITH DISC TRANSFERS
>Reading and writing the 24MB for the first half
>of the correlation processing took only a matter
>of seconds - far faster than I expected - but the
>second half took several minutes. It turned out
>that splitting the data into an integral number
>of 2016 point rows put the transfers involved
>in the second half out of step with the disc file
>allocation. Borland Pascal went away and did
>something incredibly time consuming to cope with
>this. But only when writing - reading was about
>as fast as when things were in step. The cure was
>to split the computation at a multiple of some
>large power of two (I didn't bother to find out
>the precise value; 32768Bytes worked) rather than
>at the end of a row.
>The moral of the tale is that you may need to
>worry about nasty low level details when trying
>to write out a lot of data to disc. I managed
>to make my disc look 50 times slower than it
>really was, without even trying.
>
>INTEGER FFT
>On the way to the floating point Hartley transform
>I played with integer FFT. This was a time consuming
>disaster as far as power spectra were concerned as
>I could not keep the data within the 16-bit range
>without all the interesting low level noise stuff
>falling off the end of the word. However, if anybody
>wants a set of routines for 1 & 2D transforms with
>full facilities for putting in scaling factors at
>every turn and for counting the overflows ...
>
>2Kx2Kx2B/pixel =  8M per image
>                 16M per 2 images
>  2x8M Re+Im     16M per transform, 2 at a time
>                  4M each packed Re, Im, power
>So one could do a great deal in a 32M computer.
>Pity it isn't useful.
>
>(Why Borland Pascal 7.0?
>1) I own a copy.
>2) I know how to circumvent most of the bugs.
>3) C/Linux - which I also have - is to me essentially
>a write-only language. Nearly as bad as LISP. How
>you C-Gurus cope, I have no idea.)
>**************************************
>
>Andrew Bennett, Avondale Vineyard, Nova Scotia, Canada.
>
>
>