Race condition on azimuth and elevation positions

[Saied74]

There is a possible race condition between the sun and moon tracking functions and move and its related function are manipulating the same position data. Need to protect it with a mutual exclusion lock.

[Saied74]

I have put all reads and writes to app.currAz and app.currEl (target position) and app.azPosition and app.elPosition (actual position) through a set of functions (in main.go) that use the Go sync.Mutex lock. Need to test it thoroughly to convince myself this was it.

[Saied74]

It is hard to know if this has been fixed or not, so I will keep it open for a while.

[Saied74]

Two days of testing by tracking the Sun and the Moon showed that with a 12 volts power supply, the symptoms of the race condition (current position data corrupted, the system losing where it is and movement of the dish to where it erroneously thinks it is to the target position) are gone. So, at this power supply voltage, the solution (using sync.Mutex to control access to position data from various threads) is a success.

The power supply was increased to 15 volts and some of the same symptoms reappeared. Not with the same frequency as before addressing the race conditions but nevertheless, a problem. The encoder pulses entering the RoboClaw were viewed on the scope. These pulses are between zero and 3 volts and when the power supply is at 15 volts, there are noise pulses as high as 2 volts and in the order of 10 microseconds in duration. A low pass filter using a 5K resistor and 0.1 MFD capacitor was simulated with LTSpice and it showed that it will attenuate the noise pulses and not materially impact the actual pulses. The filters were installed on all four lines and the system was tested for a day tracking the sun and then tracking the moon. None of the problems reappeared. This problem is considered closed in release v0.61