Hi, Twat is capitalized because its a temperature value (usually abbreviated T).
I cleaned all the metallic caps today with isopropyl alcohol. All the caps in the main board had at least some "sticky goo" covered with dust. I have no more "bus errors" since that. I suppose there could be something with the initial values given to the "converging" exponential function. I will get deeper on that. best. On Thursday, December 6, 2012 9:01:39 AM UTC-3, Doug McNutt wrote: > > 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/
