nexdome / Firmware

NexDome Dome and Shutter Motor Kit Firmware
https://www.nexdome.com
Other
3 stars 7 forks source link

Auto-close on low battery volts (iss #29) #30

Closed NameOfTheDragon closed 3 years ago

NameOfTheDragon commented 4 years ago

The changes in this pull request implement auto-close on low battery volts in the shutter firmware. They also try to address a random reboot in the shutter, although this may actually be power supply related and therefore not fixable in firmware.

Instructions for Testers

The firmware build(s) are attached at the bottom of this comment. Download the relevant zip files and extract the .nex file into C:\NexDome-Firmware (you should see your existing firmware already there, firmware builds always contain the version number as part of the filename, so they will not overwrite anything and are readily identifiable). Versions use Semantic Versioning, so release builds are always vX.Y.Z and prerelease builds are always vX.Y.Z-something.count.

The new version adds the following commands to the firmware:

@BRS - Battery volts threshold Read Shutter @BWS,nnnn Battery volts threshold write Shutter, nnnn is in the range 0 to 1023, default is 0 (disabled).

To enable auto-close on low battery, you need to write a non-zero value using the @BWS command. Eventually this will be in the ASCOM driver but for now it must be done manually. The values are in raw ADUs (analog-to-digital units). 1023 represents 15 volts, scaled linearly. So if you wish the shutter to auto-close at 11.5 volts, then compute your value as:

1023 / 15 * desired threshold in volts {round to the nearest integer}

so for 11.5 volts, that would be 784 rounded to the nearest whole number.

So you'd issue the command: @BWS,784. As long as the shutter wireless link is up, you can issue shutter commands to the rotator and they will be forwarded over-the-air. The response should be :BWS#. Usually the response to a successful command is to echo the command verb back. The shutter produces the response, so if it doesn't come back then it probably hasn't been received. Make sure the rotator is reporting XB->Online every few seconds.

You can see your current voltage level by observing the notifications that come from the rotator. Battery voltage is reported as :BVnnn# about every 30 seconds. There will be natural variability in the measurements due to component tolerances and you can use these periodic notifications as the basis for a reasonable threshold for your system. I actually get :BV768# when I feed in 11.5 volts from my calibrated bench supply, which is within the typical 5% tolerance of electronic components. So your readings may vary by plus or minus 30 (~2.5 V) from the computed figure.

Don't forget to save your settings to EEPROM if you want them to become permanent. Issue the @ZWS command (EEPROM Write Shutter). If you don't do this, your settings will revert when you power-cycle the unit or if it reboots for any reason (which might be what you want if you are experimenting).

Settings are compatible across any builds with the same major version number, so you can safely swap back to the released firmware if you need to without losing your settings.

If you find any bugs, please report them here on GitHub under the Issues menu. Questions or general comments are probably best sent by private message to me on Facebook

Things to look out for

  1. Is the computed theoretical threshold close enough to the actual battery voltage?
  2. Does the shutter close as expected at more or less the correct battery voltage?
  3. Is it possible to open the shutter when the battery volts are too low?
  4. Is there any indication that the shutter firmware might be rebooting at random?
  5. Does the ASCOM driver still work OK?
  6. Does the ASCOM driver react badly when the shutter auto-closes? (I haven't tried this yet!!)

Prerelease builds for testers

Shutter-3.4.0-auto-close.5.zip

NameOfTheDragon commented 4 years ago

Potentially breaking change:

the @FRR and @FRS commands (read firmware version from rotator and shutter, respectively, now return the full 3-letter command (FRR or FRS) instead of just the FR. Clients may need to be updated to take account of this.

In the ASCOM driver, I am using a regular expression to test for status updates: ^FR[RS]?(?<SemVer>[^#]+)$

According to the rules of Semantic Versioning, this technically requires a major version update, although that seems excessive in this case. Thoughts?