Questions? Comments or like to contact us? Use this form to message us.


Tel:    +1.604.421.2835

Sign up for our newsletter to get informed about NexDome news or new products.

Jun 13

Shutter closes didn’t ask it to.


My shutter has been closing randomly. Has ruined a couple of imaging sessions over night. I have the low voltage to 10.5 and it reports 12.5 V. I also do not have The rain sensor because I’m using the AAG. Do I need to change anything in the set up to ignore rain sensor? Also would software watchdog maybe cause it to close during a long exposure If it thinks the dome lost connection?


Or maybe does xbee wireless send send a data signal that could be replicated by random noise?

By the way. Running Theskyx dome add on and x2 driver. I have AAG Open but not linked to anything like a script. This behavior happened once just taking a series through Theskyx and again taking a repeating set of images using CCDCOMMANDER with weather monitoring but the weather log said clear and ccdcommande was reporting dome still open even though it is closed. SkyX reports ‘last open successful’. So I don’t think ccdcommander or TheSkyX sent a command. I’m sure the controller is just doing this by itself.

I am using TSX and the X2 plugin and have run my dome with and without a rain sensor and have never seen this happen. That said, it sounds to me like a low-voltage reading is closing the shutter. Are you reading the voltage in the X2 plugin when the shutter is closed or when it is open? It takes a few minutes for the voltage to update in the X2 plugin after the shutter opens (and disconnects from the charger), so you will need to leave the shutter open for a while before checking the voltage. Best bet is to check the battery with a multimeter when it is disconnected from the charger.


You may have a dying battery that cannot hold a full charge. I would try disconnecting the charger in the AM and then checking the battery voltage at several intervals during the day.

I checked with a voltmeter and also looked at what x2 plug-in was reporting. It was reading 12.5 V and had no trouble moving the shutter up or down. i always check when i shut down and see 13.7 bolts reported meaning it’s on the charger.


I don’t think it’s the battery being actually low.


I think it‘s maybe getting an override closure like the keep-alive or maybe the wireless losing connection to the controller and closing automatically.


i don’t suppose it keeps a log...

Jun 14

2 things can close the shutter :

- Low voltage : the voltage display in the X2 plugin settings dialog is updated every 4 seconds so you should see the change.

- Watchdog timer get triggered. This will close the shutter if the shutter Arduino doesn't receive any data for the length of the watchdog timer value. The default is 90 seconds. As TheSkyX queries the dome very often, even during long exposure, the shutter shouldn't close. In addition to this the Rotator Arduino sends a "ping" to the shutter Arduino every 30 seconds. So even if TSX was not querying the system, there will still be some communication between the 2 Arduino.


The Arduino don't have any local storage so they can't keep a log.

In term of distance the XBee can communicate to up to 100m "outside" aka with direct line of sight, which is the case in the dome (and 30m inside with walls and whatnot).





I had the exact same issue and reported long ago. Just comment out the watchdog section in shutter.ino. comment out lines 109 to 117. I've had > 40+ flawless full-automation nights with this mod.




Ron and Rudolphe thanks as usual for the informative and knowledgeable replies. I will try that mod to the shutter ino and give it a try!

ODDLY I've had several of these events. Sometimes FRUSTRATING as to why other times I figured I'd call it a night. I have no idea why... I have been playing with new software (Kstars/Ekos) and I have a AGG as well and figured it was just something triggering it. But I have no idea what. I wondered if it was a time out of lack of use as I messed with new software. But seeing this perked my interest. I'm using 2.11E - I need to rem out some code? OR - I can just wait for the new Tim Long updates!


Just comment out the watchdog and all will be well in meantime. For me 2.11 (lines 109-177 in shutter.ino commented out) has been flawless. If I leave them active random closures. I use both AAG and also NexDome rain sensor as insurance.




er lines 109-117 in shutter.ino commented out not 177..

Jun 15

I'm not sure why we see these random closure unless the rotator Arduino stops sending PING. I wonder why this would happen, XBee going to sleep ?



So there is a ping? always seemed to me like something had timed out... usually happening when I'm not tracking.


I have been using v2.11/2.11E continuously since March/April and have never seen this happen. My shutter watchdog timer has been set to 60s (default?) the entire time.

Jun 15

The rotator Arduino sends ping to the shutter Arduino every 30 seconds when you're connected even if you don't send any commands to the rotator Arduino.

For a closure to happen this would require you to disconnect, in which case the Arduino probably exit the main loop (to be check/tested) and stop sending the ping.

Are your usb port power saving disabled ?



Hi Rodolphe, I recall we spent most of a weekend once trying to get to the bottom of this. I had thought at one time the phenom had to do sky position and how often a little ~1 degree slaving move would happen. It never was reproducible in testing. Even so closure does occur with those lines 109-117 active in shutter.ino with never a mention of the event in the ascom log files. Like I said since I removed watchdog from shutter.ino I have had zero issues over 40+ full nights now with 2.11. It works really well so I simply forgot about the issue. Completely illogical problem. For me the watch dog was now trapping for a problem I never see - communications are rock solid. With lines 109=117 active it does work though.. say rotator is off and I manually open the shutter a crack to sweep water out of the u channel after a big rain.. It will close itself after a spell.

Jun 15

So we have 2 cases :

1- People who've been using firmware 2.11 and never got any problem

2- People who need to disable the watchdog or they get closure.


So it would be useful do identify what people in each category are using.

And if we can't figure it out we also have 2 option :

- disable it all together (2 line changes and I can commit this)

- Wait for Tim's firmware (No X2 plugin for now and probably for a while until there is the same feature coverage as the 2.11 firmware).





I am using v2.11 firmware with X2 plugin v2.130 in TSX 10.5.0 (Daily Build 12165). Watchdog timer set to 60s. Never had any problems.



I'm using 2.11E no changes to stock code. usb port saver? (quite sure I don't have it enabled). I'm not worried. I can often hit open and get it back - (sometimes it doesn't seem to respond to open) ? but our new firmware/drivers are near!


I am using 2.11E with ASCOM client. With watchdog enabled I see random closures about every other night. When this happens the session is killed because the client (ACP) did not request closure so it stops everything and sends a operator intervention email. with watchdog commented out like I've said all is really solid with no issues at all. I'm hoping also to be testing Tim's stuff again with next beta hopefully sometime this weekend. We did so last weekend (Tim comes in remotely to the observatory) and found a few things to address. I'm hopeful that next beta will be something that I can just leave running. Motions are sure smooth and quick. Last beta did display shutter battery in the server window and I've not looked at code but would assume low volts would call a closure. Of course a threshold needs to get set and also ignored DURING shutter motion as it can lag under load. For me this just leaves rain sensor which is not much code.. I do know the recipe to return to 2.11 as the XBeeReset hex must be run in a particular way to do that. Back and forth between Tim's stuff and 2.11 has been flawless but only if the recipe is followed:


1.) load the XBeereset hex with uploader to rotator.

2.)Connect a serial port (arduino tools fine) to rotator and watch the reset. If you do not do this the reset does not happen.

3.) power off rotator.

4.) Repeat steps 1-3 with shutter.

5.) load 2.11 back in shutter.

6.) load 2.11 back in to rotator.

7.) connect a serial port to rotator and send #x to configure xbees.


Easier to do than to type :-).



I’m using 2.11 firmware.


It happened once with CCD commander taking a set of image exposures 120 seconds. I reopened and reset the ccdcommaner and it took the set no repeat incident.


Tried just using TheSkyX and take series and it happened again after about 10 exposures of 360 seconds. Reopened and it stayed open rest of the night.


then it happened again when I did a t-point model run of 100 points. It just randomly closed while the mount Was slewing between points. So the dome was slewing, tracking, had not been idle for longer than it takes to make a 5 second plate solve Exposure.


I have not not had a chance to make the change to the firmware because it’s been cloudy but I will try it.

Jun 15

So there is no clear pattern .. TSX alone on Windows has the problem (Dave), TSX alone on Windows doesn't have the problem (Steve).

ASCOM : You have the problem.

So no clear pattern. Could be some XBee issues, interference, environment related... gremlins ...

So just disabling the watchdog in the code seems the only real option here.

I can do that now and commit the change so that you can all use your dome without having to worry about the watchdog.


Jun 15

I just pushed a new 2.12 version with the watchdog code disabled.


New Posts
  • This is the process i go through to get to the speed settings for the shutter, so a few questions: First I open ascom dome control panel I click connect. Of course it doesnt let you change values unless its disconnected, so i disconnect and reopen the nexdome ascom server monitoring window, hit setup: Seems no matter what values i put below, here 600/1500 etc, the speed of the shutter is the same. I had tried lowering these at first to see if it would help with the motor sticking. Is this the right procedure to lower the values and test? Also, i know there is a much longer thread here about updating the firmware on the shutter/rotator, but, what does the update firmware button here do? At one point i clicked it when only the rotator was connected, it claimed it updated? How do i know if i even need to update either? Both came brand new recently? Thanks in advance
  • I've completed the motor install (although i may be missing parts on the motor related to this, the set key that holds the pin in place was missing, found an m4 for now that seems to hold it but the pin doesnt go in fully, see this thread for more details) First issue (or maybe not), when i push the motor and it moves up, i think when the panel that has the band through it goes under the first panel, half way up, it sticks for a half second, flexes and pops and keeps going. After this at times on the way up, even during the first half, sometimes the motor stalls briefly. The biggest issue is after its up fully and you bring it down, the first 16" or so going back it stalls and moans repeatedly, however, interestingly i can work it forward by doing an on off real quick multiple times, OR by pressing upward on the motor. Here is a video clip of the stalling (most of it near the end): At this point i took all the wheels off the rear, added washers, so now they have quite a bit of flex available. The retention bracket is installed, but i had my son work the motor while i pulled back on the bracket and wheel on one side only, no change. When you pull the panels in the rear when its up there, apart, you can see grinding marks on each panel on the sides. So at this point i'm left with removing the retention brackets on both sides as a final test, and to be able to get the panels apart to add antifriction tape someone recommended. It appears the front panels will need to come off (not the rear solid non moving one), then apply tape as here: Here is an external view of the situation: This is the antifriction tape i've ordered (1" x 15 feet, two rolls,TapeCase 423-5 UHMW) : I dont know what else to try, other than what i have planned at this point. Pretty frustrated. Incidentally, i have the inside dome rotation working pretty solidly, so this is the only sticking point, pun intended. Thanks in advance.
  • Im breaking my shutter issues into multi parts here, in this one, i seem to be missing the set screw on the part by the gear as in this image: The part circled was naturally coming out. I'd like to get the official part to fix this, however in the meantime i've added what seems to mostly fit but not flush, m4 set screw and the locking pin goes in a tad further: Any suggestions here? From someone else, it appears that pin should slide all the way inside (i dont know if this could be related to the motor stalling/sticking issue i have (sep thread))