Hi,

I've started to realize just how valuable the scheduler can be and am trying to understand how to better use it. Here's a situation I'm trying to fix:

• I've created a list of targets to image over the next few (~6) months
• I've set each target to run a 2-hour sequence repeated for 10 runs
• I've selected the 'Sort jobs by Altitude and Priority' option in settings/options
• Aborted job management is set to 'Immediate'
• Naturally, each target cannot finish its tasking in a single night
• When I press start, the first target (say, M1) starts and runs until it hits an altitude constraint
• After hitting the altitude constraint, the mount sits and waits rather than proceeding to a new target that has risen (e.g., M65)

Here's the crux of the issue: Is there a way to have the scheduler move to a second target after the first target has set, even if the first target has not completed the whole job?

If possible, I'd prefer to avoid having to manually update my sequences every night based on what's up. I think 'Aborted Job Management' might have a role to play, but there may be a nuance that I am missing.

Thanks in advance for any suggestions!

Read More...

knro wrote: Check your logs for this message: "Target Coordinates updated to RA"

What does it report? Check all the instances for the message above, and the first alignment post meridian flip. I couldn't find it in your log.

Jasem,

Thanks for taking a look. I found the following:

Start of M65 (From wikipedia: RA: 11h 18m 55.9s, Dec: +13° 05′ 32″)
[2021-01-17T00:11:06.679 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (11h 20m 02s) DEC ( 12° 58' 36\")."
...
Followed by meridian flip (which is successful)
[2021-01-17T03:28:12.544 Pacific Standard Time INFO ][ org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "11h 20m 02s" DEC= " 12° 58' 36\"" Hour Angle "00h 00m 16s"
...
Followed by post-meridian flip alignment, but with unexpectedly large error:
[2021-01-17T03:29:18.704 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Solution coordinates: RA (11h 20m 04s) DEC ( 12° 58' 51\") Telescope Coordinates: RA (11h 20m 03s) DEC ( 12° 58' 36\")"
[2021-01-17T03:29:18.706 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Target is within 00° 56' 44\" degrees of solution coordinates."
...
Followed by unexpected coordinates:
[2021-01-17T03:29:19.868 Pacific Standard Time INFO ][ org.kde.kstars.ekos.align] - "Slewing to target coordinates: RA (11h 17m 42s) DEC ( 13° 43' 12\")."

I'll note:

• I was using the scheduler, and that the target for the captures during and after the flip was M65 (RA/Dec listed above).
• There are other "Slewing to target coordinates: RA" instances, but they are after I caught the mis-alignment and stopped the scheduler and decided to change targets.

Thanks!

Read More...

DerPit wrote:

MSFFT wrote: I’m using an EQ6-R Pro and I have the differential slewing unchecked.

OK, thanks - that was just for confirmation. I also have it unchecked, and for me it works as expected, several times in the last nights.

As per Jasems explanations: The image you posted, is that a comparison of the first image of your series with the first one after the MF? From the text I had assumed it compared two images directly before and after the flip. The target name in alignment is - AFAIK - a 'secondary' variable, i.e., it gets determined based on coordinates, but doesn't change coordinates. So it is not that it says "oh those coords are close to object XYZ, so lets change coordinates to those of that object". So the target name doesn't really matter, it's only the coordinates that do. And according to the log, the coordinates were the same before and after MF.

One question: Do you dither a lot and/or by large amounts?

The pictures posted were by RDBeck, so I can't speak to those exactly. However, I pulled my own data from before and after my meridian flip and have attached it here. Apologies if the images are hard to see - it's probably a combination of light pollution and reducing the file size.
- Pre-Flip image: image immediately preceeding the meridian flip
- Post-Flip image: image immediately following meridian flip and (re-)align
- Misalign - Stack: the stack of the two images to show the magnitude of the misalignment
- INDI_log..._shortened: the log with most of the night removed to show only around the meridian flip

I've pulled the INDI log and clipped about 10 minutes on either side of the meridian flip (3:09 to 3:38, with the flip happening at 3:28-3:29). If you want the whole log, I can provide that too, but it's 8 hours of info. As best I can tell, the meridian flip target should be RA= (11h 20m 02s) DEC= (12° 58' 36"), but once all is said and done, it syncs to RA (11h 17m 43s) DEC ( 13° 43' 12"). Dec is pretty far off. And I was using the scheduler here, so this all automatic - at least until I saw the misalignment in my post-flip image and stopped everything!

To your other question: I do dither a fair amount, but it's still on the order of 10 pixels - so it shouldn't show as much movement as I'm seeing. I've also never seen that much movement from dithering over the course of a night, much less from one frame to another.

Read More...

hy wrote: Not familiar with that code, but just to add my experience--I've done imaging with meridian flips the past two nights and had no issues. The align went to the proper spot.
I'm using the latest code, compiled on an RPi4 running Raspberry Pi OS.

Sorry for the multiple replies! For more context, I’m running the current KStars version (3.5.1) and one version behind on Indilib (1.8.7) on a RPi 4. I tried to update indi in the past couple of days but for whatever reason it didn’t work with the usual ‘apt-get update’ command.

Read More...

hy wrote: OK, that is reasonable, but it is still possible to use the scheduler for on-demand right-now jobs.
It adds a little overhead, but not too much, and does make your imaging a little more resilient to
things like clouds passing by.

If you can, please try that. It might help diagnose the issue, and it might also be a work-around for
you until that gets fixed.

The scheduler is indeed a great tool - I wish I had used it sooner, but I suppose now is the second best time to start.

As for the original issue: I was using the scheduler at the time the misalignment/target swap issue occurred.

Read More...

DerPit wrote:
Well, AFAIK "Slew to target" <strong>does</strong> sync and then moves to the target. "Sync" will only sync, but stay wherever you are.
There is an option in Align, under Scale&Positions, to use differential slewing instead of syncing. I think it's intended for mounts that build their own pointing system. What is your mount and your setting of this option?

I’m using an EQ6-R Pro and I have the differential slewing unchecked.

I suppose I wasn’t super clear: after the meridian flip is accomplished, the align module starts. It completes it’s first iteration and notes that I’m misaligned by a few thousand arcsec. Instead of fixing the misalignment, it appears to choose a ‘new target’ at or near the center of the field of view. It then begins a second align iteration, finds its maybe 100 arc seconds away, and slews to this ‘new target’ rather than the original one.

In my image, my desired target was M65, while this ‘new target’ was the NGC target.

Generally, when I send a goto command from Kstars, the mount slews to it and aligns no problem. This was new to me. I’ll note that I was using the scheduler, though was probably only my second night doing so. Also for clarity: The ‘new target’ from the NGC catalog (redundant, I know) was not on the observation list/schedule. It came out of nowhere.

Read More...

RDBeck wrote: Part of the reason I do this is I have seen the target name change sometimes after flipping.

I don't have a solution, but I noticed the same thing while imaging last night. I think it's more than a target name change. As you indicate, the pre- and post-meridian flip images don't align correctly.

Last night (see screenshot) I was imaging M65. After a successful meridian flip, the alignment process started. The first post-flip solution was off by a few thousand arcsec, but the second slew and align chose a new target (IC 2695) rather than keep with M65. It then claimed alignment success on the third alignment and restarted captures - on the new, wrong target!

This behavior seems to be similar to a "SYNC" rather than "SLEW TO TARGET", though I had the slew option chosen.

This seems to be more of a bug than a feature request - but maybe equally likely is that I've got something misconfigured.

Does anyone have suggestions?

Read More...

tjdowling,

Not sure if you ever got an answer, but I ran into the same issue with the SSAG Pro and think I found a solution. I ended up adding a line to 85-qhyccd.rules for the QHY5II driver:
indilib.org/forum/ccds-dslrs/7574-starsh...getting-started.html

Read More...

Not sure if Orion got back to you - I know they've been understandably overwhelmed.

I found a solution which appears to work. It's based on a couple of threads including these:
indilib.org/forum/ccds-dslrs/5292-qhy5-n...s/40296.html?start=0
www.indilib.org/forum/ccds-dslrs/1621-or...guider.html?start=12

Long story short, I added the following line in 85-qhyccd.rules file in section 2, the pre-enumerated device IDs:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="29a2", RUN+="/sbin/fxload -t fx2 -I /lib/firmware/qhy/QHY5II.HEX -D $env{DEVNAME}"

Again, it seems to work: the camera connects, takes images, and doesn't seem to throw any errors/warnings that aren't expected based on my test setup.

Hopefully this helps someone else - and maybe it's worth adding into the next release to add the capability for the SSAG Pro.

Thanks!

Read More...

Thanks for the welcome Jasem!

Has Orion replied yet? I'll be trying a it more experimentation on the setup this weekend and figured I'd ask beforehand.

Thanks!

Read More...

Hi everyone,

I'm trying to use a Starshoot Autoguider Pro as a guide camera, but haven't had any luck connecting to it through Ekos. Has anyone else had success with a particular driver or any file mods to make it work?

I've tried the following drivers:
- indi_ssag_ccd
- indi_qhy_ccd
- indi_starshootg_ccd
- indi_sx_ccd (really stretching here)

I'm running the drivers remotely on a RPi 4, connecting via KStars/Ekos on a Windows computer (both with Pi as a hotspot and over a router). I've tried using the Pi4's USB 2.0 and 3.0 ports with no discernable difference. I've previously connected other cameras and a mount to the Pi and successfully controlled them, but for this test, I only have the SSAG Pro connected.

In each case, I get the following prompts, respectively:
- "Failed to connect loader." "Failed to connect device." (two separate prompts)
- "No QHY cameras detected. Power on?
- "No Toupcam detected. Power on?"
- "Unable to establish remote device" (not a pop-up like the others, but in the Ekos status window)

If needed, I can post logs, but if anyone has made it work, I'd like to give their config a try.

Thanks!

Read More...