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:
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.
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?
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.
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.
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?
RDBeck wrote: Part of the reason I do this is I have seen the target name change sometimes after flipping.
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...