HY...
I have found that Peter's experience and others on the FB group all match mine: calibrate and guide on a target in the east = find....then either flip or just slew to the west and it looks like the swapDec functions are not working or working poorly - I have always reused calibration and swap dec has been checked - in calibration which I normally do in the east the swap dec box always gets checked based on the findings of the calibration process.....I did scan through the code but could not see anything that was glaring to cause this unless some initial state or stored value is incorrect - FYI I have verified MOUNT state with slews and flip and pier-side are all good as part of a bug fix in drivers to OnStep - since all these users are having some similar experience could I get you to double check the swapDec code - my next clear night I am trying a reset of calibration on slew and UNchecking reuse calibration to see if that helps - thanks in advance

If you suspect that the swap-dec functionality isn't working as well as it should, then yes, please use the recalibrate-after-slew functionality
(instead of keeping the old calibration) and see if that fixes things. If possible, first do it with keeping the calibration, then repeat without.
The comparison in similar guiding conditions would help us figure out if there are any issues with flip functionality.
As far as I know, nothing should have changed related to that, but you never know.

I assume you are using the latest beta software--not any released version. Is that correct?
Please also say what guide algorithms and star-detection algorithms you're using. A debug-guiding logs would also be very helpful.

As far as I understand, Peter had a different issue. It took him 90 minutes to calibrate, so something else is going on.

Thanks for reporting this,
Hy

 

At least for me here guiding with the new version works as before.
However, after Hys answer to my question if I have to re-do the calibration I did not do that. So I am still running with the old calibration I did several months ago. So if something goes wrong, it might be not in the guiding, but in the calibration part.

I had some quick try to adjust aggressiveness, especially as the standard 0.75 in RA seemed a bit much.
I did not change default values in the end, as they work very well for me. Re-using guiding for all pointings (N/S, before and after meridian flip) works as before for me...

I was chatting with Peter and couple of others on FB about this, and once I recounted what my situation was they all went "oh yeah!!!" - it seems the new targets were all on the other side of the pier. I am building from master both kstars and INDI so this is your week old version - I suspect that Peter was also not able to calibrate as dec was failing (a guess) which would be a logical thing if some the process to swap dec during calibration is somehow not working/not being set - the expected movements would be off when the points are analyzed (again a guess) - IN my case it is really obvious with DEC (and RA) being driven in wrong directions causing big trails and ping/pong actions - yet in the east all was super. I have no logs as on this run I had turned off all debugging what I think is a memory leak causing kstars to crash...so the NO crash mean I was able to see this behavior! lucky me
I will test away and let you know what I find and if I end up changing any code I'll let you know what works...cheers

Jamie,

Re you suspicions about calibration:
Calibration would not be sensitive to a failure of the swap-dec mechanism. The way calibration works, it pushes RA (and then DEC) one way, and just just notes which way it goes on the image and how much "push" it take to get it there. Then it reverses the direction of the push, and tries to get back to where it started. Therefore, calibration isn't sensitive to which direction it goes--it's happy if the mount moves in any direction initially, and it makes a note of that direction (in fact the specific angle relative to the guide image).
What can make calibration fail is (a) losing track of the guide star that it's following during that process, either due to clouds/obstructions/focus, or an issue with the StellarSolver configuration, or (b) some mount/mechanical/cable issue which would cause the mount not to move out (while being pushed by the initial pulses), or not to move back when the pulses are reversed. 

BTW, it would be good to share the calibration you have. For instance, here's a screenshot of my current calibration:

 

You can see that the RA and DEC are "roughly" 90 degrees apart, as they should be (319 degrees vs 234 degrees),
and that the estimated push to move an arc-second are129.6ms in RA and 155.3ms in DEC.
I know mounts and optics are different, so you may get different numbers.

I have used the new software many times in the past few weeks (though good and bad seeing)
and the performance is "as expected".  Before it became part of the beta release, 3 other folks tested it out
and all had decent performance.

My settings are below:
 
and I'm using GPG for my RA guiding with these settings:
 
My guide scope is an Orion ST80, mount an Orion Atlas Pro, and QHY 5LIIm guide camera.
FWIW, my main OTA is a 10" RC at ~2000mm focal length.
My guiding is ok, not super, which is what you'd expect on the equipment I have with a heavy 
OTA on the Atlas Pro, I can get .6 RMS error on a super night guiding in the northern part of the sky
(but of course not very close to the pole), but more typically it's 0.8 - 1.0.
I never get guiding performance like Peter Kennett showed in his original post, but his mount is
much higher quality than mine. 

There are plenty of folks since the release who, I understand, are succeeding with this new software,
but certainly there can be an issue with it, or with some other changes that were made since,
and if there is, we'll hopefully find it soon.

I do appreciate your help in trying to resolve these issues, and I'll do my best too. 
Hy
 

@Pit, Sorry, I did not intend to imply that you needed to change your calibration with this new change.
Hy

Overall I am very pleased with these changes, this seems to be a move in the right direction. However, I have encountered a few issues, none of which are show-stoppers, just minor annoyances.

• I usually bin 2x2. With the latest version, if I select 2x2, then go to a different tab, then back to the guide tab, it reverts back to 1x1. In the INDI control panel, the camera is still set to 2x2, so it doesn't actually change the setting, just the display of it in the guiding tab.
• In the graph, the corrections for RA are shown on the wrong side of the horizontal line. i.e. if a west guide pulse is issued, it shows it as an east pulse. Guiding works as intended, it's just the display that is incorrect
• When I disable the RA or Dec output by unchecking the check boxes, the graph will no longer update with the mount's tracking error. It stays at zero. I will frequently uncheck the boxes to see the mount's periodic error. This is no longer possible by unchecking those boxes. I found a workaround by going into the settings and setting the aggression to 0 for both axes. This isn't ideal, because now I need to remember what the old setting was and to put it back when I'm done.

I was going to describe the issue with the RA graph corrections being revered (just the graph, not the actual pulses), but Kevin beat me to it. Also, I too found the same problem with disabling the RA/DEC corrections, that it disables the graph completely.

 

Just pushed a fix for #1 in Git. Perhaps Hy can check the rest hopefully soon. Thank you for the great feedback!

Thanks for the feedback Kevin and Peter.
I took a quick look running with the simulator on the latest software. 

1) I saw that the RA pulses are on the same side as the RA error on the guide graph (though they are on opposite sides on the Analyze graph). Dec looked fine on both. This is true for the internal guider. When I tried PHD2 with the simulator, I saw the same thing. Do you know for sure which are on the wrong side? (whether its the correction pulses or the guide error)

2) I tried to set binning to 2x2 and  then switch to another tab, and then switch back to the guide tab. When I did that, I saw no issue--if I set it to 2x2 in guide, then moved e.g. to the capture tab, then moved back to the guide tab, it still displayed 2x2.  What exactly do you do to expose the issue? Can you re-create it with the simulator and describe specifically what you did? Are you setting binning before you start guiding, or during guiding when you see the issue?

3) Unchecking those boxes hasn't been in my workflow. 
I assume you're talking about the RA and DEC checkboxes in the section labelled "Directions" a few rows below the big button that starts guiding (i.e. not the RA and DEC checkboxes below the guide graph). When.I disable them, it seems to remember the last error and pulse and contiinues to plot those values (though I'm not 100% sure but I assume it stops actually issuing those pulses). Clearly that behavior is bad.  What do you think it should do--e.g. I assume you're saying it should continue to compute and plot the errors, but not plot nor issue correction pulses for the axis or axes that are disabled. Is that right?

Hy



 

Hy was curious why I used such long guide exposures.  It has to do with the way the CEM120 EC2 hi-res dual encoders fight with autoguide pulses.  Here's an example, where I started off with 1 second exposures, then switched to 4 and finally got good results after 6 seconds.  With my mount there is little difference between 8 and 15 second exposures.  It certainly helps when using an OAG as my fields are filled with stars!   But when my polar alignment is off a tad, or it's windy, or very poor seeing, these long exposures are not the best.  In those cases, I would get better results if I could adjust the exposure length SEPARATE from the exposure FREQUENCY.  For example, a 3 second exposure every 10 seconds - vs long 10 second exposures.  

 

Haha - no, you didn't.  I did think I'll have to, and you told me I won't.  So I first had tried that, and indeed the old one works.  
That's why I concluded the guiding still works as before, and if something is bad, it must be during calibration, not from guiding...