2017年7月22日土曜日

STM32F4で1Wire

 STM32F4で1Wireの温度センサを使ってみた。

 例によってロジアナキャプチャ。







 上から、全景、AD変化開始付近、データ読み出し付近、全景、ADC変換開始付近、データ読み出し付近。最初の3枚はロジアナ、残りの3枚はオシロ。

 ZEROPLUS LAP-Cは最近になってプロトコル解析が全て無料で行えるようになった。1Wireも含まれているので、データ転送を見るだけなら便利。ただしLAP-CではSEARCH ROM COMMANDの、アドレスツリー探索は正常にデコードできない。まぁアドレスツリー探索は例外的な動作ということで、脳内デバッグをすれば。とても面倒だけど。
 あと、LAP-Cの1Wire解析はデフォルトでMSBファーストとなっている。1WireはLSBファーストな仕様なので、ちゃんと設定しておくこと。

 1Wireはだいぶ前にFT232で温度センサを試したことが有る。1Wire通信だけなら問題ないが、パラサイトパワーではAD変換時にストロングプルアップ機能が必要になり、FT232ではこれを実現できないので、あんまり作り込んでいなかった。

 今回はSTM32F4のUART4を使用して1Wire通信を行っている。手持ちのセンサはパラサイトパワーのタイプなので、ストロングプルアップが必用。
 UART4はAF_ODで初期化するが、AD変換コマンドを送信後にOUT_PPに変更する。予めOutputはSetしてあるので、OUT_PPにすればマイコンからおよそ20mA(66mW)程度の電力を取り出すことができる。DS18B20のAD変換/EEPROM書き込み時の電流はtyp1mA max1.5mA @5Vとのことなので、マイコンからの出力でも問題ない。はず。
 本来はオープンエミッタ、あるいはオープンソースのようなピンモードがあれば楽なのだが、STM32F4にはそういう機能はない。ぐぐってもそういう使い方はないようだ。大体オープンコレクタ・オープンドレインで事足りるもんね。
 
 今回はDQを3.3Vに4.7kOhmで釣り上げ、20kOhmでGNDに落として、約2.7Vになっている。またストロングプルアップの時は3.3Vに短絡状態となるため、3.3Vになる。
 実際、オシロの波形ではAD変換中は3.3V、それ以外は2.6V程度となっている。
 ちなみにDS18B20の動作範囲は3.0-5.5Vなので、仕様どおりに使いたいなら分圧抵抗は外す必要がある。とりあえずストロングプルアップの動作確認に一時的に装着してるということで。

 1Wireはかなりアナログ寄りなデジタル通信なので、オシロとかあると便利。ロジアナも有ったほうがわかりやすいけど。
 アナログ寄りのデジタル通信というと、I2Cがあるが、それよりもさらにアナログ寄りだと思う。I2Cはクロックストレッチは有るが大抵のデバイスは必要ないし、クロックストレッチだってロジアナである程度把握することができるはず。ストロングプルアップを分圧抵抗で見ようとするとオシロスコープが必須。まぁ、I2Cのレベル変換ICとかはインピーダンスで自分の信号かほかデバイスの信号かを切り分けてるから、そのあたりは超アナログだけど、少なくともセンサをちょっと使いたいくらいなら気にする必要ないし。

 1Wireの通信は、今回はリセットパルスの生成に18.75kbaud、送信に125kbaud、受信に180kbaudを使っている。
 送信時は、0を出す時は0x00、1を出す時は0xFFを送る。受信時は0xFFを送り、0xFF以外なら0、0xFFなら1と認識する。
 リセットパルスは0x00を送信し、2バイトを受信できればデバイス有り、1バイトしか受信できなければデバイスなし、1バイトも受信できなければハードウェアに不具合がある。不具合の種類は1) 送信の問題、2) 受信の問題、3) 送受信間の接続の問題、等が考えられる。だいたいCANバスの自己診断に近い感じ。

 この通信方法では1Wireの1bitを送るのに、TTL232の10bitを送る必要がある。送信は12.5kbit/sec、受信は18kbit/secくらいの速度になる。
 デバイスの指定に64bitが必要だし、コマンドを送るのにも8bitが必用。データの読み出しの場合はさらに72bitが必要になる。AD変換開始コマンドを送るには約6ミリ秒、データの受信には約10ミリ秒がかかる。ただしDMAやNVICを使えるので、CPU負荷はあまり大きくない。
 すべてソフトウェアで作るとなると数マイクロ秒の精度で制御する必要があるので、ソフトウェアで回す必要があるし、割り込みを禁止したりとかする必要もあるだろうから、かなり厳しいと思う。その点、UARTモジュールを使うのは理にかなったやり方だと思う。


 ということで、STM32で1Wireを使ってみたよ、という話でした。
 今のところ、手持ちのデバイスがDS18B20が1個しか無いので、あんまり1Wireらしくないけど。もうしばらくしたら秋月でいくつか買って、多点温度計測をやってみたいなーと思う次第。

 ちなみに現在の室温は30.5±0.5℃くらいらしい。今日は曇ってるので日照は強くないけど、暑いことに変わりはない。



2017年7月21日金曜日

エレキットのタッチセンサ

 エレキットのタッチセンサを買ってみた。


 ↑コレは手持ちの部品でだいぶ改造してるけども。

 大雑把に説明すると、PIC12F1822のタッチセンサ機能を使ったモジュール。ピンアサインとかはamazonカスタマーレビューに書いてあるので省略。
 PIC使う人ならコレ単体でもコードを書き換えていろいろ遊べると思う。

 電圧範囲は3-5V。PIC自体は1.8Vから動作するけど、このモジュールは3Vからなので注意。
 ジャンパピンを開放すればモーメンタリスイッチ、短絡すればオルタネートスイッチとして動作する。モード切替は起動中でも変更できる。
 タッチスイッチは一瞬触れた程度では反応しない。短い一呼吸程度、気持ち程度のディレイが必用。

 タッチセンサのパッドはミシン目で切り離せる。ワイヤで延長するためのパッドもあるので、ちょっとした距離なら延長できる。

 短時間触れて遊ぶ程度なら誤動作とかは特に無い。
 10個とか15個とか並べればキーパッドを作れると思う。凄まじい値段になると思うけど。
 電源スイッチ1個だけとか、せいぜい2,3個程度までのモノを作るのに使えば良いんじゃないかな。

 タッチセンサーキットの基板はかなり単純なパターン。必用とあらばテキトーなユニ基板とか、空中配線とかでも使えると思う。ここまで来るとプログラム書き込み済みのPIC単体を売ってくれとか、そういう話になってきてしまうけども。

 僕の使いたいものは、電池駆動でタッチセンサを使って起動するみたいなモノだけど、自分で電源を切ったりもできるようなのがいい。
 ということはLDOとかでタッチセンサを駆動して、モーメンタリの出力でメインのDCDCのENを駆動、DCDCの出力を使ってENを自己保持、マイコンからbreak、みたいな感じになるのかな。
 このあたりはいろいろ試す必要があるだろうが。 




#if 0
 今更だけど、4月期のアニメを見始めた。1話だけみて面白そうだと思って録画してたんだけど、結局2話以降全然見てなかった。2クールやるらしいのでまだ放送中。だいぶいい感じだ。でも僕がこういう好みのベクトルのやつ見始めると終盤ろくなことがないからなぁ。

 最近いろんなアニメの再放送をやってる。SAOとか、涼宮ハルヒの憂鬱とか。この際にと録画してるけど、HDDの空き容量がやばい。
 DIGA買った時は1TBあれば充分とか思ってたけど、あっという間に埋まってしまった。外付けの3TBを買って今度こそ安心!と思ったらこの世代のDIGAは外付けHDDに1k本までしか録画できない仕様(当時の型落ちで安いやつを買ったけど、現行モデルはもうちょっと緩和されてる、はず)。

 そう言えばナイツ&マジックのアニメ化も見てる。Web版で途中まで読んでたけど、途中までしか読んでないってことは、微妙に僕の好みと違ってたんだろうなぁ。
 オーディオコメンタリーで「ロボットに乗るかどうかを葛藤するアニメはよくあるが、自分から乗るような作品は少ない」みたいな話をしてた。さもありなん。
 アルドノア・ゼロは進んで乗ってた気がする。まぁ上官が葛藤してたが。でもA/Zはロボットが好きだから乗る、じゃなくて、最適解がロボットだからそれを使う、みたいな感じかも。
 カタフラクトくらいの地上にへばりついたロボットは好きかな。ガスタービンエンジンで発電?して走り回るってのもエネルギー的に無理がなくて良さそう。人形で空を飛んだりしちゃうとちょっと僕の想像の埒外でつらいかんじ。
 そう言えばカタフラクトは空を飛ばないんだよな。ちょーっと長い距離を跳ねたりとか、パラシュートで降下したりはするけど。あと宇宙に行くけど。地上を歩き回ってる限りならはいふり縛りでもできそうだ。はいふり世界にカタフラクト出して何に使うかって問題は有るけど。はいふり世界にも揚陸艦ってあるのかな。海岸から侵攻とかしない世界だと揚陸艦はなさそう。でも水害が多い地域だと救難その他で使えそうだし、海面とか地盤とか動いて沈み込むような世界なら揚陸艦は発展するかも。ならブルーマーメイドが操艦する揚陸艦でカタフラクトがを輸送するみたいな妄想も……
#endif

17042

 夜空に最も明るい星が新たに誕生? - その正体はロシアの宇宙灯台「Mayak」 | マイナビニュース

 こんなのが打ち上がってたんですねぇ。

 毎度のJS Orbitリンク

 同時に投入された物体が70個以上あり、一部は未確定です。おそらく、名前が出た後も正しいラベリングになるには相当時間がかかると思います。

 件の衛星の名前はMayak(マヤーク)だそうです。まだそれらしい名前は軌道情報にはありません。


 打ち上げられてからそれなりの日数が経っているため、かなり散らばってしまっています。真っ先に展開に成功していれば、一番先頭にいるのがMayakでしょうが、展開がトラブっててまだ展開してから時間が経っていない、とかであれば中途半端な位置にいる可能性が高いです。
 ある程度時間が経てば、軌道半径の経過からMayakを特定することは可能でしょう。実際、膜展開を行ったFREEDOMというキューブサットは、同時期に投入された他のキューブサットと比べ、明らかに落下が早かったです。
 でもまぁファーストライトの観測を目指すなら、そんな悠長な事はしてられませんから、総当たりで行くしか無いかもしれません。


 僕がやるならベランダにα7s放置で30分くらい撮影かなぁ。本当にVmag-10になるなら比較明合成をすれば一発でわかるはずですし、そこにいるのがわかれば30分の動画を見れば済むことですから。
 でも家のあたりは来週中頃まで曇りとか雨の予報ですから、しばらくは静観ということで。


 軌道高度は約600kmのほぼ円軌道ですから、日照条件はISSよりはマシだと思います。地上がある程度暗く、かつ軌道上は日照状態、となる時間が、ISSよりも長いはずです。ということは、ISSの肉眼観測よりは観測可能ウインドウが広いはずです。

 しかし、日本上空で地上が暗く、上空が日照という条件は、少なくとも半月ほどはかなり厳しい感じです。


 地上が暗く衛星が日照になるのは、日本では北海道の北端付近しかありません。今後半月ほどはこの調子のようです。
 北米大陸や南米大陸はかなり条件が良さそうです。

 とはいえ、衛星の反射膜の素材によって、輝点が見える範囲も変わるはずです。乱反射するような素材であれば広範囲で暗く見えるし、綺麗に反射する素材であれば狭い範囲で明るく見えるはずです。イリジウムよりも明るいということは、可視範囲はかなり狭いはずです。また反射膜の写真を見ると、アルミホイルみたいな感じですから、反射光はかなり狭い範囲にしか届かないと思われます。
 望遠鏡で追尾すれば乱反射成分でも見えるかもしれませんが、衛星を追尾でき、かつ暗い目標でも見える望遠鏡となると数が限られますし、候補が70個以上ありますから、1個1個調べるだけでも一苦労だと思います。


 とりあえず、数日で落ちてくるような衛星ではないでしょうから、もうちょっと様子を見てみましょう。


追記:2017/07/23

 2017-42で打ち上がった物体の軌道半径をプロットしたグラフ。中央に1個物体が有り、上下に2組有る。実際に軌道を地図にプロットしてみると、中間に物体が1個あり、前後に物体が有る。
 少なくとも5日程度のプロットで目に見えて高度が下がってる物体はない感じ。
 それにしてもこんな軌道にどうやって投入したんだろうか。軌道進行方向側に放り投げた物体と、後方側に放り投げた物体の違いなのかな。

 このグラフを作るのに、自前のTLEデータを捜索するプログラムと、エクセルのファイルを2個、使っている。
 TLEデータは過去1年分ほどのTLEファイルがあるが、テキストファイルで350MB、2万5千ファイルくらいある。コレだけのファイルを全部開いてチェックするとなると、アンチウイルスソフトのチェックのほうがボトルネックになってる感じ。
 エクセルの方は1つめが26MBほど、2つめが73MBくらいある。開くのにはちょっと時間かかるが、まぁほっとけばちゃんと表示できるし。

 今日は今のところ晴れてる。けどウチの上空を通るパスは23時頃か。どっちにしろ日照条件が悪いけども。ISS放出なら少なくともISSは写るだろうけど、ロケット放出だとそれもないからなぁ。
 そう言えば今回のロケットの上段ってどれくらいの規模なんだろうか。少なくともキューブサットよりは遥かにデカいだろうし、高感度で撮影しておけば映り込むかも。
 件のキューブサットとの切り分けが面倒そうだねぇ。こっちは理想条件ならvmag-10とからしいけど、そんな明るさはめったに出ないだろうし。

2017年7月17日月曜日

LEDストリング

 WS2812BというLEDチップを内蔵した、テープ状のLEDストリングを買ってみた。以前にも同じチップを内蔵した物を試したが、その時はマイコンのGPIOで操作していた。
 今回はマイコンのプログラムを書くのが面倒だったので、FT232とC#で制御してみた。FT232H(高速品)が必要かと思ったが、昔からあるチップでも制御できた。ただしTTL RS232は負論理のため、WS2812Bの正論理の信号を作れない。
 NOT回路を作ろうかと思ったが、ちょうどいいFETの手持ちがなく、手持ちのトランジスタでは6MHzの矩形波は通らないので、FT progでFT232の論理を反転させた。
 ボーレートは最大の3Mbaudに設定し、1バイトで2bitを送信するタイミングで信号を送信した。本来のタイミングからはそれなりに逸脱しているが、WS2812Bはかなり信号幅に余裕がようで、とりあえず動作確認程度に制御するなら問題なさそう。

 今回試したストリングは1mあたり60個のチップが実装されており、1.66...cmピッチとなる。
 5m(300個)で非点灯時の消費電流が約0.12A(4V時)、20個点灯させて0.9A(4V時)くらいだった。静止電流が0.4mA/個/4V、点灯時に40mA/個/4Vくらいかな。
 5m全体を点灯させると12Aくらいになる。50Wくらい。そんなに流せる電源は持ってない。手持ちの電源だと最大でも80個くらいしか表示させられない。電圧範囲は5Vくらいまで有るが、5Vで動作させるなら100Wクラスの電源が必用かも。
 とはいえ今回買ったLEDストリングの電源ラインはめっちゃ細いので、連続で10A流すのは無理だと思う。せいぜい1mで分割してそれぞれ電源を接続する感じかなぁ。電線を太いのに交換することも可能だろうが、そもそもフレキ基板の細いパターンだから数Aが限界じゃないかな。
 1mだと2.5Aくらいなので、6Aまで流せるPOL降圧DCDCを使えば2m分を駆動できそうだ。降圧DCDCを通すならLiPoやNiMHのような不安定な電源でも問題ないかも。いろいろ遊べそうだ。


2017年7月16日日曜日

メモ:MacBook Pro (13-inch, Early 2011)で外部液晶が表示されない

 MacBook Pro (13-inch, Early 2011)で外部液晶を使用しようとしたところ、表示されなくなった。症状は、外部液晶を接続したところ、内蔵モニタのバックライトが消え、外部液晶の信号入力もない。つまりすべてのディスプレイが無信号状態。
 数日前には別の液晶を使っていたので、ここ数日で壊れたとかでもない限りは問題ないはずなのだが。
 液晶の問題かと思って型番でググっても特にクレームとかは見つからなかった、ということでPC側を疑う。

 結局、BootCampで入れたWin7に入ってるIntel Graphicsの関係だったっぽい。

 設定方法としては、タスクバーのアイコンでインテルHDグラフィックスのアイコンをクリックして、”グラフィックプロパテイ”を選択。
 ”インテル(R)グラフィック/メディア・コントロール・パネル”で”詳細設定モード”を選択し”OK”をクリック。
 左側の”オプションとサポート”で”ホットキーマネージャー”から”内蔵ディスプレイの有効化”のキーを確認する。デフォルトではCtrl-Alt-F3だが、MBPではFキーが使えないのでテキトーなキーを割り当てた。
 そして外部液晶を接続する。まだ何も対策をしていないので、内蔵ディスプレイも外部ディプレイも沈黙する。その時点で先程の”内蔵ディスプレイの有効化”キーを押す。そうすると内蔵ディスプレイの表示が復活する。
 あとはWin-Pを押して、外部ディスプレイのモード(切断・複製・拡張・外部のみ)を選択する。
 最後にホットキーの設定画面で”デフォルトの復元”をクリックしてキーコンフィグを戻す。


 運良く短時間で解決することができた。どうして外部液晶接続時に内部・外部両方共OFFになる設定になったのかは分からないが。

 それにしても、このノートPCも6年以上使ってるのかぁ。いや、特に不満とかないんだけど。
 次はTOUGHBOOKとかほしいなぁ。トカイッテミル

VL53L0X

 VL53L0Xというセンサを試してみた。
 STMicro製で、ToF(Time of Flight)というタイプの距離センサ。ざっくり説明すると、超音波距離計の光波バージョン。
 以前にSTMが似たセンサを出していたが、そっちはレンジがかなり狭かった。VL53L0Xでは最大2m程度までレンジングできるらしい。



 テスト環境。STBee F4miniの上にVL53L0X変換基板を載せてる。穴位置がかなりちょうどいい。センサ本体はかなり小型だけど、付加回路がいろいろ必用だったりコネクタが大きかったりで、結局DIP16の変換基板くらいの規模。

上からIRで撮影。さすがにレーザーなので明るい。焼付きが怖いので真上からは撮影しなかった。

ちょっと斜めから撮影。すぐ見えなくなる。

中央右下にセンサ、左上に手のひら。距離は5-10cmくらい? これくらいの距離ならIRで照らされてるのがわかるけど、指向性が低いのでちょっと離れればすぐわからなくなる。


 このセンサはSTMicro製でありながら、わかりやすいデータシートというのが一切ない。曰く「わかりやすいAPIを用意したからそっちを使ってね」ということらしいが、僕が試した限りではAPIは初期化でコケて動作しなかった。
 今回はサードパーティのArduinoライブラリをC言語で書き換えて移植した。一応測距はできるし、距離に応じて値も変化するが、精度はあんまり出ていない感じ。
 結局本家APIを動くようにする必要がありそうな気がする。メンドクサイ。


 センサ自体は0.94umの赤外線レーザーで、データシートにもeye safeとか書いてあるが、0.94umは網膜に結構吸収されるらしいので、あんまり直視しないほうが良いと思う。と言っても非可視光だから、レーザーが目に入っても全く気が付かないのだが。


 なつやすみのじゆうこうさく でVL53L0Xを使いたかったのだが、結構大変そうだ。本当に夏の間に終わるんだろうか。下手したら来年の夏とかになってしまうんじゃなかろうか。。。


追記:2017/07/19
 APIに付属するLinuxDriverMassMarket_1.0.6/kerner/drivers/input/misc/vl53L0X以下のソースを使ったらいちおうレンジングできた。移植するのがとっても、とっても!面倒くさいけど。

 あとLinuxってCCI(Camera Control Interface)にVL53L0Xを突っ込んで動作確認できるみたい。映像出力端子にもI2Cバスは出てるけど、こっちは標準化以外の信号は通すの大変なのかも。カメラインターフェースならメーカー独自機能とかを実装する余地があるとか? とにかく、Winみたいな、外部にマイコンを置いて、それ経由でI2Cを叩いて、みたいな七面倒臭いことはしなくていいらしい。
 それなら最初からマイコンで動くコードを公開しておけよ、という気もするけど。せいぜいI2C R/W回りの関数2個を書き換えれば移植できるだろうから、いちいちプラットフォームに依存した変なサンプルとか作らなくても良いはずなんだが。


追記:2017/07/20

 I2Cバスのパケットをキャプチャ。I2Cは200kbaud。立ち上げに250msecかかっており、1回のデータ転送にも35msecほどかかっている。とにかく1回のデータ転送でのパケット転送量が多い。

 あとLongRangeモードのExampleを試してみた。屋内でたぶん2mくらいまで計測できてるんじゃないかなぁ。だいたい150cmくらいは取れてるし、手のひらをかざせばそれに応じて結果も変化する。ただ精度は不明。

 今回の用途だともうちょっと狭角のほうが使いやすいんだけど、センサの本来の用途としてはこれくらいの角度が良いんだろうなぁ。
 データシートのApplicationsにUser detection for Personal Computers/Laptops/Tabletsとか書いてあって、顔の真正面からレーザーをガンガン浴びせるつもりでいてちょっとアレ。いくらアイセーフ(?)とは言えさぁ。
 でもVL53L0Xはレンジング中以外はレーザーを止めるので、人間がいない時は照射間隔を100msecとか500msecで応答性重視、近くに人間がいそうであれば5000msec周期くらいで照射間隔を広げて、みたいな安全策はできるかも。どこまで効果あるのか走らんけど。
 はっ、このレーザーを浴びれば虹彩の色が抜けて…?


 とにかく、VL53L0Xは使用コストがかなり高そうだ。特に30msec周期近い高レートで測距を行う場合、I2Cバスはほぼ100%近くの使用率になる。当然ポーリングで通信を書いているとCPU使用率も同程度になる。
 I2Cバスに他のセンサをつけたり、VL53L0Xを複数個使おうとすると、相当面倒なことになりそうだ。高レートで2-4個使いたいと思ってたんだけどなぁ。I2C転送中も大抵は1バイト単位での転送だから、DMAとか使ってもほとんどCPU使用率は変わらなそう。1バイトの転送はせいぜい数十usecだから、割り込みとか使ってもOSのオーバーヘッドであんまり効果なさそう。