At 12:10 -0800 12/5/12, Pablo Vasquez wrote: , and I snipped most of it to keep
the archive size down.
>Thank you very much Doug! Your comments are very refreshing. Below I answer
>your questions.
Your pictures show what appears to be a least squares fit of a decaying
exponential curve that is adjusted to fit 10 measured points. The x coordinate
is "Air mass" and the y is probably a measure of incoming energy from a remote
galaxy. You seem to be correcting for attenuation in the Earth's atmosphere.
Values shown are
TAUS = -.3420
TAUI = 0.1136
tauv = 84.805 +/- 918 986 749 452 309 441 200 000 000 000 ...
... with more zeros extending well off the right side of the page.
eta = 0.946 +/- 0.0
Twat = -3260.552 +/ 0.000
AZ = 185 deg
Date 10/10/2012 15:57:46 UT
The plotted curve is a horizontal straight line at y = 1.15, clearly nonsense.
The results are obviously wrong and are nothing like the earlier plot of very
similar data some nine months before. There the values were reasonable and the
plotted curve fit the observed points very well. That points to a hardware
problem and it's quite possible that leaking capacitors are the culprit.
It's pretty clear that you are choosing some initial parameters for an
exponential curve that might show up in the C source code as:
y = k1 + k2 * exp ( - k3 * x); // or
y = k1 + k2 * pow(e , - k3 * x ); // with a constant e set to 2.7182838
The exponentials are calculated hundreds of times in a tight loop while each
point is evaluated, the result is subtracted from the observation and then
squared and added to a figure of merit. The loop continues with changes to the
kx values to achieve a minimum figure of merit. That's a lot of work for the
floating point processor which is a Motorola 68882 FPU and is not part of the
68030 main processor.
That output with too many zeros looks a lot like a floating point infinity
value. The decimal conversion shows more than 16 digits which is impossible in
the 52 bits of a floating double. It's likely a decimal value of about +10 **
307 (10^307 except in C, FORTRAN, and perl) and ought to be diagnosed as an
error whenever it occurs. I'm surprised that it can happen in a long-used exp
function which I believe is in the 68882 hardware where it ought to throw an
exception that would result in an error message. If the code uses the pow( )
approach that might be bypassed. Any divisions ought to be checked for a
possible near zero denominator.
Before blaming the FPU some attention should be paid to those constants kx
which are actually being varied to obtain the fit. They have to be stored in
memory and an error in reading them using a memory bus can be disastrous. A
test, deep in the loop, for reasonable values with a printf when something is
funny would help with the diagnosis. Of course it would slow things down. The
ks here are really tauw, eta, and Twat but there are probably some conversions
to reasonable units. (And why is that last one capitalized? I don't want to be
rejected as US spam here.) A bad memory read might also originate from dirty
connections where memory is plugged in but there is a cache in the 68030 that
would mitigate.
It's possible that temperature is involved in the FPU. It, like the '030, is a
CMOS design which gets hot with usage. Those gates dissipate power only as the
outputs change state. Faster clocks make for more heat. It's possible that some
fan is allowing the FPU chip to heat up now when it didn't nine months ago. It
would be interesting to see if the bad results still occur when, say, only
every fifth measurement is processed.
I have a couple of IIci motherboards here that haven't had power applied for a
decade but they are noted "working when removed". They show dark rings around
several of the surface mounted aluminum electrolytic capacitors but they are
all in the audio section of the board. Some caps elsewhere are tantalum which
do not leak. It wouldn't take too much to swab around the aluminum caps with a
wet brush and clean water. Alcohol has been mentioned and is good for removing
the water but water is best at removing the acid leakage. Isopropyl alcohol is
good but the rubbing alcohol from most drug stores can be 50 % water. Dry
isopropanol comes from commercial cleaning stores. 200 proof ethanol is great
but it requires a license around here. Circuit boards are typically washed
after initial assembly in a washing machine that looks a lot like a dishwasher.
Water is used at temperatures near boiling. Deionized water but never
dishwasher detergent or soap. Some parts, like a dry cell or trimming resistors
have to be added afterward.
A look at the 5 volt DC power with an oscilloscope might be revealing. It
should not show much ripple and it must not show dropouts or evidence of the
main clock frequency which I think is about 50 MHz. It's pointless to try
looking at the digital signal lines for rise time or interferences. Apple
doesn't tell us enough for that to be helpful
The largest connector on the motherboard is the 10 pin power connector. I have
been told that the most common problem in all of electronics is the bad solder
joint. I agree. When Apple's boards are soldered all at once with a wave
machine or in an oven the main consideration is getting hot enough but not too
hot for the smallest items. That leaves the biggest solder lumps with a high
probability of cracking. A lot of Macs have been repaired by reflowing solder
joints on those connectors both on the motherboard and in the power supply.
Are you using MacLinux or another form of UNIX on this machine? If so you might
have a memory management problem. The IIFx had to have a Motorola 68881 (or
something like that) to make UNIX possible. Otherwise C code for Macs has to be
compiled with special compilers that use Pascal stack conventions for
subroutine calls. But that kind of thing could never be intermittent the way
you see it now.
Keep us posted. It's an interesting problem.
--
--> Use vowels every day or you'll get consonated <--
--
-----
You received this message because you are a member of the Vintage Macs group.
The list FAQ is at http://lowendmac.com/lists/vintagemacs.shtml and our
netiquette guide is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to vintage-macs@googlegroups.com
To leave this group, send email to vintage-macs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/vintage-macs
Support for older Macs: http://lowendmac.com/services/
