search

nexdome / Firmware

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

Dead Zone default is too high #34

Closed NameOfTheDragon closed 3 years ago

NameOfTheDragon commented 3 years ago

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.

StephenBogner commented 3 years ago

With respect to Issue 33 (ASCOM NexDome Driver), is is possible that having too high a value for the Dead Zone could be contributing to the erratic behavior? I recall seeing an @SRR return that had this value at 400 in the 3.4.0 firmware as I was troubleshooting this issue. If the tolerance is set at 1 degree (55080/365 = 151 steps) then even after moving 1 degree it would not have exited the dead zone, which sounds like something that could cause an issue. Perhaps there should be some relationship between the dead zone and the tolerance (say dead zone must be less than 50% of tolerance)?

Rojoyinc commented 3 years ago

I changed from 300 to 75. I'll do some test in daylight tomorrow. Sure home I can get this fixed. Ron

NameOfTheDragon commented 3 years ago

Perhaps there should be some relationship between the dead zone and the tolerance (say dead zone must be less than 50% of tolerance)?

There is no concept of "tolerance" in the firmware so I'm not sure how that would help. A large dead zone should not contribute to any error, since it does not cause the firmware to lose track of position.

NameOfTheDragon commented 3 years ago

Transferring issue to the firmware repository.

StephenBogner commented 3 years ago

Perhaps there should be some relationship between the dead zone and the tolerance (say dead zone must be less than 50% of tolerance)?

There is no concept of "tolerance" in the firmware so I'm not sure how that would help. A large dead zone should not contribute to any error, since it does not cause the firmware to lose track of position.

I am thinking in terms of the interaction between the "deadzone equivalent" in NINA (i.e. Tolerance) and the deadZone in the NexDome firmware. If the program higher in the calling hierarchy has a tighter/smaller tolerance than the program lower in the hierarchy then this will almost certainly have a potential to create instability in the system as a whole.

As I understand it, the calling program (NINA) tells the NexDome ASCOM driver to command a slew to a calculated Azimuth, and then hands off control to the driver until the driver reports back that the slew is completed. My question is about what happens when NINA (calculating from the Tolerance value it has, say 1 degree) tells the NexDome driver to make a slew of some small value - less than deadZone (say 300 ticks or about 2 degrees) - and the driver makes that command to the Firmware, which has logic to ignores it because it is less than the deadZone constant and therefor simply returns without making any slew. Does the driver know that no movement has occurred, and does it pass this fact on to NINA, and how does NINA react to this? Does it simply re-command the slew? Does it keep doing this over and over until it gets a reaction? It just seems a lot cleaner to me to have the dead zone/ignored zone get tighter as it descends the calling hierarchy.

That said, I agree with you that I can't say that I see how this directly relates to the OOC behavior reported and reproduced in NexDome ASCOM Issue 33 because it ought to cause the system to not move at all, rather than to move through a number of 360-degree rotations. Odd.