> I assume this happens when INDI starts and connects to the focuser. Is there any logging of what it reports?
I assume most drivers will query the focus position regularly, e.g. every second. Mine does.
If you enable driver logging for your focuser, you'll probably see these values, though I suppose that depends on the driver.
Hy
Read More...
Many (perhaps most?) focusers report their position to the INDI driver, which in turn sends it to Ekos.
So, Ekos gets told the focuser position.
Internally, the focuser firmware will very likely do as you said: "record where it last was and imagine that it's still there".
Hy
Read More...
Please send the log with verbose logging and all modules checked (and why not, also the .esl and .esq files).
There is decent documentation in the kstars handbook on using the scheduler, if you haven't checked it out--see
docs.kde.org/trunk5/en/kstars/kstars/kstars.pdf#scheduler
It's hard to tell what's wrong, but the "empty plan" is likely that your job was aborted for some reason (can't tell exactly why without log), and you have "aborted job management" set to "None" instead of having it retry right away or retry after some fixed time.
FWIW, I run the scheduler with the simulator all the time when writing/debugging software, so you might want to try and practice setting something up that way. (To take pictures with the simulator, you need gsc installed, and I don't know if that happens by default, but you can try and see if it works.)
Perhaps the issue is related to the fact that you're imaging near Polaris (e.g. I'm sure the guider would have issues there, are you using the guider?). Try some easier target further from the pole and see if you can get that going...
Anyway, we should be able to get this going, keep posting your progress.
Hy
Read More...
Steve,
Not sure about the old driver, you can likely compile and install it yourself, but let's see if we can get the V2 driver working for you ... I use it all the time (with my CP3, but I'm sure it was verified to be working with CP4 and CP5).
Can you connect to it with KStars/Ekos? If that shows an issue, can you send a full kstars log of your failed connections (make sure you have verbose logging on and logging for the mount driver checked). The usual issue for things like that it is trying to connect to the wrong port. E.g. if you are using a FTDI cable, you need to make sure you have the right /dev/ttyUSB0 or /dev/ttyUSB1 etc. If you are using ethernet with your CP4, I think there was some network protocol choice. If you don't get it working from that, can you also send screenshots of your INDI mount control tabs (e.g. Main Control and Connection)?
Mike Hanson at Astro-Physics has also verified all this works and can be a resource to help you.
Hy
Read More...
Also, Jean-Luc, can you please point me to the part of the handbook that was misleading?
Here's one section (in English) I found (and there are a few others too), please let me know if you have suggested changes.
Hy
Read More...
Jean Luc,
It is worth seeing if that now that you have the right scale, re-checking 'use scale' works. I assume it will work, and that it will significantly speed up your plate solves. Again, you should be able to do this debugging with the FITS Viewer's solver tool during the daytime, if you don't want to do it at night with the Align tab.
I'm not sure how scale originally gets screwed up though.
Hy
Read More...
I can't answer for PHD2, but for the Ekos internal guider, the stages are (1) increment RA, (2) decrement RA, (3) increment DEC, (4) decrement DEC.
It's probably similar for PHD2, however to be sure you can find out by just letting it calibrate and watching the mount's reported RA and DEC angles (e.g. in the Ekos mount tab).
That is, in the RA stages you should see the DEC stay the same and the RA change consistently in one direction when going out and the other when coming back in.
Read More...
Juergen,
What I do for that situation is set Capture's guide limit start setting.
This way, capture doesn't start until the guider corrects the drift. In fact your example is the reason that that parameter was implemented.
Note that I believe this parameter is a property of the capture sequence file (as opposed to a global parameter) so I believe that you'd need to load a sequence file, set the parameter, and then save your sequence file, so that the next time you loaded that sequence file the parameter would still be checked.
Hy
Read More...
Also, I imagine you should be looking on the machine that runs indiserver--that is, the machine that is physically connected to your cameras.
Hy
Read More...
FWIW, I searched on my computer--I have two ZWO ASI 1600s and they both have nicknames.
I don't know the details of the various ZWO drivers (though I did add the nicknames functionality),
but here's a screenshot of some searching in ~/.indi
BTW, I've had no crashing, etc. Perhaps there's some issue with say setting up a profile or optical train using one name then changing/setting the nickname? Perhaps re-init your optical trains, and/or create a. new profile?
Hy
Read More...
On Linux, INDI settings are stored in ~/.indi/*
There are xml files in there for the different drivers, so you could try to text-edit out the settings change to the zwo driver you changed.
Hy
Read More...
I encourage you to not only read the manual, but improve it if you see parts that are not up-to-date or could use reworking. This is an open-source user-contributed project and we could use the help.
The doc source is here: invent.kde.org/education/kstars/-/tree/m...r/doc?ref_type=heads. It is in docbook format (I never heard of it before I started contributing either). The README page invent.kde.org/education/kstars#making-updates-to-the-handbook describes how to make updates to the handbook, but if you are not up to submitting a doc merge request, I or others could do that if you submitted text and pictures in some way.
Hy
Read More...