キューブサットの軌道

　久しぶりのヤツ。

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

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


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

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

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


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

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 閑話


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

かやのみ

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

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

***

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

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

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

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

件のレーダー

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

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

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で２ピン使うほうが良さそう。

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

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

ファルコンの

　しばらく見ない間にだいぶ増えてた。
　現在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はそれほど安いセンサというわけでもないしね。妥当な性能かもしれない。

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を捨てるのはなんかもったいない気がする。


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

超音波風向風速計

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

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

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

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


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

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

超音波風向風速計

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

　とりあえず、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の温度センサは手持ちにあるが、どちらも精度は良くないし、新しい回路を増やしてソースコードもいろいろ書かなきゃいけない。ちょっと面倒。どうしたもんか。

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

超音波風向風速計

　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サンプルごとに入れるというのには向いていない。まぁ、やってできなくはないだろうけど。

超音波風向風速計

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

　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だから、電源パターンが割れてるんだろうな。

超音波風向風速計

　順次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で取れれば十分だろう。

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

超音波風向風速計

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

　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くらいかかる。ちょっと時間かかり過ぎじゃないかなーって気がするな。

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くらいの反射鏡とか打ち上げれるかもよ。