2018年12月31日月曜日

キューブサットの軌道

 久しぶりのヤツ。

 今回はSpaceTrackをソースにしてみた。


 今回は軌道長半径の計算をプログラムで行い、グラフ化だけをエクセルで行っている。
 以前はエクセルで計算も行っていたので、その関係でグラフ化できるデータ数に強い制限を受けていた。


 SpaceTrackはJSONとかXMLでデータを取れるので、後処理がかなり楽。
 今回はXMLからパースしたが、かなり楽だった。少なくともTLEから読み込むような苦労は不要。

 ただ、XMLで落とすと、相当にファイルサイズが大きくなってしまう。
 上記グラフを作るためのデータで43MBを超えている。
 SpaceTrackは最新のデータだけを取り出すか、すべてのデータを取り出すか、しかないのが辛い。2日毎、程度の頻度でいいのに。

 150日くらいの期間だと、ISSから放出された衛星はほとんど落ちない。もっと長い期間が必要だけど、ダウンロードするだけでも一苦労だなぁ。


 いろいろやりたいことはあるんだけど、まぁ、来年にがんばる。

2018年12月28日金曜日

STM32のUSARTのRTS

 STM32のUSARTで遊んでる(USB FS CDCはあまりビットレートが出ないので、大容量の転送にはUSARTのほうが有力のため、さらに有効に使うための予備実験)。

 とりあえず、割り込みもDMAも使わず、てきとーにポーリング、という状態。


 RTSを有効にした上で3バイトを転送すると、1バイト目の受信中に(最終ビットを受信した時点で)RTSがアサートされる。しかし、この時点でアサートされてもFT232Hは対応できないので、次のデータの送信が始まってしまう。
 次のデータのストップビットを受け取った時点でOver Run Errorが発生し、RTSはネゲートされる。
 FT232は3バイト目の送信をRTSによりディレイするが、STM32は2バイト目を受信した時点でRTSをネゲートするので、FT232は受信可能な状態として認識し、3バイト目の送信を開始する。

 以降、Run Time Errorをクリアしない限り、RTSはネゲートで固定されている。


 STM32F4のAPB1に接続されたUSARTは最大で5.25Mbaud程度までは対応しているが、115.2kbaudでも早すぎるなら、5.25MbaudでRTSを使うのは現実的ではなさそうだ。
 少なくとも、ポーリングでは不可能。まぁ、ポーリングで5.25Mbaudなんて活かせるわけがないので、最初から使う気はないわけだが。
 DMAを使う場合でも、うまいこと処理してやる必要がありそう。

 APB2に接続されたUSART1なら10.5Mbaudまで出せるけど、USART1のハードフローはUSB FS phyに使用されているピンと競合するので、USB FSをデバッグに使っているとUSART1のハードフローは使用できない。
 USB CDC(VCP)だけならUSB HS internal phyでもいいけど、今度はUSB DFUでの書き込みができなくなる。
 他に、APB2にはUSART6も接続されているが、STBee F4miniに使われてる64ピンパッケージではUSART6のRTS/CTSは使用できない。
 結局、APB1を使うしかない、という結論になる。
 そもそも、DMAでRTSを割り込みの中から制御するなら、わざわざペリフェラルに接続されたRTSを使う必要はないわけだから、UARTとかでもフロー制御できるわけだが。

***

おまけ

 ポーリングとは、雌伏して悪巧みをする、または反撃の準備をすること。
 出典:私、能力は平均値でって言ったよね! - 78 閑話


 「ポーリングをポーリングする」みたいな言い回しができそう。

2018年12月24日月曜日

かやのみ



 かやのみでまさかの地元回。

 正確には隣町ですらないけど、目視圏内だから、まぁ地元ということで。

***

 富良野って、アニメ作品ではほとんど出てこない。
 「ちらっと写り込んだ旅行カタログに映り込む」程度では時々出てくるらしいんだけど。

 "君の名は"のノベライズでも、富良野が出てきたけど、映画では省略されてた。
 富良野は観光地ではあるけど、せいぜいその程度しかないので、わざわざアニメとかに出すようなトコロじゃないんだろうなぁ。

 今回は酒つながりということで。

 ところで、僕は全く酒類を飲まないんで、ワインと言われてもなぁ、という感じなのだが。
 ワインと言われて思いつくのは、米陸軍工兵が成形炸薬に使う、くらいしか……
 ガラスは密度が低いんで、ノイマン効果は少ないんだけど、モンロー効果でそこそこ破壊力が上がるらしい。ちょっとした点の破壊には便利なんだとか。便利というか、そのへんで手に入るものでいかに効果的な作戦を実施するか、という話なので、ワイン瓶じゃなきゃだめ、というものでもないのだが。
 そういえば、醤油の液滴を落としてミキサーで撹拌すると美味しい、と決マネに書いてあったな。ワイン飲まないんで試したことないけど。

件のレーダー

 チャチャッとググって書きなぐった文章なので、でたらめなこと書いてあるかもよ!


2018年12月23日日曜日

キャラLCD

 キャラLCDがうまく動いてくれない。
 データシートを見ると、InputのHigh levelは0.7 Vddとのことで、5V動作なら3.5V以上がHとして認識される。
 3.3Vレベルの信号はうまく受け取れないようだ。

 "(前略)キャラクタLCDは初心者も良く利用する基本的なモジュールでありながら、実は結構気難しくてうまく動いてくれないこともあるということです"
 ねがてぃぶろぐ キャラクタLCD処方箋

 ほんとにそのとおり。

 キャラLCDに何度困らされてきたことか。。。

 最近だとI2C接続のキャラLCDとかもあるらしいんで、こっちを使ったほうが簡単かな? 単価がお高めとか、I2Cはそれはそれで気難しいとか、難点もあるけど。


 個人的には、ストリナのグラフィックELが結構便利かなーと思ったり。
 HD44780互換のコマンド形態で、3V動作が可能。低温環境でも大丈夫(動作範囲-40℃から)。視認性も高いし、残像も少ない。
 ただ、値段が普通の液晶の2倍強するのと、キャラクターモードでは表示が若干崩れるので、グラフィック専用として使う必要があるのが面倒な点か。あと地味に消費電力が高いのも。フォントとかも。


 せっかく1-Wire温度計が大手を振って使えるようになったんで、温度を表示したいなーと思っていたんだが、表示デバイスで思わぬ苦戦。
 グラフィック液晶はただ表示するだけならまぁどうにでもなると思うんだけど、使いやすいライブラリを作ろうとか横道にそれると、やることが増えてくる。

2018年12月21日金曜日

1-Wireを使ってみた

 STM32F4で1-WireのDS18B20を使ってみた。
 今回はまじめにstrong pullupを実装した。

 回路図はこんな感じ。


 R1でプルアップ、R3でプルダウン、R2でTXをリミット、という感じ。
 R1は通常のプルアップ。
 R3で非常に弱いプルダウンを作り、リセッシブで3.1V程度になるように調整している。
 R2でマイコンの吸い込みを制限することにより、マイコンがLowに駆動しているのか、デバイスがLowに駆動しているのかを判断できるようにしている。また、この抵抗によりstrong pullupでの負荷で電圧が変動するようにしている。

 今回はSTM32F405RGT(STBee F4mini)のUSART2を1-Wireの通信に使用している。
 通信はNVICで行い、DMAは使用していない。


 通信中の波形はこんな感じ(マイコンのADCでサンプリングした)。


 バスの電圧が3.1V程度で始まり、リセットパルスは100Ωにより0.1V程度までしか落ちていない。
 その後、プレゼンスパルスはデバイスが無制限に吸い込むため、ほぼ0Vまで落ちている。skip ROMとconvert tempはマイコンからの送信のため、こちらも0.1V程度。
 conv tempコマンドの直後にstrong pullupを有効にしているので、一旦3.3V程度まで上昇し、その後、デバイスのADCが開始して消費電流が増えると、100Ωのドロップ分で3.2V付近まで落ちている。
 立ち上がりから電圧のドロップまでは15usec程度しかない。DS18B20のTime to Strong Pullup On(tSPON)はこの期間を指していて、最小で10usecでADCが開始する(最大でも10usec以内にstrong pullupをONにしろ)、ということ。

 マイコンでも10usecくらい簡単に過ぎてしまうので、strong pullupは割り込みで処理している。といっても、UARTの割り込みはタイミングが合わないので、EXTI(ピン変化割り込み)を使っている。
 STM32のGPIOは、オルタネートを使いながらピン変化割り込みを発生させることができる。ただし、HAL_GPIO_Initを使用するとこの初期化が行えないので、自分でGPIOのレジスタを叩いて設定する必要がある。

 また、毎回EXTIを発生させると邪魔なので、strong pullupが必要なコマンドを送る際は、最終ビットを送る直前にEXTIを有効にし、最終ビットが送られたタイミングで割り込みが発生し、このISRの中でEXTIの無効化とAF_ODをAF_PPに変更する処理を行っている。
 次の通信の際は、リセットパルスを送る前にAF_PPからAF_ODに戻す処理を行っている。
 ビットが立ち上がる際は必ずGPIOがHighになっていて、ODはHigh Zだから、これをAF_PPにしてやればLow Z / High levelに固定される。


 その他注意点として、リセットパルスを送る際に1-WireのTx/Rxキューをクリアしたほうがいい。Txはどうでもいいが、ついでなので。
 デバイスがホットプラグで追加された場合、デバイスを挿入した際にプレゼンスパルスが送信されるが、これがRxキューに入ると正常な通信を行えないため。
 1-Wireのバスが使用中でも気にせずにプレゼンスパルスが送信されるから、1-Wireは厳密にはホットプラグは非対応、という感じだろうけども。

***

 ということで、無事にSTM32で1-Wireのstrong pullupが実装できた。3ピン必要かな、と思っていたが、2ピンで処理できた。ほんとは1ピンでできるのが理想だけどね。
 タイマ割り込みとか使えば可能だけど、コスパが悪いのでUARTで2ピン使うほうが良さそう。

 転送速度はもう少し改善できそうな気もするけど、そこまでキチキチにビットレート稼ぐようなバスでもないし。もう少しリファクタリングしたら完了かなー。
 せっかくなので液晶か何かに表示して温度計にしたいが。

2018年12月18日火曜日

TSYS01がごくたまにエラーになる


 ごくたまに、TSYS01がNACKになったり、-510℃という温度センサのレンジ外どころか、絶対零度をも下回るような結果を出す時がある。
 ライブラリの構成上、基本的にNACKエラーを検出すると+nanを返している(係数の読み出しに失敗したときも+nanになるが、その場合はすべてのサンプルがnanになるので、NACKと区別できる)。

 FFT結果がおかしいなーと思って調べて気がついた。

 トータルで8万サンプルほど取ったが、このうちNACKが13回、異常値読み出しが6回あった。異常値読み出しは必ずNACKの直後のサンプルになっている。

 まず-510℃という異常値だが、これはraw値0をこの温度センサの校正値で補正したときの温度に一致する。つまり、ADC結果を読み出したときにゼロを読むと、-510℃という値になる。

 ではなぜゼロが読み出されるか。
 不明。謎。

 次にNACKエラー。これに関しては 1) バスが接続されていない 2) センサの電源が切れている 3) その他 の3種類が考えられる。1と2を合わせてハードウェアエラーとも考えられる。
 マイコン側のバスが異常な状態になった場合、おそらく復帰はできず、それ以降はつねにNACKになるはずだが、実際はそうなっていないし、別のI2Cセンサも読めているから、マイコンのI2Cコントローラーが死んでいる、ということではないはず。
 また、マイコンに近い側の接触不良であれば、他のI2Cセンサも同様に読み出し不良となるはずだが、そうはなっていない。ということは、TSYS本体に近い部分での接触不良等が考えられる。

 1回だけ、NACKが連続して検出されているところがある。4回のNACKエラーで、1Hzで計測しているから、4秒から6秒弱の間センサが応答できなかった。


 いままで、ワイヤハーネスでの接触不良というのは(ピンアサインのミスとかを除けば)経験したことがない。よほど下手に作らない限りは、作って数日で接触不良になる、なんてことはないはず。振動するような環境でもないし。


 腑に落ちる原因がわからないのが嫌だなー。

 とりあえず、このセンサは通常の動作でゼロが読み出されることはないはずだから、NACKとraw値ゼロはエラーとする、みたいな処理にしてやれば、異常値は取り除ける気がする。


 そう考えると、計測値にCRCとADCbit数がついてくるDS18B20は便利なんだよなぁ。ビットエラーはCRCで取り除けるし、ADCbit数の異常もチェックできるし。
 ADT7420はリセット時が13bitだから、何らかの原因でセンサがリセットされると、ほしい分解能が得られなくなってしまう。
 TSYS01は何も設定するところがないので、分解能の変化はありえないけど、I2C転送中のビットエラーは検出できない。


 そういえば、TSYS01の動作確認をしているときに、時々不思議な挙動をすることがあったな。あちこち触ってる間に普通に読めるようになってたので放置してたけど、そのあたりしっかり確認しておいたほうがいいかも。

2018年12月17日月曜日

ファルコンの


 しばらく見ない間にだいぶ増えてた。
 現在64個。

 ただ、Falcon 9 Flight 64では64個の衛星を投入していて、この他にペイロードアダプタとロケット上段があるはずなので、すべての放出に成功していれば少なくとも66個の軌道物体が必要なはず。
 F9最上段ってデオービットできたっけ? ペイロードアダプタは、メーカーの動画を見る限りではデオービットするような機構はなさそうな気がする。


 件のインフレータブルな衛星は、どうやらミッションが遅れているようだ。
「衛星多すぎて軌道要素ワカンネ」みたいなことらしい。
 TLE出てくるの時間かかったからなぁ。

 ところで、今回はマイクロサットが15機、キューブサットが49機、打ち上げられている。これだけ数が多く、前後に長く伸びていると、少なくともレーダーだけでは衛星の特定は不可能なはず。
 となると、運用側が「このあたりにいるのがウチの衛星っぽいね~」とあたりをつけて運用するしかないはず。強烈な指向性のアンテナを使っていれば、数機程度には絞れるかもしれないけど。
 件のインフレータブル衛星だと、大体の位置がわかれば展開コマンドを出してやって、それが通れば空気抵抗が増えて一つだけ特異な動きをする、みたいな感じで判断はできそうだが。

 ISS放出で数機しか衛星がいないときでもどれが目標かわからず四苦八苦、みたいな感じらしいので、これだけ数が多いと辛いだろうなぁ。

 そういえばイリジウムNEXTは1回で10機くらい上げてた気がするけど、彼らはどうやって同定しているんだろうか? 最近のインテリジェントな衛星なら自分でGPSとかで精密に軌道決定できたりするんだろうか。

/* ところで、Falcon9のフライト64で衛星を64機打ち上げたのは、偶然なんだろうか? */

温度センサのノイズ比較


 1Hzで計測したTSYS01(青)とADT7420(赤)とDS18B20(緑)のスペクトル。
 横軸が秒、縦軸がケルビンピークピーク、のはず。

 意外にも、僅差ではあるが、ADT7420が一番ノイズが多い、という結果になった、次点でDS18B20、やはりというか、一番ノイズが少ないのはTSYS01、という結果。

 それでも、すべてのセンサで全域に渡って周期的なノイズは1ミリケルビン以下と、十分に少ないわけだが。

 DS18B20はもっと悪いかな、と思っていて、「1つくらいノイズフロア高いやつほしいよね」と思って計測しただけに、少し裏切られた気分。

 もっとも、温度センサの性能はノイズ量ではなく、オフセット量で判断すべきで、この計測方法ではオフセット量はわからないし、校正に使えるほど高精度な温度センサもないので、どのセンサが一番いい、という判断はできないのだが。


 ちなみに、データシートから拾ってくると、ADT7420は3σ±0.15℃、DS18B20は3σが温度によって異なるが、20℃から30℃の範囲では+0.5 - -0.45℃くらいの範囲になる。DS18B20はmean errorが結構オフセットしてるが、2線式で使えることを考えれば十分に補って余りある精度だと思う。DS18B20はそれほど安いセンサというわけでもないしね。妥当な性能かもしれない。

2018年12月14日金曜日

TSYS01

 ストリナに注文してたTSYS01が届いた。佐川だから明日かなーと思ってたら今日届いたし、今日届くかなーと思ったクロネコは届かないし、槍でも降るかもしれない。雪なら降ってるが。


 ADC結果は24bit、係数は16bitで得られる。とりあえず読み出しはできるようになった。Excelで計算するとちゃんと気温らしい数字になるんだけど、オンボードで計算するとちょうど10倍された値が表示される。
 係数は16bit幅8本で得られるが、最終レジスタはチェックサムも含む。このチェックサムの計算は、すべてのレジスタを8bitに分解し、8bit32本を加算して下位8bitが0x00になればよろしい。

 計算式はかなり大きなスケールを扱う必要がある。
 一番大きな数字は(24bit / 256)^4かな? 10進で20桁くらいになる。
 あとはk0からk4までの係数5個があるが、これは+4や-2をかけてから10^-21をかけたりする。
 10倍で出てくるのは、10^-nの値が間違ってるのが一番ありそうだけど、ざっと見た感じそうでもないんだよなぁ。


 exampleをexcelで計算すると、最終桁が一致しない。
 ADC16の小数点以下を丸めると正しい結果になる。ただ、ADCの下位3分の1を捨てるのはなんかもったいない気がする。


 もうちょっといろいろ試行錯誤する必要がありそうだ。

2018年12月13日木曜日

超音波風向風速計

 初期化周りがうまく動かないんで他のところをやってる。


 気温1(青)が温度センサからの気温、気温2(赤)が超音波で計測した気温。
 風速は、水平・垂直ともに0.1-0.25m/s程度のオフセットがある。たぶん温度依存の部分だと思う。

 ADT7420に関しては、パターンにジャンパを飛ばすことで対応した。
 GNDのパターンが切れいたので、そこにジャンパを飛ばしたところ、安定して計測できるようになった。

 風速は全体的にノイズがあるが、普通に風速計として使うなら10秒くらいの平均を取ればいいので、それほど問題にはならない。応答性が必要としても、1秒平均とかすればいいはず。


 サンプリングポイントが今は1024だが、これが512や2048になったときに、ノイズがどうなるか。最大4096ポイントまでは処理できるが、それに対してノイズがどれくらい減るか。

 あとPCで表示する機能を作りたい。文字だけだと味気ない。

2018年12月12日水曜日

超音波風向風速計

 風向風速の計測はある程度メドがついたので、初期化周りに手を出してる。

 とりあえず、4種類の周波数をだして位相を計測してみた。

***
ch: 1
  0 39.772727 kHz  +48.38 deg -14.0 dB
  1 40.384617 kHz +109.09 deg -12.7 dB
  2 41.015625 kHz +168.91 deg -12.2 dB
  3 41.666668 kHz -125.06 deg -12.8 dB
ch: 2
  0 39.772727 kHz  +69.02 deg -16.5 dB
  1 40.384617 kHz +137.11 deg -15.3 dB
  2 41.015625 kHz -161.83 deg -14.8 dB
  3 41.666668 kHz  -84.12 deg -14.8 dB
ch: 3
  0 39.772727 kHz  +22.40 deg -14.4 dB
  1 40.384617 kHz  +77.55 deg -13.3 dB
  2 41.015625 kHz +141.26 deg -12.8 dB
  3 41.666668 kHz -158.72 deg -13.8 dB
ch: 4
  0 39.772727 kHz  -90.43 deg -13.5 dB
  1 40.384617 kHz  -35.55 deg -12.0 dB
  2 41.015625 kHz  +19.98 deg -11.4 dB
  3 41.666668 kHz  +67.97 deg -12.2 dB
ch: 5
  0 39.772727 kHz  +17.68 deg -13.5 dB
  1 40.384617 kHz  +82.63 deg -12.6 dB
  2 41.015625 kHz +135.29 deg -11.9 dB
  3 41.666668 kHz -170.44 deg -14.3 dB
ch: 6
  0 39.772727 kHz  +59.73 deg -14.0 dB
  1 40.384617 kHz +119.71 deg -12.5 dB
  2 41.015625 kHz +177.73 deg -11.5 dB
  3 41.666668 kHz -126.82 deg -11.7 dB
***

 周波数は39.77kHz、40.38kHz、41.01kHz、41.67kHzの4種類。パルス周波数とFFT分解能が整数比になるのは、40kHz前後ではこの4つの組み合わせだけ。広げればいくつかは増やせるが、とりあえず今は4個あれば十分だろう。


 周波数とゲインをグラフにするとこんな感じ。中心周波数は40.7kHzから41.0kHzのあたりにありそうだ。パルス圧縮で超音波レーダーを作ってたころも、中心周波数が40kHzより高いんじゃないかと思っていたが、実際にそのようだ。数字としてはたいしたことないけど、dB表示だから、40kHzで13dB、40.6kHzで12dBとすると、0.6kHz違うだけで3割弱の差になる。結構でかい。

 ch2のゲインが低いのは、中心周波数が上に寄っているから、というのも原因の一つ。もっとも、一番ゲインが高そうなあたりでもほかの物よりは低いのだが。
 もしかしたら素子のセラミックが薄いのかもしれない。そのために圧電効果が低くなり、ゲインが低く、また軽いために共振周波数が高くなっている、というシナリオは有り得そうだ。


 とりあえず、周波数と位相のデータは取れたから、あとはここから正しそうな数値を取り出す必要がある。
 この位相は送信開始から1msec経ったところでの位相角度で、送信開始時は常に0度から開始している。ただし、パルスは正弦波ではなく、矩形波で近似しているから、それは誤差になるかもしれない。

 数値データは2個4組で1ch分だから、これくらいなら簡単に扱える。
 PC上のGCCでいろいろ試せるので、いちいちマイコンに焼かなくていいのは楽。


追記



 各周波数で、0の時点での位相をch1の計測値に合わせるような波形を書いてみた。一部を拡大したのが下の図。
 -0.27msecあたりですべての波形の位相が揃う。ほかにも、-1.85msecとか1.3msecあたりとかにも位相が揃う位置はある。
 ADCは送信開始から1msec遅れた場所から計測を開始しているから、相対-0.27msecは絶対0.73msecで位相が揃っている、ということになる。

 ところで、このデータ、どういう解釈をすればいいんだろうか。
 伝搬遅延は0.43msec程度だから、0.73msecでは0.3msecほど計算が合わない。


 自分でも何をやりたかったかわからなくなったグラフ。
いちおう、上のグラフとは相関してるから、根本的な考え方は間違っていないはず。最終的にどういうふうになるのかはわからないけど。


 もうちょっと、実際のものをうまく取り込んだモデルを考える必要がありそうだ。考えがまとまらない。でっかいホワイトボードほしい。


追記

 想像上のタイミングを図にしてみた。


 最初の400usecが伝搬遅延、送信開始から1msec後からの1msecがサンプリング期間。
 伝搬遅延400usecって気温で摂氏115度くらいあるけど。実際は460usec程度か。これなら摂氏20度くらいと現実的。まぁココはイメージ図ということで。

 この図により、伝搬遅延が400usecならサンプリング期間の一番最初のサンプルは送信開始から600usec、ということになる。
 実際は460usecとすると、540usec後の位相が得られるはず。
 つまり、サンプリングした位相から540usec前ですべての周波数の位相がゼロになるはず。

 ただ、実際にサンプリングした位相を重ねてみると、250usec前あたりでゼロになる(というのは、上の方の図の通り)。

 計算した位相が間違ってるのか、とも思ったけど、ADCの波形を見て人間が角度に変換する限りでは、計算値と大きくずれているということはない。
 あとはどんな要因があるかなぁ。例えば、グラフに波形を書いたときにSINとCOSを間違えていた場合。この場合、ズレはせいぜい6usec程度だから、今のところは全く問題ない。送信パルスの位相が180度ずれていても、同様に12usec程度の誤差にしかならないから、今の数百usecのズレからすれば誤差の範囲。
 考えられるとすると、ADCの遅延が1msecに設定できてない、とか? でもプリスケーラ値をミスってたら整数倍(2倍とか)のズレになるから、1msecを間違うと500usecか2msecになるわけで、今回の300usecくらいのズレにはならないはずなんだよなぁ。
 もしかしたら、低レベル部分のサンプリング前の設定で変なバグが有るか? でも168MHzのコアで300usecを使うには5万クロックくらいかかるから、そんなに長い処理に心当たりはない。
 位相を複数回計測しても同じような値になるから、少なくとも遅延量がランダムに変化している、ということはない。ということは、遅延タイマの設定は問題ないはず。そもそもこいつがバグってたら風速の計測とかも動くわけないし。

 うーむ、謎い。
 今回、受信素子とADCが直結していて、ADCの入力インピーダンスに比べて素子の出力インピーダンスは高いはずだから、ADCが動いているときは波形の振幅が変化するはず。ということは、パルスを出し始めてからADCが正しく1msec後に開始しているか、というのは、オシロで見ればわかるはず。
 とりあえず、そのあたりは明日やろう。
 それでも原因がわからないなら、初期化周りは一旦放置して、別の部分(リファクタリングとかUI作成とか)を先にやろうっと。


追記:2018/12/13

 オシロで見てみた。


 ch1が送信パルス、ch2が受信波形。ch1はDC、ch2はACで結合。
 受信波形のノイズが凄まじいけど、ch1からのノイズだと思う。なんとなくこのオシロはch間のアイソレートが悪い。まぁ、プロービングもひどいし、安物だし。

 思ったほどch2が落ちてない。が、心の目で見れば1msecあたりで若干下がってる気がするので、ADCサンプリング開始タイミングは問題なさそうな気がする。
 伝搬遅れも500usec程度なので、おおよそ予想通りという感じ。
 ADC遅延を500usec程度にすれば波形の立ち上がりが見えるかな。

 あと、上で「サンプリング期間は1msec」と書いたが、これは誤りだった。実際にはサンプリングレートは1.2727273Mspsから1.3333333Mspsで1024サンプルなので、768usecから805usec程度の幅になる。

 そもそも全く考え違いしてる気がしてきたなぁ。


追記
 計測値を8個平均しても似たような位置に解が出る。
 そもそも位相値をてきとーに設定した場合は解が出ないから、少なくとも間違った値を見ているわけではないんだろう。
 そもそも位相位置の絶対量がわかればいいんだから、今のままでも問題ない気もする。けどやはり気持ち悪い。

 あと、温度センサが完全にお亡くなりになった。
 あたらしいセンサが届くまで持たなかったかぁ。
 どーしようか。サーミスタとか1wireの温度センサは手持ちにあるが、どちらも精度は良くないし、新しい回路を増やしてソースコードもいろいろ書かなきゃいけない。ちょっと面倒。どうしたもんか。

 とりあえず絶対量の推定は中断して、別のところをやろうかなぁ。

2018年12月11日火曜日

超音波風向風速計


 Excel上でだが、やっとマトモに計測できるようになった。
 右下の青が風向、赤が垂直風速、緑が水平風速。10サンプル(1秒間)の平均なのでそれなりに滑らかな波形。

 風はシロッコファンに大量のストローを突き刺してブロアーっぽくして使った。
 まず南側から風を送り、それを西からに移動。また南に戻り、天頂方向に移動、そこから西に下ろし、南に戻る、という感じの波形。
 南風が方位角0で西風が方位角90度、吹き下ろしの風が垂直成分で負方向、という感じだが、ちゃんとそのとおりに波形が動いている(ように見える)。

 左上のあまり動いていない線はFFTのpowerをdBで表示している。-11dBから-15dBのあたり。chによって感度が違うが、ある程度の風が吹いていてもch内ではそれほど感度の変化は見られない。多少ノイズが増えてる感はあるけど。
 -12dBだと0.2Vppくらいになる。3.3Vに比べてかなり低いけど、一応問題なく計測は出来てる。-15dBだと0.1Vppくらいしかないけど。
 今は受信素子をADCに直結しているが、前段にオペアンプを入れて12倍くらいしてやれば十分な振れ幅になる。ただ、オペアンプで位相遅れが出るし、それがどれくらいの誤差になるかは不明。
 今は送信素子も受信素子もマイコンのGPIOに直結だから、外部のエラー要因はほぼ無い。もっとも、受信素子にはAC結合とオフセットのためのCRが入ってるが。


 とりあえず、今はターミナルソフトからExcelにコピペしたデータだけを解析しているので、次はこの処理をオンボードで行うのが目標。
 それほど高負荷な処理ではないから、問題ないと思う。


 現在は起動時にキャリブレーションを行っているが、最近温度センサがどんどん調子悪くなっていっているので、いつまで持つか。
 一応、以前に30秒位かけて取ったキャリブレ値があるのだが、その時の気温は記録していなかった。気温が変わってもキャリブレ値は有効だが、気温が大きく変化するとサイクルスリップしてしまう(キャリブレーションというか、位相追尾の処理の問題だが)。


追記

 オンボードで計算してみた。今回は水平方向の移動だけ。
 とはいえ、オンボードで計算しているのは水平速度(Hspd)、垂直速度(Vspd)、水平方位(dir raw)だけで、dir rawはノイズが多いのと、-180 - +180の範囲を取るので、Excelで正弦波・余弦波に分解した後に移動平均を取り、それをATAN2で角度に戻し、さらにリミットの修正を行ったのが、緑の線。

 水平成分は水平方位と水平速度の極座標で表しているが、データとしては直交座標のXYZで出したほうが扱いやすい気もする。ただ、人間が読むならやはり極座標のほうが直感的なんだよな。

 ノイズが多いのが問題なので、XYZを移動平均で平滑したあとに極座標に変換して表示したほうがいいかもしれない。
 CMSISライブラリにFIRもあるのだが、このライブラリは複数のサンプルをまとめて処理するのが得意で、1サンプルごとに入れるというのには向いていない。まぁ、やってできなくはないだろうけど。

2018年12月9日日曜日

超音波風向風速計

 追記も伸びすぎたので新規エントリ。


 10Hzで計測し、起動後の5秒(50サンプル)の平均をオフセットしたのが上の図。
 計測部を上下に動かして、上下方向の風速をシミュレートした。

 ch1risは打ち下ろし方向、ch1fallは打ち上げ方向を示す(risとfall逆だ。。。)

 下の図はris-fallのグラフ。
 上下方向の動きはrisとfallが逆になるから、差を求めると上下方向の成分が得られる。逆に、和を求めると左右方向の成分が得られる。

 また、下の図の紫のall aveは全chの平均を表す。
 本来、all aveは真っ直ぐな線になるはずなのだが、若干上下しているのが謎い。もしかしたら天井部と床付近の室温の変化が見えているのかも。
 人間の吐息の温度で有意に値が触れるくらいだから、天井と床での室温の違いも見えるのかもしれない。普通に温度センサを上下に動かすだけじゃ時定数が長くてわからないだろうが、超音波風向風速計の時定数は事実上ゼロだから、あとは分解能次第。

 位相が22.5度動くと、約1.5usecの差になる。15cm/441usecで340.136m/s、15cm/442.4usecで338.983m/sになる。340.136m/sだと14.5℃、338.983m/sだと12.6℃になる。いろいろ定数をてきとーに入れているが、まぁ当たらずとも遠からずな数値になってるはず。
 ということは、気温1°Kの差で位相10度程度の差として検出できるわけか。
 たかが1.5m程度の高さの差で2℃も変わるもんかな? 換気吹き込む古い住宅ならあり得るかも。


 とりあえず、風速とか気温の変化をちゃんと計測できているようなので、あとは生データから欲しい情報(風速ベクトル、温度スカラ)に変換するモデルを作らなければ。
 恒温槽とか風洞があれば、いろいろパラメータを変えて「こういうモデルにすると現実に即した値になる」って調整ができるんだが、どうやろうかねぇ。

 とりあえず6chの生データ(サイクル追尾をしたあとの位相情報)はCOMポート経由で取り出せるから、その後のデータ変換はPCで処理したほうがやりやすいかもしれないな。プログラムサイズも大きくなってきて書き込みに時間がかかるようになってきたし、PCソフトなら直接グラフとか表示できるし。


追記:2018/12/10

 部屋のドアを開けてサーキュレーターで換気してみた。思ったほど下がらない。
 横軸は秒、縦軸はtempが℃、ch1-ch6がusec。usecは位相(rev)を周期(41.015625kHz)で割った値。 途中でノイズが多い区間は、おそらくサーキュレーターの気流が影響してるんだと思う。
 ガッツリΔtemp稼いでΔtimeを比較すれば、素子間の相対的な距離の差が得られるはず。ただ、数度変化させたくらいじゃねぇ。逆に言えば、数度の変化程度ならそのあたりは無視できるってことか。結局、各変数はてきとーに決め打ちしてやるしかないかな。

 あと、温度センサ(ADT7420)の信頼性がちょっと悪い。時々ACKが帰らなくなる。基板を触ると治るんで、パターンが切れてるかな? 0.1mmのリジット基板なので、かなり嫌な感じ。遊びで使う程度なら、裏にスルーホールのユニ基板入れて補強してやったほうが良さそう。いまさら遅いんで、次買うときにでも。


追記

 キャリブレーションモードで5秒間の50サンプルの平均を求め、その際の気温からオフセット量を計算するようにした。距離を15.8cmとして計算しているが、15cmがセンサ表面の距離、4mmが表面から圧電素子までの距離。
 そのグラフが左上で、縦軸はマイクロ秒。
 左下のグラフは距離を時間で割ったもの。計測した音速に相当する。
 右のグラフは音速から温度を求めたもの。

 ch1とch4がちょっと高めに出てるのが気になる。ch1とch4はA組、ch2とch5はB組、という組み合わせなので、A組が大きく振れてる、ということになる。息の速度成分なら、ch1は上がってch4は下がる、みたいな差動成分が出てくるはず。腑に落ちない。センサ感距離がA組だけ大きく違うのかな? 一晩じっくりΔtを取ってみたらわかるかな。


 風速を求めるには、chXはコモン+ディファレンシャル、chYはコモンーディファレンシャル、が計測されるので、まずコモンとディファレンシャルに分離する。
 3組のコモンの平均から温度を求めると、それが媒質の温度になる。
 ディファレンシャルを垂直からの角度で補正して平均を取ると、風速の上下成分が得られる。
 ディファレンシャルを垂直からの角度で補正し、さらに水平方向を補正すると、風速の水平成分が得られる。これはxy平面のベクトルだから、方位もわかる。もちろん、垂直成分のzを加えて3次元の風速ベクトルにもできる。


 超音波風向風速計の生データはドリフトがなくていいねぇ。ジャイロセンサじゃこうはいかない。もっとも、強烈に温度ドリフトが乗ってる、とも言えるけど。

 一旦キャリブレ値を決定してしまえば、しばらくはドリフトしないはず。おそらくシステムをリセットしてもこの値は有効なはずだから、STM32のバックアップメモリに突っ込んでおけば、いちいちキャリブレモードに入らなくてもいい。


 息で温度差を作るには、雰囲気の温度を下げておく必要がある。ただ、普段はヌクヌクした部屋でヌルく生きてる人間だから、20℃を下回るとだいぶ寒い。耐えられないほどじゃないけど、指が思うように動かなくなる。プログラミングとかしてると結構致命的。
 体は厚着すればどうにでもなるけど、指はどうにもならない。まさか防寒手袋してキーボード打つわけにも行かないし。


追記
 キャリブレをRAM/ROMに保存すると、キャリブレ時と大きく温度が違うところで開始した際に、サイクルスリップが発生してしまうという欠点がある。
 位相の絶対値がわからないのは、1つの周波数の位相だけを見ているのが原因だと思う。いくつかの周波数の位相を使えば、計算で位相の絶対位置を決定できる気がする。
 風速の計測とかの計算が落ち着いたら、絶対位置の決定も試してみよう。


追記
 ADT7420を注文した。ついでにTSYS01というセンサも注文してみた。
 ADTは1200円でσ3が0.15℃、TSYSは980円でmini/maxが0.1℃。TSYSのほうが高精度っぽいし、安価。そしてTSYSは分厚いリジット基板なので、パターン割れの影響も少ないはず。
 ただし、ストリナのサムセンスとかいう規格らしくて、固定穴が邪魔くさい。穴1個しかないから角度を固定できないし、M2だからそのへんに転がってるM3を使うこともできないし。最近の米粒みたいなセンサはほとんどがサムセンスになってる気がする。せっかくの小型センサが活かしきれない。企業の試作品に使うのが目的ならこういうのでもいいんだろうが、小さい所に押し込みたいような個人ユーザーにはつらいな。

 TSYSはSPI/I2Cが切り替えられるらしい。
 ストリナの3軸センサとかも切替式だけど、それはCSがHならI2C、LならSPI、みたいなややこしい動作モードになってる。ネゲートされたSPIはどうなるんじゃ!という感じ。
 TSYSのほうはProtocol Selectというピンがあって、これがLならSPI、HならI2Cで、Chip Selectは別にある。

 また、ADTはレジスタを128で割れば℃で直読みができるが、TSYSは4次関数で校正する必要があるらしい。センサ個体の補正値がセンサごとに焼かれてるんだそうだ。国土地理院の地磁気の近似式みたいな感じ。

 ま、とりあえず、今週中には届くだろうから、届き次第動作確認。駄目なら新しいADTを使おう。

 ADTがACKを返さなくなったあとに読めた温度は、小数点以下2桁表示で0.06度の分解能になってる。16bitモードは分解能0.0078125度、13bitモードは分解能0.0625度なので、明らかに13bitモードになってる。リセット値が13bitだから、電源パターンが割れてるんだろうな。

2018年12月8日土曜日

超音波風向風速計


 順次6chを計測してFFT解析、40kHzの位相を計測、というのが動くようになりました。
 山が6個ありますが、前2個は軽く息を吹き、後ろ4個は2個ずつ、上と横から吹いています。
 ch1/ch5が暴れているのはサイクルスリップの問題で、位相を追跡して整数波数を追うようにすれば問題ありません。

 前半で軽く息を吹くと、伝搬物質の温度が室温から体温に変化するため、音速が上がり、位相が進みます。
 息を吐くのをやめると少し遅れながら温度が下がりますが、これは息を吹くときは息の勢いで一気に換気され、吹くのをやめると慣性や対流によって比較的ゆっくりと換気されるためと思われます。

 息を強く吹いたときの山はいまいち実際の状況と相関が取れません。
 そもそも強く息を吹いたところでその息がどの方向に向かっているかなんて、意外とわからないもので、ちゃんと超音波風向風速計の焦点で風速が変わっているかは確認していません。

 一番確実に風速を作るのは、まぁ風洞に入れれば確実なんですが、それ以外では、超音波風向風速計自体を手で持って動かすのが、今まで試した中では確実だと思います。
 ただ、周辺回路をぶら下げたまま動かすのは精神衛生上よろしくないですし、USBケーブルとかがあるので、無闇矢鱈と動かすわけにも行きません。
 やっぱり風洞ほしいなぁ、って話になります。

 あと、超音波素子の距離を正確に測るには、おそらく温度を変えた際の位相変化を見るのが確実です。
 温度から素子間の距離を推定し、既知の風速からの割合で素子の姿勢を推定する、という流れになるはずです。もっとも、姿勢は垂直から45度寝せて120度間隔、という設計を行い、その形を作るために3Dプリンタでジョイントを作りましたから、設計から大きな誤差はないはずです。
 素子の間隔は設計でキッチリ作ってはいません。これは、素子の表面がメッシュで保護され、圧電素子はその奥にあるため、解体しない限り正確な距離がわからないためで、またフレームを少し押せば1mm程度は動いてしまうことが予想されるため、あとから距離を推定する、という前提にしたためです。


 とりあえず、この時期の北海道の古い家なら夜寝ている間に大きなΔtempが得られますから、寝ている間の位相をログって、明日解析してみることにします。
 ADT7420も実装済みなので、温度変化と位相変化を比べてみるのもアリですね。


追記:2018/12/09
 一晩ログってみた。

 開始から10000秒あたりで一回ストーブをつけてる。超音波は時定数がほぼゼロなので、すぐに変動しているが、温度センサは時定数が大きいためなかなか温度が上がりきらない。でも下がるのは結構追従性がいい気がする。

 そのあとはゆっくり室温が下がっているが、35000秒以降は上昇傾向。太陽が出て部屋が暖められてるのかな?

 その後、43000秒あたりでストーブをつけて、46000秒あたりで設定温度を上げている。

 5000秒あたりの温度センサのヒゲは、人間が近づいたことによる黒体放射の影響だと思う。温度センサすっげーずれてんぞ!と思ってアルミテープを上に載せたので、遠赤が遮断されてその後は安定している感じ。

 ストーブで温度をコントロールしているあたりは温度変化が大きいので、あまり参考にならない。
 また、温度センサは降下は早いが上昇は遅い傾向がある気がする。机の熱容量とかの関係かも。窓際に机があるので、机自体は寒気で冷やされるので、温めづらく冷やしやすい。

 温度センサは時定数が長いので安定している、というのを差し引いても、位相のノイズが大きい気がする。10度くらいの範囲だろうか?
 超音波は41.015625kHzで出しているので、約24.4usecの長さ。10度だと0.67usecくらいの誤差。±0.35usecくらいの範囲か。素子間隔15cmだとおよそ±0.25m/sの誤差になるかな。10Hzでサンプリングできるなら、5サンプルの平均移動とかで平滑すれば十分問題のない範囲になりそうな気もする。

 しかし、Δtemp7ケルビンくらいじゃ位相90度も動かないんだなぁ。360度以上動かすとなると、Δtempは40ケルビンくらい必要かも。
 -15℃から+30℃くらいを作れる恒温槽が必要、ってことか。冬の北海道なら窓開けて-5℃、暖房ガン焚きして+25℃、くらいは作れそうだが、低温側は人間が耐えられない。部屋においてあるケミカル類も気温一桁になると廃棄しなきゃだし。
 ペルチェ素子買い込んで恒温槽作るしかないかなぁ。消費電力すさまじいだろうなぁ。

 とりあえず、素子間隔は15cm+1cm程度、と仮定した上で風速に変換できるような処理を作ってみて、校正はそれが動くようになってから、だな。


追記

 ADCとFFTの波形。ADCは横軸がマイクロ秒、FFTは横軸がkHz。
 ADCは、素子から14bitのADCに直結して2048のオフセット後の値。振幅はかなり小さい。0.2Vppくらいかな?
 FFTは、FFT分解能の整数倍の周波数なので、きれいなピークが出ている。微妙に2倍高調波が出てる感じがあるが、まぁ無視できるレベル。

超音波の周波数

 超音波風向風速計に使っているのはSTM32F405RGTだが、超音波パルスやADCサンプリングレートは、コアクロックの整数分の1にしか設定できない(実際には、コアクロックが2分の1に分周され、それを更に整数分の1に分周する)。
 変態的なチップだと固定小数点のPLLが入ってて整数比倍に増幅できたりするらしいのだが。


 で、できれば超音波パルスとFFTステップを近くしたい。
 どれくらいの値にするか?

 試しにC#でそれっぽい範囲を総当たりしたところ、超音波が39.77272...kHzで、ADCが1.2727...Mspsと0.8484...Mspsの2通りが一番エラーが少ないらしい。
 FFTが1024ポイントの場合、前者は約1242.89Hz、後者が約828.598Hzで、それぞれ32倍、48倍すると39.77272...kHzになり、エラーがゼロとなる。
 超音波は230Hzほど低いところに出ていて、経験則的に今使ってる超音波素子は40kHzより少し高めの部分が一番ゲインが高いわけだが、まぁ誤差の範囲だろう。

 他に、超音波40.385kHz、ADC1.2923MspsでFFTエラーがゼロ、という設定もある。
 ただ、こちらはADC周波数が若干高めになる。

 もっとも、ADC周波数が高い分にはADC計測時間が短くて済むから、ADCがその速度でサンプリングできるなら、あえて遅くする必要はないのだが。

***

 相関を行わないなら、実部のみのFFTで済む。やったー、メモリ4分の1で良いぞ~!と思ったのに、RFFTは入力と出力で違う配列を与えてやらなきゃいけないので、結局CFFTと同じメモリが必要になる。
 もっとも、基準波形を保存しないでいい分、メモリ消費量は2分の1にできるが。

***

 波形の安定待ちに約1msec、ADCサンプリングで約1msec、FFTの処理で約0.5msec、他に細々な処理を加えても、1chあたり4msec程度で計測できそうだ。6ch計測すると25msec程度かな。休みなく回せば40Hzで計測できる。
 実際には他の処理もいろいろあるが、それでも10Hz程度は取れそう。自然風なら10Hzで取れれば十分だろう。

 取らぬ狸の皮算用とならぬよう…

2018年12月7日金曜日

超音波風向風速計



 上が相関結果の全体、下が一部の拡大。

 Fc40kHz、ΔF4kHz、PW2.5msec、PCR10、の設定。
 まぁ多少は特性が落ちてるけど、こんなもんだろ、という程度にはパルス圧縮できてる。


 青が入力波形、赤がパルス圧縮後の波形。
 入力ののペーっとした感じからすれば、きっちり山が出てる。山の前後が下がりきらないのはおそらくサイドローブの影響。相関を取れる期間が狭いのでサイドローブがしっかり見えないが。
 入力波形の前半の振幅が低いのは、素子の立ち上がりが遅いからなのか、あるいは素子の中心周波数が高めにシフトしてるのか。


 素子間が15cmなので、340m/sとすれば0.44ms程度の位置にピークが出るはず。
 しかし、実際は0.75msあたりにピークが出ている。
 音速が200m/s程度なら15cmで0.75msになるが、200m/sというと-175℃あたりになる。そんなに寒いわけはない。

 超音波素子の応答性の悪さがチャープ信号を遅らせてるのかもしれない。
 単一方向のリニアチャープだから、信号が遅れてもそれを検出できない。折返し型のチャープ信号であれば、素子の特性の悪さはドップラーシフト成分として検出できるはずなんだが。ドップラーシフトを検出するのはかなり面倒なのでソフト実装じゃやりたくないけど。
 たぶんFPGAを使ったレーダーとかならRAMに中心周波数をずらした基準信号を複数持って、並列して比較、みたいなことができるはず。


 目に見えてch2の信号が小さい。これは前にも出ていた症状。たぶん素子が不良なんだと思う。
 ch2とch4だけ位相が逆転してるのは、配線の極性の問題だと思う。素子には極性が書かれていないから、はんだ付けしている時点では極性はランダムになる。極性は2分の1の確率になるから、6ch作って4個が同じ極性というのは、当たらずとも遠からず、という感じ。


 とりあえず、相関結果から位相を検出して、包絡線検波からサイクルを推定して、それを6ch自動で処理して、という処理を書く必要がある。 
 おそらく包絡線検波でも±2程度の誤差になるはず。それでも、前の「全くわからない」よりはマシなんだが。
 1chあたり推定値が5個だと、全体で15625通りの結果が得られる。その中から正しそうな結果を選択しなきゃいけない。そのアルゴリズムも面倒だなぁ。


追記
 パルス圧縮を使うより、連続波をFFT解析して複素数からatan2を通して位相にしたほうが高精度に位相を得られそうな気がする。パルス圧縮でも結局位相を追跡してサイクルを求めなきゃいけないので。
 その場合、コアが84MHzだと82分周して1024.3902kSPSでADCを駆動し、40.015kHzの正弦波を出せば、160chのところにピークが出る。

超音波風向風速計

 歯車にも飽きてきたので、気分転換に超音波風向風速計のプログラムを作り直してる。

 今回は、試しにパルス圧縮を仕込んでみることにした。

 とりあえず、送信パルスをADCに直結してみた。ADCのサンプリング開始から1msecほど遅れてパルスを送出してる。


 サイドローブが結構出てるが、そもそもメインローブがデカイ。今回はADC直結だけど、超音波素子通したらもっと特性悪化するんだろうなぁ。

 横軸が時間[msec]だが、ちゃんと1msec遅延したところにピークがある。

 CMSIS LibのFFTライブラリを相関に使っているが、これは4096ポイントまでしかFFTに通せない。ということで、サンプリングレートが結構カツカツな気がする。サンプリングレートを上げないと位相精度が得られないが、サンプリングレートを上げるとパルス幅を短くしなきゃいけない。手持ちの超音波素子はダンパーが強烈なので、かなり長いパルスを入れてやらないと波形が出てこない。

 ムラタの車載用素子だとテスト回路の仕様が8パルスなので、かなり応答性がいいんだろう。もっとも、58.5±1.5kHzで15パルスとすると、パルス圧縮比0.77あたりになってしまうので、パルス圧縮には使えないだろうけど。


 パルスの送信はGPIOから行い、TIM8のCC1のDMAでGPIOx->BSRRを書き換えている。またTIM8のUPDATEのDMAでTIM8のARRを書き換えることにより、リニアチャープ信号を作っている。
 ARRの配列をうまく処理すればノンリニアチャープも送信できるけど、面倒だし、ノンリニアチャープのパラメータが理解できてないので。


 とりあえず、もう少しリファクタリングして、実際に素子を接続してみて、か。
 素子を通してもちゃんと相関できるかな?

 1回送信するのに今の所10msecくらいかかってるし、信号処理でも10msecくらいかかるので、少なくとも1chのサンプリングに20msec程度かかる計算。
 1組6chなので1組を計測するのに150msecくらいかかる。ちょっと時間かかり過ぎじゃないかなーって気がするな。

2018年12月5日水曜日

3回目のFalconのヤツ?

 打ち上げ前はいくつかのニュースサイトで話題になってたのに、打ち上げ後は特に書かれてないかわいそうなヤツ。


 JS Orbit

 最近の打ち上げで逆行軌道だとコイツかな? 18099で10個。少ない気がする。TDBでいくつか逆行してるのがあるので、今後増えそう(ただ、この10個と比べて遠い場所にいるので、同じ打ち上げかは微妙)。


 今回打ち上げに使われた1段目はFalcon 9 booster B1046というモノで、それの3回目の打ち上げなのでB1046.3という名称になるらしい。

 Falcon 9 booster B1046 - Wikipedia

 ロケット1機1機のwikipediaページが作られるなんてなぁ。もっとも、中の人は「機体ごとに作られるようじゃだめだ」くらいに思ってるのかもしれないけど。ボーイングにしろエアバスにしろ機種ごとのページはあるけど、それぞれの機体のページとかは特にないだろうから。


 天体写真撮ってる人にブーブー言われてる風船衛星があるらしくて、ちょっと観測してみたい気もありつつ、この時期の北海道はずっと曇りだし、外寒いし。
 おそらく直径20cm程度、長さ数m程度だと思うので、すごく明るい!という程にはならないんじゃないかなぁ。


 宇宙空間でインフレータブルな構造ってのは、圧が抜けない限りは有望な気がする。ウレタンフォームみたいな発泡樹脂を流し込んでやれば硬化するので、硬化するまで持てば、それ以降は紫外線で劣化してリークしたって問題ないわけだし。もっとも、内部樹脂が劣化しない程度には紫外線を反射(or吸収)してくれる素材じゃないとまずいだろうけど。
 フレキシブルなソーラーセルとかも研究されてるし、カーボンファイバーみたいな引張強度の高い素材で形を作ってやれば、それなりに大きな構造物+発電能力あり、みたいな物が作れるかも。カーボンファイバーに形状記憶合金みたいなのを組み合わせて長さを5%程度可変できるようにしておいて、発泡樹脂の硬化時間を48時間くらいにしておけば、地上とか他の衛星からコヒーレント光を出して、それを受信して鏡面形状を修正しながら硬化させて、みたいなこともできるかもしれない。打ち上げるのは表面だけだから、硬化樹脂の発泡率に応じていくらでもデカい構造物が作れる。直径100mくらいの反射鏡とか打ち上げれるかもよ。

2018年11月30日金曜日

インボリュート歯車

 自作ドローソフトは、基準となる歯車からの角度を指定すれば、その場所に配置し、上位の歯車の角度に応じて回転する、という動作も組み込んだ。
 一番最初の駆動ギアの角度を秒/60で指定すれば、1分で1回転し、下位のギアは減速比に応じた角度に回転する。
 ギアの位置と角度で矢印を表示する機能を作れば、機械式時計のアニメーションを表示できる。


 と、回転させていて気がついたのだが


 ギアのかみ合わせが良くない。大きい歯数のギアが小さい方の根本に食い込んでしまっている。
 基礎円の下の処理が良くないのかと思いつつも、基礎円より先端側にも食い込んでいるような気がする。

 この画像はz8:80だが、z8:20程度(z42未満)の組み合わせでも発生する。

 そもそもギアの形が良くないようだ。
 小さい方の歯数が12以下になると良くない感じ。13以上だとあまり気にならない。


 あと、ドローソフトを10fpsくらいで書き換えるモードにすると、メモリが足りなくなって落ちるんだよなぁ。どっかでリークしてるんだが、どこでリークしてるのか見当もつかない。
 たぶん最近作った機能じゃなくて、前に作った機能のリークがここに来て表面化してきた、ということだと思うんだが。


追記
 干渉する現象は切り下げ(アンダーカット)というモノらしい。z = 2 / sin(α)^2から切り下げが発生し、α20度なら歯数17.1以下で発生するようだ。
 12と13の部分は関係なく、大きく拡大して細かく見れば16でも干渉していた。
 切り下げから逃げるにはどうすればいいんだろうか?
 圧力角を30度にすればz8でも切り下げは発生しなくなる。あんまり歯車っぽい形じゃなくなるけど。
 アンダーカットの形が計算できればいいんだが、どうやるんだろうか。

2018年11月29日木曜日

インボリュート歯車


 歯数が42以上になると基礎円が歯底園を下回り、それに対応しないと不適切な形状になる。
 インボリュート曲線のrがdfを超えるθから開始すればいい。
 前に作って結局不要で消した、途中のθから開始する処理を復活させるだけで適切に表示できるようになった。


 歯車を1個1個場所を計算したりしてスクリプトにするのはかなり面倒。
 ギアAとギアBのzやmを指定して、ギアBはギアAから90度の位置に配置して、みたいな指示をすれば位置を計算してくれるような機能があれば楽ができる。

 1秒に1回位強制的に書き換えて、その際にシステム時間を取り込んでギアの角度を指定して、それを減速比に応じて他のギアに伝えていって、みたいな機能があれば、機械式時計の表示ができるようになるな。

2018年11月27日火曜日

インボリュート歯車



 ようやくそれらしい形になってきた。
 かみ合わせも悪くなさそうだ。


 結局、インボリュート曲線は基礎円の高さから開始するという、世間一般で言われているとおりだった。

 キッチリ作ってしまうとバックラッシュがないので、そのあたりをどうにかする必要がある。軸をずらすのが楽だが、そうすると1箇所変更すると他にも影響してしまう。
 転位係数をいじれば見かけ上の大きさを変えられるから、これで変更すれば歯車の組み合わせのうち、特定の組のバックラッシュだけを調整できるはず。

 歯底はもう少し太くても良さそうだな。

 今は歯底円は単純に円を書いているが、これをしっかり分割してやれば、いよいよ歯車としての形になる。

 あとはこのクラスをLuaスクリプトから実行できるように工夫してやれば、スクリプトベースのドローソフトで歯車を書けるようになる。
 さて、もうあと数歩…… 歩幅が1km位あるなら。

インボリュート歯車



 インボリュート曲線の径からθを求める方法がわかったので、基準円と歯先円を10分割してインボリュート曲線を書いてみた。いい感じ。
 ソースコードもすっげー簡単になった。数学すっげーー。


 上の図は全体像、下の図は歯の拡大で、全体像の円は、内側から歯底円、基礎円、基準円、歯先円、となる。拡大では歯底円は見えていない。

 たぶん、基準円のθがψになるはずなので、このあたりももう少しいい感じに処理できそう。
 強度が必要ないなら歯の根元はある程度自由に処理できるから、当面は基準円の内側を中心点に向ける方向で。


 そういえば、今は歯底円も歯先円も、DrawEllipseで書いてるけど、このあたりもちゃんと処理しないとなー。

 とにかく、いろいろ方向性は見えてきたので、もう少し……


「これでまた一歩、偉大なる野望に近づいた」というところか。野望、なんだろう。それも考えておかないと。
「プログラム作ってみたけど使う予定もないしこのあたりで開発一旦止めよう」で以降一切触らないは有る有るだからな。ちゃんと用途を決めておかないと。

2018年11月26日月曜日

インボリュート歯車


 前回の、かみ合わせが悪い問題の原因がわかった。
 歯厚の処理が悪かったようだ。

 歯厚はパラメータψ(psi)だが、前回参考にしたページには出ていないパラメータだった。たぶん、前回はテキトーにそれっぽい数値を入れてたんだろう。

 このページに有る。
 小原歯車工業(株):歯車技術資料 弦歯厚法

 小原歯車には足を向けて眠れないな(?)
 ちなみに、小原はコハラと読むようだ。

 歯厚を適切に処理すると、上の画像のように、きっちりと噛み合う。バックラッシ? 何それ美味しいの?
 インボリュート歯車は多少ピッチがずれていても大丈夫なようなので、そこにバックラッシを調整する余地があるのだろう。

 それと、基礎円の内側の処理が謎い。この図を見る感じ、基礎円ではなく、基準円の内側を削っておく必要がありそうだ。
 ということは、インボリュート曲線の始点は基礎円の高さ(=インボリュート曲線のtheta=0)ではなく、基準円まで上がったところが支点になる。なかなか難しそうだ。。。


 上の図のインボリュート曲線は、適当なピッチで計算して、中心点からの距離がda/2を超えたところで計算を打ち切るようにしている。なので、よく見ると歯先円より飛び出しているのが見えるはず。
 例えば、歯先円の内側のインボリュート点をp1、外側のインボリュート点をp2として、p1とp2のそれぞれの角度を計算(atan2)し、歯先円の半径でθ1、θ2のp3、p4を計算し、線p1-p2と線p3-p4の交点を求め、その交点を最後のインボリュート点として扱う、みたいな処理をすれば、きっちり歯先円でインボリュート曲線を止めることができる。まぁ読めば分かる通り、かなり面倒な処理になるのだが。
 そして、基準円の根本を削る必要があるなら、この処理を根本にもやる必要がある。

***

 前に作った、Luaで絵を書くプログラムを、新しく作り直してる。
 そして、C#のスクリプト機能も追加し、Luaでは扱いづらい処理をC#で書くことができる。
 例えば、Luaスクリプトで位置とモジュール、歯数を指定して関数を呼べば、C#側でその形を計算して画像やPDFとして書き出すことができる。
 一つの歯車のパラメータを複数箇所で使うことができれば、歯車を切り出すPDFデータと、それを組み合わせた外観図を作ることもできる。
 と、期待しているのだが。

追記:2018/11/27
 歯厚半角の計算に出てくるxが謎で、0.3をそのまま使ってたんだが、計算が合わん。なぜだッ! (坊やだからさ) と悩んでたんだが、xは転位係数らしい。これを0にしたらいい感じになった。

 各記号は以下のページに書いてある
 小原歯車工業(株):歯車技術資料 歯車記号と用語

 ググって出てきたページを読むだけだと、その前に重要な事が書いてあっても気が付かんからだめだなー。

 だいぶそれっぽい歯車になってきた。

2018年11月22日木曜日

ミサイルのカラーバンド

 "石川潤一の軍用機ウエポン事典"を読んでいたらカラーバンドのとかの話が書いてあった。
 昔ペーパークラフトで作ろうとして「写真によって色が違うけどどーなってんじゃ!」と書いたやつ。

 P82に記載がある。

 これによると、FS595a/bという規格らしい。
 FSはFederal Standardの略で、「連邦標準」の意味らしい。アメリカ合衆国連邦政府(Federal government of the United States)が策定した標準規格、ってことなんだろう。

 ちなみに、FS595は2017年2月に廃止されて、SEA-AMS-STD-595に移行したらしい。

 SEAは"自動車技術者協会"の意味で、"Society of Automotive Engineers"の略らしい。
 AMSは"Aerospace Material Specifications"の略とのこと。

 SEAの日本語訳は国立国会図書館のページに書いてあるが、AMSの訳は書いてなかった。直訳すると"航空宇宙材料の仕様"となる(Google翻訳)。

 自動車技術者が航空宇宙もやってるのかぁ。。

 FS595からSEA-AMS-STD-595になったのは、RS-232がEIA-232になったのと同じようなもんだろう。


 廃止になったFS595だが、ドキュメントはダウンロードできる。
 ASSIST-QuickSearch Document Details

 内容はカラーチップの大きさとか、運用の注意事項とか。
 「カラーチップは定期的に交換しろ、直接触るな、化学薬品にさらすな、紫外線を当てるな。冷暗所に保管しろ。複製はするな」みたいなことが書いてあるっぽい。
 関白宣言かよ。

 ちなみに、カラーチップは製造から3年以内に交換し、メーカーによっては2年以内の交換を求めているところもある、らしい。めっちゃ厳しい。

 カラーチップは692個の個別のチップ(3x5in(=76.2x127mm))で約900USD単語帳みたいな形?で175USD、3x5inの単色で35USD、とのことらしい。1枚35USDが700枚で900USDは計算に合わないので、1枚じゃなくて何枚かのセットかも。あるいはまとめて買うとめっちゃ安いのか。


 で、ミサイルのカラーバンドの話に戻るわけだが、黄(弾頭)はFS33538、茶(推薬)はFS30118、青(イナート)はFS35109、とのこと。
 この型番のフォーマット見たことある!と思ったら、プラモデルの塗料だった。なるほど。プラモデルの塗料を売るときに米国の色標準の型番をそのまま商品名にしてるのか。

 Federal StandardのPDFのAppendix II/IVに各色の詳細が書いてあるが、標準光源A, C, F2, D65で書いてあって、他に60°glossとか色のグループ、色の名前、といったことも書いてある。
 60°glossというのは表面に対して垂直から60度(表面から30度起きたところ)から光を当て、反対側の60度のところで何%の光を受けれるか、という基準。前方散乱で、光沢の基準だと思う。

 色番号のうち、最初の桁は1が光沢(反射率80以上)、2が半光沢(30から45)、1が非光沢(6以下)、とのこと。
 また、2桁目は色のグループを示し、0から8まで順番に、0:茶、1:赤、2:橙、3:黄、4:緑、5:青、6:灰、7:その他(黒、白、金、銀、紫)、8:蛍光、とのこと。
 弾頭は33なので非光沢の黄、推薬は30で茶、イナートは35で青、という感じ。


 前述の通り、色は各標準光源のものが書いてある。
 標準光源Aはタングステンの白熱電灯、CはAにフィルタを通して、平均的な日光を再現、D65は昼間の日光、F系は分子のスペクトル? とのこと。
 たぶんAから順番に出てきた規格なんだろう。D65は6500Kの黒体放射に近い(近い、であって、同じ、ではない。規格が制定されたあとに物理定数の変更があって変わってしまったとのこと)。
 ちなみにAからFまでは順当に増えているが、次はLまで飛ぶ予定らしい。LED関係なんだそうだ。

File:Planckian-locus.png - Wikipedia

 図の中にA, C, E, D50, D55, D65のマーカーがあるが、これが各標準光源のホワイトポイントの位置。Aは白熱灯なので、黄色っぽいところにある。CやD65は日中の色を目安にしてるので、青白い感じ。D65って6000Kと7000Kの中間じゃないんかい!!


File:CIExy1931 AdobeRGB.png - Wikipedia

 D65色空間だけどゆるして! Cは見つからなかった。

 FS33538(弾頭のオレンジ)はX55.59%, Y50.09%, Z6.93%で、xyYに変換するとx0.49, y0.45,Y0.50あたりになる。上の図から拾うと、580nmの少し内側で、輝度が50%、となる。
 FS30118(推薬の茶)はX11.34, Y11.17, Z6.84で、x0.39, y0.38, Y0.11となり、ブラウンと言うよりは、かなり暗い黄色、という感じ。
 FS35109(イナートの青)はX9.86, Y11.38, Z21.29で、x0.23, y0.27, Y0.11となり、暗い水色、という感じ。
 もっとも、これはD65光源からのピックアップで、上記のXYZはC光源の値なので、多少の違いはあるだろうが。


 ということで、ミサイルのカラーバンドの色は「すっげーキッチリ決められてる」ということがわかった。想像以上に厳しい。
 でもこの値をRGBに変換して印刷したところで、その色が本当にFSで規定されてる色とは限らないからなぁ。完璧にその色がほしいならSAE-AMS-STD-595のカラーチップを買わなきゃいけないんだが、10万って無理ゲー。まぁ、雰囲気だけですから、大体でいいんです。。。


 このエントリに書くことを調べるだけでまた新しい知識を得られた。世の中知らないことばかりなり。ボーッと生きてるなぁ。


2018年11月21日水曜日

DTMF FFT

 ソフトDTMFデコーダを作ってる。
 時間軸と周波数軸を比較する予定。
 とりあえず時間軸では動くようになったので、周波数軸で計算してる。



 DTMFで1, 2, 3, A, 1, 7, *, 1, 5, 9, Dを送ったときのFFTの波形。
 横軸が時間(秒)、奥行き(俯瞰は縦軸)が周波数(Hz)、高さがpower。

 FFTに入れる前にオフセットしてやらないと強烈にDC成分が出る。そりゃそーだ。
 12bitADCで2048をオフセットしても若干DC成分が出てるけど、無視できるレベル。
 もっとも、DTMFのデコードではDC成分は見ないので、オフセットするだけ計算リソースの無駄な気もするが。

 8kSPS128ポイントだと微妙に分解能が悪いんだよなぁ。8kSPS256ポイントとかあればだいぶマシだけど、波形を集めるのに32msecかかるので、短いDTMF信号は取り逃すことになってしまう。

***

 メモリの使用量は、ADC周りで520バイト、時間軸で4104バイト、周波数軸で1048バイト、とのこと(それぞれのclassをsizeofして計測)。
 時間軸での計算には、FIRで強烈なBPFを作ってるので、そのバッファでメモリがガッツリ食われる。
 FFTは入力と出力にFFTポイント分の配列が必要だが、4byte*128point*2なので1024バイト+α程度で処理できる。

 感覚的には、時間軸で処理したほうが信頼性が高い気がするんだが、まだ比較してないので、なんとも言えない。

追記
 時間軸で処理した場合は3700usec、周波数軸で処理した場合は280usec、という感じ。どちらも64MHzのC-M4Fコア。
 そんなに差があるのかぁ。時間的リソースは消費電力に直結するので、低消費電力が重要な今回の用途には時間軸は無理っぽい。RAM消費リソースもすごいしね。
 もっとも、素直にFFTを使おうとするとアホのようにデカいROMテーブルを使うので、Flashが小さいチップだと厳しいけど。

 とりあえず、時間軸を使うヤツはお先真っ暗だけど、誤検出とかの比較はしておきたいな。
 無線電話に通すならホワイトノイズ耐性はほしいし。

追記2
 試しに時間軸と周波数軸の両方に入力信号を通して結果を表示してみた。
 明らかにFFT方式はホワイトノイズ耐性が低い。時間軸の方はほぼ全く誤検知しない。

 ただ、FFT方式はもう少し工夫の余地がありそうな気がする。例えばホワイトノイズなら全体的にスペクトルが出ているはずなので、全体の平均と、検出した信号のピークの比を判断に使う、といったことができるはず。ただあんまりやりすぎると弱い信号を取れなくなるんだよなー。

 それと、誤検出したとしてもランダムエラーが主で、バーストエラーはほぼ発生しない。発生したとしても同じコードではなく、いくつかのコードが出てくるはず。
 ということは、チャタリング対策みたいな感じで、例えば3回以上同じコードが出ていれば正しいDTMFコードとして扱う、みたいにすればいいはず。
 1区間は1sec/8000sps*128point = 16msecなので、3回なら48msecになる。大抵はこの期間以上は出るはず。DTMFの仕様としては最小50msec以上送信しなきゃいけないらしいので、48msecはギリギリで受けれる。タイミングによっては無理だけど、まぁ送信側で最低限100msec以上送る、みたいな運用にすれば問題ないはず。

 あと、計算時間の計測は、信頼性がちょっと怪しい。たぶん3700と280の比は問題ないはずだけど、絶対値(usec)として扱えるかは怪しいところ。
 オシロでビジーのパルス幅を見ると2.5msec/divより狭いので、3700usecはだいぶ長過ぎる。ちょうど2倍ずれてるかも。とすると1850usec対140usecか。それだと合わせて2msecくらいなので、2.5msec/divより狭い点の説明ができる。

2018年11月18日日曜日

インボリュート歯車

 インボリュート歯車を書くプログラムを作りたかったんだけど、いまいちわかりやすい説明が見当たらなかった。このあたりは基礎知識ってことなのかな。


 内側の緑が歯底円、外側の白が基礎円、次の緑が基準円、一番外の緑が歯先円。
 インボリュート曲線は基礎円の直径で計算する。基礎演から歯底円までは任意の形状でいいらしい。任意と言っても、相手の歯が入り込める形状にする必要はあるが。
 とりあえず幅を基礎円の幅で落としているが、このピニオンギヤとか見ると見るからに根本が細いので、中心点に向かったほうがいいのかもしれない。

 数値の計算は以下のページがわかりやすい
 小原歯車工業(株):歯車技術資料 平歯車、ラックの寸法計算

 ただ、上の画像をドローソフトを使って、基準円で並べてみると、歯が噛み合わないんだよなぁ。

***

 ある人曰く、レーザーで歯車を切りたいなら、歯車屋からCADをダウンロードしてきて使えばいい、とのこと。データを自作するのにこだわりがないならそれが早そうだ。

 「歯車 製図」とかでググると、簡略化したモデルしか出てこない。確かに、機械を作るなら歯先直径と基準円直径だけあれば干渉とか位置決めはできるだろうし、いちいち全部の歯なんて書いてられないだろうし、「ここは歯数n、モジュールmのギヤを使ってね」という指示さえあれば歯の形は指定できるし。それにしてもなんだかなぁ。

 レーザーで歯車を切り出してなにか物を作るにしても、歯車をCADデータから切るなら、あとは軸受のプレートだけ自分でデータを作ればいいだけだし、そうするとそれこそ基準円と歯先円だけあれば十分だし、そっちの方で攻めるべきかなーとも思い始めてる。

 どっちが目的か、という問題。「ギヤのデータを作るのが目的で、ギヤで動くメカメカしいモノはギヤの動作確認の手段でしかない」なのか、「ギヤを使う機械を作ることが目的で、ギヤのデータを作るのは手段でしかない」なのか。
 うーん。どっちだろう。。。
 手元にレーザーカッターがあれば機械を作るのが目的足り得るけど、それができない以上、歯車のデータを作るのが目的になる。とか言い訳してみる。

2018年11月9日金曜日

STBee F4miniでPSP液晶

 気分転換に、PSP液晶で遊んでみました。

 型番はATM0430D5というモノで、HsyncやVsyncが不要なタイプです。こいつはディスコンになって現在は別のものが出てるみたいですね(未確認)。

 バックライトの点灯にはストリナのLEDドライバを使っています。5Vを突っ込めば最大38Vまで昇圧して0mAから20mAまで32段階(33段階?)で任意の電流を設定して定電流駆動できるスグレモノです。
 さすがに32ステップとかあっても人間の目には変化はわからないですし、そもそもリニアに変化させても、ということで、対数(2.2)で4段階に変化させてみました。





 いい感じに輝度変化がわかると思います。


 裏面はこんな感じです。
 ピンアサインは変換テーブルを使うので、ある程度自由に設定できます。もっとも、8bitバスをGPIOをまたいで設定すると面倒なので、RedをGPIOB[0-7]、GreenをGPIOB[8-16]、BlueをGPIOC[0-7]、というふうにしてあります。が、Red0がGPIOB0に、といった関係ではなく、配線しやすいようにバラバラになっています。

 STBee F4miniのメモリを持ってしても、480x272x3byteの保持は不可能で、8bppIndexでも不可能でした。ということで、横解像度を240pxに落としていますが、これでもかなりギリギリです。
 GPIOの変換テーブルはFlashに入れて256x3バイト、カラーパレットはRAMに入れて256x3バイト、画像データはRAMに入れて240x272バイト、他にピクセルバッファが525px x 24line x 2本 x 2バイト(16bit)あります。24ライン分を確保しているのは、可能な限り大きな範囲を一括して変換するためです。2本あるのはGPIOBとGPIOCの分です。


 ブロック図はこんな感じです。


 RAMからGPIOに対してDMAで転送する場合、DMA2を使用する必要があるので、駆動するTIMは1か8になります。今回は1を使いました。

 LEDドライバの輝度の指定にはパルス数を送りますが、タイミング要求が厳しく、遅くても100usec以内を目安にトグルを続ける必要があります。が、10パルスを送るなら2msecほどかかり、この間にDMAからの割り込みが発生するため、ソフトウェアでは転送できません。そのため、今回はパルスの生成にTIM2を使い、TIM2を特定のパルス数(&位相)で停止させるためにTIM3を使用しました。
 TIM2は0分周8400カウントで駆動し、1周期100usecのパルスを作ります。
 TIM3は2100分周0xFFFFカウントで駆動し、CH1に1を指定すればTIM2はLowを出すだけ、7を指定すれば1個目の立ち上がりエッジで確定、15を指定すれば2個目の立ち上がりエッジで確定、というふうに駆動できます。
 輝度の指定(0で消灯、1が一番暗く、32が一番明るい)から直接CH1のパルス長にすることはできないため、ここは変換テーブルを使いました。
 TIM2のスレーブモードはGatedを使用しています。
 ただ、TIM3を駆動する際にTIM2のプリスケーラやカウンタをリセットする必要があり、ここはソフトウェアで実装する必要があるので、タイミングクリティカルになります。なぜか今回は問題ありませんでしたが、TIM2に対するUpdateの生成からTIM3の開始まではクリティカルに指定したほうがいいかもしれません。

 DISPは基本的に触ることがないので、ソフトウェアで制御しています。

 DEはピクセルデータに同期する必要があるので、ピクセルデータと一緒にパラレルデータに埋め込んでいます。

 GPIOCはLSEの接続があり、STBee F4miniでは外に引き出されていません。そのため、GPIOCを16bitバスとして使うことはできません。そのため、GPIOBを16bitバスとして使用し、残りの8+1bitをGPIOCに割り当てています。

 ということで、ようやく液晶の制御と相成りました。

***

 とはいえ、今回は解像度を落とした静止画1枚を表示するのがやっとで、UARTから画像を受け取る、といった基本機能ですら動作しません。
 実用性は皆無です。

 ま、複数のGPIOで、16bitを超える幅のパラレルバスを駆動できるのがわかっただけ収穫、ということで。
 前にTIMでクロック出してGPIOからデータ出したときはうまく動かなかったんだよなー。なんで今回はうまく動いたんだろうか? クロック周波数が低かったから遅延の影響が少なかったのかな?

2018年11月4日日曜日

STM32F446RET


 買ってきた新品のNucleoを開封直後に動作確認もせずに割るやつはそうそう居ないと思いますが、とりあえずUSB DFUで動作確認できました。
 最初動かなくて焦りましたが。U5VじゃなくてE5Vに突っ込んでやらないとだめみたい。U5VはST-Link側のLDOにつながってるのかな? 確認してないですが、とりあえず動いてるので。。

 なんか変だなーと思ったら、USER SWが負論理でやんの。。。
 USER SWとBOOT0を直結しているので、単純なリセットではブートローダーが起動し、ユーザーコードを起動するにはUSER SWを押しながらリセットする必要があります。NOTインバータ挟んでもいいんだけど、それよりBOOT0用のスイッチを追加したほうが楽かなーって気がします。

 STM32F446RETは64pinLQFPなので、STBee F4miniのSTM32F405RETを引っ剥がして載せ替えたほうが楽かな、とも思います。今回はDCMIを試したくて446を買いました。
 STBee F4miniはPD2が出てないのでSDIOが使えませんが、446RETだとDCMIとSDIOが排他なので、SDIOが使えないのは関係ないですし。
 っていうかなんでカメラインターフェースとメモリーカードインターフェースが排他なんだよ。普通DCMIを使うならSDIOも使いたいだろ。と、思うわけですが。まぁSTM32F4でデジタルカメラを作ろうって人も少ないんでしょうね。それならなんでDCMIが乗ってるのか謎ですが。F4の性能だとガッツリ画像解析するには足りないだろうし、どういう用途を想定してるんだろうか。


 コードは以前書いたものと同じですし、STM32Cubeのアップデートも来ていませんが、CDCの接続に時間がかかってるような気がします。
 USBの接続がやっつけなのが原因かな? たかが12MHzでこの程度の配線延長はあんまり関係ない気もするんだけど。
 Nucleo64はHSEの水晶が実装されていないので、手持ちの16MHzと15pFをつけています。LSEは実装されてるのにHSEがないのが腑に落ちない。あとUSBコネクタくらい実装しといてくれやー!!って思います。
 mbedとして使えるならUSB deviceで遊んだりUSB hostで遊んだりいろいろできるはずなので、microUSBレセプタクルくらいあっても良さそうなのに。


 今回は妥協してNucleo F446REを使いましたが、これならSTBee F4miniのチップを載せ替えたほうが楽だと思います。
 Nucleoはピンが連番で出てないので、配線作業もかなり面倒ですし。
 この手間を考えたら、LQFP64pinを実装するほうが楽です。

***

 PICでやりたいことがとりあえず作れたので、そっちは一休みして、しばらくはSTMで遊ぶことになりそうです。
 他にもやりたいことあるんだけどなー。
 なかなか気力ゲージが回復しないので少しずつ。

追記
 Q. なんでPowerLEDが消えてるの?
 A. USBの5VをVDDに突っ込んでるからだよ!!

 まさかのやらかしです。。。

 それでちゃんとコア動いてUSBも接続できてるんだから末恐ろしい。
 あれれー?なんでLED消えてるのぉ~って調べなかったら全然気が付かなかったとおもいます。

 今日はなんかやらかしが多いです。5箇所作業したら2,3箇所はやらかしてるレベル。

 Absolute maximum rangesのVDD-VSS項はmax4.0Vが規定されています。5V突っ込んだら普通死んでますね。まぁ、AMRsは「これを超えると動作は保証しないよ」というものなので、即死ぬわけじゃないと思いますが、かといって無害なわけでもない。

 


 電源の修正のついでにリセットスイッチとユーザースイッチも追加しました。
 オンボードのスイッチはPC13(タンパ検出)ですが、白のタクトスイッチはBOOT0とPA0(Wake-up)に接続しています。リセットスイッチはどちらもリセットですね。
 このスイッチの配線だけでも相当やらかしてます。。。

 昨日やった細かい作業の疲れが残ってるのかな。。。
 年食ったなぁ。。。

2018年11月3日土曜日

PICの謎

 PIC10F222で遊んでる。
 3.3Vで動かしているのだが、気がついたらプログラムの書き込みができなくなっていた。
 5Vだと正常に書き込めるが、3.3Vではなにがしかのエラーが出る。

 最初の頃は3.3Vでも書き込めていた気がするんだが。
 ググってもそういう話は全く出てこない。
 海外フォーラムでそれらしい話し合いがあるけど、いいところで中断している。


 結局、今回はVDDをダイオード経由にして、MCLRは無接続で逃げることにした。
 こうすれば、書き込み時は外部から5Vをブチ込んで、MCLRは無接続なのでプルから外部に高電圧が抜けることもない。
 MCLR(リセットスイッチ)は使わないので、コンフィグでMCLRも無効化する。


 しかしまぁ最初の頃は書き込めていたはずで、なんとも釈然としない。
 PICのFlash? EEPROM? の書き込み耐数はかなりの回数だが、これは5Vの話で、電圧が低くなるほどシビアで、3.3Vあたりでの書き込み耐数は10回程度じゃないのか、という仮設を立ててみた。
 新品のPICでいろいろ試せばはっきりするだろうが、面倒なのでやらない。


 しかしまぁPICは手間がかかる。


 別のとこで書いているのだが、今回作っているもの、「昔のスパイ映画に出てくるようなアイテム」とでも言おうか。映画見てるときは「んなもん」と笑って流していたのだが、自分が作る番になるとそうも言ってられなくなる。
 近年の半導体製品の進化を考えると、昔のスパイ映画に出てきた電子機器はCOTSで作れそうな気配もある。

2018年10月30日火曜日

IM920c

 IM920cというモジュールを触ってみました。

 920MHz無線モジュール(コンパクトタイプ): 無線、高周波関連商品 秋月電子通商-電子部品・ネット通販
 IM920c用変換アダプタ: 無線、高周波関連商品 秋月電子通商-電子部品・ネット通販



 モジュール本体は表面実装の小さなコネクタで、そのままでは使いづらいので、変換基板で2.54mmに変換します。なお、コンパクト以外のモジュールの標準的なコネクタは1.27mm(ハーフピッチ)のピンソケットです(変換基板にもハーフピッチピンソケットが生えています)。

 モジュールは3.3V動作なので、USBで使う場合は自分でレギュレータを持っておく必要があります。XBeeの変換基板だと大抵はLDOを載せてますが、その場合は3.3Vを入れたいときにムカー!!ってなりながら引っ剥がすので、どっちもどっちですね。

 とりあえず今回はGND, 5V, TX, RXを結線しています。というかこの変換モジュールはそれしか出てないので。
 メーカーのドキュメントを見ると、BUSYをフロー制御に使え、みたいな事が書いてあります。ビジー中にコマンドを打つとNGが返りますが、フローに使えばハードウェアでディレイしてくれるので良さそうです。

 コマンド自体はクセも少なく素直なもんです。タイミングだけ気をつける必要がありますが、それもシビアではないので、人間が使う分には何も気にする必要はありません。
 19.2kボー/CRLFは注意する必要がありそうです。よくある9.6kボーとか115.2kボーではないです。また改行もCRが必要です。

 それから、通信を行う場合は、登録したIDから以外の送信は受信しないという動作です。なので、一番最初に使うときにはペアリングが必要です。「無線機器なんて送信すれば受信するだろ~」とか油断してるとハマります。subGHzなので特小トランシーバみたいな雰囲気ですが、モノとしてはXBeeに近いです。まぁそりゃそうだ。



 スペクトルはこんな感じです。
 下側の、帯域幅が広くて時間が短いほうが高速モード、上側の、帯域幅が狭くて時間が長いほうが長距離モードです。
 長距離モードは「スペクトラム拡散」と説明されてますが、高速モードのほうが帯域幅はかなり広いですね。
 当然、通信モードが違うデバイス間では通信はできません。

 長距離モードなら帯域幅が狭いので、SDR#からRAWで吐いてステレオミキサ経由で受け取ればソフトウェアデコーダが作れそうですね。どんな変調方式なんだろう。

***

 例の、「2.4GHz帯は使いたくない」用途でこのモジュールを使おうか、と思いっています。通信距離はせいぜい300m未満なので、おそらく足りるはずです。コレで駄目ならXBeeだって駄目だろうし(XBeeのほうが周波数が高いので、地上対地上ならフレネルゾーンが狭い分有利かもしれませんが)。

 どれくらいの速度が出るかわかりませんが、高速モードは50kbpsが出るそうなので、2kbyte/sec前後は通ると思います。それでも低画質なJPEG1枚送るのに5秒以上かかる計算ですが。。。

 スペースプローブ/缶サットでカメラで撮影してダウンリンクする、というミッションをやる場合は、QVGAでガッツリ画質落として、それでも10KB以上あるので、1枚しかダウンリンクできません。もちろん、ARLISSのような、高高度から放出したりするなら別ですが。
 1枚しかダウンリンクできないなら、確実に最初の1枚で写したいものを写す必要があります。そうすると、太陽センサのようなもので自分の姿勢を判断して、カメラが下を向いたタイミングで撮影する、という機能が必要になると思います。ちゃんと下を向くかは運任せなので辛いところですが、何も写ってない青空をダウンリンクするよりはマシなはずです。JPEGならソフト的に判断するのもありかもしれませんね。

 ま、今のところはミッションも何も決まってないので、どうなるかはわかりませんが。とりあえず通信モジュールくらいは使えるようにしておかないと何も作れないので、もうちょっと調べてみます。
 もっとも、自分でプローブを打ち上げると、プローブのほうが気になって、ダウンリンク画面なんて見てる余裕ないんだよなぁ。WinとかMacなら音声合成が簡単に使えるので、ダウンリンクを音声化できるような仕組みを作っておくといいかもね。