Benign "non-slew" slew when idle

[ron crouch]

This is with firmware from beta installer. I first noticed it with the first version of beta3. After startup and connection an ascom client will report a slew every 6 sec. No motion at all.. Like a heartbeat. The non-slew event lasts about 5 sec. It’s possible my introduction of a +2 degree bias in my client’s preferences are responsible because I made that change with previous firmware as well. As imaging is about to begin I’ll test that in the morning. Perfectly benign.

[Tim Long]

I believe this is why I added the ‘dead zone’ in the firmware. The display is responding to actual real slews being issued by the client application (see the log file to verify). You can view the log output in real time using SysInternals' DebugView.

The dome slaving algorithm in the client app computes the target azimuth as a floating point number, which must then be sent to the firmware as an integer number of degrees. The target can’t always be represented as an integer number of degrees or whole steps. Furthermore, this integer step position then has to be converted back to a float when the client application reads it back. This is a real-life physical example of loss of precision when converting from float to int.

So because the software constantly sees the dome as “not quite there” (by a fraction of a degree) it will keep trying to bump the dome every few seconds. The client app has no idea of the dome’s precision, and testing equality of floating point numbers is inherently risky, so the effect is that it will constantly try to send tiny fraction-of-a-degree slews every few seconds. Depending on the type of drive used, this can either result in “hunting” (for DC drives, where the dome oscillates around the target azimuth) or in the case of stepper drives, the motor coils constantly energize and de-energize with a loud annoying “clunk”.

The remedy to this, in the firmware, is the addition of the “dead zone” which is, in effect, a minimum slew distance, which eliminates the unwanted effects on the motor, which is why you don’t hear it clunking. The effect of this on the firmware is that there is a minimum slew distance of 1.5 degrees before rounding.

The reason you see the indication in the UI is because the driver sees the slew command from the client app and thinks a slew is about to start. The state machine reacts as for any slew. Then the firmware command is issued, and the firmware immediately reports that the slew has stopped (before it even starts). The driver sees the end of slew and turns off the annunciator in the UI.

Consider this: without the “dead zone”, every time you see the UI blip the annunciator, there would be a loud “clunk” from the motor as it started and stopped instantly. The dead zone fixes this, but we are left with the indication in the UI. It is probably an accurate representation of what’s happening, because the UI is correctly indicating that the client app requested a slew (which the firmware then rejects). so I think we can reclassify this as a feature and Not A Bug :)

It would be possible to review all this if it turns out to be a problem in practice, but with the code space basically all used up, it is something that should not be done unless really necessary.

If you are happy with this, please mark the issue as Resolved of Closed.

[ron crouch]

Thank you. Makes good sense. I would close this but lol I’ve not yet had coffee and cannot see where to do that

[Tim Long]

Working as designed. No fix needed