One of the issues I had with calibration was that somehow the DEC Backlash setting was turned on after the new upgrade.  That's a huge no-no for EC2 mounts, as is the GPG RA guider.  Both of those options cause havoc with CEM120 EC2 encoders.  

Interesting.  I only have an CEM60EC, so no encoder for DEC.  But while I have similar issues in RA with guiding cadence (I run at around 6.5s, faster it will start to oscillate wildly), I don't have any issues with GPG.  My (total) guide RMS is between 0.25 and 0.35 arcsec, worse only when (too much) wind comes up...

Unfortunately I can't test things at the moment - having 40-50km/h wind here.  Guess it must be New Moon!? 

@Kevin: I found the 2 other issues and sent a fix to Jasem. If you are good at getting code off of git repos, and want to test this before it hits the main repo, then "git clone   invent.kde.org/murveit/kstars.git " and go to the guider-fix10 branch (git checkout guider-fix10), and compile that. It is currently at HEAD with this mod. I've done simulator testing, and it seemed to fix up the two remaining issues.

Hy
 

Hy,

Thanks, it's building now. It takes a while on my Rock Pi. I'll test it out tonight, it's supposed to be at least partially clear tonight.

-- Kevin

Well, the guide pulses are still showing on the same side of the line as the guide error. So that hasn't changed.

The Direction checkboxes now work like they used to. Turning off the guiding output still allows the graph to show the error. Great.

Now the really bad news. The guiding algorithm doesn't seem to take binning into account. I verified this by turning off the guiding output, and measuring the periodic error of my mount, with both 1x1 and 2x2 binning. The periodic error goes from about 36" pk-pk when binned at 1x1, to 18" pk-pk when binned 2x2. So that isn't right.

Periodic error when binning 1x1:

 

Periodic error graph when binning 2x2:

 

Sorry, Kevin, made a mistake in the RA plotting thing. Jasem has already merged my MR from guider-fix10, but just sent him another (it's now branch guider-fix11).

As far as the binning, it would help if you had a log with guide debug where you sent me the bin 1x1 vs bin 2x2. I'm talking about an Ekos log, not a guide log.
Do you have that handy?

Hy

Kevin,

I'm pretty sure I've identified what the issue is, but it's a little tricky to fix so I want to make sure I get it right.
I can give you a work-around right away, though (and a way to verify that my theory is right).

The issue is that the calibration object doesn't get updated when the binning is changed. So, it returns the same arcseconds-per-pixel value with the new binning as the old, which is wrong after the binning is changed. I'll bet that if you recalibrate after you change binning, then you would get a similar peak-to-peak periodic error with 2x2 as you get with 1x1 (there may be some slight differences in the two calibrations, but roughly the same).

Of course, this should be fixed for realz, hopefully without the need for a recalibration after changing binning. Thanks for finding the issue.
Hy

Kevin,

Here is a fix for the "change binning while re-using a calibration" bug.
invent.kde.org/education/kstars/-/merge_requests/420

If you have the time, can you please test both with your periodic error test, as well as standard guiding (and perhaps also try changing binning after calibrating).
It is available on my kstars fork, in a branch named guider-fix12
So "git clone     invent.kde.org/murveit/kstars.git  " and go to the guider-fix12 branch, git checkout guider-fix12, and compile that. It is currently at HEAD with this mod. 

Thanks for your help,
Hy
 

Thanks Hy!

Unfortunately, last night was the last clear night in the forecast for about a week, so it might be a while before I can test it.

-- Kevin

Kevin,

No problem. I ran your "change binning and test periodic error" test on my rig last night with the new code.  [Interesting thing--never did that periodic error measurement before. Makes you wonder if PEC improvements can be added to the guider on top of GPG for mounts that output their encoder positions.] In any case, it worked well, as expected: roughly same peak-to-peak error binning 1x1 or 2x2 while both used the same stored calibration. Standard guiding worked well too. It's now merged into the latest code, and I believe all the issues you brought up are fixed. 

There is one "comical" thing I noticed. The "target" drift plot and the drift graph are inverted with respect to RA. That is, if one of those says the latest RA drift is 1 arc-second West, the other will show -1 arc-seconds (or 1 arc-second East). The guiding itself works fine, this is a display issue, not a guiding issue. I would fix it, but I don't actually know which one is right. I suppose I could trace through the code and see which makes more sense, but if you know for sure, please let me know.

Hy

I thought I would chime in,
I have been using the kstars beta 376 and tested last night, I was running a series of ten minute subs. and guiding for couple of hours, the sky did have some high very thin cloud waft through.
I was getting some oscillation with the dec axis, and I am not sure what caused it
My polar align is fairly good and scope balanced well
NEQ6 celestron edge800, OAG using qhy 178 guide camera
Stellarmate version 1.5.9, Kstars 3.5.5 (376 build) on windows pc. Ohhh also agression on RA was better at .9 too, I did try changing the dec, but did not see much effect. GPG was also engaged.
I have included both the Analyse and a phd logveiwer snap of results.
The guiding by the numbers looked great, but is that understanding what is the oscillation  caused by?
I thought I would chime in,
I have been using the kstars beta 376 and tested last night, I was running a series of ten minute subs. and guiding for couple of hours, the sky did have some high very thin cloud waft through.
I was getting some oscillation with the dec axis, and I am not sure what caused it
My polar align is fairly good and scope balanced well
NEQ6 celestron edge800, OAG using qhy 178 guide camera
Stellarmate version 1.5.9, Kstars 3.5.5 (376 build) on windows pc. Ohhh also agression on RA was better at .9 too, I did try changing the dec, but did not see much effect. GPG was also engaged.
I have included both the Analyse and a phd logveiwer snap of results.
The guiding by the numbers looked great, but is that understanding what is the oscillation  caused by?

  
 

Hmm, oscillations usually point at overcorrections - but that is clearly not the case. Rather backlash. Have you measured that?
What intrigues me most is that the errors in RA and DEC seem phase shifted, which could point at a crosstalk. How does the calibration look? Are the axes perpendicular?