Non-guided imaging with dithering - problem

[jcbeyer]

BackyardNIKON v2.0.11

Nikon D800E

Astro-physics Mach 1 Mount with APCC-Pro

I dithered without guiding for about 6 hours over the past several days, dithering was every 3 frames and had no problems at all.

Last night, imaging started 10:33, 50 second exposures, dithering every 3rd exposure.  The system worked fine until 11:59 when a command for a dither was sent and the RA axis moved a long distance almost moving the target out of frame and never moving back.  It stayed in that location through the next exposure.  I recentered the target and continued.  BYN continued to indicate that dithers were being sent to the mount, however, there was no movement or indication the mount received the command - I confirmed the mount was connected to BYN.  Parked the telescope and re-slewed to the target.  Restarted the series, but with each dither afterwards the RA axis would move approximately 10-15 degrees west then return to approximately the same location.  The final movement after the long travel was approximately the distance a normal dither would produce.  Terminated that sequence.

Parked telescope and restarted BYN and APCC-Pro.  Slewed to a different target to test.  I took a series of about 10 exposures with dithering and all seemed to work normally.

Let me know if you'd like the log from the computer.

Joe

 

 

 

[admin]

Send me the log file.

 

[admin]

Thank you for the log file.  However, you send me 4 log files. Can you please identify in which log file the issue occurred?  Otherwise it's like find a needle in a hay 4 hay stacks instead of one.

Thank you,

[jcbeyer]

Of course, my apologies I thought I had provided the information.  The first errant slew occurred immediate before the image saved as 23h56m13s186ms.  That's when all the problems started.  Everything prior to that point was fine.

[jcbeyer]

 The smaller log file dated 5/7/2020 sometime after midnight I believe, was after I restarted both BYN and APCC slewed to a different target didn't see a problem after that.

[admin]

9 hours ago, jcbeyer said:

 The smaller log file dated 5/7/2020 sometime after midnight I believe, was after I restarted both BYN and APCC slewed to a different target didn't see a problem after that.

Okay, thanks.

[jcbeyer]

I was testing the system again last night and believe I understand what is happening.  Astro-physics mounts have the capability to slew to a counterweight up position in order to eliminate a meridian flip during the evening.  In a counter weight up configuration, before the mount can slew to any other position it must first correct the orientation to counter weight horizontal or down position to avoid potential tripod/pier collisions.  The behavior I'm observing is when a dither is triggered by BYN the mount then slews to counterweight horizontal position then likely dithers the Dec axis then returns to the imaging position.  I'll confirm with A-P that this is the normal state.  

[jcbeyer]

I confirmed with Astro-Physics that the seesawing movement I'm seeing is referred to as a safety slew in response to the direct dithering command.  They provided me scenarios that create such a slew and how a dither can be instructed to avoid triggering the safety slew.  

When the counterweight is up, the mount moves according to the safety protocol. There are two ways to move a mount. 

 

1. Issue a timed move. Example: to move the scope 15 arc seconds, issuing a command to move for 1 second at 1x sidereal. This will not trigger a safety move. The mount will instantly move to the correct point and not return to the counterweight down position.

 

2.  Issue a coordinate command move. Example: Move mount coordinate by 15 arc seconds. This will trigger a safety slew as you experienced.

 

Hope this provides some clarity for the movements the mount.

 

Joe

 

 

 

[astroman133]

#1 seems like a pulse guide command.

#2 is a slew

I would suggest that unguided dithering should use pulse guiding if the mount supports it. Of course changing how this works may cause unforeseen side effects, so the current behavior could be maintained as the backup.

I hope this helps.

[admin]

I looked at your log file and dither does work, it's not returning to the original position at all.

 

2020-05-26 23:50:10,421 [18] INFO  - ASCOM dithering...
2020-05-26 23:50:10,421 [18] INFO  - ASCOM Dither is starting...
2020-05-26 23:50:10,467 [ProcessCapture(Normal)] INFO  - Image resized to : Width 3893 Height 2596 Factor 1.232666
2020-05-26 23:50:10,921 [ExifRead(Normal)] INFO  - C:\Users\Joseph Beyer\Pictures\BackyardTEMP\Download\img_95.NEF
2020-05-26 23:50:10,921 [ExifRead(Normal)] INFO  - ExifRead C:\Users\Joseph Beyer\Pictures\BackyardTEMP\Download\img_95.NEF
2020-05-26 23:50:10,936 [18] INFO  - Current RA(16h42m30s) DEC(36°24'38")
2020-05-26 23:50:12,076 [DeleteFile(Normal)] INFO  - Try delete C:\Users\Joseph Beyer\Pictures\BackyardTEMP\exif_args_7f6e05ef-c08a-4c86-b5d5-9f4b720c913e.txt
2020-05-26 23:50:12,076 [DeleteFile(Normal)] INFO  - C:\Users\Joseph Beyer\Pictures\BackyardTEMP\exif_args_7f6e05ef-c08a-4c86-b5d5-9f4b720c913e.txt DELETED!!!
2020-05-26 23:50:12,076 [ExifWrite(Normal)] INFO  - C:\Users\Joseph Beyer\Pictures\BackyardTEMP\Download\img_95.NEF
2020-05-26 23:50:12,076 [ExifWrite(Normal)] INFO  - Skip exif write due to user configured setting
2020-05-26 23:50:12,092 [MoveFile(Normal)] INFO  - Attempting to move file...
2020-05-26 23:50:12,092 [MoveFile(Normal)] INFO  - move: C:\Users\Joseph Beyer\Pictures\BackyardTEMP\Download\img_95.NEF
2020-05-26 23:50:12,092 [MoveFile(Normal)] INFO  -   to: C:\Users\Joseph Beyer\Pictures\BackyardNIKON\M13_LIGHT_50s_800iso_5_20200526-23h49m17s638ms.NEF
2020-05-26 23:50:12,092 [MoveFile(Normal)] INFO  - Try move C:\Users\Joseph Beyer\Pictures\BackyardTEMP\Download\img_95.NEF
2020-05-26 23:50:12,092 [MoveFile(Normal)] INFO  - moved to C:\Users\Joseph Beyer\Pictures\BackyardNIKON\M13_LIGHT_50s_800iso_5_20200526-23h49m17s638ms.NEF
2020-05-26 23:50:12,108 [7] INFO  - M13_LIGHT_50s_800iso_5_20200526-23h49m17s638ms.NEF
2020-05-26 23:50:13,264 [18] INFO  - Dither settled to RA(16h42m26s) DEC(36°24'50")
2020-05-26 23:50:13,264 [18] INFO  - Difference of RA(-0h0m4s) DEC(+00°00'12")

 

There is a difference of RA(-0h0m4s) DEC(+00°00'12").

Now, your issue of counterweight up/down is a mount issue and/or ASCOM driver issue.

BYN calculates a small RA/DEC delta at random and then issues a single SLEW command via the ASCOM driver and at the point the mount/ASCOM driver takes over.  BYN has not control on how this command is performed by the mount.

There is one log entry missing the the logs that would be helpful however, the actual RA/DEC coordinate the BYN calculated to the send SLEW command.  I will add this log in a future release.

Regard,

[admin]

Also, please try the pre-release BYN 2.1.0 Release Candidate

[astroman133]

I would pose a question to Ray Gralak, the author of APCC and the Astro-Physics V2 ASCOM telescope driver about how to prevent a meridian flip when doing a short slew across the meridian.

That said, now that you know what the behavior is, you should be able to prevent the flip by setting the driver's Meridian Flip delay time.

[admin]

I looked at the code and there is nothing I can do, this is your mount / ASCOM driver implementation.

This is the command issued by BYN for ASCOM dithering.  This is standard single call to the ASCOM driver of your mount. If this command makes the mount slew CWUp and the CWDown it is not from BYN.

Telescope.TargetRightAscension = translatedCoordinate.Ra;
Telescope.TargetDeclination = translatedCoordinate.Dec;
Telescope.SlewToTarget();

with the log quoted above this would translate to:

Current RA(16h42m30s) DEC(36°24'38")

Telescope.TargetRightAscension = translatedCoordinate.Ra; <== 16h42m26s
Telescope.TargetDeclination = translatedCoordinate.Dec;   <== 36°24'50"
Telescope.SlewToTarget();

 

[jcbeyer]

Thanks for trouble shooting this from the BYN side.  I appreciate the assistance.  I will carry the information over to the A-P forum.   The good news is most of my imaging is done east of the meridian due local light pollution where this is unlikely to be a problem.