Closed StuartLittlefair closed 6 years ago
hi stu,
ah, sorry I added this because I was reducing ultracam drift mode data and the default bad times are set to 2000, so you get a plot with a timescale of 10**6 mins or something if you plot the first few bad times. two approaches are (1) plot bad times but not if earlier than some bonkers time (say 2001 which should pick up the default ULTRACAM bad times), or (2) flag the HiPERCAM drift mode times as good. I think I might prefer the latter, but it's touch and go, opinion? will check the new bug
Is it a total pain to find some way of flagging the hipercam drift mode times as neither good nor bad? I can imagine it causes downstream headaches, in which case I am happy to flag the drift mode timestamps as good automatically.
just pinging @trmrsh to see if the issue of what to do about drift mode times was resolved?
sorry Stu, I vaguely thought I had fixed this, but not sure I did. Is it still a problem do you think? [I take it you have updated the pipeline?] I just picked up your flat field fix by the way.
Think this one is fixed, although it needs checking for ULTRACAM. closing for now.
Hi Tom,
This has come up because we are reducing the maxiJ1820 data, and on L657 you've introduced a piece of code that skips the CCD if the time is not flagged as good. However, in October we intentionally stopped checking the sync status in drift mode runs, because it caused the timestamp buffer to over-run.
This raises a couple of issues:
There's also a minor bug introduced by this line when plotting images. When
implot=True
the print statement above ends without a newline, expecting the implot routine to add some output later. But, since the frame is skipped, this never happens and the output just wraps around the screen....