Syncless centering successful! 2.5.2.3

On my first try with syncless centering, SGP put my target within my set point of 20 pixels in 2 iterations. I’m imaging with a Paramount MX+. I haven’t yet tried the newest version of TSX but I did inhibit the sync in the ASCOM driver. Before, this would always cause SGP to either give an error or never get closer to target.

Nice job guys! I’ll keep testing.

Chris

1 Like

Awesome. That’s good to hear! People were freaking out over at CN.

1 Like

Fantastic. I’m thinking about getting a MYT, and this is a big factor that was making me hesitate.

Dean

1 Like

We should do some testing around RA=0 and Az=0 - they are the areas that can cause headaches for the maths… a long time ago there was such an issue with the meridian flip when the RA was close to zero.
I just bought a new scope, so that rules me of testing it for the next three months.

1 Like

RA= 0 and Dec = 0 would be good candidates for testing. Specifically with the scope thinking it’s on “one side” of the line and the offset correcting it to the other. Those things may be difficult to setup and test. But could probably be accomplished via a purposefully bad sync. I’ll do some testing around those areas this evening as well.

Thanks,
Jared

1 Like

Tonight I tried syncless centering again. It wouldn’t get below 200-300 pixels with each iteration. In fact, it didn’t change with each try. The first two times I tried it, it failed. I tried 2 more times and it worked fine again. I don’t know what was going on but here is the log.

sg_logfile_20161009183931.txt (171.1 KB)

Chris

1 Like

What is the mount - could it simply be backlash?

1 Like

@Jared

I tried a manual slew then center to my target last night using the offset mode, TSX and a Paramount. The slew worked but the centering slew failed on the correction - on the first attempt (19.54). I then hit center again and it worked on the second attempt. This may be related to my other thread where I had a slew crash when the centering was automatic. In both cases the sync type showed offset but before hitting the sync a second time around, I opened the sync dropdown and selected offset again. Could it be that SGP is picking up the wrong sync type on power up? That is what the log file suggests.

update: I’m doing an intensive test with a mosaic, short single exposures of each tile and see what happens.

1 Like

Mine is also a Paramount (MX+) so I don’t think it’s backlash. It’s always centered perfectly before.

I think you may be on to something in the setting itself. When I powered up last night, the system was already set for offset in the first two attempts. I then went to the control panel and chose offest again. It then worked fine after that.

Chris

@Jared
Yes - it is repeatable. I load a sequence - it shows offset for sync - fails on first attempt. Reset sequence, open up sync method and click offset, run sequence - it works.

link to sequence:

Just tried this in 2.5.2.4 last night and the offset sync still requires an explicit re-setting after loading the sequence for it to work. (I am not sure from the change log if this was addressed in 2.5.2.4 or not.)

Thanks, we’ll address this.

Jared

Jared - just to note that this little gremlin is still in the latest 2.5.2.5/6/7- one has to explicitly set the offset sync mode after connecting the equipment. I think it goes so far as after disconnecting and reconnecting all, the offset sync mode no longer ‘sticks’ and one has to go back and set it again after connecting all.

It is unfortunate, as it stops a completely automatic run-sequence from scratch.

Having said that - it does sync very well with the offset.

I have been meaning to try this but have held off (and held off updating TSX) until it is solid. Looks like not quite yet.

This should be fixed in 2.5.2.8 (beta)

Awesome. I will try it out when the clouds part.
thanks

I briefly tried 2.5.2.8 and I could select offset without having the hardware connected. It then centered correctly. I forgot to check if the saved profile is good too but assume it is.

Thanks for the feedback.

Yes, that was a bug. The guiding philosophy here is that settings that define sequence behavior should never be disabled and actions that pertain directly to gear (park, slew, move, etc) should be enabled and disabled with connection. Just FYI in case something else is not lining up there.