From: Walter Stafford <STAFFORD@bbri.org>
  To  : bogos@octopus.chem.uu.nl
  Date: Mon, 4 Oct 1999 7:21:10 -0400 (EDT)

RE: Unusual(?) problem

Dear Bogos,
	The times reported in the second line of the xl-a/i files are not 
sedimentation times; they are elapsed times since the beginning of the run and
I have seen cases, from time to time, in which the times get reset to zero.
BUT the values of w^2t are seem to be correct. It has been known for along time
that any analysis software must use these w^2t to get the sedimentation time
by dividing w^2t by w^2 to get t(sed), the effective sedimentation time at the
finial speed of the run. I don't know which value of t is used by Ultrascan.
You might contact Borries Demeler directly to find out. 

Walter Stafford
____________________________________________________________________
From:	SMTP%"bogos@octopus.chem.uu.nl"  4-OCT-1999 05:31:21.72 
To:	STAFFORD
Subj:	Unusual(?) problem

Dear all,

I recurrently have experienced the same problem when trying to
analyse velocity data from an XL-A here at Utrecht, using the old
(v.2.5) UltraScan package + Origin 3.78.  

Specifically, the problem appears within the Van-Holde-Weischet
analysis; everything comes out OK, until just before the VHW plots are
ploted where I get a funny time correction reported (**** instead
of a number). Next, when the plot is displayed, all interpolation
lines are more or less parallel and pointing upwards (to unexpectedly
big s values). I have observed the same behaviour with data collected
from completely different protein samples, which naively led me to the
conclusion that there must be something wrong with the times in the
XL-A raw data header. Indeed, the time in the headers of these files
(second line) seems very small compared to the W^2*t number next to it.

Moreover, when I substituted the headers of some of these files with  
headers of some old velocity data I had collected at EMBL, Heidelberg 
(leaving the data unchanged), everything came to normal again (of course 
I doubt whether I should trust the s values I got after such swapping). 
I suspect, it could be some kind of asynchronization, or incompatibility
between the XL-A and the IMB computer it comes with it.  

Has anybody seen this strange, apparently, Beckman's problem before?
Is there any way to 'go round' it, i.e. by manually correcting the reported
times? Or, I just have to plug in the XL-A another computer?

Any help would be greatly appreciated.

Bogos