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.

Oct 20, 2018

Tested Latest 2.0 Build



I saw that Rodolphe had committed items a few days ago and today I cloned from Git and want to report back. Both PDMRotator.ino and PDMShutter.ino compiled cleanly and upload fine. The usual stuff to get shutter working after a power off.. open a little with rocker then close with switch til it stops. On first connect to POTH after that shutter showed as Unknown. Just clicked Close and all was then well.


So far as I can tell everything if fine function wise. From ACP issuing a Home homes the dome but exactly as before leaves a lingering slew which must be stopped from ACP's control button. Failure to do this and then asking for another slew results in the Rotator having to be power-cycled to function again. I suspect something in the ASCOM driver side here. I do have workarounds in my ACP startup/shutdown/weather scripts which keep everything happy. There remains something funky in Dome.FindHome and reporting of athome. No different than before.


I also noticed that from POTH using setup rotator shows as version 2.0.0 and shutter version is blank. Also!! Now in Rotator settings the dome calibration numbers are what was in the new ino not my values. Doing a home then calibrate proceeds normally but values are not updated. Not a problem as my numbers were only 30 steps different than what is there now.


Also in POTH setup shutter both speed and accel are 0. Set does nothing.


So it does appear that the latest Git commit has ASCOM driver and the firmware slightly out of sync. I have no ill effects functionally myself but felt it important to report.


I have slewed/slaved all over the sky and run weather safety and shutdown/startup scripts mimicking an observing run and all has been fine. So my report is that all is OK with a bit of out of sync with ASCOM driver. I do not know how to compile ASCOM so will need to rely on installers as they update.


Thanks everyone for the hard work!!


Oct 20, 2018

I powered all down and reconnected. Did not touch with POTH. At this point the rotator would no longer slave! I returned to (with debug disabled). Now ASCOM setup was normal, calibration was fine and shutter looked as it should it setup. Went back to slaving slews in ACP and all has returned to normal. Survived shutdown/restart normally.


It is nice it is so painless and easy to test builds.


Oct 20, 2018

Ron, that's interesting. Are Rodolphe's changes in the release package or are they somewhere else?

Oct 20, 2018

Oh no not in a release. I was just testing the last Git version 2 push.. build NexDome-a4b7bfd966b45e411740996ee0b573ca4ee0e7c5.


I've noticed other strange stuff (not related to firmware) such as the rotator power supply acts like it is some power-saving Green thing. When dome sits idle for a little while driver will show a crazy low voltage - like 5.4v. As this happens the silly led on the power supply goes dim like it's breathing. Once dome is asked to move it jumps back up. From day 1 I had had to set the rotator voltage low threshold to 0.5 to avoid ACP disconnecting from low power. I have no personal reason to replace the power supply because it does work and my low threshold takes care of it causing troubles. Like I say.. once asked to turn the power jumps back to 12.6v. I have a proper 12V 5A switching supply from Mean Well but it's power center pin hole is no where near fat enough to plug into the rotator.

Oct 20, 2018

Strange stuff seems to be the rule! My shutter disappeared several weeks ago and I spent a bunch of time trying to sort it out. Finally replaced the Arduino board and got everything to work again. Last night, the dome ignored the close command from CCD Autopilot - I checked this morning and the shutter is gone again. Tried the usual stuff (power-cycle, reload firmware, swap out XBee) but still can't see it. Fortunately, I have another Arduino and am going to try swapping it out (again).


I am glad to see Rodolphe Pineau is working on Pat's firmware. I worked with him to get the bugs out of version 2 of his X2 plugin for TheSkyX - based on how well his plugin works (very well), I think we may see some progress soon!

Oct 20, 2018

I've been lucky. Yes indeed it is good to have Rodolphe working with this too. I've learned quite a lot from him and also from Pat's docs. Eventually this will just be solid and stable.


With your shutter.. I'm sure you're way past me on this.. Just move it with switch open a little then close til it stops. See if it is there. ALSO! Look in the thread here from Tom G about the shutter where Rodolphe points out that in PDMRotator the XBee initialiazation string should have a 1 rather than a zero at some point. That might help you.



Oct 20, 2018

Thanks Ron - tried the switch. What's weird is that the shutter responds to open/close commands from TSX even though it's not showing up in POTH or the X2 plugin (no version and zeros in the speed & acceleration fields). I will check out Tom's thread.

Oct 20, 2018

Yeah I've tried to keep things as simple as possible. With ACP no need at all for TheSkyX so I never run it during sessions.. A bit of a CPU hog anyway. So.. my automation Client, ACP, is directly connected to the PDMDriver and the telescope. No other softwares are involved. Also Focusmax is not connected to mount either. ACP controls all pointing via pinpoint. Seems to make things pretty robust but of course we both know that saying that will curse me.

Oct 20, 2018

I've been thinking of going that route too. BTW, when I said "I helped Rodolphe..." what I meant was he wrote the code and I tested it on my equipment :-) - the last time I wrote any code was in the mid-80s!

Oct 21, 2018

Hi guys.

Thanks for the reports.

So far I only tested the code that "fixed" the communication between the 2 XBee.

I'll see if I can run more test with power cycle and what not tomorrow .. or next weekend.

@Ron : the extra slew issue is either in ASCOM or ACP, unless the home sensor is not detected and it keep going round and round. One way to confirm this is to use a serial terminal and issue a h# command and see if it goes home and stops.

The low voltage and the behavior you're describing is weird, but I'll look into the code (I did already but there is nothing that would explain the low voltage as we do a direct conversion of the value from the analog pin to volts based on the Arduino docs).

Also the fact that after power cycling we don't get any value for the shutter (as Steve said.. but he doesn't have my latest version of the X2 plugin ;) ) is telling me we're not quite out of the wood regarding XBee communication (even though from my tests it is already a lot better).

Arduino dying all the time is also not normal (or is it the XBee dying).

In any case I hope to have some times soon to do more test on the test rig (mostly with TheSkyX Pro as I don't do Windows :) ).

As for ASCOM... I'm not an ASCOM dev and would like to avoid touching anything related to it as from a developer stand point this is .... as bad as it gets in term of dev framework, language used and platform.

Oct 21, 2018

Hi Rodolphe. It's great to know you are working on this!!


So here's the latest on my shutter: after being "missing" for two days, it mysteriously reappeared sometime last night! I have been using the past few nights to test settings in CCD AutoPilot and had left the "close dome" command in to test the timeout setting on the shutter. When I checked this morning, the dome was closed and parked like normal with no errors in the log file; and the shutter firmware is reporting version #, shutter speed, acceleration, voltage and etc.


Very strange!



Oct 21, 2018

Good News Steve! Great to hear your advice Rodolphe. here in Texas just need a run of OK skies but it really looks like my setup can run itself via ACP with no interactions required from me other than keeping work in the queue. I do that using the web interface which is quite phone-friendly. The scripts now turn everything on and connect and when it gets to a certain brightness from my cloudwatcher dome opens and waits til right time past twilight. In ACP unknown weather is unsafe and unsafe runs a script called ACP-Weather. I'll paste my working one here. All works without error now from all states I trap for. When morning twilight arrives dome is parked and closed, all software disconnected and power shut off to all devices. Computer then just sits waiting till next dark time and if weather sensor says it's clear things fire up. Next I'll plug in the nexdome rain sensor for redundancy. So it feels like I'm 100% automated.


From a safety point if view it would be good to get the code back into shutter logic to close if there is no word from the computer. I do have all on a UPS which can hold things for about 20 - 30 minutes but should connect that to the little headless NUC computer by usb to run a script to safe the observatory after maybe 10 minutes.


HELP here Rodolphe!!!


Looking at ASCOM logs I see that ShutterState is poled once a second!! Gosh that creates on HECK of a lot of log file noise!!! How might I slow that down? I see rain sensor is poled once a minute if it's connected or not. Only error I see in my logs which is benign is that anytime the dome is repositioned as opposed to a slaving move an unknown command "g:217.3" (where is this example 217.3 is the old position) is received from somewhere.



Here is what the working seems ok weather script looks like.. I used java but might move to python since Oracle will start charging for that net year or two. In the script Telescope.Park both parks scope and closes shutter based on my ACP preferences. The Dome.Park() is just for other scripts to know it's parked so things like shutdown know it is closed up and safe and do not bother.


//My weather safety script


function main()




Console.PrintLine("Weather Safety Script..");

Telescope.Tracking = false;


if (Dome.ShutterStatus == 1)


Console.PrintLine("Dome shutter is closed. We are safe");



//check if dome already at zero

if (Dome.Azimuth != 0) {

Console.PrintLine("Positioning shutter over charger tabs...");






Console.PrintLine("Parking telescope AND closing shutter....");





} else { //now cover case where dome was open but parked like at startup

Console.PrintLine("Closing shutter. Dome was at zero azimuth already....");








Oct 21, 2018

So A quick test done in a serial terminal shows what happen when the dome rotate too fast and passes home :


it does home and stop but the z# command report z1# .. which means it saw home but is not AT HOME. I issued another h# command ... and of course same result.

But no extra slew happens here (@Ron : your extra slew doesn't come from the firmware so probably from ASCOM on ACP).

My rotation speed is set to 2000, so I changed it to 1000 (remember this is not a real dome but a small test rig, so 2000 is very quick on mine and takes about 30 seconds for one rotation).

So now with a lower speed :


z# reports z2# .. AT_HOME .. so if you're having issues homing, reduce your rotation speed.

I'll see if I can do something like when homing is asked. reduce the speed by 50% just for the homing.


Oct 21, 2018

My XBee code changes did help but I still see some issues where commands run into each other .. so we're not out of the wood on firmware when pushing new settings to the shutter arduino (shutter speed, acceleration and cut off voltage).

More debugging is needed to figure out why this is still happening even after my last fixes.


Oct 21, 2018

Thanks Rodolphe!

To be clear I hijacked my own thread here cause I'm back on 5.2.3. I am OK now because home is found close enough for the charging tabs and when ACP closes the shuttter with Telescope.Park the lingering slew is cleared.


Regarding the benign "g" error.. here is an excerpt from the ascom logs....


23:41:51.814 ShutterState Get Value (0)

23:41:51.814 ShutterState Received 0

23:41:51.845 Rotator Get Slewing (0)

23:41:51.916 Rotator Slew from (74.84) to (98.55)

23:41:52.113 Unknown command g:74.84

23:41:52.454 ShutterState Get Value (0)

23:41:52.454 ShutterState Received 0

23:41:53.438 ShutterState Get Value (0)

23:41:53.438 ShutterState Received 0

23:41:54.423 ShutterState Get Value (0)

23:41:54.423 ShutterState Received 0

23:41:55.422 ShutterState Get Value (0)

23:41:55.422 ShutterState Received 0

23:41:56.407 ShutterState Get Value (0)

23:41:56.407 ShutterState Received 0

23:41:56.969 Rotator Get Slewing (1)

23:41:57.422 ShutterState Get Value (0)

23:41:57.422 ShutterState Received 0



We can see that the slew request is processed (and is always done) but the g:<start pos> is likely as you say being mis-sent. Again.. during dome slaving no such messages arise. No harm. The other thing is you can see how crazy often ShutterState is refreshing! 5 times between the slew being issued and it beginning at 23:41:56.969. I'd bet that with folks who have either slow systems or too many software pieces in play this would lead to trouble. I don't think a variable is needed but I'd think checking once every 4 sec or so would decrease traffic by a factor of 4 and be plenty up to date. I've looked at code to do this and it's a bit much for me right now. I think after seeing one example of such a change I'd start to "get" it.


Thanks so much for your help!


Oct 21, 2018

Oh yeah I agree that slowing down during last homing step is a good idea! The reason I move to 340 then home (which is actual 0 azimuth for me) is that approaching from that side always nails the charging tabs. Tonight ACP will auto startup on it's own and I'm not wanting to touch anything till I see that a couple of nights. Once I'm sure what I have is cool I'll slow things down. As it is right now I have my Mach 1 slewing at 900x and the dome seems to track with that quite closely if they happen to be moving together.


Oct 21, 2018

When you do a goto, the controller replies with a g<current position>#

My guess is the ASCOM driver doesn't (yet) know about this and reports an error.

Or.. it send g:74.86# instead of g74.86# (no : in there) which triggers the unknown command error.

here is what it looks like in a serial terminal :


then when it's done I issue another g# command : g#g74.86#

if I put a : in there it act as a goto 0 apparently (need to check the code but it probably convert the : to 0

I'm also seeing issues when we're sending commands to quickly to the shutter and they get mangled together.. I wonder if it's the same for the rotation controller and the issue is not just a XBee issue but an issue with how much things are done in the main loop and the arduino is having a hard time keeping up.


Oct 21, 2018

Good find! I'll bet the ASCOM driver has something like a :: instead of a : someplace. I think I'm going to have to learn how to compile ASCOM. :-). Thank goodness it's benign.


Oct 21, 2018

So I still see issues and command being mangled when the shutter is sending a message while the rotator is also sending a message, the results is that the response from one is being seen as the parameter for the command being send.

So the shutter sends F# to ask for the rains status, the rotator tries to send E1000# .. the shutter sees EF0# .. F0# being the answer from F# , so it resets the E value to 0 as the conversion doesn't even see F0 as a integer value ( value.toInt() doesn't see it as int so it returns 0 ).

So There is definitely an issue where commands and response are being mangled.


Oct 21, 2018

All commands with a parameter use the value.toInt() or value.toFloat() code to convert it. If the param is not a proper integer it returns 0. So a g:XXX.XX# would see the :XXX.XX as a non valid float value and return 0


Oct 21, 2018

Yes!! Here is another excerpt from last night's ASCOM log showing shutter voltage getting mangled while shutter was asked to close and also right on a rain status request. Wonder where "M2" comes from?


18:44:49.665 Open Shutter Started

18:44:49.775 Serial Receive Short message (O)

18:44:50.322 ShutterState Get Value (1)

18:44:50.322 ShutterState Received 1

18:44:51.134 Rotator Get Slewing (0)

18:44:51.368 ShutterState Get Value (2)

18:44:51.368 ShutterState Received 2

18:44:52.360 ShutterState Get Value (2)

18:44:52.360 ShutterState Received 2

18:44:53.345 ShutterState Get Value (2)

18:44:53.345 ShutterState Received 2

18:44:54.235 ShutterState Get Value (2)

18:44:54.235 ShutterState Received 2

18:44:55.376 ShutterState Get Value (2)

18:44:55.376 ShutterState Received 2

18:44:56.157 Slow update Get

18:44:56.266 ShutterState Get Value (2)

18:44:56.266 ShutterState Received 2

18:44:56.266 Rotator Get Raining = (0)

18:44:56.266 Shutter Voltage Invalid (1329,1200M2)

18:44:56.266 Rotator Get Slewing (0)

18:44:57.360 ShutterState Get Value (2)

18:44:57.360 ShutterState Received 2

18:44:58.360 ShutterState Get Value (2)

18:44:58.360 ShutterState Received 2

18:44:59.360 ShutterState Get Value (2)

18:44:59.360 ShutterState Received 2

18:45:00.266 ShutterState Get Value (2)



Shutter voltage is returned without error except in this sort of situation.

Somehow the ShutterStatus update needs to be brought down to reason.



Oct 21, 2018

Invalid (1329,1200M2) -> yep I see the same thing and I'm trying to figure out how to fix that.

I made a change in the ATString to specify the actual address of each XBee instead of using the broadcast address to see if it helps but my gut feeling is that this is a code issue and not a xbee issue.


Oct 21, 2018

another example using debug on the shutter arduino :

<<< Command:E Value:K1000

Set acceleration to K1000

So the E command got mangled by the K1000 command.



Oct 21, 2018

So more weird thing with the XBee. I did set them to only talk to each other and not send to the broadcast address .. for some reason now it's no longer working :( and even setting it back to sending to the broadcast address is no longer working on the shutter XBee and when it sends response I don't see them (I have a 3rd XBee on a usb-serial board to monitor the traffic). It does get the request though so it does receive data but can't send anymore.



Thanks for your work on this guys. I had 1.1 installed because the INDI driver required it andrecently my shutter speed changed to a crawl. Like 30 min to open and close. I'm gonna be testing the offical nexdome beta in the next week and figured I'd get ready. I moved from the PI to the NUC, made windows my default dual boot (vs linux) and downloaded and installed 2.11E (with shutter). I normally have a hard time syncing the shutter and rotator. At first the shutter wasn't connecting. I pulled the power plug for 60 seconds and plugged it back in and both synced up and shutter speed is restored. Seemingly shutter and rotator both seemed fine (it's raining right now) from my initial command tests from SGP.


Any work done on different mount sync with something like an LX200?

@Tom Gwilym I would not think this has anything at all to do with the dome firmware. It should be completely in the client software running the dome. Here is hopefully a link to ACP's dome help regarding type of mount and dimensions. The rotator is just told where to move and it's firmware makes no decisions about type of mount OTA diameter, offset from RA axis, etc.. All of that is in the client software driving the mount and dome.




Load more replies
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))