Testing of pull request #30 has revealed a puzzling issue as follows:

@FRS
FRS3.4.0-auto-close.5
@ZDS
ZDS
@RRS
RRS46000
@RWS,20000
RWS
@RRS
RRS200009

The final reading of @RRS returns the wrong value, always some extra data appended to the end.

Some thoughts on this:

• The XBee isn't implicated because it happens when issuing the commands locally on the shutter (as above).
• The command and payload appears to arrive intact when sent remotely from the rotator, as in this example:
  When sending @RWS,20000 from the rotator, the shutter emits Cmd @RWS,20000 which suggests that the data is arriving intact.
• Reading the configuration and performing microsteps-to-steps conversion doesn't appear to be implicated, because reverting to factory defaults restores the correct value, which it then reported correctly.
• The appended spurious data is always "09" so it doesn't seem to be a random memory corruption.

Conclusion: something is happening to the value between receiving it as a command and the value being written into the configuration structure.

This needs to be traced in detail to determine what's going wrong.

The 4.0.0 ascom properties seems to only want to show 4.0.0 files and no actual paths - how do we update to 4.0.1?

Problem report #33 is not fixed.
Adruino 1.8.19, ArduinoSTL 1.3.3. You have us switch to "Arduino AVR Boards" by Arduino 1.8.2
otherwise sketch does not compile

I posted this in the wrong version. Reposting here. (may be it's fixed already) as a update was just released?

I had an issue where my shutter sprocket slipped a few turns. (I think due to friction build up in the shutter panel). Once the sprocket slipped the shutter position count was in error. When the driver showed and stated the shutter was closed. (it was in reality very much open). There was no way for me to RESET and close the shutter without going out there manually. If this had happened the week before (I was 800 miles away) and it would have been open for days. !!!!

It did it a week later again. I got up at 3am from bed and closed it manually. In doing so (not sure why) pressing the rocker on the shutter box to close would only do so in about 2-3inch increments and then stop. A release and repress of the rocker continued another 2-3 inches and after 20 or so presses it was closed.

Requirements

• When the battery voltage falls below a threshold, the shutter should auto-close

• While the battery voltage is below the threshold, the shutter should ignore open commands.

• The toggle switch should always work regardless of battery voltage

• Auto-close should work regardless of the wireless connection to the rotator

Considerations

• Different battery chemistries have different voltage discharge curves, so the threshold needs to be user-configurable

• The default setting should err on the side of closing too soon (safe by default)

• There is very little available code space and significant optimisation effort might be needed.

• The ASCOM driver will need to be updated to allow the threshold to be set

• Other drivers and plugins (X2, INDI) will also need to be updated (communication).

After upgrading the firmware to 4.0.0, the manual rotation button on the physical device no longer works. ASCOM control still functions though.

Examine which XBee modules and options are supported and in production from the manufacturer, and which ones will work with the current firmware.

Shutter, but not dome is going unresponsive after some indeterminate time. Possibly more than a day. This is probably the 5th time now. Currently on 4.0.1 but happened on 4.0.0 as well. There's no way to reset it remotely...? How about a xbee based command to make it reboot? Magic packet or something - I have a spare xbee usb controller I could use to do such a thing.

During development of release 3.0.0, XBee Series 3 devices were tried and found not to be 100% backward compatible with the XBee Series 1 devices. Although they are pin-compatible and the API is very similar, there are some minor differences and the firmware as currently designed will not work with them.

XBee series 1 has been discontinued by the manufacturer and although they are still available, clearly this is not going to hold true forever and we will need to move over to the XBee series 3 devices.

@nexdome has requested that @NameOfTheDragon investigates what changes would be needed to make the firmware compatible with both S1 and S3 XBees.

I apologize if this is not the correct place to ask such questions, but as I was developing the INDI driver, I needed some clarifications:

Max/Min limits for parameters:

• Acceleration Ramp
• Dead Zone
• Travel Range
• Velocity

Do you need to explicitly connect to shutter? or the firmware automatically connect to it? How do you open and close the shutter? By issuing steps 0 to fully open for example?

@NameOfTheDragon commented on Wed Oct 02 2019

On power-up, the firmware loads settings from EEPROM and performs an integrity check on the data. If the integrity check fails, then default settings are loaded.

In specific circumstances, EEPROM can be corrupted in a way that still allows it to pass integrity checks. In this situation, the device will behave erratically. Symptoms reported include the user needing to press the rocker switch repeatedly to get the dome/shutter to move.

The specific circumstances that lead to this corruption are when the user has upgraded to V3 firmware, downgraded to V2, then upgraded to V3 again. This happened a few times during alpha testing but should not be a problem post-release.

Workaround

1. Download the EEClear.hex firmware image from the GitHub repository and drop it into C:\Nexdome-Firmware
2. Open the driver SetupDialog and use the firmware update utility to uploed the EEClear.hex image. This will immediately clear the settings from EEPROM.
3. Upload the normal operating firmware and continue to use the software as normal.

Proposed solution

Write the integrity check 'fingerprint' at the start of the settings instead of at the end. Then the 'fingerprint' will be the first thing to be overwritten instead of the last.

Firmware/TA.NexDome.Shutter/TA.NexDome.Shutter.ino sketch shows to big.

Thank you for the great documentation. I'm developing the INDI driver for NexDome v3 and the documentation is pretty detailed and straight forward.

Regarding the events, what's the delimiter? Is it <CR><LF>

And just to confirm, the XBee, Rotation, and Shutter events are not terminated by a '#'?

This is an issue for @nexdome to review and decide whether there is any feasible hardware remedy.

Problem

The DFRobot Arduino Leonardo with XBee socket leaves the XBee reset pin disconnected. This is OK technically because it has an internal 50K pullup, but it means there's no way for the Arduino to perform a hard reset of the XBee. This is a problem because the XBees sometimes get into a state where they either refuse to associate with another XBee, or refuse to enter command mode so that the firmware is unable to send configuration and the only fix seems to be to power-cycle the system.

As you can see from DFRobot's circuit schematic, the XBee reset pin is left open.

According to the XBee data sheet:

The /RESET signal is forbidden from being driven high and this is probably why it was left unconnected, since Arduino output pins might drive the signal high after a power-on reset.

However this creates a problem where XBees can sometimes get 'stuck' (despite the firmware issuing a soft reset) and there's no way to recover other than to power off the system, which is quite inconvenient for users.

Questions

Therefore, the questions I would like to raise for discussion are:

• Would there be any point to connecting up this reset line? Would it in fact let us reset the device?
• Could it be done in such a way that the Arduino can safely activate it?
• If so then, would it be practical to modify the electronics to enable this as part of the production process?

This problem was raised when a user observed the dome apparently trying multiple times to find the home sensor. The user was using the X2 driver.

Rodolphe reports:

It retries because when it stops it’s not on the home magnet, it backs too much depending on speed and acceleration Even without myb plugin by using a simple serial terminal I can reproduce the home miss, When I get back home tonight I’ll make a small movie of what happens when the “dome” backs back to the home sensor and the speed is too high and/or acceleration is too long.
This is 100% reproducible and when you send a @rrr the atHome flag is 0.

To which I have replied:

OK so I think you’re checking the home flag at the end of all that and seeing it as false. That might be a bug, I’ll check into it. During the development I changed how homing worked because my original method didn’t work very well. The method I finally settled on works very well and has good repeatability, but It’s possible that I’m not handling the home flag correctly.

Hi Tim.
Based on a few lofs for 2 users I see timeout every time I request the shutter position 👍

[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] sending : @PRR


[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] response : ':PRR20196'
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::getDomeAz] szResp = PRR20196
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::getDomeAz] m_nNbStepPerRev = 55080
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::getDomeAz] m_nCurrentRotatorPos = 20196
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::getDomeAz] dDomeAz = 132.00

[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] sending : @PRS
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] response : ':PRR20196'

[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] sending : @PRS
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] response : 'XB->Online'
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] XBee status : 'XB->Online'
[Thu Nov 14 20:26:09 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:10 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:12 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:13 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:14 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:16 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:17 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:18 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:18 2019] [CNexDomeV3::domeCommand] response : 'XB->Online'
[Thu Nov 14 20:26:18 2019] [CNexDomeV3::domeCommand] XBee status : 'XB->Online'
[Thu Nov 14 20:26:19 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:20 2019] [CNexDomeV3::getDomeEl] ERROR = PRR20196

as you can see I do get some of the inline messages, like the XBee online status and no actual :PRSxxxxx response to the @prs command, but I do get the same response as the previous command (which was a @prr in this case).
So there is either a timeout in the XBee communication with the shutter or in the firmware somewhere.
Is there a minimum amount of time required between commands ?

Reported by Rumen Bogdanovski:

there is a mistake in the description:
AR[R/S] Returns AR[R/S]ddddd not ARddddd as listed.

When the software closes the shutter it appropiately shows "Closed" at the end of the cycle. However, if you use the manual control to tweak the shutter just a bit further closed, the software reports "Open" even though the magnetic switch is still in the closed position. Disconnect and reconnect and the software once again shows "Closed." I'm running the latest 3.3 version firmware on both shtter and rotator.

See also:

• https://forum.arduino.cc/index.php?topic=696369.0
• mike-matera/ArduinoSTL#56
• arduino/ArduinoCore-avr#287

Projects targetting AVR boards that #include <ArduinoSTL> fail to compile when upgraded to boards version 1.8.3. See the linked discussions above for details.

Workaround: for the time being, NexDome firmware must be compiled with AVR Boards version 1.8.2. The problem should be resolved when boards package 1.8.4 is released.

Not quite sure how to qualify this one.. but, if I'm at position 108 and do a @gar;108, I get a :GAR response but I would also hope to get a :SER response after to indicate the end of the move even if there was no move and will not get a :left or :right
So it's not a bug per say, more of a behavior question.
Thanks
Rodolphe

It would be really ideal to have a way to do this.. every once in awhile this happens..
a way to force close the shutter when it stutters and loses position due to a stutter/slip on closing..

IE: it closes, stutters, then stops 3/4 of the way down, because it thinks its at 0% open (or vice versa it goes up all the way but is now at 90%)
A simple way to override the close button to keep going into the negative would be ideal. In this example -10% would be fully closed.

The dead-zone default value is 300 steps (~2 degrees). This was put in when the slewing resolution was 1°, but now that we have precision slewing it should be much smaller. A value of 75 steps (~0.5 degrees) seems to work well and would be a good starting point.

I uploaded the 4.0.1 firmware to both my rotator and my shutter. Both reported successful uploads. However now I cannot connect to the dome. I get the attached error message every time I try. The port# is correct. I've tried cycling the power on everything with no success. I also tried reinstalling 4.0.1 and also reverting to 4.0.0 with no success, although firmware is installed correctly according to the message.
I'm stumped. The log just shows a failure to connect. I have no problems installing the firmware.

Reported by @rpineau

The find home now works very well at all speed.
But .. There might be a new issue with this firmware.
As expected we can get status message between a command and its response but usually the response comes back fairly quickly after.
With the new firmware I see huge timeout between the command, status messages and the actual response :

[Sat Oct 26 16:37:08 2019] [CNexDomeV3::domeCommand] sending : @PRS

[Sat Oct 26 16:37:08 2019] [CNexDomeV3::domeCommand] response : 'XB->Online'
[Sat Oct 26 16:37:08 2019] [CNexDomeV3::domeCommand] XBee status : 'XB->Online'
[Sat Oct 26 16:37:10 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:12 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
^X[Sat Oct 26 16:37:14 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:14 2019] [CNexDomeV3::domeCommand] response : ':BV823'
[Sat Oct 26 16:37:14 2019] [CNexDomeV3::domeCommand] m_dShutterVolts : 12.07
[Sat Oct 26 16:37:16 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:18 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:18 2019] [CNexDomeV3::domeCommand] response : 'XB->Online'
[Sat Oct 26 16:37:18 2019] [CNexDomeV3::domeCommand] XBee status : 'XB->Online'
[Sat Oct 26 16:37:20 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:22 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:24 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::getDomeEl] ERROR = PRR0

As you can see the @prs command is sent at 16:37:08, then we get 2 "event notifications" (XB status and shutter voltage) at 16:37:08 and 16:37:14
and then another XB status at 16:37:18
and a response arrives at 16:37:24 , that's 16 seconds after sending the command, and it's not the proper responser (hence the ERROR label).
So there is something weird going on when requesting shutter states.
This is not happening often but I saw it once on connect and another time (above)

I see more response that do not match the command send :

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] sending : @SWR

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : 'STOP'
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : 'Hstop 4'
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] sending : @SWS

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : ':SER,0,1,12347,0,30'  <==== This is not a proper response to @SWS
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] sending : @PRR

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : ':SWR'  <==== This is not a proper response to @PRR
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::getDomeAz] szResp = SWR
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] sending : @PRR

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : ':PRR0'

Originally posted by @rpineau in #11 (comment)

@rpineau later commented:

I agree that this is potentially due to a XBee response being lost as I only see these on shutter commands. On my test rig the 2 XBee are about 15cm from each other so distance here is not the issues.
Between the 2 "XB->Online" status there are 10 seconds during which we also get a battery update. So could it also be that the Shutter XBee didn't receive the command and is therefore not responding to it.

My rotator was missing the xbee and I can only find the Xbee S2C in the UAE.
Should the firmware and codes change to match this version of the Xbee?
Can I use the S2C on the rotator and S1 on the shutter?
If I change the shutter xbee s1 to the S2C version as well (both shutter and rotator will have S2C) would that work?

I just performed "open" on my observatory remotely with the nexdome control software on windows. Unfortunately something was stuck and I'm at a distance so I don't know what that is. However the shutter kept trying to open, despite commanding close, a few times. The state then ended up in "close" state but I had to have somebody shut off the shutter for me. Loud racket, probably not good on the battery or motor to do indefinitely.

Can you add an emergency stop, at least that is recognized to the xbee comm frequency?

Due to the 1 degree default azimuth command resolution, telescopes with large apertures can experience vignetting of the aperture by the edge of the dome slit as the telescope/mount moves continuously but the dome only moves on 1 degree changes. For astronomers doing non-differential photometry this issue creates discontinuities in the light curves that are difficult to correct for. Problem observed with a Celestron C14 EdgeHD with a 0.7 reducer.

TA.Nexdome.Server-2019-11-30-MSI_dolphinzilla-MSI.log
TA.Nexdome.Server-2019-11-29-MSI_dolphinzilla-MSI.log

Some users have reported a drift in azimuth over an observing session. User Christopher Duffey spent time troubleshooting this with me and showed me that the effect was real. We were able to provoke a drift of about 3 degrees in 10 minutes, using excessively high dome refresh period (~3 seonds) in TheSky X. Christopher seemed to intuitively know what was needed and made the process much easier, for which we owe him a debt of gratitude.

We tried various workarounds:

• decreasing max motor speed and increasing acceleration ramp time - no effect
• increasing firmware "dead zone" setting to 75 steps (~0.5°) - improved accuracy

The working hypothesis is that many small nudges somehow introduce lost steps. The exact mechanism isn't clear but it might be linked to the fact that the motors are de-energized after each slew, and somehow a lost step creeps in when there is no holding torque.

Increasing the "dead zone" in the firmware to 75 steps [@DWR,75] results in tiny movements being ignored by the firmware and seems to eliminate the problem.

Therefore, we should look at the possibility of:

1. Not de-energizing the motors after each slew, or making this a user-settable option. This may or may not solve the problem and will probably make the motor run hot, so the impact needs to be assessed.
2. Choose a better default value for dead-zone (it appears to be 1 step, currently, although the documentation has it much higher).
3. Consider enforcing a minimum value for dead-zone.
4. Raise user awareness of the importance of the dead-zone.

I am running a Pointing model t-point and it is supposed to skew to several targets and take pictures. I did not have this problem when using the older x2 driver.

The problem is that it will get stuck at ‘slewing to target’ and will not move on to taking a picture and image linking. It will do one or two targets and then get stuck.

If I quit the Pointing model and do a normal slew to target it seems to act normally.

Also during this time it looks like it reports in the SkyX dome controller that the dome azimuth is 0.0 (zero) when it is not.

A user pinged me as there is an issue when using both computer control and the rocker switch to move the dome.
when moving the dome via the rocker switch the position is properly updated but the at home status is not.
Here is how the user tested this and what I got from my log :

1. Connect Dome = OK; Note the dome is starting out at home (Az164)

Yes.

2. MANUALLY GoTo Az146 (approximately)
Yes, I see it

3. Find Home = DOME DOES NOT MOVE!! Az changes to 164 and dome reports Finding home complete. No errors <<<===

This is where we see the issue
The position is :
[Sat Dec 7 08:15:03 2019] [CNexDomeV3::getDomeAz] dDomeAz = 145.95

I send the command to get the status :

[Sat Dec 7 08:15:03 2019] [CNexDomeV3::domeCommand] sending : @srr

The response is :
[Sat Dec 7 08:15:03 2019] [CNexDomeV3::readResponse] response = :SER,22331,1,55080,25092,150#

If we decode it :
SER : status response
22331 : position in tick counts
1: At home status , 1 means at home <==== THIS IS NOT TRUE as we moved.

4. Use Command to GoTo Az150 = Dome moves to what it thinks is Az150 which is now actually about Az132 or so

It’s like as you move manually some internal sync is not done and it’s lost !

5. Find Home = Dome goes all the way back to home sensor; Az reports 164 (position is now correct)
Yea, because this time it comes from the serial command so probably goes through a different code path.

So this is clearly a firmware bug when using manual control with computer control at the same time

In normal use, we expect to see a single activation of the close sensor and in most domes, this appears to be the case. However there has been at least one case (Sylvain Lefebvre) where the close sensor appears to trigger multiple times, resulting in the close operation not stopping.

The mechanism is not fully understood, but during troubleshooting via Facebook, Sylvain was asked to remove the close sensor magnet and then the shutter did close and stop correctly.

So there is definitely a hardware component to this issue, but there is also a firmware component. When closing the shutter, multiple activations of the close sensor should be idempotent. The firmware needs to be improved in this area.

I am working from 3.2.1 beta and I am still having problems where the shutter gets dropped if the other controller is turned off.

I have been leaving the dome on but if power blinks or anything goofy happens, I have to go up and reset the shutter.

I saw there is a 3.2.1 firmware folder, but I could only find the rotator .ino files. Is there a compiled/ready to go .hex file for it?

Dave Compton

I'm integrating NexDome into NINA, which is open source AP imaging software. I'd like to be able to change the destination of an active slew request, but it doesn't seem like there is a way to do it either in the ASCOM driver or the firmware. My observation so far is that the firmware ignores @gar commands if a slew is in progress, and the only way to stop it is to abort a slew first (@SWS). This has a few downsides:

1. If a shutter operation is in progress, that is aborted to and the shutter is left in an error state (you have to fully close before you can try opening again)
2. The movement is abrupt
3. Perhaps the instant stop without deceleration is bad for the hardware if done regularly?

Would it be possible to add support for some combination of the following?

1. Soft abort with deceleration
2. Accepting new slew requests to change the destination without requiring a stop first
3. Separating shutter stop from dome stop, so they can be controlled separately if needed

The current 3.0.0 firmware, when responding to shutter commands, is missing the leading ':' in the response.