毛虫計算機:Blog

数年ぶりにメモリ増設とグラフィックカードの更新を行った｡ CPU: Corei5-3470 3.2GHz RAM: DDR3 8GB → 16GB SSD: 240GB HDD: 1TB GPU: GT640 → GTX960 4GB PSU: Antek EA-380D-Green (380W) 世代的にはIvy止まりで､バスがやや古くなってしまったがまだまだ快適｡ 3DCAD絡みで時々メモリが足りなくなるので､グラフィックとともに増設した｡ ケースはCore2時代から使っているPowerMac(ポリタンク)筐体 下が GTX960 4GB グラフィックカードと電源容量  もともとmini-ITXで自作していたこともあり､その流れでACアダプタ電源で駆動できるTDPに押さえてきたので､EA-380Dに電源を変更してもそのままにしてきた｡ GTX960は中古品で安価になっていたものを入手｡ ただし､TDPは最大120Wで､6ピンの補助電源コネクタが必要なクラスとなる｡ 最低400Wの電源が推奨されている｡ 以前から使っているEA-380D Greenは80Plus電源だ｡ 一応､6ピン端子も付いている｡ 仕様によれば､12Vがデュアルレーンで合計380Wとなっている｡アンペア的には､片方のレーンだけでも足りている｡ 更に､ eXtreme Power Supply Calculatorでシステム全体を見積もると､合計で290W程度となった｡ ギリギリ動きそうなので､思い切って導入してみた｡ 一応､3DMarkを回しても電源が落ちたりはしていない｡  昔のミドルクラスでは厳しかったかもしれない｡  実際のところ､コスパとインターフェースの将来性で選んだものの､フル稼働させることはあまりなく､普段は1割程度の電力で動いている｡セミファンレス機能があり､普段はファンが停止状態になっていることのほうが多い｡  性能を実感できるのは､KSPでScattererというシェーダーMODを入れて､大気や海洋のグラフィックを最高画質で動かしているときだろうか･･･｡

GPSアンテナを作ってみた｡ 1575MHzの波長は約19cmなので､半波長で9.5cmとなる｡ GHz帯とはいえ､結構長いものだなぁ｡ セラミック等の誘電体がなければ､平面アンテナで真面目に半波長アンテナを作ろうとすると手のひらサイズの面積が必要になってしまう｡ 普通のダイポールだと指向性があるので､交差させてクロスダイポールにする｡ 屋外地上局のアマチュア衛星用アンテナの設計をそのまま縮小したもの｡ 水平パターンはややいびつ 92.2mmの真鍮の針金(Φ=0.5mmくらい)を2本用意して､42.3mmで90°に曲げる｡ 長さの同じ素子同士を並べて配置する｡ (全長が半波長より長い素子と短い素子が交差した状態) 片方をアンテナ信号線､もう片方をGNDにつなげば完成｡ 実際5分くらいでつくったけれど､果たしてどうだろうか｡ 今回は､道具箱に眠っていた表面実装タイプのMT3339系モジュールに取り付けた｡ アンテナはもともと3x1.2mm程度のとても小さいチップアンテナで､ LNAが入っているけど感度が悪かったのでお蔵入りしていた代物｡ 最近の携帯機器はみなアンテナに厳しい｡ さて･･･ クロスダイポール版モジュールをPCでモニタしたウインドウ(左)と､QZ-Rader画面 東側に建物遮蔽があるので､そちら側の衛星はSNが悪い｡ とりあえず補足できた衛星数はシミュレーションされたものとほぼおなじだった｡ アンテナの角度をいろいろ振って､逆さまにしてもロストすることはなかった｡ セラミックのパッチアンテナレベルにはなったかな･･･｡ 簡単にできてそれなりに測位するけれど､携帯性は皆無になった｡ あと､近接周波数の干渉を受けやすいかもしれない｡ GPSアンテナのDIY例としては､QFHアンテナもある｡ ラジオゾンデなどで使われている例がある｡ いつもお世話になっているQFHアンテナ計算シートのサイト https://www.jcoppens.com/ant/qfh/fotos_gps.en.php ヘリカルアンテナは加工精度の難易度が上がるので､今回はクロスダイポールにした｡ GNSSとなると､複数の周波数のために調整されているセラミックパッチアンテナが有利だと思う｡ セラミックパッチア...

冬になってから､屋外に設置していた受信機ボックスとの接続が断続的になり､取り外して改修をすることにした｡ Funcube Dongleを接続していたUSBデバイスサーバーは動作はするものの､通信が不安定になっていた｡ 劣悪な温度環境で4年程度ノーメンテで動作していたことを考えると､よくもったなぁ､と思う｡ ボックスを再利用して､もともと検討していたRaspberryPiによる地上局構築をしてみる｡ 今回はRTL-SDRのTCXOつき公式モデルを入手したので､それを設置してみよう｡ 構成としては､RTL-TCPによる遠隔接続をすれば､今までどおり､他の端末からSDR#による観測が可能となる｡ RTL-SDRをRaspberryPi2につなぎ､AndroidタブレットのSDRTouchからネットワーク経由で接続してみたところ｡ FM放送のウォーターフォール画面を表示している｡ 気になる消費電力だが､Raspberry Pi2を利用して､有線LAN接続した状態で､ SSH接続中は1.8W RTL-tcpで待機させると2.5W  待機中でもRTL-SDRは動作状態になので､発熱も増えてしまう｡ RTL-SDRは､RasPi2と一緒に10cm角のアルミ板に固定してある｡ RaspberryPiを単体で屋外においておくのはなんとなく物足りないので､とりあえず部品箱から余っていたRTCを取り出して取り付け､時刻保持ができるようにした｡ また､LM60と12ビットのA/Dコンバーターを搭載して､複数箇所に温度センサを配置｡  GPIOやバスへのアクセスも､今はWiringPiやProcessing等の環境が整備されているので､SSH経由でソースをちまちま書いて､機能確認できる｡  Linux系の衛星追尾ソフトとTNCをインストールしておけば､単体で衛星追尾と記録も可能になってしまう｡ 手がまわらないけれど･･･｡ 屋外設置 RaspberryPi2の基板にはハヤコートによる防水､防湿コーティングを施した｡ タカチの防水ケースの中に組み込む｡ アンテナも秋月のモービルアンテナから､自作のUHFクロス八木に変更｡ 天頂パスにも強くなった｡ デスクトップのSDR#での受...

ビクセンのアトレック ライト BR6x30WP｡ 6倍 30ミリ口径の低価格なポロ式双眼鏡だ｡入門機としてけっこうおすすめされているもの｡ 最近はロケット雲などの現象によく遭遇するので､即応観測のために取り回しやすいものが欲しかった｡ 中古のニコン12x40を持っているけど､三脚なしでは手ブレがひどく､重たいのでタンスの肥やしと化している｡  店頭でいろいろな機種を見比べてみて､ 明るく､ 6倍なので手ブレを抑えやすく､ 大きさのわりに軽くて持ちやすい というところが気に入った｡ この機種も今時のハイアイで､眼鏡をつけたままでも観察しやすくなっている｡(アイレリーフが長い)  自分は裸眼なので､覗くときに､繰り出し式のアイキャップと顔の距離にちょっとコツがいることがある｡  OEMのため､コーワのYF30-6と構造は一緒らしい｡ 店頭で見比べてゴーストが少なめなこちらを選んだ｡  レンズコーティングで若干差異がある｡ コストパフォーマンスでいうとコーワのほうがお得｡ 落ち着いた性能の双眼鏡を最初に選ぶというのはなかなか難しいけど､導入を皮切りに､どの性能を伸ばせば､自分の用途に最適なのかというのが見えてくるという点で､バランスのよい機種だと思う｡

物体の温度を非接触で測定できる放射温度計を空に向けると､何の温度をはかることになるのだろうか｡ NASAの教育用サイトに簡単な解説があった｡ http://mynasadata.larc.nasa.gov/science_projects/measuring-the-temperature-of-the-sky-and-clouds/ どうやら､上空を通過する雲や､数キロ上空の大気からの赤外線放射を捉えることになるようだ｡大気に塵や水蒸気量が増えると､赤外線放射も多くなる｡ 上空の気温がどの程度なのかについては､気象庁がラジオゾンデによる観測を行っていて､高層天気図として公開されている｡ http://www.jma.go.jp/jp/metcht/kosou.html nLogにセンサをつなぐテスト 本題としては､デジタルな放射温度センサMLX90614(3Vモデル)を手に入れて､簡単な動作テストのために､真上の空を24時間測定してみた｡ この素子の観測波長が記載された資料を見つけられていないけれど､ "大気の窓"とよばれる､赤外線を透過する5～14μm付近を捉えるようになっているはず｡熱放射に対して-70℃～380℃のレンジをもっているから､大気中なら申し分ない｡ 実験は昼12時から24時間､屋外での連続観測を実施｡ MLX90614はセンサの温度と放射温度､カラーセンサはRGBと赤外線を捉えている｡ 気象条件としては､前半は快晴､夜中も星空が見えていた｡ 明け方から薄雲が増えはじめ､午前中は曇り空になった｡ 夕方にカラーセンサが突然落ち込むのは､太陽が建物の影にはいったため｡ 遮蔽が無いため､日があたっているとセンサ自体が熱せられ､温度(ambient)が上昇する｡ その間も放射温度は-15℃付近を示していた｡  日没後はグラフが安定し､明け方に雲が通過したようなピークがみられる｡ 高層天気図を読むと､この日の－15℃の空気は､上空5～6kmの気温に相当しているようだ｡ センサを裸で曝露させているので､視野が広い｡ 横の建物由来の赤外線放射もある程度捉えていそうな気がする｡ 少なくとも､上空の雲の量や大気の澄み具合が値に反映されることはわかった｡ 空をいろいろな波長...

 簡易データロガー第二世代｡ 3年前のモデル の改良版｡ 極限環境でのプロトタイピングを目的とし､いろいろなものに組み込む形での利用を想定している｡ 基板サイズと端子配置はUP-204GSRに合わせてあり､今回は端子数を増やし､RTCと9DoFセンサを搭載した｡ 特徴 引き続き 5V系 (※I2Cは3.3V系) ATmega644P使用(4kB RAM 64kB Flash) 16MHz Sanguino互換 ヒンジ付きマイクロSDカードスロット搭載､衝撃に強い｡ 300kB/sec程度のリード/ライト速度(一例) RTC(TCXO)搭載､MCU割り込み可 MPU-9250搭載 GPIO 12ch  アナログ入力 8chと共用 去年以来､KiCadでのPCB設計も7枚目になるので､だんだんと慣れてきた｡ 今回も片面実装｡  電源は5V系｡ SDカードとI2Cバスは3.3V系｡ 5Vと3.3Vは基板外へ出力できて､配下の回路電源に利用可能｡ メインのリニアレギュレータはLT1763で､VINにプルアップされたEN端子を引き出してあり､LOWレベルで基板の電源を落とせる｡ このLDOはちょっと値段が高いけど､DC/DCが選択肢でなければ､ 逆流防止も備わっていて便利だ｡ RTCは新たにEPSONのRX8900を実装｡TCXO搭載でとても小さい｡ バックアップバッテリは前回の設計の反省を踏まえ､1次電池用のコネクタを用意した｡ 外部GPIOは､PWM機能付きのピンを4つ｡ アナログ入力をもつポートAはまるごと引き出しているので､合計12本となる｡ 基板面積に余裕があったので､MPU-9250を搭載｡ 9軸のセンサデータを単体で記録できる｡ こちらもGitHubで公開しています｡ GitHub   https://github.com/kentN/nLog_9DoF

 ASTRO-H(ひとみ)を打ち上げたH-IIA 30号機｡ 前回の29号機では､関東で ロケット雲が観測できた ので､東京からやや期待しながら打ち上げを待っていた｡  多かった雲も消えて晴れ渡った日没直後の空で､今回はロケットそのものを観測するという機会を得た｡  (肝心のロケット雲は見られず｡ 雲が遠かったようだ)  自分で撮影した動画｡ HD画質で視聴しないと､最初はぼやけてよくわからない｡ (急いでいたのでピントの無限遠固定を忘れている)｡ iPhoneでJAXAの公式配信を聞きながら､そのシーケンスを目撃するという､面白い体験になった｡ 動画の途中を拡大してみたもの｡ 見え方は､ISSなどの可視パス観測に似ていた｡ 低軌道を進んでゆく､ガスをまとった小さな彗星のようでもあった｡  目視では､第一段燃焼停止を南の方角で見ることができた｡  推進中はガスの雲が彗星のようにVの字に光条となって見えていたが､第一段燃焼停止のタイミングで形が変化し､移動速度を保ちながら丸く拡散して散っていくのが見えた｡ (追記: 近所にある国立天文台がより細かな追尾撮影を行っていたので､そちらのほうが見応えがあります｡ https://www.youtube.com/watch?v=XqMXSi5yXx4 1080p画質で画面一杯に拡大して見ると､1分くらいで燃焼停止が起こり､明るい光点とやや小さい光点の2つに分離しているのが写っています｡ 光は太陽光の反射で生じているとすると､2段目はどっちなのか気になりますね ) なぜ綺麗に見えたのかを整理すると､ 打ち上げの方角が東向きだったこと｡(本州から見やすい) 天候: 大気が澄んでいて､雲がなかったこと(重要)｡ 打ち上げのタイミング: 観測地では日没で､ロケットには太陽光があたっている条件｡(可視パスであること)  空が明るすぎると､昼間の金星を探すのと同じで､肉眼では場所がわからないと識別しにくい｡ 当時も南西の方角は西日の名残がのこっていて､発見した当初はかすかなモヤのように見え､輝点の動きから飛行機でないことに気づくまでしばらくかかった｡ 第一段が燃焼を停止する直前には暗い箇所まで移動して...

Wineが登場してしばらく経っていたけれど､久しぶりに確認すると､今のWineではかなりのソフトウェアがそのまま動くようだ｡ 物は試しと､いろいろと使ってみた｡ 上はOrbitoronが普通に動いているところ｡ Ubuntuノートをサブノートとして携行できるように､いろいろ試してみる｡ Wineのバージョンは1.6.2 (apt-get で導入) Teraterm Ubuntuで入手できるシリアルターミナルでも問題は無いけれど､動くというので導入してみた｡ USBシリアルに接続する場合は､ /dosdevices/配下に com1というシンボリックリンクを作成するようだ｡ cd .wine/dosdevices ln -s dev/ttyUSB0 com1 USBシリアルはudevルールに登録して､あらかじめ権限を得ておく必要がある｡ そのあたりがなかなか慣れない･･･｡ 一度登録がうまくいけば､あとはあっさりと動作した｡ LTSPICE系も普通に使える｡  Notepad++でのテキスト編集も問題なかった｡ 実行もアイコンをクリックするだけだし､ほとんどストレスなく使えるのでびっくりした｡ デスクトップにWindowsアプリが増えてくると､これはUbuntuなんだろうか･･･とだんだん不安になってくる｡ フォントの問題などは､調整が必要な場合もあった｡ 少なくとも､Windows機をサブノートにしなきゃいけない理由は減ってきた｡ いいことだなぁ｡

たまたま､Chromebook C720/2 の中古を見つけて安く手に入ったので､Ubuntu専用機として環境整備をしてみた｡ C720/2のスペックは､ Celeron 2955U(Haswell世代) 4GB RAM 16GB SSD(M.2) USBポートが左右に一つずつ､オーディオジャックとSDカードスロットがあるだけの割りきった設計｡  2～3万円でWindowsタブレットやWindows10の激安ノートが新品で手に入る時代だけれど､ ハードウェアに32bitOS縛りが無いものはその2倍程度になってしまう｡  ファンレスではないが､最大負荷でもほとんど音が聞こえない､静かなファンを搭載している｡ 価格なりの点としては､液晶がTNなのと､キーボードの日本語配列は英字配列の枠をそのまま使って､キーを分割して詰めこんであるあたり｡ やや慣れが必要だ｡ ChromeOSそのものはブラウジングだけでいろいろ完結するので､ストレスなく利用できる｡ スワイプ動作が秀逸｡   貧者のMacbookAirと呼ばれるけれど､北米では教育機関への導入でAppleのシェアを奪っているという記事もあった｡ Linux機としての利用 ChromeOSそのものはlinuxカーネルで動いていて､Ubuntu等を利用する場合は3通りの方法が存在する｡ ハードル(ChromeOS､ハードウェアへの影響度)の低い順だと､ 1: croutonで､ChromeOSのカーネルを利用して､Ubuntu環境を追加で導入する｡(開発者モード) 2: Chrxの導入で､予備のパーティションを利用してChromeOSとのデュアルブート環境を構築する｡  (開発者モード､レガシーブートの有効化) 3: Ubuntuをクリーンインストールする｡ (開発者モード､レガシーブートの有効化､USBブートの有効化)  一通りの導入を試してみた結果､自分の場合はクリーンインストールが最もストレスが少なかった｡ もしSSDが16GBのままなら､デュアルブート環境では残り容量の点でかなり厳しいという弱点もある｡ ChromeOS自体は､BIOS設定で失敗して文鎮化しなければ､リカバリメディアを作成し...

年末に書いていたつもりが､もう2016年ですね｡ 32ビットのArduino互換機を比較してみる目的で､円周率を計算させ､実行速度を出してみた｡ ｢C言語によるアルゴリズム辞典｣ に載っていた多倍長演算による円周率の計算(Machinの公式)を使って､1000桁ほどを実行するのにかかる時間を調べる｡ 手元の32ビットな互換機は､ ･ChipKit MAX32 (PIC32MX795F512L MIPS32 M4k ) ･Arduino DUE ( SAM3X8E ARM Cortex-M3 ) ･MSP432launchPad (MSP432 ARM Cortex-M4F ) ･Teency LC （MKL26Z64VFT4 ARM Cortex-M0+） 2017_Feb 追加 それぞれ開発環境はArduino, MPIDE（Chipkit Core）, Energia 参考枠として､8ビットのATmega328Pにも頑張ってもらった｡ 結果 処理時間/ (MCU名､@動作周波数)/ 処理時間x動作周波数 / ( ATmega328Pのスコアを1とした時の倍率) 732ms    ( PIC32MX795F512L @15MHz )  10980 (29.8) 364ms    ( PIC32MX795F512L @30MHz )  10920 (30.0) 136ms    ( PIC32MX795F512L @80MHz )  10880 (30.1) 139ms    ( SAM3X8E @84MHz )               11676 (28.1) 222ms    ( MSP432 @48MHz )                 10656 (30.8) 2149ms  ( MKL64Z @48MHz )               ...