Thanks for taking the time to reply, Ferrante
I should have been clear - the log snippet was from when I was using an LED panel.
Ekos captured 80 images, but saved only 40 of them. The cycle is: Capture, check ADU and decide it is OK (this file is not saved), capture again (this file is saved)
Although the exposures are 1 second and the reported download time is just over 1 second, the total overhead of exposure, download and process adds up to ~ 5 seconds per frame. There is no intentional delay set.
With sky flats, I did try widening the acceptable ADU values. If the ADU range is 19000 +/- 1000 the procedure starts somewhere in the range. If the sky is darkening, once the ADU goes below 18000, the algorithm increases the exposure, but only a very small increment. This raises the ADU to something like 18030. The 'test exposure' decides that is OK, but by the time the next exposure is taken the ADU value is back down to 17980. So it increases the exposure again by a few thousands of a second, gets back up to just slightly above 18000, declares that to be OK, takes what should be the next valid image but the ADU is again slightly below 18000.
Widening the ADU range further will not change the behavior, it would simply change the 'cycling' from 18000 ADU to some other point.
I will try to find a log where this happened. The solution would seem to be to have the algorithm try to change the exposure to hit the *farther away* ADU limit, not the nearest ADU limit - but I do not know how the program is calculating its 'corrected' exposure time.
I set up a schedule last night that did re-align at intervals. Bit of a kludge hack.
I saved a capture sequence file for more frames than I would take (I set it for 500).
Then in the scheduler the first job was set to continue until 10:00pm
2nd job to continue until 11:00pm
and so on.
Less-minor issue: When I try to take sky flats anywhere near twilight, the auto-expose routine always gets stuck in a loop chasing the correct ADU value. It will capture an exposure that will be a bit outside the acceptable ADU-value window, adjust to a new exposure time that gives an ADU just barely within the acceptable range, take another exposure but now it is again just outside the acceptable range. This cycle continues until I give up. Is there some strategy I should use for sky flats that I'm missing?
Minor issue. Is there a reason why it takes two images for every one that it keeps? As this log snippet shows, Ekos double-checks the exposure every time. I'm pretty sure it did not do this in the past.
[2022-04-14T10:29:28.432 EDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 4 out of 40."
[2022-04-14T10:29:28.437 EDT INFO ][ org.kde.kstars.ekos.capture] - "Captured /mnt/usb/Flat/Lx_30k_LED_med-film_0.125plex__Flat_004.fits"
[2022-04-14T10:29:29.179 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.910-second image..."
[2022-04-14T10:29:34.533 EDT INFO ][ org.kde.kstars.ekos.capture] - "Current ADU 30020 within target ADU tolerance range."
[2022-04-14T10:29:35.617 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.910-second image..."
[2022-04-14T10:29:40.610 EDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/mnt/usb/Flat/Lx_30k_LED_med-film_0.125plex__Flat_005.fits"
[2022-04-14T10:29:41.046 EDT INFO ][ org.kde.kstars.ekos.capture] - "Download Time: 1.11 s, New Download Time Estimate: 1.13 s."
[2022-04-14T10:29:41.061 EDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 5 out of 40."
[2022-04-14T10:29:41.065 EDT INFO ][ org.kde.kstars.ekos.capture] - "Captured /mnt/usb/Flat/Lx_30k_LED_med-film_0.125plex__Flat_005.fits"
[2022-04-14T10:29:41.947 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.910-second image..."
[2022-04-14T10:29:47.204 EDT INFO ][ org.kde.kstars.ekos.capture] - "Current ADU 30019 within target ADU tolerance range."
[2022-04-14T10:29:48.074 EDT INFO ][ org.kde.kstars.ekos.capture] - "Capturing 0.910-second image..."
[2022-04-14T10:29:53.047 EDT INFO ][ org.kde.kstars.indi] - "FITS" file saved to "/mnt/usb/Flat/Lx_30k_LED_med-film_0.125plex__Flat_006.fits"
[2022-04-14T10:29:53.455 EDT INFO ][ org.kde.kstars.ekos.capture] - "Download Time: 1.03 s, New Download Time Estimate: 1.13 s."
[2022-04-14T10:29:53.466 EDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 6 out of 40."
Did you have a narrow-band filter in front of the camera?
Did you try bin 2x2 and increasing the camera gain?
Do you see stars in the fits viewer?
Hopefully not a hardware failure.
Lots of people have trouble connecting recent CEM40s to a pi. The usual solution is to put a usb hub in between, though there seems to be a variety of experiences about which hubs work best. I use a powered usb2 hub.
As far as I understand, the fundamental problem between the pi and new CEM40s is that the mount uses a USB hub chip that does not have a driver in the linux distribution. Beyond that, there seem to be a variety of things that can cause the connection to act up.
My eventual solution involved 4 separate actions:
1) Put a powered usb2 hub in between the pi and the mount
Some sort of intermediate usb hub is going to be necessary until the linux distro catches up, if it ever does. I am not certain the powered hub is required for me because I added it before taking step #3
2) Used a 3rd-party usb cable to the mount
Not 100% sure this is necessary, but my mount is rock-solid reliable now and I'm not changing back
3) Swapped 12v power supply.
Not the one the mount uses, I still use the one from iOptron. I use a 2nd 12v supply for the camera cooler, dew heaters, etc. I was testing indoors with just the mount powered and all was well. Then I plugged in the 2nd 12v supply immediately (and frequently) the mount dropped the usb connection to INDI. I tried a different 12v supply and all is well. I assume the supply I started with generates a lot of RFI
4) Wrapped a velcro around the usb plug and the 12v plug at the back of the mount
I know #4 sounds weird. Myself and some others noticed that the usb connection at the mount is not completely snug (and for me it is much worse with any usb cable other than the one supplied by iOptron). I think I was getting some sporadic physical disconnection. It would disconnect during a meridian flip, for example. Seems to only be a major issue when very cold, but, again, it's working so the velcro stays. The purpose of the velcro is to apply a (gentle) sideways pressure to the usb connector
Without the hub, the pi simply never connects to the hub in the mount or any of the mount's devices (FTDI, iPolar). After adding the hub it was connecting, but suffering from frequent 'Read error' messages from the mount. Since taking all 4 steps I cannot recall any Read errors. The mount always connects and stays connected.
With an OAG, my guide scale is very close to the main imaging scale. I would like to dither by 15-20 main camera pixels to fully eliminate walking noise, but the entry field maxes out at 10.0. Can that be increased?
The 2nd part is an impossible request, I suppose, given how the parts fit together. I recently swapped back and forth from OAG to guide scope and then, last night, back to the OAG for my RC6. I have saved equipment profiles for each configuration. In the last swap back to the OAG I forgot to go into the Guide Options window to reset the dither settings from the 1.5 pixels appropriate for the guide scope to the max setting for the OAG. I ended up with massive walking noise.
Equipment: CEM40, QHY183C main, QHY5III462C guide, Rigel NStep
All had been working and coexisting for some time. I do sometimes get a situation where INDI connects to the camera, but will not download an image and I have to restart KStars. This usually affects the 183, but a couple of times the 462. So I am in the habit of taking a 1-sec test shot with both cameras on startup. Once it works, it does not fail mid-session
I usually guide with PHD2. Tonight I decided (unfortunately, it seems) that I should make a fresh PHD2 equipment profile. Perhaps related, perhaps not, I had quite some trouble getting the 183 to connect to INDI. A few reboots, re-seating of usb, and powercycling the pi later, I had INDI and Ekos seeing all of the equipment. Successful 1 sec test image with both cameras. I needed to refocus the guide camera, having moved the prism and the camera within the helical focuser. Focused the main camera "manually" using the Focus tab and the NStep, then focused the guide camera the same way, but using the helical focuser instead of the Rigel, of course.
Went through the PHD2 equipment wizard and all appeared OK, but PHD2 would not download anything when trying to make the new dark library (or, later, when telling it to loop the 462).
Figured I'd give the internal guider a go - haven't used it in 15 months or so, so things have changed I'm sure. I left everything at defaults. Made a profile and slewed to someplace to calibrate. At first it said unable to autodetect a star. I slewed just a bit until I could see 3 obvious stars in the guider tab. Clearly real stars, because I can move them around by slewing. Start calibration again. A box appears. Not on one of the obvious bright stars, but that should be OK. It says it is moving RA and then Dec. The green box is wandering all over the frame, but the 3 obvious stars have not moved, and there remained only a single dot in the center of the calibration plot display.
I am totally unsure what to do regarding troubleshooting, either for PHD2 talking to the guide camera or for getting the internal guider to work for me. I will start going through all the log files (many restarts tonight, so no idea which logs have which issues in them), and I will try getting PHD2 to connect to the 462 indoors, rather than standing out in the dark and cold.
Would a workaround be to set each job as a sequence that takes, say, 60 minutes, and set it to repeat until terminated? Or, if it hits the altitude limit during a repeat, will it still shut everything down for the night rather than move to the next job?