OK, I decided to have a go at it :-).
I simulated the AVX mount, which is a derivative (subclass in my program) of the SynScan protocol. With the OTA pointed close to the Prime Meridian (i.e., between the NCP and the Zenith) about 1/2 a degree in Declination from the NCP (i.e., just a little higher in altitude than the pole -- I am at North 45.58º).
I added a bunch of debug prints to log mount commands from ASIAIR and also time stamped them.
Before starting the polar alignment, the ASIAIR periodically polls the mount...
2020-11-21 21:44:04.126 MountSim[6581:2028251] e
2020-11-21 21:44:04.169 MountSim[6581:2028251] t
2020-11-21 21:44:04.205 MountSim[6581:2028251] p
2020-11-21 21:44:07.766 MountSim[6581:2028251] e
2020-11-21 21:44:07.818 MountSim[6581:2028251] t
2020-11-21 21:44:07.850 MountSim[6581:2028251] p
...
Notice that it repeatedly sends the e (Synscan getPreciseCoordinates command), t (getTrackingMode) and p (getPointingState) at a repetition rate of about one group every 3.64 seconds (don;t ask me what the significance of "3.64" is :-) :-)
Once I started the Polar Alignment process, I see this sequence
Passthrough 36
NexStar slew destination 16 direction 1 rate 5
2020-11-21 21:44:07.902 MountSim[6581:2028251] P
A little bit of explanation... the NextStar stuff apparently is made up of multiple hardware components (my guess is a bunch of disparate microprocessors). One of them controls the RA motor and another (could be the same microprocessor) controls the Declination motor, etc.
These controls are not in the original SynScan protocols, so what happens is that the computer (ASIAIR in this case) has to send a "passthrough" command. The main parser ignores the command and sends the command instead to a different destination.
The passthrough commands also appear to be specific to the mount manufacturer or even mount version (that is why the SynScan/Celestron mounts are a mess if you don't use EQMOD).
The Passthrough command is "P" (capital P) with some arguments. "36" is the NexStar MC_MOVE_POS (turn motor in the positive direction, presumably?) . Notice in the first set of Passthroughs, the destination is 16 (RA motor), direction of slew is (1) which is Westerly, and the rate is 5 (one of the indexed slew rates of the AVX).
So, the first group of passthrough starts the RA slewing westerly at the AVX rate of 5 (which is I believe 200x sidereal rate; sorry of I am not familiar with the mount; I have never owned, nor wish to own a Celestron mount :-). For example, I have no idea why it has a positive motor movement, and also a direction argument.
The passthrough group is followed by one "e.t.p" polling group and then this sequence appears (notice the time stamp is 1.716 seconds after the start slew command above):
Passthrough 36
NexStar slew destination 16 direction 1 rate 0
2020-11-21 21:44:09.618 MountSim[6581:2028251] P
Notice that it is still addressing the RA motor, but this time, notice the slew rate is now 0. This is how the NexStar stops a slew.
Interestingly, this is immediately followed by another passthrough command
Passthrough 36
NexStar slew destination 17 direction 1 rate 0
2020-11-21 21:44:09.721 MountSim[6581:2028251] P
Notice that the destination is now 17 (the Declination motor). And the rate is 0. So, even though ASIAIR never commanded the Declination motor to start, it sends it a stop command anyway. As a matter of principal (I started programming computers in 1966), I would not issue unneeded commands like this. It is not documented what the mount would do if it is commanded to stop a motor that has never been started. But hey, that is me, and I am past my "sell by" date (I am so old, Oregon cannot ask me to go for Jury Duty anymore :-).
Surprisingly, there is no position polling (you would think it needs to poll once to get the "current location" (perhaps therein lies the ASIAIR bug, who knows! It immediately send another passthrough command:
Passthrough 37
NexStar slew destination 16 direction -1 rate 9
2020-11-21 21:44:09.881 MountSim[6581:2028251] P
37 is the NexStar MC_MOVE_NEG command. The direction is -1 (eastwards), and the rate is really fast at 9; which I believe is 1500x sidereal rate for this mount, although I don't know for sure.
So, perhaps the first slew and this slew combines to clear backlash. We won't know unless ZWO decides to disclose the reason for the reversing slew, and at different slew rates.
This is followed by a bunch of position polling, until the next passthrough command (notice that it is 23.9 seconds later):
Passthrough 36
NexStar slew destination 16 direction 1 rate 0
2020-11-21 21:44:33.776 MountSim[6581:2028251] P
A rate of 0 indicates this is a stop slew command to destination 16 (RA motor).
And as you might expect now (snicker), it issues a gratuitous stop for the Declination motor too:
Passthrough 36
NexStar slew destination 17 direction 1 rate 0
2020-11-21 21:44:33.956 MountSim[6581:2028251] P
No, we are not done yet!
After one position polling. It issues yet another passthrough command:
Passthrough 36
NexStar slew destination 16 direction 1 rate 0
2020-11-21 21:44:44.180 MountSim[6581:2028251] P
A gratuitous stop RA motor. And (this is getting old...) another gratuitous stop Declination motor:
Passthrough 36
NexStar slew destination 17 direction 1 rate 0
2020-11-21 21:44:44.328 MountSim[6581:2028251] P
You think we are done by now, right? Nope. It sends yet another Stop RA motor, and another Stop Declination motor. I think it is trying to say "Stop, dammit!" just in case the USB serial port is flakey :-).
Anyway, that's what I saw. It did move my simulated mount by about 60 degrees (ASIAIR says 62 degrees). But at least it moved the simulated mount. Many folks with the AVX says their mount went on strike and did not move.
By the way, did you say you are below 45.00ºN? I forgot to try the case for lower latitudes.
Chen