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.

May 31, 2018

Debugging firmware


Edited: Jun 3, 2018

For the purposes of debugging I've added quite a bit of serial debug messages to the firmware that can be turned on and off by including or commenting out a single line in a header (.h) file.


The Rotator talks to the driver (or serial monitor) via the USB port and to the shutter (if present) over XBee radio. Because there is only one USB port the debugging messages MUST be turned off when using the ASCOM driver or the debug messages will confuse the driver and make a right awful mess.


The Shutter only has to talk to the Rotator over XBee radio so it's USB port can always be used for debugging messages but the fact that the controller moves with the shutter means you better have a really long cable and make sure it doesn't snag on anything if you want to monitor the shutter messages directly. Thankfully, I have this problem as well so the Rotator will also display some messages from the Shutter.


To enable Rotator debugging, load up the firmware in the IDE and switch to the RotatorClass.h tab then find the line saying #define DEBUG. If this is commented out (starts with two slashes "//" then just delete the slashes (or add them in to disable). Its near the top of the file with a line number in the 30s (may be a little lower or higher as the code changes). In the screenshot it's commented out and on line 30.

You can see there is actually a conditional block that starts with "#ifdef DEBUG" and ends with "#endif". If the #define DEBUG is not commented out then the first part of the block (above the #else) is used, if it is commented out then the second part is used. This called a macro in programming parlance.


The first part says that anytime it sees a "DBPrint()" it's to substitute Serial.print() and the same with DBPrintln() and Serial.println()". The second part says that if debug is not defined to substiture the DBPrintxx() line with nothing - basically excluding the code from the compiled program. The executable file is actually smaller with debugging disabled because all those DBPrint lines are excluded.


To see the debugging in action, delete the "//" in front of #define DEBUG then click on the serial monitor icon (the magnifying class on the upper right). That will open a window that shows the serial communications to and from the Rotator. It's best to not have the IDE expanded to full screen so you can have the IDE and the monitor side by side. The IDE is a bit annoying in that the monitor doesn't dock inside the IDE and will disappear behind the IDE when the IDE is selected. Keep them side by side and you won't have that problem.

Once your windows are layed out, upload the firmware with debugging enabled and after about a 12 second delay (giving time for the XBee to boot itself) you'll see the XBee and Controller initialization messages along with the information the shutter sends to the Rotator if you have one installed and programmed. If you watch for a while messages will periodically show up about the rain sensor and, if you have one, voltage messages from the shutter. If you don't have the RG11 installed you'll still get the rain messages but it'll always say it's not raining.

At the top of the monitor window is a textbox where you can enter commands for the Rotator (and shutter). The commands are listed in all the source files near the top of the .ino file (the first tab in the IDE by default).

To enter a command, look up it up in the source then type the single letter shown in the source. For example, if you want to know the current position of the rotator (in motor steps) type "p" (without the quotes) and hit enter or click the send button. The results will be completely unspectacular with just "p0#" showing up if you haven't moved the rotator after uploading. This is the message that is actually sent to the Windows driver. The "p" tells the driver it's getting a rotator position message, the "0" is the step position (can be in the hundreds of thousands) and the "#" is the message terminator so the driver knows that's the end of the message.


Dont worry about the line ending settings, the program will accept CR, LF, CR+LF, or manually using "#" at the end of the command (needed if the monitor is set to no line endings).


For a little more excitement you can tell the rotator to go to a step position. Enter "p3000" and the rotator will go to that step position and say STOP! when it's reached the destination.


You can also move the Rotator to an azimuth using the 'g' command. To see the current azimuth just type "g" by itself and to command it to move add the azimuth you want like "g10".


It won't take long before you notice some ugly formatting. The messages meant for the windows driver end with a "#" and do not have the usual line endings like CR or LF so there's no new line after them. This is to cut down on the number of characters actually transmitted between devices (one character instead of the usual 2).


These commands are subject to conditional checks before the firmware will comply. If the rotator voltage is too low you'll see "pL#" show up and the rotator won't move. There are also checks for rain, unknown position on the shutter.


If you look at the list of commands you'll probably notice that the rotator and shutter use (mostly) the same letters for the same commands except the shutter commands are capitalized.


Some time soon I'll be re-working the debugging so that it sends the messages to the Windows driver for display in a traffic window (you'll still be able to use the serial monitor too) and enabling or disabling debug messages will be done with a check box in the driver settings form.


For now do NOT have debugging enabled when using the Windows driver, it really messes things up.


Some other useful commands

v - Rotator firmware version

V - Shutter firmware version

m - Rotator status -1 CCW, 0 not moving, 1 CW

M - Shutter status 0 - Open, 1 - Closed, 2 - Opening, 3 - Closing, 4 - Unknown (stopped but not at end switch)

Commenting is off for this post.
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))