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:

(790) Pretoria, 15.01 magnitude.

(663) Gerlinde, 16.52 magnitude.

(Magnitude info is from Kstars).

Clear skies,



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.



Hi everyone,
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: 

I started trying to manually setup a job schedule to do this, but after a while it was obvious that it was not reasonable. I have now written a Python script that creates the scheduler file (.esl) to scan a given number of RA "columns" and DEC "rows" starting from a given RA and DEC (lower right corner in the schema). It considers the field of the camera-telescope combination and has parameters for the desired overlap between images. The scheduled jobs execute a capture sequence that is be predefined in Ekos. Each field in a RA column is visited three times following the order: DEC1, DEC2 ... DECn, DEC1, DEC2, ...DECn, DEC1, DEC2, ...DECn, and then the telescope moves to the next RA. Focusing is called once per RA column, in the first field (at DEC1). I'm attaching it as a .txt file to this post (needs to be changed to .py), in case someone wants to try it. As a result, 3 folders are created for each field (named e.g. Field10, Field10b, and Field10c).

I wrote a SiriL script to process and stack the captures from each field and to align the resulting 3 images for comparison.

Finding moving points of light in the images "by eye" proved absurdly difficult, so I wrote a script in Python that compares the images and presents the findings in a visual way. This is the output from a couple of known asteroids:
That is (391) Ingeborg, a fairly fast moving asteroid of about 15.6 mag. Images were obtained with a 115mm f/5.6 refractor equipped with an ASI1600mm-pro camera (each image: 3x 60 sec Lum subs). The animated GIF is saved by the python script. The color image is also output by the script (each image is a color channel, showing moving objects as aligned R, G, and B dots).
This is another one, about magnitude 17.75 (can't remember the name now, will update info later). It shows the script does a good job at finding them.

I am attaching the image comparison script here too as a .txt file, for anyone to play with. Just be aware that I'm not a programmer (so my code is probably laughable at some parts...tongue.png). 

Things that don't work well yet:
useless rant --> 1. I run INDI/Ekos/Kstars on a Raspberry Pi 4 at the telescope: There has not been a single night where something fails (if it's not a general crash, it's the solver taking forever, or the guider failing in some way pinch.png). 
2. I haven't found a way to make the scheduler wait for the guider to stabilize before starting the capture sequence. Clearly, after the alignment procedure, waiting some seconds seems to help. I think changing the capture sequence to 6x 30sec LUM subs night help with this.
3. Did I say I use a Raspberry Pi? The scheduler takes some time to load the .esl file. I wouldn't dare include more than 6 fields in the file (6 fields are 18 jobs...).

I'm looking forward to knowing if someone else is trying something similar and what has been your approach. It would be nice sharing ideas. 

Already a very long post. I hope it didn't come out to complicated because of my bad English.

Clear Skies,



Hi Ron,
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?



Hi Anders,
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... :(



Dear Hy,
Here are the images (60 lights taken sequentially, and 16 darks).

File Attachment:

File Name: M5_lights_guider_02.zip
File Size: 4,881 KB

File Attachment:

File Name: M5_lights_guider_03.zip
File Size: 4,874 KB

File Attachment:

File Name: M5_lights_guider_04.zip
File Size: 4,877 KB

File Attachment:

File Name: M5_darks_guider.zip
File Size: 1,759 KB

File Attachment:

File Name: M5_lights_guider_01.zip
File Size: 4,868 KB

These images are not binned but I normally run the guide camera binned 2x2 (less noise helps my guiding more than higher angular resolution). 
Hope they will be of help. 

Best regards,



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.



Or avoid mixing SEP Multistar and globular clusters with my current setup ... grin.png



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,