[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: quick notes on Data Set 20
Boggle!
Sigh! I try to look at representative images. But did not notice this
problem. Probably because I was just looking that the quality was OK.
This looks like the infamous "bad data" problem. But in a way that I have
not seen before.
The problem is usually that the data looks bad. In the old days before
Rob's program, I printed out a few lines in the middle of the image. I
could see if the bytes were coming through in the right order. Now I have
to rely on the data looking "bad". It is probably a high/low byte switch
cause by a bite either being missing or added somewhere. This can happen
naturally from time to time if a noise pulse - say caused by some piece of
heavy machinery turning on - causes an extra write strobe on the cable to
the memory. Note that this rarely happens. One can run for days without
getting a bad image from a noise pulse. So I have not worried much about
that cause.
But there is another problem. Somewhere in the system, a byte is sometimes
saved/lost. This either happens in the memory card or in the Windows
system. From time to time when I turn on the system, it gives "bad
data" The condition can persist all evening long. So it is some sort of
hard error. There are two possibilities. One the memory card is not being
properly reset and so starts at address 1 instead of address 0. This has
to be a write problem since it can be read many times with many resets
after being written.
But it could also be an initialization problem in Windows. I lean in this
direction since Arne, Mike and Michael have not reported this problem. But
possibly they will see it when they run more often.
Now the mind boggling problem. For these runs, the system seems to be
skipping/adding two bytes. Now the data looks OK, but it is one 16 bit
word off. This would interchange the V and I data.
I observe that the way I cure the problem when it is observed is to turn
the power off on the CPU. Sometimes I have to do it a half dozen times
until it starts up with the proper data sequence. This does not guarantee
that the problem is in Windows. I can sometimes cure the problem by
turning off power to the Mark IV. But note that this will cause a
transient on the cable and thus load bytes into the memory and cause
changes to the I/O bus. So I cannot be sure where the trouble lies.
A first solution might be for someone to provide data collection code. I
would hope that some of you are close to such a solution. I am busy
learning Linux so that I will be able to run under it. It could still be a
memory card problem, in which case, I will be able to fix it once I
understand the problem.
So the short answer is Michael is right. I will go through the disks and
try to identify which were reversed.
I think this had no real consequences to the data. Everything is a word
off. This means that all the data is displaced one column from where it
might be if the system was working properly. I think this is of no
consequence to the images.
Sigh! This is very discouraging for me. I had hoped that I finally had a
good data set.
Tom Droege
At 02:43 PM 12/3/01 -0500, you wrote:
> I'm working on images from DS20; my first goal is to compare the
>photometric precision and accuracy of analysis with night-sky flats
>vs. analysis with light-box flats. Some early results:
>
> - light-box and night-sky flats do have significantly different
> "shapes"
>
> - light box flats are pretty consistent after box is rotated
> by 90 degrees; the ratio of rotated to non-rotated
> flats differed from unity by at most 0.06% in V,
> 1.3% in I
>
> - I'm pretty sure that the filter names are swapped from their
> proper values in the FITS headers for disks 6,7,8.
> That is, files with names like
>
> hvra2239820.fits and FILTER = 'V'
>
> are really I-band, and vice versa.
> I haven't checked the values for the other disks...
>
> More notes later. Just thought people might like to know about
>the FILTER mixup -- if I'm wrong, please correct me!
>
> Michael