Slew and center starts imaging before dome has finished settling.

[Graham Hollis]

The ‘Slew and Center as well as the ‘Slew, Center and Rotate’ sequencer commands start imaging the plate solve frame before the dome (which is synchronized with 'Enable Dome Sync’) has completed its move and/or is settling. This can cause the plate solve to fail, drop into blind solve and still fail.

[Stefan B]

Hi - please include the log file to analyse the issue.

[Stefan B]

The log file can be found in %localappdata%\nina\logs

[Graham Hollis]

The log segment below shows one of the occurrences that I found. I run multi-day with target scheduler so log is massive so I hope this is enough to work with. I tried increasing the dome settle time in dome options but that does change the behaviour. Not enough stars as its trying to solve an image of the inside of the dome.

2023-10-15T20:49:09.1581|INFO|TelescopeVM.cs|Sync|786|Syncing scope from RA: 21:31:07; Dec: 12° 16' 23"; Epoch: JNOW to RA: 21:26:44; Dec: 12° 23' 50"; Epoch: JNOW
2023-10-15T20:49:13.1462|INFO|DomeVM.cs|SlewToAzimuth|578|Slewing dome to azimuth 140.65665795803537°
2023-10-15T20:49:24.1735|INFO|CenteringSolver.cs|Center|115|Slewing to target after sync. Current Position: RA: 21:26:44; Dec: 12° 23' 50"; Epoch: JNOW; Target coordinates: RA: 21:31:07; Dec: 12° 16' 23"; Epoch: JNOW; Offset RA: 00:00:00; Dec: 00° 00' 00"; Distance: 00° 00' 00"; Bearing: 00° 00' 00"
2023-10-15T20:49:24.1935|INFO|TelescopeVM.cs|SlewToCoordinatesAsync|905|Slewing from RA: 21:26:44; Dec: 12° 23' 50"; Epoch: JNOW to RA: 21:31:07; Dec: 12° 16' 23"; Epoch: JNOW
2023-10-15T20:49:24.1942|WARNING|DomeFollower.cs|SyncToScopeCoordinates|198|Cannot sync dome at this time
2023-10-15T20:49:43.3959|INFO|CameraVM.cs|Capture|715|Starting Exposure - Exposure Time: 5s; Filter: L; Gain: 100; Offset 50; Binning: 1x1;
2023-10-15T20:49:50.0280|INFO|ImageSolver.cs|Solve|41|Platesolving with parameters: FocalLength: 952 PixelSize: 3.76 SearchRadius: 30 BlindFailoverEnabled: True Regions: 5000 DownSampleFactor: 0 MaxObjects: 500 Reference Coordinates RA: 21:29:58 Dec: 12° 10' 01" Epoch: J2000
2023-10-15T20:49:50.3775|INFO|BaseImageData.cs|FinalizeSave|157|Finalize image and moving it to C:\Users\Graham\AppData\Local\NINA\PlateSolver\nqodz010.o22.fits
2023-10-15T20:49:54.1887|ERROR|ASTAPSolver.cs|ReadResult|62|ASTAP - Plate solve failed.

Not enough stars.
2023-10-15T20:49:54.2006|INFO|ImageSolver.cs|Solve|41|Platesolving with parameters: FocalLength: 952 PixelSize: 3.76 SearchRadius: 30 BlindFailoverEnabled: True Regions: 5000 DownSampleFactor: 0 MaxObjects: 500
2023-10-15T20:49:55.2816|INFO|BaseImageData.cs|FinalizeSave|157|Finalize image and moving it to C:\Users\Graham\AppData\Local\NINA\PlateSolver\0lyid1vt.odu.fits
2023-10-15T20:49:58.6094|ERROR|ASTAPSolver.cs|ReadResult|62|ASTAP - Plate solve failed.

‌

[Dale Ghent]

Can you provide some details about the dome and its driver? There have been past instances of dome drivers that lie about the slewing state of the dome after a slew to an azimuth had been given to it. This can lead to NINA believing that the dome had completed the slew where, in reality, it had not.

[Graham Hollis]

I have a NexDome, running the Beaver Dome Controller that was developed by Lunaticoastro in collaboration with NexDome. NINA is using the Beaver Nexdome ASCOM Driver.

One additional point I’ve observed is, on the status line at the bottom of NINA, it has both the dome settle time and Imaging exposure time going at the same time. The settle time only starts when the dome reaches the correct azimuth so the driver does seem to be doing it job in that regard. If the exposure started after the dome settle was complete I believe that would resolve it.

[Dale Ghent]

I’m confused, though - the settle time would kick in only after the dome has completed its slew to the requested azimuth. That means that no portion of the dome should be obscuring the telescope’s field of view at that point - the slew is complete and the telescope should be staring at open sky. The subsequent plate solve exposure should fine at that point.

[Graham Hollis]

I think its marginal, depending on how far apart the targets are. Most times the dome arrives in time for exposure start and it's only infrequently the problem occurs. From what I recall and I don't sit watching it everytime, when it fails the dome settle starts after the exposure has started, which I think only indicates the driver has signaled NINA that the dome has arrived at the azimuth. I would need to setup and do some tests if you think that would help.

I believe this problem has always been there. My workaround in the past was, within the target container, first to use only the ‘Slew to Ra/Dec’ which inherits the Ra/Dec from the target, ‘Wait for Time Span’ of a few seconds to allow the dome to catch up, and then issue the ‘Slew and center’ to start plate solving.

With the target scheduler plugin which I now use and love, this previous workaround has been negated as the target schedule container manages the slew and center now, with no opportunity to insert a delay.

This problem has also been exacerbated by the freedoms of target scheduler to jump between many targets based on the proximity to the meridian. First west for setting soonest then back east for a new target now in the meridian window, has the dome now swinging 180 degrees several times throughout the night for new targets and the associated meridian flips. In the past I would generally sit on one one target all night.

I will test another workaround which occurred to me while writing this, which will be to increase the scope settle time after slew, which I think the ‘Slew and center’ does wait for. This extra scope settle time should give the dome time to catch up.

‌

[Dale Ghent]

If the dome is in fact still moving, or hasn’t fully completed its slew, by the time the ASCOM driver sets its Slewing property to false, that is very much a driver defect. Once NINA tells the dome to move to a given azimuth, NINA starts watching the dome driver’s Slewing property, which would reflect a value of true (it’s a simple boolean). NINA continues to poll this property every 2 seconds until it presents a value of false. This is supposed to signal to NINA that the dome has completed its slew to the requested azimuth and all movement associated with that movement has been completed as far as the dome is concerned. NINA then moves to the next operation. If Slewing transitions from true to false prematurely, then that must be addressed in the driver as it is now providing an inaccurate state to NINA.

The intent of the Settle time option in NINA’s dome options is for people who (inexplicably) do not have their pier/mount sufficiently isolated from their dome, and the dome’s movement causes the mount and OTA to vibrate. The settle time option is not there to make up for these kind of tail-end-of-slew gaps where the driver claims that the dome has finished moving but it really has not. Under normal circumstances, this setting should be of 0 duration.

[Graham Hollis]

I did some basic testing before this evening imaging and the driver looks to doing everything correctly.

In the Equipment->Dome I connect the dome, open the shutter and under manual control I enter 90 and click slew. The status line reads ‘Dome: Slew’ until it reaches the destination position and then reads Dome: Settle with the seconds counting down.

I tried this with several different movements from 10 degrees to a full 180 and the status line reads correctly. If it was the driver setting slewing to false early I would expect to see something different to what I observed.

The fact that there is a non-zero dome settle value that is not being followed by the Slew and center sequencer instructions is in itself an issue is it not? OTA vibrations could also cause a plate soleve to fail.

[Dale Ghent]

So, what is the actual problem with the plate solve? If the dome were still in the way, the failed plate solve image would be obviously blocked with the portion of your dome that’s still in the camera’s FOV. If it’s vibrations, you would see stars but they would be blurred or zig-zagging. Which one is it?

[Dale Ghent]

Testing dome slew settle on NINA 3.0 seems to work (using the ASCOM dome simulator)

https://drive.google.com/file/d/1bdFlTEa6Auyft6fM_afUvxVu14Wu93mY/view

‌

[Graham Hollis]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Graham Hollis]

My issue is that it starts taking an image while the dome is still reporting it slewing causing the image to be the inside of the dome. The image above was from an autofocus run where the autofocus starts to capture images while the dome is still slewing.

[Dale Ghent]

Are you certain you don’t have these operations inside a parallel instruction container?

[Graham Hollis]

100% positive, they are is a Sequential Instruction set.

So Slew and Center, Slew Center and Rotate as well as AutoFocus all start their imaging before the dome slew has completed.

[Graham Hollis]

I just want add that I’m using the ‘Enable dome sync’ after I open the shutter to make the dome follow the scope for the rest of the night, and not the ‘Synchronize Dome' instruction. The latter I think does cause the imaging to wait for the sync to complete but the automatic dome following scope enabled by ‘Enable dome sync’ does not. I will test that tomorrow to make sure that is correct.

I raise this point because even in a parallel instruction set (which I’m not using), the autofocus should wait for the dome slew to finish as there is no specific dome sync instruction that is being issued other that ‘Enable dome sync’ that may have been issued in a separate instruction set much earlier.

[Graham Hollis]

It may be the way it's currently structured thats its not possible to do this as imaging and dome slew are not mutually exclusive. It's just the action of starting imaging that needs to wait for the dome slew to complete and not imaging itself. The dome does slew during a long sub to keep the shutter aligned with the scope. In that case there will be an exposure active along with a dome slew active at the same time.

[Graham Hollis]

I did the additional testing with a screen recording link of the result:

https://drive.google.com/file/d/1jTmHcKo7jKJR0j63SnJjdAILyNV-qDqf/view?usp=sharing

The synchronize dome instruction before the Run Autofocus fails for the same reason I think it failed in the original log I posted above, in the line:

2023-10-15T20:49:24.1942|WARNING|DomeFollower.cs|SyncToScopeCoordinates|198|Cannot sync dome at this time

I guess its because the dome cannot sync when its in ‘Enable dome sync’ mode.

The video shows the exact issue I’m reporting, that the imaging occuring while the dome is still slewing. The test is a but contrived as I pre-slewed the scope and enabled dome sync after the scope slew. It does highlight the issue that ‘Slew and center’ and ‘Slew, center and rotate’ do suffer from this issue when switching targets and if the targets are far apart.

‌

[Stefan B]

Hey Graham - I just checked this with the simulator and can reproduce it for the case when we only have dome following enabled when using the slew to ra/dec instruction.
I’ll dig deeper into the code if there was a reason for this behavior. The alternative is to use the dome synchronization trigger that will kick in between instructions, but only works if your exposures aren’t that long to require a shift of the dome in between.

[Stefan B]

Alright - I think I have a fix ready for the next nightly (# 067) that should prevent that the dome is still slewing after a mount slew.

Please reopen the ticket if the issue persists, as I can only test this using simulators.

[Stefan B]

Fix Issue #1262 - Slew and center starts imaging before dome has finished settling.

→ <<cset 1ef2d7599f5b>>