Rotator commands blocking doppler thread

Hi,

Regarding Observation 2164901

I have observed numerous examples where doppler shift is not updated for a short while exactly at times when commands are sent down the rotator controller for tracking updates. Sometimes this can last from a few hundred milliseconds up to 3 seconds and can result in decode errors.

It looks like both doppler shift updates and tracking updates are done in separate threads, but not using the python multicore processing library (i.e. those threads are dispatched to the same core). If, for any reason, calls to hamlib and usb-serial are blocking that core, that makes the doppler shift thread hang. Doppler shift immediately resumes to the correct value right after.

The artifact can be seen on waterfalls, where the downlink signal suddenly gets tilted to the left while at the same time local stations show a clear vertical line (for about 1 to 3 millimeter when zooming in, which corresponds more or less to up to 3 seconds of waterfall).

It looks like the doppler shift thread is hanging the longer mid pass, which is when tracking updates are greater in degrees for azimut and elevation. It also looks like the hang time is more or less relative to the rotator trip time during its updates. Could it be that hamlib waits for the rotator to finish a tracking update and blocks its caller thread, and perhaps the whole core during that short time? Or would there be another reason for this phenomenon?

Does anybody know of a fix?

Tx & 73,

Bernard KI6TSF
Mountain View, CA

Wondering if this issue is related to https://gitlab.com/librespacefoundation/satnogs/satnogs-client/-/issues/354.

@ki6tsf if this insists could you please open an issue at https://gitlab.com/librespacefoundation/satnogs/satnogs-client/-/issues/?