AZ-GTiのアライメント情報はsynscanアプリ側で保持していると考えるのが合理的

# twitterで記述するには重すぎるため、ざっとですがまとめてみました。

アプリをアンインストール&再インストール、またアプリのデータを削除(アプリ管理から)してみたところ、両方の場合共その後アライメント済みの架台に接続してもアライメント情報は初期状態のまま。
また、以前2台の端末を順次一つの架台に接続するテストをした際、2台めでは1台目のアライメント情報は利用できなかった。

勿論、synscanのマニュアルには、違った架台に接続した時にはdefault modelに戻る、とあるのでその作用とも考えられる(新規導入やデータを削除したアプリは過去に接続した架台の情報を持たないので)が、もし架台側にアライメント情報があるのであれば、仕様として接続してきたアプリ全てにアライメント情報を書いてやれば良いだけのはず。
そもそも、違った架台に接続した場合にdefaultに戻る、という記述自体が、アプリ側で保持しているアライメントパラメータを誤適用しないためと考えられる。

経緯台での天体追尾に必要なパラメータは実は少なく、高度、方位、(観測地の)緯度だけあれば良い。また一度追尾を始めれば以降は通信せず自律的に追尾の継続が可能。
zeusプロジェクトの技術資料(経緯台の制御に必要な天文計算)方位軸，高度軸の追尾速度

また導入についても、赤道座標から地平座標への変換をアプリ側で行えば、当然だが架台には方位と高度のみ伝えれば良い。
zeusプロジェクトの技術資料(経緯台の制御に必要な天文計算)地平座標－赤道座標変換

kenkoにはse-at100という安価な望遠鏡があり、このse-at架台は観測地の緯度と北の方向を与えると天体の自動追尾を行うものだが、これにwifiアダプタを経由してsynscanアプリを接続するとアライメント(自動導入)が可能になる。
se-at架台が自動導入を目的としたものではないことを考えると、架台側にはアライメント情報を保持していないと考えるのが妥当ではないか。

そう考えると、AZ-GTi架台は、synscanアプリより伝えられる方位、高度情報に従って天体を導入し、(これだけは保持している必要がある)緯度情報と、(対象天体の)方位、高度情報に基づいて水平垂直方向の追尾速度を随時計算し追尾しているだけ、と考えたほうが合理的に思える。(基本的機能はse-at架台から変化していない)
アライメント情報は、synscanアプリ内で対象天体の赤緯赤経情報を修正するために用い、その修正結果を方位高度情報に変換して架台に伝えている、ということになる。

架台を駆動する直接的なレイヤであるモータコントロールプロトコルにアライメント関係のコマンドが全くないことも、この考え方を裏付けている。

また、これはマニュアルにもあるし誰もが経験していることだが、synscanアプリを停止若しくは接続が切れても、再度起動、接続すればそれまでのアライメント情報を利用した継続使用が可能になっている。
アプリからは自分が停止している間に架台の電源がoffになったかどうか知る手段がないため、ハイバネートを経ない架台の電源off/onがあった場合にも保持しているアライメント情報を破棄することは出来ない。
これが一見悪仕様のように見えるが、再接続性を維持するために必要な処理なので、架台の電源off後はアライメントのリセットを必ず行う以外に方法はない。(こういう仕組みだと考えれば現在の仕様も納得できる。)

以上、正確なところは、架台とアプリとの間の通信パケットをアナライザで直接見てやれば明らかになると思われるが、それ以外の点からはアプリ側でアライメント情報を保持していると考えたほうが合理的に思われる。

この辺り、2年ほど前にlambdaさんと色々やり取りしていたのですが、何故かすっかり忘れていました。また一部の見解をその時から修正しています。