AO-X compatibility update

Discussion in 'Guiding and Adaptive Optics - StarChaser and AO' started by Ron Frisk, Oct 20, 2014.

Page 3 of 3
  1. Frank Barnes

    Frank Barnes Standard User

    Joined:
    Oct 13, 2014
    Messages:
    22
    Location:
    South Carolina
    Hi Beau,
    I use an AO-X on my 16"RCOS and except for the STL11K, (I use a STL-6303) everything else is the same. Well my FFT is only 70mm but you get the idea. I am running it with TheSkyX, CAO and it works like a charm. I had Ashley at PreciseParts make the adapters for the input and output side of the MMOAG. It all fit in my backfocus requirement with .0015" to spare. HTH ......
     
    Frank Barnes, Apr 6, 2015
    #41
  2. Beau Worsham

    Beau Worsham Cyanogen Customer

    Joined:
    Oct 10, 2014
    Messages:
    15
    Location:
    Mayhill, NM
    Frank,

    Thank you for the information, I replied on the RCOS Yahoo Group in more detail. I see that you do use TheSkyX, nice.

    Beau
     
    Beau Worsham, Apr 7, 2015
    #42
  3. Mike Rice

    Mike Rice Cyanogen Customer

    Joined:
    Oct 13, 2014
    Messages:
    14
    Still having difficulty with an AO-X here. See below.

    rings.png

    Problem specifically being concentric rings arcing from top left, towards bottom left, to bottom right, and a bar along the top. Bar looks potentially noise-related, rings look like reflections; however, we've determined through extensive testing with multiple different cables, cameras, AO-X units, etc., that the problem is nonexistent when using "SBIG Universal" driver (even with AO-X plugged in), but 100% consistent in the exact same pattern regardless of pointing location and rotator position angle when using "SBIG w/ AO" driver. Consistent whether using USB or ethernet connection; completely disappears upon switching back to SBIG Universal. Using an external remote guide head on an STX-16803. Appears to be perhaps a driver issue? Any thoughts and/or assistance would be appreciated.
     
    Mike Rice, Apr 28, 2015
    #43
  4. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    9,956
    That looks very optical in nature - or perhaps the curved polishing marks you'll get from the manufacture of the original silicon wafer. They show up as a slight flat-fielding variation, and the marks vary in position depending on where they cut the chip out of the wafer.

    You don't get curved lines from driver issues.

    I can see dust spots on the image. You have a very bright sky background, which makes all these things look worse. Please try a flat field.
     
    Doug, Apr 28, 2015
    #44
  5. Mike Rice

    Mike Rice Cyanogen Customer

    Joined:
    Oct 13, 2014
    Messages:
    14
    I used an image taken tonight as an example, and stretched it considerably so the pattern would be more obvious; flat fielding (or dark or bias frames) did not get rid of the problem. Additionally, as stated before, the pattern *completely disappears* using "SBIG Universal".
     
    Last edited: Apr 29, 2015
    Mike Rice, Apr 28, 2015
    #45
  6. Mike Rice

    Mike Rice Cyanogen Customer

    Joined:
    Oct 13, 2014
    Messages:
    14
    Further data that I should have included:

    The pattern does also exist in the flat frames; they actually compound the pattern when used.

    The pattern exists in pointing exposures as well, meaning it is not dependent on the AO-X actually running; again, this is only the case when using the "SBIG w/ AO" driver.
     
    Mike Rice, Apr 28, 2015
    #46
  7. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    9,956
    I'm afraid I'm a bit skeptical that the choice of driver affects the flat-fielding pattern.

    Could you please provide two exposures, taken back-to-back under identical conditions but with the different drivers, to illustrate - and provide FITS files? For the SBIG w/AO plug-in please do not run the AO (guide normally), so the conditions really are the same.
     
    Doug, Apr 29, 2015
    #47
  8. Mike Rice

    Mike Rice Cyanogen Customer

    Joined:
    Oct 13, 2014
    Messages:
    14
    http://www.nmskies.com/ao-tests.zip

    I am in agreement with you that it's very odd, what we're seeing. In the above-linked ZIP file are four images: one each Universal and w/ AO of M51, five minute exposures taken one right after the other (neither one guided), and one each Universal and w/ AO flat field. (The flat field w/ AO was taken at 180 degrees, so it will not be able to be used for actual flatting, but I am including it to show that the pattern does appear there.)
     
    Mike Rice, Apr 29, 2015
    #48
  9. Doug

    Doug Staff Member

    Joined:
    Sep 25, 2014
    Messages:
    9,956
    AO image: READMODE = 'Normal w/RBI pre-flash'

    Univ image: READMODE = 'Raw '

    I suggest that THIS is the reason for the differences.
     
    Doug, Apr 30, 2015
    #49
  10. Mike Rice

    Mike Rice Cyanogen Customer

    Joined:
    Oct 13, 2014
    Messages:
    14
    ...

    That did it. Thank you for finding that.

    Now we have to figure out why our automation software was defaulting to Raw for one, and w/RBI pre-flash on the other...
     
    Mike Rice, Apr 30, 2015
    #50
  11. Bob Denny

    Bob Denny Cyanogen Customer

    Joined:
    Oct 12, 2014
    Messages:
    1,115
    Location:
    DC-3 Dreams, SP, Mesa, Arizona +1 480 396 9700
    If it is ACP check out the support for readout modes. I am out of town but will be back Monday. You can post a ticket on the Comm Center and I will surely get to it. I happened to be poking around here and found this. The key is that ACP looks for the word 'normal' and uses that, but you can specifically tell it which modes (by name) to use for pointing updates, focusing, etc, versus final/science images. Advanced observers can also include directives in plans that can specify any readout mode for anything.
     
    Bob Denny, Apr 30, 2015
    #51
Page 3 of 3

Share This Page