Bias Time Dependence

Discussion in 'Legacy Models - Community Support' started by JoshuaFrechem, Oct 23, 2018.

  1. JoshuaFrechem

    JoshuaFrechem Cyanogen Customer

    Joined:
    Oct 1, 2018
    Messages:
    41
    Location:
    Virginia
    I will give the bias for every session a go. However, how will that affect my darks since it has a different bias? With enough darks, would the difference show or would the dark current noise swamp it out and essentially treat the bias as a relatively constant offset? The important part of the bias is the amp glow, or what appears to be amp glow. That shows in my uncalibrated stacks very clearly and luckily are reliably corrected across the datasets.

    Also, to an earlier question: is the longer download time in MaxIm DL vs CCDOPS normal? CCDOPS states a rate of 7.8MP/s, close to the stated 10MP/s, but MaxIm DL takes about twice as long. That makes me believe it is a handshake between driver and MaxIm that is longer than CCDOPS or the default digitization in CCDOPS is faster than the MaxIm "Normal Exposure" digitization rate. That is why I wonder if the bias frames from CCDOPS are comparable to the MaxIm DL ones because the bias would have more read noise with higher digitization rate, but I measured no difference in read noises.

    I will upload a night of OIII data and the corresponding calibration frames since OIII shows the banding most clearly in my IC443 image. That way you have as much data as you see fit and can just download what you want.




    Is that Johnson noise in the FETs and Amps and the type of CDS used? Detectors are among my favorite things to study so I am curious. Metrology is what I am considering doing after my degree, so I am more obsessed about characterizing my camera than maybe I should be.
     
  2. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    10,313
    I'm skeptical that the bias frames are causing an issue with your final images, because the ADU shift is so tiny. It's much smaller than the read noise. I'm definitely interested in seeing your OIII data, and also your flats.

    Please note that the digitization rate is NOT affected by the download speed. The digitization happens at the same speed regardless; it is buffered in a frame store memory in the camera.

    The STT does not exhibit significant bias sensitivity to temperature; I just mentioned it because there's the possibility that some effect might be present at a very low level. And no Johnson noise can't do that. For one thing if that was a factor it would increase noise not change the bias. Also it is not a factor in read noise because the camera is designed to ensure that the CCD's internal readout circuitry is the dominant noise source.
     
  3. JoshuaFrechem

    JoshuaFrechem Cyanogen Customer

    Joined:
    Oct 1, 2018
    Messages:
    41
    Location:
    Virginia
    I am not meaning to claim it is the bias frame. It was just my first idea since with a stack of 200 it was so apparent. I am just wondering if there is something on the camera or software level causing it or if it is somehow an optical issue.

    Thank you for clarifying that. I forgot about the frame buffer. I think this is the first camera I have owned that has one. I am used to 10s+ downloads. Is the longer download speed in MaxIm DL normal vs CCDOPS?

    I misinterpreted "bias shift" thinking you meant higher noise. But now I remember we were discussing the shift Colin mentioned. The STT and above cameras have impressive readout electronics. I was unsure how I felt about 11e- readout noise until I realized how high the digitization rate was, especially compared to. In the past, I dealt with an STL 1301E that had readout issues and a Yankee Robotics 6303 that had a water cooling issue from the previous owner that showed its hand by cracking through epoxy in the sensor chamber. So, I am always paranoid about thoroughly inspecting calibration frames for the slightest sign that something is off.


    The images are in the shared folder. These images were taken while adjusting the collimation of my scope after adding a reducer, so the stars are off. I am switching to a Spike-a Flat panel to try to eliminate any flat issues. My OIII flat looks very odd and I want to make sure it isn't my EL flat panel which was not specifically made for astro.



    Sidenote: Are the supplies you sell now 13.8V? I thought I saw you mention it somewhere and I would like to be safe, but the Cincon regulator used should be fine even with the voltage drop. But, better safe than sorry.
     
    Last edited: Nov 2, 2018
  4. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    10,313
    The speed should be similar. We've very rarely seen users who experience longer download times for mysterious reasons, and have never had a good explanation. Make sure you've turned on threading for all equipment on the Setup tab.

    Okay I'll fetch the images and have a look.

    Not on the STT cameras. We've gone to 13V on the STX / STXL cameras, to compensate for losses in the extension cables. The STT doesn't draw as much current so it isn't affected.

    (This was all caused by new Energy Star regulations that essentially forced all the power brick manufacturers shorten their DC cords on high current units. Yeah, seriously. We couldn't procure extension cables with big enough wire gauge, so we compensated by increasing the voltage.)
     
  5. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    10,313
    I have a suggestion to try. Don't use bias frames at all. Instead take some "flat-darks", which match the exposure time of your flat-field frames (you might need several different exposures for different flats - MaxIm DL works out which one to use automatically).

    In the meantime we're going to perform some tests on an STT-8300.
     
  6. JoshuaFrechem

    JoshuaFrechem Cyanogen Customer

    Joined:
    Oct 1, 2018
    Messages:
    41
    Location:
    Virginia
    I usually have flat darks and fully calibrate every frame with appropriate darks and flats. However, OIII is the one flat exposure time I don't have darks for my SII flats and Ha flats both have their own matching darks and the pattern is slightly visible in Ha frames but I haven't seen it on SII. But, I haven't used my SII filter much. I will be getting a better flat panel that will allow me to avoid having 10-40 second flat darks. My OIII flats are 4 seconds while SII and Ha are 40 and 10 seconds and my LRGB filters are uncomfortably around .5-1s and I want to boost up to around 1-2 seconds for every filter.

    I will do flat darks as you suggest. Hopefully I will get some clear nights around new moon.
     
  7. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    10,313
    Okay we were able to replicate the behavior.

    When the camera reads out, the pixel data is transferred into a frame store. Once there's some data in the buffer, the computer can start downloading the data, even while more pixels are coming in from the CCD sensor. What is happening here is that when the USB interface starts transmitting large volumes of data to the PC, we see the noise floor on the readout tick up very slightly.

    So what you're seeing is just a little bit of extra noise that is generated by the logic driving the USB interface, feeding back into the analog chain. It's something that we routinely test for during camera integration testing, because there are a number of very subtle "sneak paths" for this sort of crosstalk (power supplies, phase jitter, grounds, etc.). Usually the same computer would experience the same pattern, unless something changed in terms of CPU loading or whatever other factors might affect download timing. Something changed your download timing, which changed your bias pattern.

    This is a very small effect on the STT camera that we tested, but we can see it. Unfortunately since the STT was discontinued in favor of the Aluma, we are very limited in our ability to fix this. (And no, Aluma doesn't exhibit this behavior.)

    It is possible to mitigate this with a software kludge, which would be to delay the camera download until after the CCD has completely read out into the frame store. MaxIm DL does have a scripting feature that can delay the readout; it's used by programs like ACP that want to start the telescope slewing before the CPU-intensive image download process starts. For more information, please see http://www.diffractionlimited.com/help/maximdl/AutoDownload.htm
     

Share This Page