07 GPD赤道儀の改造 Feed

2016年9月 8日 (木)

2016年夏の遠征の総括(反省を含め)

SP赤道儀用1軸コントローラについては、前に書きましたように2軸化することにしましたので、それ以外の機材についての総括です。

【フルサイズ改造機D610】

やはりと言うか、BKP150とフルサイズ機の組合せは、周辺の光量低下が激しいです。

D5000とD610は、ピクセルサイズは同じなので、D610で撮ってAPS-CサイズにトリミングすればD5000と同等なのですが、フラット補正がよりシビアとなってしまうので、常用するには無理がありそうです。

BKP150にセットした時のFLAT画像の等光度曲線です。
どちらも同じ8段階表示です。

D610(フルサイズ) 

D610_flat

D5000(APS-C)

D5000_flat

また、周辺部の画質低下もありますので、BKP150とフルサイズ機を組み合わせるときは、特に入念な光軸調整とピント合わせが必須でしょう。

D610改造機は撮影対象にもよりますが、180mm/300mmと組み合わせての撮影をメインにしようと考えています。

【BKP150】

8~9日の遠征の前に、鏡筒とフードに植毛紙を貼り付けました。その効果は検証しようがありませんが見た目は良さげです。

D5000の画角内画像は、BKP150+コマコレクター(F5用)の組合せでほぼ満足が行く程度にきれいだと思っています。

これで、再度光軸調整をやり直し、ばっちり決まって、8~9日の撮影は上々だったのですが、2回目の遠征で現地で確認したところ少し狂っていましたので、現地でレーザーコリメータを使って調整しなおしました。

ところが、これが中途半端だったみたいで、結果は、すでに書いたとおりです。

車に載せている間に狂ってしましたみたいで、これについては、新たな対策を講じるとともに、現地での光軸調整方法を含めてスキルアップを図らなければ成りません。

【GPD2軸制御コントローラ】

夏休み中にニワトリを含め、5夜ほど動かした結果、目標天体導入補助機能を含め、若干の取り扱い上の不便さはあるものの、ほぼ満足できるところまで来たと思っています。

今後の課題

  • 南中付近への望遠鏡の指向ができない  
    駆動モータをウォームギア軸上にダイレクト接続している関係から、赤緯側モータと赤経側モータあるいはコントローラ本体ボックスが干渉してしまい、目標天体が南中前後だと望遠鏡を向けれません。  
    このレイアウトを採用した時点で覚悟をしていたのですが、南中前から撮影を開始して、南中後に撮影を終わると言う一番おいしい時期が使えないのは痛いです。  
    モータレイアウトそのものの問題ですので、当面は我慢するしかありません。
  • 導入補助機能の基準天体が足りない  
    基準天体として1等星を選択しましたので、南中前後の制約もあって、秋の天体、M33等を撮影する際の基準天体に困る結果となりました。  
    アンドロメダ座 α等を基準天体に追加しました。  
    AT-Mega326のEEP-ROMは1000byteで、1基準天体で20byteを使っていますので、50個までは増やせるのですが、あまり多いと却って使い勝手が悪くなりそうですので20天体にしています。
  • 鏡筒回転時のコード類の取扱が煩雑  
    接眼部にカメラを接続すると、鏡筒の中心を軸とした回転方向に大きくバランスが崩れた形になってしまい、鏡筒の前後バランスを取っていても、指向方向によっては、赤緯軸のバランスが大きく狂うことになり、鏡筒の回転モーメントが最小になるよう鏡筒回転が不可避ですが、その都度コード類の取り回しや乾燥空気ホースの付けなおしが必要になってしまいます。
    カメラと反対方向にカンウターウェイトを付けるなどの対策もありますが、これ以上の搭載重量増加は御法度ですので、コード類の取り回し方法の改善で対応するしかありません。
  • 撮影最後での赤経側制御不調   2回目の遠征の最後に赤経側制御が不調になったことについての原因は不明ですが、制御信号用RJ11端子の取付方は、同じ問題を起こしたSP赤道儀用コントローラと同じですので、これと同じ端子の断線が疑われます。  
    現在の実装方法の弱点と考えられますので、実装方法の再検討が必要です。

【結露防止対策】

BKP150の乾燥空気、ガイド鏡の熱線ヒータとも効果は十分のようで、この撮影地(小石原焼伝統産業会館=これが正しい名称で、いままで間違っていました)は夜露が多いことが有名みたいで、特に8~9日は、湿度が高く、鏡筒表面にはびっしりと露が付きましたが、BKP150、ガイド鏡とも一晩中結露しませんでした。

【電源】

今回は新たに買い足した45Ahバッテリーと従来の28Ahの2台体制でのぞみました。

  1. 45Ahバッテリー    
    GPD赤道儀2軸ドライブコントローラ    
    D5000用電源    
    BKP150乾燥空気ポンプ    
    ガイド鏡熱線ヒータ    
    オートガイド用パソコン
  2. 28Ahバッテリー    
    SP赤道儀(改)1軸ドライブコントローラ    
    カメラレンズ用熱線ヒータ    
    オートガイド用パソコン

機材準備完了後の20時頃から翌日4時過ぎまで動かして、負荷状態で12Vを切ることはなく、現況の機材構成であれば、電源の心配はなさそうです(冬期の効率低下の影響は不明ですが)。

【その他】

今回の夏休みの遠征を含め、何度も機材の出し入れをしたことで、段々設置・撤去の手順にも慣れてきて、機材ごとの収納もやっと整理出来てきました(格段に時間短縮です)。

次に本格的撮影ができるのは、11月初旬の連休になると思いますので、それに向けて機材の改善をやっていきます。

 

2016年5月24日 (火)

自作コントローラの導入補助機能のエラーの原因究明

自作コントローラの目標天体導入補助機能で、暴走や方向音痴状態になることの原因を探るため、ブレッドボードでエミュレータを作成し、検証してみた結果について、以後同様のことを避ける目的で詳細を書いておきます。

まずは、現象の再現です。

20160523_3370_2赤経移動量

20160523_3371赤緯移動量

アークトゥルス→M51の導入 手元操作ボックスでの、移動量の計算値

アークトゥルス= 赤経14h15m40s=213.91° 赤緯+19°10'57"=+19.17°= 70.83°
M51           = 赤経13h29m54s=202.47° 赤緯+47°12'00"=+47.20°= 42.80° 移動量        = 赤経-11.44° 赤緯-28.03°

手元操作ボックスが送信した赤経移動量(ステップ数)

赤経移動量の計算値 = (1144× ( 2048(step/0.1°) + 5(step/0.1°)) ÷ 10 = 234863 = 0x0003956F

手元操作ボックスが送信した赤緯移動量(ステップ数)

赤緯移動量の計算値 = 2803°× ( 2048(step/0.1°)  ÷ 10 = 574054 = 0x0008C266

本体コントーラが指示した赤経移動量

その差 (234863 - 169327)÷2053 ÷10 = 3.19°

本体コントーラが指示した赤緯移動量

その差 (574054 - 508518)÷2048 ÷10 = 3.20°

前回検証した誤差量3.2°に一致します。

また、おおぐま座η→M51の導入について、上記と同様に検証したところ、本体コントーラが指示した移動量に「-」が!!
移動量の±は、回転方向で表していますので、移動量は絶対値を使っており、負の数にはならないばずなのですが、これが暴走の原因です。

20160523_3372

長々と書きましたが、結論は、暴走、方向音痴とも再現する現象で、プログラムミスに原因があることは明白です。

どうも、本体コントーラが受け取ったbyteデータをlong型の整数に戻すときの式に型変換上の問題があることが分かったのですが、どう書いたら、正しく計算するのかがなかなか分かりませんでした(つまりはC言語の型変換が理解できていないと言うはずかしい結果)。

試行錯誤した結果、手元操作ボックスからの指示データ(4byteデータ)を受け取って、ステップ量に戻す式

step = val[0]*0x1000000 + val[1]*0x10000 + val[2]*0x100 + val[3];
※変数の型はstep・・・long、c[]・・・unsigned charです。

の赤字部分に問題がありました。

ここの部分だけ、型変換時に符号拡張があり、0x80以上の値では、負数に変換されてしまっています。
unsigned charの符号拡張では負数にはならないと思っていたのですが、char型、byte型でも同様の結果です・・・・わかりません。

とにかく、下の式のようにlong型にキャストすることで対応できました。

step = (long)val[0]*0x1000000 + (long)val[1]*0x10000 + (long)val[2]*0x100 + (long)val[3];

結局プログラムミスに原因があったのですが、あやまった記述方法でも数値範囲によっては正しく動作するため、誤認していたのでした。

型変換の理屈はとんと理解できていませんが、上記式の「val[2]×0x100」が問題をおこしていたみたいです。

なにはともあれ、これでめでたく導入補助機能の問題点も解決したはずです。 いよいよ、次の撮影が楽しみになってきました。

2016年5月22日 (日)

自作コントローラの導入補助機能の検証

5月の連休では、ほとんど撮影ができませんでしたが、自作コントローラの目標天体導入補助機能を試すことはできました。

導入補助機能の概要は、

  1. 基準星(1等星等)を手動で導入し、導入した基準星をArduino nanoのEEPROMに記憶させた19天体から選択、併せて望遠鏡のサイド(東/西)を選択し、望遠鏡の現在位置を設定する。
  2. 目標天体の赤経(hh/mm/ss)・赤緯(dd/mm/ss)を入力、差分を計算、移動量を赤経/赤緯とも±ddd.ddで表示。
    内部計算は、移動量を計算しやすいように赤経はhh/mm/ss値を度表示(ddd.dd)へ変換、赤緯は±dd/mm/ssを北極を0度とし南極を180度とする度表示(ddd.dd)へ変換して行っている。
  3. スタートボタンで計算された差分だけ赤経→赤緯の順で移動して目標天体を導入。
    赤経/赤緯のモータドライバは独立しているので、同時に動かすこともできるが、動作の確実性を期すため、赤経側移動が完了したあと、赤緯側の移動を行うようにしている。
  4. 望遠鏡の現位置=目標天体位置に更新。
  5. 試写後、必要に応じて、位置を微調整。
    位置の微調整には、速度を変えて(0~400倍速)ボタンを押している間移動するモードと、400倍速でボタン1押しでの移動量を決めて(移動量の範囲0.01~1.00°)動かすモードを使い分けるようにしている。
  6. 以降は、目標天体の位置を指示すれば、次の目標天体へ

となっており、移動速度は400倍速(40r.p.m)としています。

さて、試行の結果ですが、いきなり本番でアークトゥルスを基準にM51へ導入を試みした。
ここでは、赤道儀コントローラを本体と手元に分けたことで、アークトゥルスを視野中央に導入する際の手元コントローラの微動機能を使っての微調整は、もくろんだとおりカメラファインダやPC画面を見ながら手元コントローラボックスで操作できるようになり、極めてスムースに行うことができるようになりました。

コントローラを本体と手元に分けたのは大正解です。

しかし、試写の結果は目標としたM51が写角のなかにはいっておらず、導入失敗です。
これは、前に書いたように赤緯軸のバックラッシュが大きいことが原因と考えられたため再調整して、翌日再挑戦です。

今度は、導入の精度を検証できるように、まずはアルクトールスからおおぐま座η星を導入、その結果が下の写真です。

157若干ずれてはいますが、写角内に目標を捉えており、私的にはほぼ満足できる結果です。

これで気をよくし、ここからM51への移動を試みたのですが、どうしたことか、赤緯の回転が止まらず(暴走)失敗です。

そこで、もう一度アークトゥルスで設定し直し、M51への導入を試みたのですが、今度も写角内に捉えることが出来ません。

M51はあきらめ、今度は、アークトゥルスからM13を導入したところ、ちゃんと導入できました。

これが前回掲載したM13の写真で750mm、1200mmでもほぼ中央に捉えています。

M51の導入に失敗した原因は不明です。 極軸はPHD2のドリフト法まで使って合っていることを確認しましたし、M51の座標は何度も確認したはずなんですが、ふしぎです。

導入後に撮った写真を元に、どれくらいずれているのか調べたかったのですが、目印となる天体が見つからず、半ばあきらめかけていたところで、画面の上隅に銀河が写っていることに気づき、これを頼りにwikiskyで同定してみました。

その結果、写っている銀河はNGC5297で、写真中心は、赤経13h42m43s、赤緯44°02'20"と思われます。

156対して目標としたM51の位置は、赤経13h29m54s、赤緯47°12'00"。

誤差は、赤経で+3.20°、赤緯で-3.16°ととんでもない方向音痴状態です。 赤経、赤緯とも約3.2°の誤差とはなにか意味がありそうですが、M51と比較的近い位置のおおぐま座η星への導入がうまくいっているのでなおさら不思議です。

M51の位置入力は何度も確認したはずなんですが、そのときのメモは残っていませんので、検証しようがありません。
まあ、結局はなんかの思い込みによる誤入力というのが落ちなんでしょうけれども。

また、赤緯軸が暴走したことについては、もう一度プログラムを見直してみる必要があります。

でも、M13の導入では1200mm+D7100の写角(1.1度×0.7度)でもほぼ中央に捉えていますし、アークトゥルス→M13(赤経差36.5度、赤緯差17.2度)を40秒弱で導入できますので(赤経軸・赤緯軸を同時に動かせばもっと短縮できるのですが)、この導入補助機能が安定すれば、実用上は有効ではと考えています。

2016年5月13日 (金)

なかなか予定どおりにはいかないもの

5月の連休は、9連休とし、前半で機材の最終調整、後半で遠征撮影を企画していたのですが、はからずも私事事情で最終調整も半ばの状態で終わってしまいました。

機材の最終調整で、モータコントローラを赤道儀に搭載し最終形にまで仕上げ、BKP150の光軸の確認を行った後、試写となったのですが、どうも導入補助機能の誤差が大きいみたいで、確実に目標が捉えられません。
原因は、赤緯軸のバックラッシュが大きいことだと思い、赤緯軸のウォームギアを再調整しました。

導入補助機能を使ってアルクトールス→M13の導入で撮影した結果です。

222_3

【撮影データ】 2016年4月30日 自宅庭
BKP150 + 純正コマコレクタ(F5用) + TC-16A (焦点距離1,200mm)
LPR-Nフィルター + Nikon D7100(ノーマル)
ビクセンGPD赤道儀(自作2軸モータドライブ化)
D60mm L=240mmガイドスコープ + QHY5L-IIM + PHD2 Guiding
ISO1000 露出360秒×11枚
DSSでコンポジット、Cature NX2で画像処理
周辺光量低下が目立たない2/3程度にトリミング

結局、まともに撮影できたのはこのM13だけになってしまいました。

風があり、テレコンバータ×1.6を使った長焦点(1200mm)とガイド精度がイマイチで、星像が太っていますし、フラット処理をしていないので、周辺光量不足も目立つ失敗写真です。

それと、D7100の長時間露出ノイズが非常に目立つことが気になります。 なにか原因があるのか、気温18度程度、ISO1000の6分露出にしてはノイズが目立って使い物にならない感じで、比較対照をしていないので感じだけですがD5000ではこんなに酷くなかったと思うのですが・・・・。

2016年4月 7日 (木)

三カ月間の成果・・・・・・

昨年の12月中旬の遠征以来まともに撮影していない期間が3カ月以上になってしまいました。
5月の連休が待ち遠しい毎日ですが、はたして天候にめぐまれるかどうか・・・・・。

この三カ月間、ひたすら機材の改造などでお茶を濁してきたのですが、手がけたものもほぼ完成形に近づいてきました。

まずは、GPD赤道儀用コントローラ(7号機)です。 私としては非常にコンパクトに仕上がったと思っています。

20160401_33047号機本体コントローラ外観

20160401_3310同内部(ぎゅうぎゅうです)

20160401_3307同 コネクタ部(シールが不揃いなのはご愛嬌??)

20160401_33137号機 手元コントローラ

ステッピングモータドライバーは、結局秋月電子製の品切れ状態に待てなくなり、ストロベリーリナックス製としました。

※現在は、秋月電子製の品切れは解消されたみたいです(先日いったときには店頭にはありませんでしたが)。

現在、ソフトウェアのブラッシュアップ中で、主に天体導入補助機能について機能の改善を目指しています。

※先日書いたOnStepのASCOMドライバーについては、通信手順が思った以上に煩雑で、苦労しても効果はそれほどではないかと中断しています。

次は、SP赤道儀改造の一軸制御コントローラ(8号機)です。

20160401_33028号機コントローラ外観

20160402_3314同 内部

これは、7号機以上にコンパクトになりましたが、実はモータドライバーをモータ横の部分に追いやっただけのことです。
これで、極軸調整用に追加したボルトとも干渉せずにとりつくはずです。

実際の取付には、タップ立てやアルミ板の切断が必要ですので、自宅に帰ってからの作業になります。

最後は、D5000のバルブ撮影をdigiCamControlで制御するたの外部トリガー用USBリレーボックスです。

20160401_3300USBリレーボックス外観

20160401_3299同 内部

前回の掲載したものから作り替え、当初のケースに納まり、結構小さくなりました。

連休までの作業は、SP赤道儀のPEC機能を使った追尾精度の検証ですが、これは天候次第となります。

2016年2月20日 (土)

性懲りもなく、赤道儀モータドライブ用自作コントローラの改造

先週は、11~14日に帰省して、機材調整、あわよくば遠征もと思っていたのですが、帰省前日の9~10日は快晴となったものの、以後は曇り/雨と天候はままなりません。

機材の調整、主にBKP150の光軸調整とスパイダー隠しの仕上げを行ったのですが、実写ができずに調整結果の確認まではできませんでした。

ほんと、福岡市が日本海側気候であることを思い知らされた次第です。

5月の連休までは帰省の予定が立たないので、この期間は単身赴任先で機材(主にコントローラ)の改善に当てたいと思っています。

そこで、SP赤道儀を改造した一軸ノータッチガイド機一式を単身赴任先に送り、コントローラ7号機の製作と平行して、一軸制御コントローラの改造に取り組むことにしました。

目標は、コントローラを小型化し、赤道儀にキチッと搭載できるようにすること、ピリオディックモーションキャンセラー機能を搭載し、180~300mmの長時間露出を可能にすることです。

ここで、改めて今までに作成した赤道儀モータドライブ用自作コントローラの変遷についてまとめてみました。

【自作コントローラの変遷】

  1. < 1号機>
    ・タンジェントスクリュー式式用
    ・ユニポーラ型ステッピングモータ
    ・モータドライバ STK672-050   
    CPU PIC16F886 モータドライバ STK672-050の動作が不安定で、マイクロステップが機能しない。
    動作不安定の原因は、外付け回路の不備が原因と思われたが、追求せず、新しいドライバ(外付回路不要)を選択。
  2. <2号機>
    ・タンジェントスクリュー式用    
    ・バイポーラ型ステッピングモータ    
    ・モータドライバ L6470    
    ・CPU Arduino Uno
    モータ回転はスムースになるも、タンジェントスクリュー式に限界(撮影可能時間、追尾精度)を感じ、放棄する。
  3. <3号機>
    ・ウォームホイル式用   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU ATMega328(Arduino互換) + PIC12F629(モータ駆動パルス発生用)    
    ・シャッタータイマー機能付き    
    ・結露防止ヒータ温度制御機能付き
    モータコントローラの構成・機能は本機でほぼ完成、これ以降のコントローラはこの構成を踏襲。
    ほぼ、意図どおり動作するも、ギア等の機械部品の精度からか再現性に乏しく、追尾精度が向上しない。市販赤道儀の改造へ方針変更。
  4. <4号機>   
    ・ナノトラッカー用   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU ATMega328(Arduino互換)    
    ・シャッタータイマー機能付き
    ナノトラッカーの精度向上を目指して導入するも、再現性が悪く放棄。 現時点で考えると、再現性の悪さの最も多いな原因は、カメラを搭載機構(雲台を含めた)の強度不足ではなかったかと思われる。
  5. <5号機>   
    ・SP/GPD赤道儀用二軸制御   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU ATMega328(Arduino互換) +  PIC12F629(モータ駆動パルス発生用)    
    ・オートガイドへ対応    
    ・天体導入補助機能付き    
    ・シャッタータイマー機能付き    
    ・結露防止ヒータ温度制御機能付き
    焦点距離1,000mmでもオートガイダー使用でほぼ満足できる精度がでており、機能的には満足できたが、コントローラの操作性が悪く、使い勝手に不満が残った。
  6. <6号機>   
    ・SP赤道儀用一軸制御   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU ATMega328(Arduino互換) + PIC12F629(モータ駆動パルス発生用)    
    ・シャッタータイマー機能付き
    ほぼ、意図どおり動作するも、赤道儀への搭載方法、ノータッチ追尾精度に180mmカメラレンズでも露出90secが限界と不満が残る。
  7. <7号機>(5号機の改善版、製作中)   
    ・GPD赤道儀用二軸制御   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU Arduino nano + PIC12F629(モータ駆動パルス発生用)    
    ・天体導入補助機能付き    
    ・シャッタータイマー機能付き    
    ・結露防止ヒータ温度制御機能付き
    本体/手元コントローラに分割し、操作性の向上を意図している。
  8. <8号機>(6号機の改善版、製作中)   
    ・SP赤道儀用一軸制御   
    ・バイポーラ型ステッピングモータ   
    ・モータドライバ L6470    
    ・CPU Arduino nano + PIC12F629(モータ駆動パルス発生用)
    SP赤道儀への搭載のための小型化、PEC機能によるノータッチ追尾精度の向上を意図するのがメイン、小型化のためシャッタータイマー機能を省く。

こうやって見てくると、なにか天体写真を撮ることよりも、電子工作そのものを楽しんでいるのではないかと思えてしまいます。

製作や改造がなくなったら、撮影のモチベーションが下がってしまうのではないかと心配です。

2016年2月 9日 (火)

悪戦苦闘のI2C通信

前回に書きましたようにモータコントローラ7号機を製作中ですが、本体コントローラと手元操作ボックスをつなぐ肝心のArduino同士のI2C通信で泥沼状態を経験しました。

プログラムのデバッグにあたり、I2C通信については、マスタ→スレーブの一方向通信は、LCDキャラクタディスプレイのI2C化で経験していましたが、今回は、双方向通信となるため不安はあったのですが、それが現実のものになってしまった次第です。

今回のブログラムは5号機の改変ですので、デバックは、通信が主体となりますので、確認のためエミュレータをブレッドボードで作成して確認しながら進めました。

20160207_3283作成したエミュレータ

問題は、マスタ側(=手元操作ボックス)からの送信要求に対してスレーブ側(本体コントローラ)が返す結露防止ヒータの温度データがうまく取れないと言うことです。

スレーブ側が返すデータは、モータコントローラのBUSY状態(1byte)、温度制御の状態(1byte)、温度データ(2byte)の計4byteを返すように設定しているのですが、うまく行きません。

Arduinoのスケッチ例を見ても、1byte送信か文字列送信しかなく、複数バイトの送信方法がうまくないみたいです。

最初に書いたスケッチ

viod Send_THermo(){
       Wire.write(L6470_BUSY);                // L6470_BUSY=BUSY/nBUSYの1byteデータ(0又は1)  
       Wire.write(TEMP_CON_NOW);         // TEMP_CON_NOW=上昇/降下/制御なしの1byteデータ(0~3)  
       Wire.write(TEMP_NOW / 0x100);     // TEMP_NOW 温度データ(2byte)(0~600)  
       Wire.write(TEMP_NOW % 0x100);   // 少数点以下1位を有効とするため温度×10のデータとしている
}

結局、これでは最初の1文字だけが送信されるだけでうまくいきません。

色々と試したり、Web上で検索したりした結果、次のように書くべきだと言うことになりました。

viod Send_THermo(){  
     char c[6];

     c[0] = L6470_BUSY;              // (1又は2)  
     c[1] = TEMP_CON_NOW;       // (1~4)  
     c[2] = TEMP_NOW / 0x100;   // (10~600)  
     c[3] = TEMP_NOW % 0x100;  
     c[4] = '\0'; 
     Wire.write(c);
}

とし、文字列のポインタ渡しによる送信でうまく行きそうでした。

※この時点で、各送信データバイトに「0」があると、終端文字と解釈されて、以後のバイトデータは送信なれないことはわかっているつもりでした。

ここに至るまで、3日を要してしまいましたが、なんとかうまく送信できました。

ところが、その他の部分のデバックにかかると、2バイト目まではうまく送信できるものの、肝心の温度データが取れなくなるケースがあり、またぞろケーブルやコネクタの接触不良を疑ったりと際限がなくなってしまいました。

結論は、しごく単純なこと、温度データが256未満(25.6度未満)では、温度データの上位byteが0となって、終端文字と解釈されていただけでした。

つまり、うまく行くときは、結露防止ヒータの温度が26度以上の時で、それ以下になっていると、送信の3yte目が0となって温度データが送信されない状態になっているだけでした。

ケーブルやコネクタの方の不都合ばかりに気をとられ、こんな単純なことに思いが至らなかったことに、唖然とした次第です。

エミュレータで確認しながら作業を進めたのが正解でした。
これで、本番同士で接続して確認していたなら、なにがなにやらわからず、放り出していたかもしれません。

以後のデバッグは多少の紆余曲折はあったももの、概ね順調にすすみ、5号機では隠れていたバグ潰しもできて、ほぼ完成の状態まで仕上がっています。

7号機で手元操作ボックスから本体コントローラへ送信するコマンドは下表のとおり。
これだけで、5号機の機能はすべて動作させることが可能です。

7

さて、今週末は金曜日を有給とし、連休で帰省し、機材の調整とあわよくば遠征もと欲張っていたのですが、案の定、天気予報は最悪を示しています。

2016年2月 7日 (日)

まさかのSDカードデータ消失!!

前回に書きましたようにGPDモータコントローラを置き換えるべく、7号機を製作中ですが、意気消沈の事故が発生してしまいました。

手元操作ボックス側のソフトのデバック作業がほぼ終わり、本体コントローラと接続したデバックを開始したところ、その途中でプログラム、基板図等を入れていたSDカードが突然認識しなくなってしまいました。

ここ2週間近い期間のプログラムが全部パーです。

要因となったのは、手元操作ボックスと本体コントローラとをつなぐ4芯のカールケーブルです。

20160207_3282上が問題のコード
下は、作り直した約1mのコード

一見かっこよかったので採用したのですが、カールしているため短そうですが、実は2m以上あって、これでI2C通信をしたのが裏目に出ました。

プログラムのデバックをやろうとすると、全く動作しません(LCDキャラクタディスプレイに表示されない)。
本体コントローラ側は、初期のL6470チェック部分は動いていますし、I2Cの接続をしないと通信部分は通過して、プログラムは進行していましたので、なかなか原因がわからず、試行錯誤がつづきました。

結局I2C通信線を50cmくらいの短いのに換えたら、正常に通信できるようになりましので、通信で止まる原因が長すぎるケーブルであったことがわかりました。

しかし、通信が正常になったあとも、結露防止ヒータからの温度データがうまくとれません。
温度センサーとGNDの間に5.1kΩの抵抗をいれているのですが、この点(=電圧を取っている場所)の電圧をテスターで計ると0ボルトになってしまっています。

これらの問題点を検証するため、USBの抜き差し、Arduino nanoをICピンから抜き差しするなどを繰り返してしたところ、突然USB接続していたSDカードが認識しなくなったわけです。

このArduno nanoは互換品で、非常に安かったのですが(780円)、内1個が入手当初からUSBMiniの差し込みが奥まで入らず、中途半端だったものです(もう1つの方はチャンと刺さります)。

20160207_3287激安互換品

結局、このArduino nanoもお亡くなりになりました。

分かったことは、I2C通信ができないような長さのケーブルをつないだ状態では、I2C通信のルーチンで待ちになってしまうと言うことです。

また、温度データが取れなかった原因は、以前の回路と接続ピンを変更したことで、シャッター開閉用リレーピンと温度センサーデータ取得用ピンの混同があり、アナログデータ取得用ピンのモードを「出力」にし、初期化(LOW)したピンに対してアナログリードを行っていたことでした。

温度データの本体コントローラ側からの送信(スレーブ側からの送信)については、まだまだトラブルがつづいたのですが、これは後日。

今回も色々勉強させてもらいました。

今回のプログラムは、全く最初から作成したものではなく、現用の5号機から改変したもので、このプログラムはバックアップがありましたので、全くはじめからのやり直しではないのですが、大幅な手戻りとなってしまいました。

また、このデバック作業中に虎の子のL6470モータコントローラキットも端子間をショートさせたみたいで、あえなくご臨終となってしまいました。

このキットは、まだ、秋月電子で品切れ状態は続いています。

2016年1月26日 (火)

首都圏は快晴・・・・

九州を含めた日本海側は、大雪で、我が自宅がある福岡も雪なんですが、首都圏は風はあるものの快晴、特に今朝方は、澄みきった空に西の空の低い位置に満月がくっきり、富士山も非常にくっきりと近くに見えました。

でも、どんなにいい空模様でも、こちらでは機材がないのでなんともなりません。 こんどの帰省の時にお持ち帰りしたいところです。

GPD赤道儀コントローラ7号機の手元操作ボックスがほぼ完成しました。

20160123_3272_01

 外観

20160123_3270_01内部

20160123_3276本体コントローラとのコネクタ部(DIN 4P)

今回は、オンボードでプログラムの書き込みができるようにしたので、プログラムのデバック作業が非常にらくになりました。

いつものように、プログラム設計もなにもなく、行き当たりばったりでプログラムを作成しますので、相当量のデバックが必要なのは、いつものとおりですが、今回は、その都度ICソケットから抜き差ししてプログラムを書き込む必要がないので、軽快にデバック作業が進みました。

それでも、つまらない落とし穴にはまり、正常に動作しない原因をArduino IDEのバージョン違いに疑いを持ったりして、Ver.1.05→Ver.1.67→Ver.1.06→Ver.1.67と入れ直しを繰り返したりしてしまいました。

結局原因は、本体コントローラ側が未完成のため通信ができない状態で、プログラム中の変数に想定外の数値が入っており、LCDキャラクタディスプレイへの表示ルーチンで桁あふれが出ていただけのことでした。

手元操作ボックスは、私のレベルでは非常に完成度高く出来上がったのですが、後は本体コントローラをうまく搭載スペース(GPD赤道儀の本来のモータ搭載位置)に納まるよう、仕上げれるかです。

でも、まだ肝心のモータードライバーの品切れが続いています。

ストロベリーリナックス製でもいいんですが、値段が高くなるのと、I/Oピン配置が違うので、できれば秋月電子製が手に入るのがいいのですが・・・・・。

2016年1月24日 (日)

やることがないと、つい・・・・・

単身赴任の身、年明けから次の帰省予定の2月中旬まで、光軸修正の方法やスパイダーの改善方法など、色々と考えてはいるのですが、実際に試すことができずに、堂々巡りをの思考をするばかりです。

資金があれば、ついついポチリと不要・不急の用品を増やしてしまうのでしょうが、幸いにも慢性的な資金不足で、結局は暇を持て余してしまう毎日が続いています。

結局、GPD赤道儀コントローラ5号機(改=7号機)を作ることにしてしまいました。

主要な改善点は、コントローラ本体から操作・表示部を切り離して、コントローラ本体と手元操作ボックスの構成にすることです。

5号機は、コントローラ本体に操作・表示部がありますが、本体からは赤経モータ、赤緯モータ用4芯コードが2本、オートガイダー用モジュラーコード、結露防止ヒータ用4芯コード、カメラレリーズ用2芯コード、電源2芯コードの計6本ものコードが出ており、これを手にもって操作するのは、コード類の取りまわし等が大変で、据え置きで使用するしかありません。

対象天体の導入やレイアウトの調整などでの微動操作は実質不可能となってしまっていました。

そこで、本体と操作・表示部を分離し、この間を1本のコードで接続することで、赤道儀の操作の利便性を図ることとした訳です。

さて、全体の構成をどうするか、今回は5号機の機能そのものには変更を加えないので、本体コントローラと手元操作ボックス間をどう接続するかが主要な課題となりました。

手元操作ボックスを単純なスイッチボックスとし、スイッチの数だけの線(7本+グランド線)で?ぐことも考えたのですが、これでは、手元操作ボックス側での情報表示ができず、本体コントローラの表示をみながらの操作になりますので、不便さが残ります。

また、手元操作ボックスをパソコンとし、USBで接続することも検討したのですが、利便性の面で5号機と大同小異です。 結局、本体コントローラ側はモータドライバーの制御のため、手元操作ボックスは指示の受付・表示用にどうしてもそれぞれにCPUが必要で、ArduinoでI2C通信を利用すれば、多芯ケーブルで接続しなくても、4芯のケーブルでいけるのではないかと考えた次第です。

I2C通信の規格は、もとも回路内を想定したもので、長距離通信は想定されていないとのことですが、個人的に使用するだけですので、実際に通信できればよいわけで、約1mの距離で試したところ支障なく通信できましたので、これで行くことにしました。

7

またCPUについては、今までArduinoのブートローダを書き込んだATMega328を利用していたのですが、今回は省スペースを優先するため、Arduino nano互換機(Amazonで980円)を利用することにしました。 ※ATMega328を使用した場合、ATMega+電源、水晶発振子、コンデンサー等で410円で済みますが、オンボードでのプログラム書き換えはできません。

これで、いままでプログラムの書き換えの度にCPUを抜き差ししなければならなかったのが、オンボードでの書き換えが可能になりました。

20160123_3277

今回も回路パターンをpcbeで起こし、感光基板でプリント基板を作成しています。

20160117_3263

左が、手元操作ボックス、右が本体コントローラ用基板です。

感光基板を使ったプリント基板の作成は、線幅0.3mm、線間隔0.3mmで、ほぼ失敗なくできるようになりましたので、ハンダ付けが苦手な私としては、1点もので、ユニバーサル基板を使うより割高なんですが、感光基板を選んでしまいます。

5号機と7号機の違いがもうひとつ、手元操作ボックスが大きくなりすぎないようLCDキャラクタディスプレイを20字×4行から16字×2行へ変更しました。 このため、表示内容を整理しています。

ところが、落とし穴、秋月電子製L6470ステッピングモータドライブ組立キットが品切れ!!、入荷時期不明とのこと。 はてさてどうなることやら。