Thanks for the recommendation, though it doesn't really answer my question.
I wasn't complaining, I just wanted to know. The reply though suggests the refraction switch has no influence on the PA routine.
As I understand the method used in the (new) Polar Alignment tool will align to the refracted position of the pole. Now in the Advanced Settings of KStars there's the option to correct for atmospheric refraction, which I have active.
Does that influence the PA module, i.e., does it adjust to the 'real' NCP then?
knro wrote: Patches are welcome! An option can be added to mimic this behavior. Anyone needs help in setting up their development environment?
That part is not the real problem. It's more understanding C++ and the layout of the code. KStars/EKOS is a complex beast and not the best starting point to learn I'm afraid
(Just wanted to have a look at what is needed to add also the Hour Angle to the "Mount & Alignment" overview, instead of issuing a wish. But even that looked to me like Olympus Mons to an ant )
My Pegasus DMFC fortunately has an internal driver setting to specify backlash.
But I do agree that it would be valuable to have a focus mode in EKOS that can take care of backlash by itself, for those that cannot set it in the driver.
A simple solution would be to have the focusser approach dialed-in values always from the same side, with a definable overshoot. I.e., to go from 10000 to 9950, it first goes down to 9800, and then up again to 9950.
Should of course be optional, so people with driver-internal backlash compensation can switch it off.
Would be great if the FITS viewer (or the internal one in the overview tab of EKOS) had an easy option to highlight saturated pixels
I have meanwhile updated to the very latest version of the firmware, all boards are now at 20190424, so definitely fulfill the criteria mentioned in the docs.
Still the error is the same, I get a timeout when trying to read the position data.
Is ANYONE using this driver successfully with a CEM60?
Last night I wanted to play with tracking rates, especially the custom ones. I can select 'Custom' in the INDI manager, but when I then try to change the values it will only accept a very narrow range (15.035-15.051) around the nominal sidereal value. Larger or smaller values make the button red, and the value is not accepted.
Is that an input limit in the manager, or coming from the mount? Is there a way around?
This is a CEM60EC with the iEQ driver.
Would be great to get the information about pier side from the iEQ driver. The mount seems to have it (at least my CEM60EC).
It really is sad having such a quite high-level mount and still have to flip calibration in PHD2 manually
Thanks so much!
Just compiled it, will test ASAP
It was less than two hours after rise, more than 4 hours before meridian.....
sterne-jaeger wrote: Hi,
it looks like you stepped into a very special situation. You paused a sequence exactly at that time when the mount decided it was time to execute a meridian flip.
Who decides to flip? The mount, or EKOS? I thought (only) the latter.
What should not happen is that a paused sequence restarts automatically after a meridian flip. Can you reproduce this with Simulators?
I can try - I haven't used simulators so far. But of course, for an automatic meridian flip the sequence should continue after the flip....
Next point: EKOS executes only a meridian flip if the meridian flip is activated on the Mount tab. Are you really sure that the meridian flip on the Mount tab is deactivated?
Quite sure, yes. It wouldn't be too helpful for the CEM60, as the iEQ driver unfortunately doesn't support pier side info, so guiding would go crazy without a (manual) calibration flip in PHD2.
So let's assume it was checked. But why did it start so early? As far as I understand, it was roughly 3h too early. So there must be something wrong with the location or the KStars time. Because the meridian flip is only executed when the HA of an object changes from a negative to a positive value.
Indeed. Even if the option had been set, it would have been for HA zero. If, for whatever reason, the pointing was giving wrong info on the HA - why dit GOTO to the target work perfectly?
What I could imagine is that pressing pause does a check if a flip is needed, and that check goes wrong, e.g., because the pier side info isn't there?
I've seen it already several times, but wasn't sure if I did something weird. For sure I didn't yesterday. This is what happened:
I had created a sequence in the camera tab of EKOS (+ button) that was supposed to take 120 frames of 30s each.
After a while I thought I'll go for a refocus and wanted to pause the sequence. So I pressed the pause button below the sequence table display. What now happened perplexed me:
It would finish the current exposure.
Then the activity display (text next to the exposure) told me 'Aligning'. From the beep I gather it did a (successful) plate solve. Why? After that, it continued to take frames.
The two buttons (stop and pause during a running sequence) had changed to play and pause, with pause greyed out and inactive. Pressing play aborted the sequence.
Looking at the log file, after pausing it executed a meridian flip! The target (Coat Hanger Asterism) was many hours before being even close to the meridian!? (rise 20:50, transit 3:37, time of the event 22:32). I had not even activated any automatic meridian flip activity... What's going on there?