Limits for parameters about firmware HOT 7 CLOSED

You can look in the CommandProcessor.cpp file to see how commands are handled, the code isn't complicated. In most cases, parameters are limited by hardware and the firmware doesn't place any limits on them. Commands that take a step position or range, for example, are 32-bit integers and can generally take any valid uint32 value. Step positions are always in whole steps (not microsteps). So its up to the client application to decide what makes sense. In the ASCOM driver, I use the following:

Note: I don't recommend changing the circumference. There are a fixed number of teeth in the rack so this should never need to change. Dead zone can be changed but because of how the move commands work, dead zone is essentially rounded to 1 degree increments.

The microstep generator bandwidth is a bit less than 250Hz up to something way faster than any stepper motor would be able to handle. So that's 250 microsteps/sec or about 32 whole steps per second (8 microsteps per step) up to way more than the motors will be able to handle. The default of 600 steps/sec appears to work well. Note that the motors are 200 whole steps/revolution but this is further geared down by a (not quite exactly) 15:1 gearbox, so its about 3,060 whole steps (24,480 microsteps) for one revolution of the pinion. There are 288 rack teeth and 16 pinion teeth, giving 18 pinion revolutions per dome revolution, or 55,080 whole steps, 440,640 microsteps. See https://github.com/nexdome/Firmware/blob/master/Gear%20and%20Step%20Calculator.xlsx for details.

Given that the number of teeth in the rack is fixed at 288, then the dome circumference should be fixed at 55,080 whole steps. It's best to treat this as fixed and I don't recommend letting the user change it or you risk introducing positioning errors and making support incidents for yourself.

The shutter connection is automatic. You have to pay attention to the XBee event notifications to work out the connection state. You are looking for XBee->Online to signal that the shutter is connected. Any other state means it's offline and shutter commands will be ignored.

Open the shutter using @OPS and close it using @CLS

Did I miss anything?

from firmware.

Thanks! That answers all my questions. I have other concerns that I talked about in PR #5

from firmware.

Also, what's the maximum range in steps for the shutter? It appears that dead-zones are also applicable to shutter.

from firmware.

As for the rotator, you can set any uint32 value for the shutter range. The default is 46,000 whole steps which was chosen to be "a bit more" than where I empirically determined the most likely location of the limit switch magnet to be. This shouldn't really need to be changed in a client application and I don't recommend doing so - but that's up to you.

The shutter does not have a dead zone because it currently doesn't support moving to any position other than fully open or fully closed. The user can do so manually with the rocker switch, but the firmware only has commands for @OPS (fully open) and @CLS (fully close).

from firmware.

Thank you, that clears it up.

For battery voltage, it says it's in ADU? I am getting 878, how to translate that to volts?

from firmware.

from firmware.

Thank you! Now the INDI driver is ready for testing, once we are done with testing, I'll inform the Facebook group if they can test it more thoroughly. Thank you for the great documentation, design, and support!

from firmware.