Just an update on the asteroid hunting tests...
I made some changes to the image comparison script (the new version has been updated in my original post). Now the candidate animated images are stamped with the dates/times extracted from the FITS files. Also made some other minor changes that should make it more "sensitive", I prefer having false-positives than overlooking a possible find.
Here a couple of animations from the last session:
Thanks for your reply Ronald. How did you find the asteroids in the image? When I stack many subs, the rejection usually gets rid of transient phenomena...
Also thanks for the tips on the Raspberry. I do too use a model 4, but with 4GB only. I don't think I have memory issues, though. I connect to it using VNC and by how slow it is I think I it might be draining resources too much. I also think I might have some hardware problems, with the mount in particular (HEQ5-Pro). About a month ago the mount led started blinking randomly (not like when power hungry, but rather as if the power connector was loose), then the whole system crashed (Raspberry going offline and not comming back). And near the end of my last imaging session (two nights ago) suddenly was not able to guide (as if it had stopped tracking altogether) magically recovering the next minute... Might be the winter temperatures approaching.
Regardless, I'll have a look at my OS as you suggest. I'm curious now to see if it might help with other minor issues.
I was curious if the automation already available in Ekos could be put to use to search for asteroids. The idea was to use the scheduler to run a capture sequence on the same area of the sky three times at fixed intervals. Captured sequences could then be stacked to produced three images to compare to see if something had changed position between them. Additional fields could be imaged during the intervals, in a more or less continuous process. A swath of the sky could be scanned moving in RA direction, imaging several fields at different DEC at each RA before moving to the next RA, like this:
Yes, exactly like that, except for the position and extension of the blacked area (the whole lower half in my case).
I'm also using v. 3.5.4
This interesting. I experienced a similar issue while using the dark library, but with the alignment images. A large horizontal band in the image appeared completely black after the dark was substracted, as if the dark in the library had become corrupted. I had not changed anything in camera settings (nor in ekos nor directly in the indi control panel).
I was able to fix it by redoing the dark library, but i'm worried it might happen again while unattended.
Not related to the issue but related to the new dark library management: I noticed that the script that takes the darks to populate the library also changes the capture storing path and unchecks the option to display captured images in fits viewer but sometimes it does not revert these options to their previous states (found out after a long time wondering where my captures were and why they were not being displayed...). Could it be that unintentionally storing my captures there corrupted the library?
I started using an AF3 with my setup (TS 115 f/7 reduced to f/5.6 -> 645mm focal length, ASI1600MM-Pro) a couple of weeks ago only and I've had good results using the polynomial method.
I use the full frame with an annulus between 25% to 70%, exposures are 1 second long, binned 2x2 (I've setup an average of 3 images for exposure, but I'm not sure if this parameter is used in the full-frame mode). Autofocusing takes only 8 exposures and the solution falls consistently within my critical focus zone. The whole process takes approximately 140 seconds.
I'm curious, why does your target move that much during focusing?
I leave auto-guiding on during focusing (I guide a non-moded HEQ5 with a 60mm guidescope at f/11 with an old ASI120MM and my guiding is consistently around 0.5" RMS*), but even if off it will move very little if I've got my PA right.
* that is, when the ASI120MM is not glitching...
Here are the images (60 lights taken sequentially, and 16 darks).
Of course Hy, I'll take them as soon as I get another clear night (unfortunately, most likely not in the next 7 days according to the local weather forecast).
I should add more specifics: the situation presented itself during guiding calibration. The central area of the globular was in the guide frame and the auto star selection algorithm tended to pick a bright area within it as guide star. This inevitably resulted in a "guide star lost" error during calibration. So, in practice, the guiding could not really start in that scenario.
I guess I could try calibrating a bit off-target and then moving back to it to see how having the globular in the guide frame affects the actual guiding...
I'll post back as soon as I have the frames.
I was trying the SEP multistar guiding algorithm last night -to much delight I should say (thanks for a great tool)- when I stumbled on a small problem potentially affecting any guiding based on automatically selecting stars:
My setup has a fixed guidescope pointing in the same direction of the main scope and this means the target is partially visible in the guide frame. When pointing at a globular cluster the star selection algorithm just goes crazy....
Is there a way to tell the guide module to avoid certain regions of the guide camera frame?
Or to select stars only from certain areas?
That would be a good option to have also in the case there are areas affected by excessive aberrations or permanent defects...
AWay from the globular, the SEP multistar performed amazingly well, at times achieving RMS below 0.4 arcsec (HEQ5, 60/700mm guidescope, ASI120mm camera, 2 sec exposures, 0.7x guiding rate).
All the best,