「PIC AVR 工作室」サイトの日記的なブログです。
サイトに挙げなかった他愛ないことを日記的に書き残してます。
PIC AVR 工作室 ブログ



http://www.youtube.com/watch?v=9kLCzytyX8A
これすげー。デュアルポートRAM使ってるのか…

http://www.youtube.com/watch?v=IXu8P2qGoj8
すげー懐かしい感じ。1ビットずつパチパチって。

http://www.youtube.com/watch?v=-U-cc_Qcf-w
32Mhzって… ショートしないのかな?

http://www.youtube.com/watch?v=fC8YQNQQey8
キャラクタLCDでスペアナ…。なかなか。



コメント ( 0 )




先日windows7でネコロジーを使いたいって思って
久々に動かしてみたら動かなかった件。
http://brown.ap.teacup.com/nekosan0/1182.html

シリアル経由でのI/Oが追いつかなかった対応を
色々やってみたんだけど、とりあえず安定して
動くようになったみたい。


最初に試してみたのは、ファーム側、PCソフト側とも
XON/XOFFに対応させてみること。

→やっぱりデータがあふれちゃって、途中で送信がNGに。

うーん、ソフトやファームのバグか?と思って調べ
直してみるも間違えはなさそう。

PC側のXON/XOFFは、VBのプロジェクト編集画面から
シリアルI/Oオブジェクトのプロパティー設定を開いて
弄ればOKのはず(プログラム実行時にドライバの設定
をこの内容で弄りなおす)なんだけど、一応コンパネから
ドライバの設定を見直してみると…

詳細設定にレイテンシの設定があったんだなぁ。見ると
16msになってる。ってことは、xoffをPC側ドライバが
発行しても、16ms経ってからようやくAVR側に送信される
ってことだよな?1msに変更してみる。

…動いた。取りこぼし無く取り込めた。しかもなんだか
ちょっと取り込み速度が速いな。

もしやと思って、VBの編集画面でXON/XOFF制御から
フロー制御なしに変えてみて、実行。

…動いた。


???何じゃこりゃ?

AVRからの送信は矢継ぎ早に…考えられる範囲でのフル速度
で行っているので、レイテンシが何ミリ秒に設定されて
いたって、USB-シリアル変換ケーブル内のバッファが一杯
になった都度PC側に送信されるんじゃぁ無いのかな?
それならレイテンシの設定変えるだけで動くようになる
はず無いんだけど。

なんだかつじつまが合わん…。


でもまぁ、なんにしてもゲイツ君にあらぬ疑いをかけて
しまってゴメン。多分ゲイツ君のせいじゃぁ無いよ。


ザックリ計算しなおしてみよう…。
115200bpsで16ミリ秒の間にAVRから何バイト出力されるか
というと、計算では184.32バイト。1ミリ秒では11.52バイト。
受信バッファは4096バイトに設定してあるんだけど、
どの段階でドライバがXOFFを送信しているかに因るのかな。

仮にバッファ残量5%程度でXOFFを送っているとすると、
およそ200バイトを割ったところで発行しているはず。
16msだとギリギリかもしれん。タイミングとバッファの
使用具合によっては確かにエラーが出るかも知れん…。

まぁ、115200bpsなら1msにしておけばXOFF制御でも
なんとかなりそう。


それにしても、16msにしただけでなぜAVR→PCの通信
速度が速くなるんだろう?散発データなら解るんだけど、
AVRから送信するデータは連続データだからなぁ…。
そんなはずは無いんだけど…


でもまぁ、ドライバの設定をフニャフニャすれば
ネコロジーのプログラム自体はそのままでもちゃんと
使えることが判った。シメシメ。


http://headlines.yahoo.co.jp/hl?a=20101222-00000006-maiall-bus_all
オイラのホンダ。ジェット機がテスト飛行に成功とのこと。
市販化までこぎつけるといいなぁ。

http://headlines.yahoo.co.jp/hl?a=20101223-00000009-jij-soci
こういう基礎研究が将来の医療進展を進めるといいなぁ。
メカニズムは大事だよな。思いもよらない応用範囲が
有るかもしれないからな。蛍光発光するクラゲみたいに。

http://nazunalab.blog.so-net.ne.jp/2010-11-28
ポルタを2軸モーター駆動の赤道儀にしちゃうのはすごいな。
http://nazunalab.blog.so-net.ne.jp/2010-11-07
PWMのデューティー比と電流は比例すると思ってた
んだけど、そいうじゃぁないのかな?ホント?



コメント ( 0 )




天に見放された昨日とは打って変わって、今日は
すっかり晴れて、しかも北風に変わり始めたせいか
湿度も下がってきて、かなり夜空がきれい。

ってことで、0.5秒悩んだ挙句、完成品を近所で
ちょっぴり試してみることに。

とりあえずファーストライトとして写ってきたのは


お月様がオリオンの間近、ふたご座なので青空みたい
になってるけど…。星を撮るのが目的じゃなく、性能
チェックが目的なので…。

2分20秒ほどの露出時間。焦点距離45mm(銀塩換算
約68mm)

左下の大きな白いのがシリウス。右中央に3つ並んでいる
のがオリオンの三ツ星。その下の赤で囲ったところが
小三ツ星。小三ツ星付近を画素等倍で切り取ったのがこれ。



かろうじてM42と判るぎりぎりの線。ちょっと流れてるかな…


で、とりあえずほぼ点像に近い写真が撮れそうな事は
判った。目分量で適当に極軸合わせてみたけど、大体
合ってたみたい。よかった…。

だけど、実は色々と紆余曲折。やっぱ使ってみないと
欠点は見えてこないんだな…。ハードウェア側のバグ。


致命傷は、この写真を撮るちょっと前に発覚。というか
本当の最初の1枚は致命的な欠点によって失敗作に。
なにかというと、カメラを載せた時に重量で生じるひずみ
をどう逃がすかってことが設計上加味されて無かったこと。

正確に言うと、設計時には加味してはいたんだけど、まさか
ここまで… というのが正直なところ。

↓これは昨日の写真に赤く矢印書き入れたもの。


カメラを搭載すると、カメラの重量によってこの赤い矢印
のように微妙にウォームホイールが当初の想定以上に
ウォームネジ側に圧されて、ギヤ同士の摩擦がでかくなって
脱調を起こしてしまってました。

写った写真を見ると追尾が全然できてない状態。とりあえず
モーターのトルクはスペック的に精一杯でこれ以上はどう
しようもない。そもそもトルクがでかいからokってわけ
でもなく、適量の軸間距離を保たないとピリオディック
エラーが生じちゃうので、ナントカしないとイケナイ。

その場でできる打開策を考える…

筐体を90度横にクルッと回してみよう…そして力を受け流す
方向をウォームギヤの軸と平行にしてみよう…と。


で、その結果冒頭の写真になったんだけど、重量的に
というか構造的にというか、重さの支え方がイマイチ
不安定な姿勢。
姿勢は大事。ちょっとゆるい風が吹いてきても、姿勢が
悪いとすぐに揺れちゃう…

もっと困るのは、折角極軸合ってたのに、ニーニッパレンズ
に載せ変えた途端重量に耐えられなくなり、全体的にしなって
極軸が明後日を向いちゃう。200mm端(銀塩300mm相当)
では信じられないくらいに追尾エラー…。

まぁ、そもそも長焦点の重たいレンズは前提としていない
んだけど、ここまで構造上よわいとすると、さすがに
ちゃんと考えないと実用的にどうなのよ…と。カメラ
リュックにポンッと入るのはいいんだけど、実写に
向かなけりゃ意味無いからなぁ。


抜本的な解決として今考えているのは、ベースになっている
アルミ板上のレイアウトの変更。全体のレイアウトは縦長の
ままで、でもウォームネジは横側に持ってくる形にしたい。

それならカメラが載ったときでもウォームホイール
とウォームギヤの距離に影響する方向には力が加わらず、
かつ重量はストレートに三脚に逃がすことができるので、
重量の増減が極軸にあまり影響及ぼさないはず。


また穴あけやり直さないといけないかもしれない…
11mmの穴開けなおさないで済ませられないかなぁ…
それともハンズでアルミ板買ってくるか…?

とりあえずハード面で設計しなおさないと致命的なのは
この1つだけ。他は色々改善が図れるところだから
特に問題なし。

それにしても、頭の中でかすかに疑問を感じていたところ
って、大体テストしてみるとしょっぱなに顕在化するもの
なんだよな…。テストっていつもそうだから不思議。

うーん。なんとかなるといいんだけどな…。



コメント ( 0 )




ここのところなにやらムニャムニャとやっていたモノ
がようやくカタチに。




arduinoでもwin-avrでも開発可能なボードを搭載した
ポータブル赤道儀。これで一応フィールドに持ち出して
遊べる状態。ネイキッド感満点なんだけど、それはそう。
arduinoと組み合わせるならやはりハード側もネイキッド感
が無いとバランス取れない(使いにくい)かと。

使い勝手を考えながら、操作周りとか色々細かくチューニング
しつつ使うのだ。フフフ。

LED、LCD、圧電ブザーといった出力装置、3つのタクトスイッチ
といった入出力機能もあるので、使用中にモードを切り替えたり
電源電圧や経過時間のアナウンスをさせたり、色々できちゃう。
(LCDはオプションなので取り外し可能)

ISP端子やarduino接続用端子はプログラミングのときしか
使って無いので、ここに拡張ボードを繋げばSPIやUSARTで通信
可能。さらにはLCDを取り外してパラレルI/Oも可能。


こんな風に使います。

上部先端に自由雲台を付けて、そこにカメラを載せて使います。
この三脚は部屋に置きっぱなしにしてある旅行専用小型タイプ。
広角ならこんなヘナヘナ三脚でも結構なんとかなるでしょう。
まぁ飛行機旅行のとき以外は使わないけど。

極軸望遠鏡が無いけど、広角の場合はおおよそ合わせて
おけば済むし、そもそも極望無くても方法さえ知ってれば
極軸を高精度に追い詰めて行くことは簡単なので付ける
つもり無し。


ファームウェアは目下arduinoのIDEで作成中。一応電源オンで
恒星追尾が可能になっていて、スケッチをちょっと弄るだけで
太陽追尾、月追尾、1/2速度追尾も可能に組んであるんだけど、
タクトスイッチの操作でモードをパチパチ切り替えて使える
様にしたり、北半球/南半球を切り替えたり簡単にできるように
仕上げていく予定。


単三のニッ水電池4本で駆動させるんだけど、実験中は秋月の
スイッチングアダプタ5Vを使用。数時間駆動しっぱなしにして
見たんだけど、とりあえず問題ないみたい。実写が楽しみ。
それまでに色々機能を整備なのだ。


ちなみに、赤道儀一般について。

追尾モードを色々と選べるようにすることと、水晶の発振
周波数を何分周するのかっていうのが意外と悩ましい部分。
特に古い赤道儀なんかだと、よく2のべき乗の発振周波数を
カウンタICで分周してステッピングモーターを制御して
たりするんだけど、それだと微妙な速度に調整しなおす
ときにはppmレベルまで誤差を追い込めないので…。
時間経過に比例して誤差が蓄積していくという問題が。
(タイマーの制御周りね…)

で、今回は例の三号機で使った方式を踏襲して、1クロック
単位で誤差の蓄積が生じないようにソフトウェア側で
制御してます。恒星追尾、太陽追尾、月追尾などどれでも
蓄積誤差をゼロにするっていうのは、旧来のロジックICの
組み合わせでは事実上無理なので、そこがマイコン使う
メリット。

まぁ、実際に撮ってみないとどれだけ使い物になるのか…


そうそう。この基盤。一般的なバイポーラ用ステッピング
モーター制御ボードとして汎用的に使えるようになって
いるので、モーター出力5W程度まではこのボードが
使いまわしできるようになってます。というか、そんな
汎用品として使うつもりで作ったんだけど。ってわけで
このボードはあと一つ二つ手元に欲しい…。

中古で買ったあのkenko赤道儀のコントロールにこれを
繋いだらとってもいい感じになるんだよな。
各種追尾モードの速度に変更するだけでなく、急速回転
にも対応するのが比較的簡単。
望遠鏡の場合は視野が狭いから手で方向を変えるのが大変
なので、それゆえモーターで数倍速の移動(前進/後退)
ができれば微妙な構図修正が可能に…。そこまでできると
いいんだけどな…




コメント ( 0 )




天は我を見放したか…
天気予報はほぼ完璧な雨予報。

せっかくいい子にしてたのに、どういう仕打ちなのさ?

明日に向けて、ハードウェア、ボード、そして最低限の
スケルトン+α程度のファームを作り終えたって
言うのになぁ。


まぁ、仕様が無いので次に空が晴れるときを目指して、
スケルトン状態からバージョンゼロまで仕上げておく
ことにしよう。


それにしてもがっかりだなぁ。オイラはあのどら焼き色
のお月様を眺めるのが大好きなのだ。
前回皆既月食を見たのは、どうやら2000年の夏だったみたい。
あのころは確かまだカメラ始めてから間もなかったかと。
リバーサルじゃなく、カラーネガ持って出かけた記憶が。

地球の影にすっぽり入って、真っ暗にならずになぜ赤っぽく
なるのかって理由を知ってから、月と地球の不思議が
織り成す皆既月食がとっても不思議なものに見えるんだよな。

来年の12月にも月食があるらしいんだけど、皆既の時間は
短いみたい。
http://homepage2.nifty.com/turupura/gessyoku/kako/20111210/g111210.html

でも来年は土曜だから、天気さえ良ければなおよしだな。
高度も充分あるから、写真におさめるには好都かも。

来年まで良い子にしていよう。



コメント ( 0 )



« 前ページ 次ページ »