SC4 and Maxim v6.4

Thanks Colin. Random numbers showing up for the exposure time - explanation.

The DLImaging AO Control panel has a Locate function. The exposure time is set manually or via an external program making a call to the Maxim DL API. If set manually - say 5 seconds - Maxim will complete a 5 second guider image and select a suitable guide star. The Track exposure time can also be set manually to, for example, 0.1 second for the selected guide star. Assuming the guider is properly calibrated for that PA the guiding will be successful. So far so good. The problem occurs when an external program - in this case ACP - makes a call to the Maxim DL API requesting a 5 second (as set by the initial ACP configuration) Locate exposure time and makes a request for that image. The number that shows up in the DLImaging AO Control Panel for Locate exposure time is not 5 seconds but a number in scientific notation. This number is of the form 1.2345e-67. This is the number that the guider driver uses for exposure time (which, in this case is 0 seconds). ACP analyzes the image and tries to make sense out of the noise and sometimes selects a guide star and then tries again with a new number sent to Locate exposure. After a few tries it gives up. This took a while to figure out because the box containing the Locate exposure time is so small it wasn't obvious that the form was incorrect. The core of the problem is that ACP sends a simple exposure request (set between user set limits on ACP configuration - in my case it is 5 seconds to 0.1 seconds). The form of that request has not changed in years. The Maxim DL DLImaging API that receives that request assumes a different data form and then turns it into scientific notation before it passes it on to the guider control. This is the heart of the problem. And it is a show stopper for all of those who use an external program such as ACP to control Maxim DL.


Cheers,

John

 

I responded to John on our support system, and didn’t see this. Now I get that the exposure time being set via the API is getting munged somehow. I’ll review the ACPP log, but I think John already knows how to read it where it sets (and logs) the guide/AO exposure interval.

 

John posted a screenshot of the issue, it is on the previous page.

 

Hi Bob and Colin,

Here are the log files from ACP, DLImaging and Maxim for the evening of June 18 that show the story when you synch up the logs. Unfortunately, the actual exposure time number processed by DLImaging is not in the log. But you can see the many restarts and retries.

Cheers,

John

 

I’m on an iPad with limited resources (at the SAS conference). I can interpret a log such that you can spot the patterns. For NGC 5033 Test-20240619@061239.log the relevant info is



It takes a 5 sec image, finds a bogus “star” at 247, 1.5, and rejects it. Then it chooses one at (34, 215) and measures the SNR at 4.8. It then scales the exposure (for 3.0 SNR) tries again at 2.59 seconds. It undershoots a bit for 2.1 SNR (the target is 3) so it tries once again for 3.11 seconds hoping for SNR 3. Instead it can’t find the star at all. For some reason it keeps going (?!?!?) assuming that the 3.11 sec exposure is gonna work. Then it starts the guider. Then it runs trhe User Action (plugin). It does one last check and sees the RMS wander at 0.08,0.78 which is “good enough” and starts the exposure.

I am not in a position here at the conference to look at and analyze the other ACP logs but I’m guessing they are similar and the above info can help to interpret them. I will say that I am 100% certain that the logged exposure intervals are the values being written to MaxIm’s guider exposure interval.

 

The SBIG with AO on the SC3 does work perfectly. That is what I have working on the installation in Chile. The DL Imaging plug in required for the SC-4 / AOX is where the Locate exposure time problem was observed.

This problem has been corrected. There was something going on in the configuration that was fixed by reconfiguring and re-calibrating the SC-4 and AOX in both Maxim DL 7.0 and ACP. Three nights of image data with the SC-4 and one with the SC-4 and AOX without error indicate this problem was likely a configuration or incorrect driver issue and not a code issue.

There are a few outstanding issues with SC-4 / AOX - failure to disconnect cleanly is the major one - but progress is being made and I'm feeling pretty good about Maxim DL 7.0 and the DL Imaging plug in.

John

 

Adam, I ran a few more tests tonight. Here are some quick notes (Maxim DL 7)

1. Guider Settings / Settings / Autoguider Output Control via must be set to Telescope. In Maxim DL v6.5 it is set to ASCOM Direct (which probably makes sense given the guider ASCOM test below).

2. In ACP the guider camera must be set to the generic rotated off axis setting, not SBIG when using DL Imaging. Setting to SBIG - which I did initially by mistake - will yield erratic results. It will calibrate successfully and sometimes track but will be erratic. Using the generic rotated off axis setting in ACP Preferences cleared up these problems.

3. In Camera Control - Camera 2 is configured (SC-4) as DL Imaging / no AOX - this configuration was tested over two nights with successful results. Guide star location and tracking worked without error over about 9 hours of imaging. Next test is to configure with AOX and test. So far the results are encouraging for Maxim DL 7.0 with the minor fixes done for me by Bob Denny (Pinpoint license) and Adam (replaced 32 bit driver with correct 64 bit driver).

John

 

One more night of observing with Maxim DL 7 / SC-4 with AOX / ACP went well. The most significant issue is the Disconnect DL Imaging camera 2 issue which throws several errors before disconnecting. Minor issues are the lack of entries in the AO log, overstretch on the autoguider image (noted long ago) and the lack of updating (perhaps none is needed) in the camera 2 status window.

Here are my configuration suggestions - which were learned from trial and error.....

1. ACP guider camera configuration must be set to the generic off axis rotated camera setting. An incorrect setting here may seem to work but it will generate strange errors.

2. Guider Settings / Settings / Autoguider Output Control should be set to ASCOM Direct. Don't forget to use the setup button to get to the ASCOM chooser to select the mount. For some mounts selecting Telescope will likely work OK but the recommendation for ACP users is to use ASCOM Direct.

3. Guider Settings / Settings must be set to BIN 4. BIN 1 and BIN 2 result in erratic "chasing." Bin 4 works. The SC-4 has a 4.8 micron pixel size and a 0.7 reducer. That yields 0.36 arc-sec / pixel at BIN 1 on a 4 meter FL OTA. BIN 4 at about 1.5 arc-sec / pixel is about right for guiding. BIN 3 at about 1.1 arc-sec/pixel would probably be suitable as well but I didn't test that.

4. Set the PA to 0 and locate a suitable guide star using the Locate function. Ensure mount tracking is turned on. Then set camera 2 to DL Imaging without AOX. Run the ACP / calibrateguider.vbs .

5. Then reconfigure camera 2 to DL Imaging with AOX. Run the Maxim FL calibrate function which will calibrate the AOX. Set the button back to Locate and in Guider settings set to Track.

6. Now everything is calibrated and ready to image with adaptive optics.

That is what has worked for this installation. When the Disconnect function is repaired the system will be fully operational.

I'm staying with Maxim DL 7 and will use it as a production application.

Great work Adam, Colin and Doug!

Cheers,

John Downing

 

The reason for ASCOM Direct instead of Telescope is to prevent MaxIm from trying to control GEM flip guiding polarities and jamming ACP’s controlling of same.

 

The same thing you would connect Telescope to. If the mount has an executable type driver (most now do), or an Alpaca controller (there is already one) there is no need to go through the ACP (or any other) hub to share the mount between apps. Just pick the mount itself in the [SET] button Chooser. In John's case that would be PWI4 (PlaneWave) which will accept multiple ASCOM conections from either 32- or 64-bit apps.