Dome slews the long way around during short slew requests

[ghilios]

A NINA user reported an issue (here) that I believe is a Nexdome firmware bug. The user is on the latest alpha release (both firmware and ASCOM driver), and I don't personally observe this from the 3.1 driver.

It seems like a slew request over a very short distance (within 1-2 degrees of the current azimuth) can result in the dome going the long way around (like a 361 degree slew) during Dome following. It also seems like the ASCOM driver isn't reporting azimuth position updates during this time. Dome integration in NINA has a feature called "Dome Following" which calculates the target dome azimuth and compares it against the current dome azimuth every few seconds. When the difference exceeds a user-configured threshold (it was 1 degree initially, happened less frequently but still happened with 2 degrees according to the user), then NINA issues a slew request to the ASCOM driver.

See the linked issue for a very helpful timeline of events as well as logs showing exactly what the device-reported Dome azimuth was and what NINA slewed to each time this happened.

Thanks!

[StephenBogner]

I am the original reporter for this issue. Just to clarify, the dome more often than not actually makes more than 1 revolution before eventually halting. I don't know if it is significant or not, but the runaway rotation has always occurred in the clockwise direction, but that may be because I have been testing tracking and imaging towards the south. I will be happy to follow up with you with log files and additional testing if this is helpful. Cheers!

[StephenBogner]

I have conducted a series of tests to attempt to better characterize the failures I have been experiencing. The pdf Test Report is here: Testing to Resolve Dome OOC Events.pdf

[StephenBogner]

I performed the "Reset to Factory Settings" and the controller and stepper motor have returned to function. The @FRR command returns :FRR3.4.0-alpha.9#, so I am still on this version of the firmware. I attempted a test run at 135 degrees azimuth and 55degrees elevation and 2degree tolerance. This test run failed with OOC events, and when it eventually stopped it was not in the correct position to point the telescope out of the slit. TA.Nexdome.Server-2020-12-30-STEPHEN-ASTRO_Stephen-STEPHEN-ASTRO.log 20201230-142618-1.11.0.1032.6088.log

Screen Capture Video during an OOC event. https://1drv.ms/v/s!AlSF_aJSkaKVuzTAaVeRIoFIBOvv?e=Xi22As

[StephenBogner]

I have attempted to revert to the 3.3.0 Firmware. I was able to use the TA.NexDome.EraseSettings.hex to clear the rotator, and installed 3.30 successfully. Unfortunately, I was unable to do the same with the Shutter, and get the error message below:

I have confirmed the COM3 is connected to the Shutter. What is the next step for troubleshooting further?

[StephenBogner]

After unplugging all other USB devices and retrying after unplugging and reconnecting the shutter USB and attempting to rerun 2 times. First time reported Port COM4 and failed by returning 1, second time succeeded in reverting to 3.3.0 on the shutter with the following reported from the terminal:

Preparing to run C:\NexDome-Firmware\Uploader\TA.NexDome.FirmwareUpdater.exe with arguments --PortName COM3 --HexFile C:\NexDome-Firmware\Shutter-3.3.0.hex --Verbose. COM port: COM3 File: C:\NexDome-Firmware\Shutter-3.3.0.hex Detected bootloader port on COM4

avrdude.exe: Version 6.3, compiled on Jan 17 2017 at 12:00:53 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\Stephen\AppData\Local\Temp\.net\TA.NexDome.FirmwareUpdater\vpe32g1e.egc\avrdude\avrdude.conf"

         Using Port                    : COM4
         Using Programmer              : avr109
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : butterfly
         Description     : Atmel AppNote AVR109 Boot Loader

Connecting to programmer: . Found programmer: Id = "CATERIN"; type = S Software Version = 1.0; No Hardware Version given. Programmer supports auto addr increment. Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices: Device code: 0x44

avrdude.exe: devcode selected: 0x44 avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e9587 (probably m32u4) avrdude.exe: reading input file "C:\NexDome-Firmware\Shutter-3.3.0.hex" avrdude.exe: writing flash (28422 bytes):

Writing | ################################################## | 100% 2.24s

avrdude.exe: 28422 bytes of flash written avrdude.exe: verifying flash memory against C:\NexDome-Firmware\Shutter-3.3.0.hex: avrdude.exe: load data flash data from input file C:\NexDome-Firmware\Shutter-3.3.0.hex: avrdude.exe: input file C:\NexDome-Firmware\Shutter-3.3.0.hex contains 28422 bytes avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.29s

avrdude.exe: verifying ... avrdude.exe: 28422 bytes of flash verified

avrdude.exe done. Thank you.

Programmer returned with exit code 0

---

• Firmware update SUCCESSFUL

• ---

C:\NexDome-Firmware\Uploader\TA.NexDome.FirmwareUpdater.exe exited.

[StephenBogner]

I ran tests using 3.3.0 firmware, with dead zone = 300, Azimuth = 135, Elevation = 55, for both 2 degrees Tolerance and 1 Degree Tolerance. Both tests tracked for 30 minutes without issue. This suggests that the OOC events are narrowed down to the 3.4.0 firmware. Perhaps a test where the dead zone is varied would be worth doing?

[NameOfTheDragon]

Thank you @ghilios and @StephenBogner for persevering with this. I believe this could be related to a firmware bug that I've fixed in the upcoming 4.0.0 release. There was a problem in the way I was converting strings to integers so that sometimes the step position was computed incorrectly and was leading, in extreme cases, to never ending slews. Version 3.4.0 would have been affected. You can try the 4.0.0 beta which is available under 'releases' and you should no longer have the problem. I haven't had any major issues reported so I may well release that tomorrow.

[StephenBogner]

Thanks @NameOfTheDragon. I had my mount in little pieces trying to fix poor guiding, so have not been able to test anything for the last week or so. I have things back together so I will get back with the program presently. Cheers!