Thanks! That’s exactly what I was looking for.
Jasem, I made few trial with the simulators and Load&Slew but no success. Probably I was not clear with my request.
First of all, I have NO automatic rotator, so I need to match the angle by hand, with the help of ekos.
Load&Slew correctly center the FOV (but not the rotation of course). What I see in kstars atlas are two FOVs, CCD Simulator FOV and Solver FOV. The latter is pinned to the solved position and rotation, the former has the same size and rotation but it's always at the center of the screen. Probably I'm missing the purpose of the two FOVs....however it seems that the rotation of the loaded file is not reported anywhere.
Rotator in Capture module is disabled if not automatic rotator is connected, so no help also from here.
What I would like to do is:
1 - Load a FITS file, solve it and show it onto kstars atlas
2 - Slew to solved target and show actual camera FOV on kstars atlas as well
3 - Since the two FOVs will usually be aligned but with different rotation, I would like to have an interactive assistant that continuously acquires and solves images, updating the rotation of the camera FOV, so that I can manually align it with the one originally loaded from the FITS file.
I hope now it's more clear.
Is it possible in some way?
I found out that I may use the rotator in capture module to superimpose the desired fov with the actual fov. Would load and slew show the two fovs as well, with the actual one updating if a start a preview loop, and the loaded one fixed? I have to try.
I was wandering if there is a way to easily match the camera rotation with a desired one, or to a previous imaging session. Something similar to the polar assistant, in which I would load a previous image or set a framing, plate solve and align the actual image, and then in live view ekos would tell me how much I have to rotate the camera to match with the desired framing.
The update was pushed on kstars git repo yesterday evening in the 3.5.5 beta path. Are you building from source? I don’t know if it is already available as a nightly build.
Jasem, the update is only for non guided dithering, here the issue seems with guided dithering.
I also noted that non guided dithering happens more on one side than on the other. At the beginning I thought it was the mount drifting, but then I realized that such a drift over the small amount of time (10s) between exposures (30s) would result in extremely elongated stars, which is not the case. I have still to understand where the wrong guide pulse is generated, if in kstars or in the ioptron driver. I may be wrong, but I seem to remember that this behavior started when I updated my GEM45 to the v3 command set (which, by the way, introduces a new set of commands for guiding).
Nevertheless, I searched a bit in the forum, and found out that a similar behavior was seen also for guided dithering, and then Jaseem fixed the "random dithering not being not so random" (github.com/KDE/kstars/commit/6e4d0c91846...202a1ef28432c08de4fd). Maybe a similar fix is needed also for non guided dithering? I analyzed the logs, and even if on the long run the direction and amplitude of dithering are uniformly distributed, there are often sequences of 5-10 pulses with the same direction and almost same amplitude.
I have this issue with a GEM45 (latest firmware) and ioptronv3 driver.
I’m GMT+1 with DST, and kstars is updated from the mount 1 hour earlier, i.e. as if DST is off. However, I have to stress that the issue is only related to the time displayed by ekos as Local Time. Sidereal time is correct, so no issue with slewing to target.
Not clear to me here. You should acquire data with guiding OFF. What is "save 10PEC cycles"? You should save only the smoothed curve, a single cycle, in EQMOD format.Did you check that 1ms pulses are really applied by the mount? The procedure assumes that every pulse is correctly applied, if they are skipped or applied with a different duration the correction will be off. I found that 10ms seemed to undercorrect, so used 20ms.Yes, there are many checks missing at this point. Will fix them later.It's simply the polarity of the correction, which depends on how your camera is oriented, i.e. if a West correction will move the image toward negative or positive image coordinate. You have to try. If after PEC the error increases by about a factor of 2, you have to change direction.This is the index at which your PE curve changes sign for the first time. It is needed to avoid a big correction step at the beginning of the training. In fact, when the PE curve changes sign the correction needed to nullify the error is almost zero.
For data acquisition I have a 2s exposure every 10s (using a DSLR and for some reasons I cannot go faster). Then PECPrep generate a smooth correction curve, with a sample every 1s. My code finally generate a correction pulse every 1s, but since I set minimum step to 20ms (with guiding rate to 0.5) and the PE is small, actually it's very frequent that only a pulse every 2 or 3 seconds is issued.
If you want to try, I think it is now stable enough. So:
- Acquire data. I use ekos guiding. Just start guiding with corrections OFF
- Retrieve the guiding log (usually in your home under .local/share/kstars)
- cleanup so that only the last guiding session is present
- take note of the time of start reported in the file and add the time to the first sample (in my case 10s)
- process the file in PECPrep and generate the EQMOD PEC file
- go back to the driver. Set file name and path, the time of acquisition you noted before, the minimum pulse step (I used 20ms), and the index at which the PE curve generated by PECPrep crosses zero for the first time.
- start recording. You should see a countdown to playback start, then the actual training. Training will stop automatically when the mount say it is over. Check that the last index recorded is within +/-1 of the zero crossing.
At last I was able to test the training procedure.Here you can see the native PE of my GEM45 (first picture), and after PEC training (second picture). In the second picture first 2 periods are with PEC ON, and last one with PEC OFF, for a direct comparison. Seems quite good. I had to modify the training function so that only guide pulses in multiples of a minimum step are issued (as done by PEMPro), and set the minimum step to 20ms (I tried also 10ms, but it seems to undercorrect).
I'm too waiting for some good weather to test on field. As for guiding, right now I will only do unguided exposure, this is the reason for my interest in PEC. Yes, I saw several posts as well about weird behaviors with PEC+guide, but there are also some guys who had no issue, and others for which it worked for some time and then stopped. I don't think it's a matter of double correction. Guiding corrects the error after having seen it, so with a perfect PEC on, periodic error cannot even be seen by the guider (in reality some error will still spill). The issue is probably due to the fact the at the same time both PEC and guider would like to apply a correction (non necessarily of the same sign and amplitude) and this is not well managed by the firmware. Combining the two corrections in the driver would work (you would start applying only the PEC, and then add the reactive guide for the residual error), but, as you said, requires the driver to know where the worm is, which can be inconvenient. You should always park and unpark, but I think that also any manual slew with the mount not monitored by the driver has to be avoided.