いや、そうはならんやろ……
Renishawのタッチプローブはコンコルドで使われていたエンジンの生産性向上や品質保証に起源を持っておりますので。偶然ってこともないだろうから、そういうことも含めてのディレクションであろう。制作コストはかかるけど、ちゃんと自社製品や自社工場を生かしたコンテンツを作ってる会社は好き。
サンタさん、僕にもマザックのCNCを1台ください。日本でこういうお願いをするとプラモデルが届きそうだが。
CGはシンプルだけどなかなか手が込んでる。最後のスピンドルで文字を書くシーン、プローブをつけて紫外線で照らせば励起して光らせたりできないかな? プローブのルビーって光るような成分なんだろうか?
去年は通販サイトを立ち上げたのでそこで扱う商品をプレゼントしてあるきまわっていたような気がするが、今年はオートメーションに力を入れているので、シンプルな映像。工作機械メーカーって自社製品でオーナメントを作ったりする映像が多い気がするけど、Haasはソリューションやサービスに力を入れているような感じ。
最近はあちこちセキュリティも厳しいからね…… 来年は子供相手に侵入検知ソリューションあたりを売り込むんじゃないだろうか? マッチポンプ乙。FLIRの製品にはLeptonとかもあるからな。ちょっとお高めだけど、Raspberry Piと一緒にプレゼントに入れてけばまた来年はサンタに新しいシステムを売り込める。
***
99分のCD、もっと散々な結果になると思ったら、全く問題なさげじゃん。もっとゴリゴリ普及させればよかったのに。
***
信じられないけど、GoProってフィルムカメラのブランドだったんだよねぇ。
最近はいくつかのカメラメーカーがフィルムカメラの新製品を出しているし、GoProも出さないかな? コダックのフィルムを入れてさ。
***
何もしていないのにテレビが映らなくなった。今年1月にも似たような現象があった気がするけど、それ以来? 熱環境的な問題かな?
今回は地デジ、BS、CS、全滅。テレビの受信強度メータでは地デジは若干の数値が出ているが、BS/CSはゼロ。背面の同軸を抜けば地デジもゼロに落ちるけど、同軸線でちょっと受信しているのかな?
アンテナ等の設置は自分でやって、一部は5CケーブルにFコネクタを自分で圧着したものを使っている。このコネクタが、ナットを締めても接触不良になるような症状が出ている。屋外のミキサ兼ブースタに電源LEDがついているけど、コネクタ付近のケーブルを触るとLEDが点いたり消えたりする。VHFを通すくらいなら多少の接触不良は問題ないんだろうけど、DCを通さないといけないので、接触不良になると地デジ/BS/CS全部切れる。
ワンセグチューナーでOFDMスケルチ作れば地デジ放送の有無を検出できるから、電源断で信号止まってるかくらいは検出できると思うが、作るのメンドクセ。。。
温度変化の収縮とか微妙な変化で接触不良になったりするような感じっぽいけど、とりあえず大丈夫そうなので当面は様子見かなぁ。暖かくなったら同軸引き直そう。それまでにまた発症したら…… 極寒の屋外でケーブル剥くのはやりたくねぇなあ。
***
そういえば、もうすぐH3ロケットの打上げじゃね、ということで、久しぶりにペーパークラフトのデザイン。ブログ内検索だと、ペーパークラフトは1年半ぶり、設計はAIM-120頃が5年近く前、とか? そんなに経つのか。時の流れとは残酷なものよ。
とりあえず1/100で作成。H3-22L形態。デカイ。軸方向は接着していないので、ショートフェアリング形態も作れる。SRB-3も置いてあるだけ。LE9は接着済みなので部品を外してもH3-20Sまでしか作れないけど。
大雑把な形としてはこんなところかなー。SRB-3のスカート周りを作りたい気はするけど、絶妙に作りづらそうな形。/* SRB-3のスカートはSRB-Aのスラストストラットと近い役割で、ノズルスカートとは別物なので注意。ほぼ同じ場所に「スカート」と「ノズルスカート」という似た名前で全く別の構造がある。スラストスカートみたいに別の名前つければよかったのに */
AIM-120は羽が8枚付いてるからある程度見栄えがするけど、ロケットはただの円筒なので、作るのは楽だけど、飾っても面白くない。LE9の配管類や第1段のLOX配管、システムトンネルとかを追加すればもう少し見栄えがするのかもしれないけど、さすがにこのスケールで作るのは厳しい。タンク間部のリブを表示すれば少しはマシになるかな。
*
プリンタのインク、めちゃくちゃ劣化が早いインクもラインナップしてくれないかな。例えば印刷してから1週間か1ヶ月位で目視できなくなるような感じで。折り目とかのマーキングみたいに、しばらくはちゃんと見えてほしいけど、作ったあとは見えないほうが嬉しいような用途に。あるいは、最初は可視光で見えていて、可視光成分が透明になってもUVで照らすと見える、とか。最悪、最初から可視光では見えず、紫外線で見えるようなインクでもいいけど。RGB色空間からの変換がネックか。適当なカラーコードを割り当てるような感じになるのかな?
UV蛍光インクで郵便のカスタマーバーコードを印刷して、可視光では宛先人の名前だけ、みたいな郵便って、ちゃんと届くんだろうか? 届くとしても嫌がられそうだけども。肉眼でパッとみて住所が書かれていない郵便物(名前は書いてある)は、セキュリティというよりデザイン面の方でちょっと面白そうではあるが。
日本郵便、受取人の氏名がなくても届ける「特別あて所配達郵便」 - Impress Watch
受取人の名前がなくても届くサービスはあるらしい。中途半端な田舎だと住所だけでは家1件まで拘束できないけど、ある程度の人口密度の地域だと建物一つとかその中の区分一つまで拘束できるんだろうな。/* そういえば10年くらい前に郵便番号だけで荷物が届いたことがあったような気がする。住所とか名前とか無しで。郵便番号だけだと数十件くらいの家があるはずなんだけど、差出人の組織名から届けてくれたらしい */
***
SpX Dragon、データ通信が必要な貨物に対してはいろいろなオプションが提供できるけど、1553Bにも対応しているそうだ。Dragonの中でも1553使ってるのかな? 時代的に飛行制御はFirewireとかEthernetを使っていても良さそうだけど。システムバスが何にせよ、ISSとのIFでは1553が必要っぽいし、結局は1553が必要になるのか。
HTV-Xでも1553を使ってるはず。いまさら1553が必要なのかよ、とは思わなくもないけど、RAISEも「必要なら1553も使えるよ」と言っているらしいし、小型衛星でも使えるくらいには安いコンポーネントがあるのかも。1553はそんなに早くないから信頼性がそこそこでいいなら安く作れそうだけど、それだと本末転倒だろうし。
ISSは旧システムに合わせてやる必要があるとしても、月ゲートウェイみたいに新しく作るなら、ドッキング周りのIFとかも含めてSpW化すればいいのにな。でも既存の輸送機が全部1553だから改造するのめんどくせーってことで結局1553が使われ続けるんだろうな。
機械的には従来のドッキングポート(1553)と同じだけどSpWにも対応、みたいなインターフェースって作れないのかな? 接続されたらまず低電圧・高周波のSpaceWireでハンドシェイク、応答がなければ高電圧・低周波の1553で接続、みたいな挙動。1553はツイストペア1本、SpWはツイストペア2本なので微妙に相性悪そうだ。
ドッキングシステムのコネクタのピンアサイン。各種電源、1553が4組、ギガビットイーサ、他。未使用ピンがめちゃくちゃ多いな。もっとカツカツだと思ってた。こんなに余ってるなら適当なピンをSpWにもらっても良さそう。まぁ、結局は1553を使い続けるんであろうけども。。。
ISSは当初IEEE 802.4を使う予定だったそう。開発要素を減らすために実績のある1553へ変更。ラップトップを1553にぶら下げてヒューマンマシンインターフェースに使用。
JEMの特徴として、DRTS経由のEthernetが書かれている。当時のTDRSはEthernetは通らなかったのかな。適当な交換機を作れば通るはずだけど、1553の通信がデフォルトなんだろうか? 確かに地上で1553向けのパケットを作ってTDRSに飛ばして、衛星側ではTDRSと1553を直結レベルにシンプルに接続すれば信頼性は高そうだが。とはいえTDRSでスペースVLBIの実験やったりしてるし、結構好きなデータを流せるっぽいから、結局は交換器を作る手間を惜しむかどうかという問題になりそう。有人の信頼性を考えれば1553しか選択肢は無いのかもしれないけど。あるいはISS/TDRSが1553だからこそJEM/DRTSが信頼性を多少落としたEthernetを使えていたのか。
JWSTは1553とSpWの併用だそう。観測機器の中にも1553とSpWが通ってる。ハウスキーピングみたいな信頼性重視に1553、大容量データにSpW、イザとなれば1553でバックアップ、みたいなことなんだろうか? 当初は1553+1773の組み合わせで、1773をSpWに置き換えた、みたいな感じだろうか?
BepiColomboも1553とSpWの併用みたいな感じかな。これも歴史の古いプロジェクトだからJWSTと似たような流れのような気もする。
DS2000も1553と必要に応じてSpWを併用みたいな感じだし、ASTRO-HやMMOみたいにSpWへ一本化は結構特殊な感じがする。
*
うちのオシロの関連で1553の話を書いたような記憶があったので、1553デコーダが入ってるものだと思いこんでいたのだけど、記憶違いだった。思い返してみれば「ウチのオシロはAC400Hz対応なのに1553は非対応で、1553対応のオシロは400Hz非対応」みたいな話だったか。
ZEROPLUS LAP-Cは1553のデコードに対応しているので、試しにArduino(秋月のPro Mini互換)で1553っぽい信号を出してみた。1Mbpsだと処理速度が足りないので、1kbpsで出力。LAP-Cデコーダは1bpsから1Mbpsまで設定できる。
開発環境がクソデカとか言いたいこといろいろあるけど、数kHzくらいの信号を出す程度ならArduinoは楽だなー。
GPIO2本で抵抗2本を挟んで3値を出せるように。DCオフセットがあるけど、オシロで見るとそれっぽい波形になる。
1553のマンチェスタ符号、IEEE型じゃなくてトーマス型なのかな? 立ち上がりエッジが0、立ち下がりエッジが1。
シングルエンドでロジアナに突っ込んでデコード。ちゃんと解析できてる。
1553の転送はブロードキャスト含め一通りデコードできてるっぽいけど、mode command without dataが上手く動かず、フォーマットエラーになる。後ろに1ワードつけると正常にデコードされる。謎い。
1553は送信するだけならかなり楽でいい。データワードの送信だけ作ればコマンドやステータスはそれを流用すればいい(Sync反転が必要)。
MIL-STD-1553っぽい信号を出して軽く遊んでみる程度ならen.wikipediaをざっと眺めるのが一番楽な気がする。一通り書いてある。あとはJAXAの標準設計に若干の情報がある。
他にはmil-std-1553.jp/1553_top.htmlに日本語資料が、www.milstd1553.comに英語資料がある。日本語の方は若干機械翻訳っぽい感じもするけど、かなり詳しく解説されているので、これだけでも良さそう(まだちゃんと読んでない)。英語の方も詳しく色々書いてありそうだけど、最終更新が'14年頃? Rev.Cの話は書いてない。Syncの長さが「1 1/2bit」とか書いてあってさすがメリケンって感じの。
en.wikipediaのオシロの画像、おそらくトランス結合をキャプチャしていると思うんだけど、波形がめちゃくちゃ綺麗なのが謎い。トランス結合でこんなに綺麗に通るものなんだろうか? こんなに通るならExtended1553みたいに使えるのも納得な気はするが。
1553は1本のバスに31個のデバイスがぶら下がる。各デバイスが30個のサブアドレスを持っていて、サブアドレスごとに最大64オクテット(32ワード)を伝送できる。64オクテットに収まらないデータの場合はサブアドレスで拡張する。例えば11番から19番までの8個を割り当てると512バイトの伝送ができる。
転送データ数は5bitで管理するので、0-31の範囲を取る。0を指定すれば32ワードになる。ZEROPLUSのバスデコーダでは、コマンドで指定したワード数以上にRTから送ってもフォーマットエラーにはならない。例えばカウントを0に指定して33ワード送っても正常なフォーマットとして処理される。普通に考えたらバスタイミングの管理で死ぬから、指定されたカウント以上にRTから送るのはヤバいので、コンプライアンステストとか通すと失敗になるだろうけど。
1553は5+5bitのアドレス空間で1アドレスあたり64オクテットまでなので、例えばCAN FDに1553のパケットを流すことができる(ただしレスポンス時間要求は満たせないはず)。無人機とか小型衛星で、1553のデータフォーマットを使いつつ安価なトランシーバで接続する、みたいな使い方ができるかも。1553は誤り検出が16bit毎の1bitパリティしかないけど、CAN FDならCRCが使えるからより強力な検出ができる。アドレス空間も28bitあるから、仮想的に複数の1553を1本のCAN FDに通すこともできる。小型衛星で使うとたのしそう。自前プロトコル考えるほうが便利そうな気がするけど。
*
久しぶりにC++プログラミングをやって、かなりハマった。
Arduino IDE、bool f1(int a);みたいな関数があって、void f2() { return f1(1); }みたいなコードを書くと、f2の戻り値がvoidなのでf1の呼び出しが削除される。環境設定ですべての警告を表示するようにしても、警告の表示は出ない。
少なくともg++で同様のコードを書くとコンパイルエラーになる。Arduinoってガッツリ警告出してバグの温床になりそうなところは全部修正させたほうが良さそうなのに、デフォルトで警告がすべて非表示とか、謎い。バグが有っても気にするものか、いかに早くコードを書くかが重要なんだ!みたいな世界なのかな。
ヌルいarm-none-eabi-g++ -Wallに慣れてしまっているので、Arduino IDEの厳しい環境では生きていけない。。。
あと、検証ボタンと書き込みボタンが隣接しているのも不便。「なぜかコードの変更が反映されない」みたいな事態が多発したんだけど、おそらく書き込みを押そうと思って検証を押していたんだと思う。どちらもログに出てくるメッセージは同じだから、押し間違えても気が付かない。設定でコンパイルログは非表示、書き込みログは表示にしておけば、間違って検証を押してもログが出ないので気が付きやすいかな。
*
MIL-STD-1553でも使われているマンチェスタ符号、ユーロ紙幣の透かしにも使われているそうだ。額面がエンコードされている。Wikimedia、「Euro banknote security features」カテゴリ内に「Euro banknote watermarks」という透かし専用サブカテゴリまで作ってあるのに、コンテンツがめちゃくちゃ乏しい。マンチェスタ符号の透かし画像も無い。画像検索してもほとんど出て来ない。
100 ユーロ紙幣に透かし の写真素材・画像素材. Image 20208054.
表面から見た透かし画像なので、CCWに回して文字が正しい向きになるようにして、左右反転して裏面から見た画像にする。そうすると□■□■■□■□のパターンになって、これが01011010になり、立ち上がりエッジ(IEEE型)で1100となり、100ユーロのパターンになる。
この画像は旧ユーロ紙幣っぽいけど、現行のユーロ紙幣でもマンチェスタ符号は入っているそうだ。
ところで、新しいユーロ紙幣を作ってる最中だそうだけど、マンチェスタ符号は残るのだろうか? マンチェスター大学を擁するイギリスは欧州から離脱してしまったが……
*
P-1哨戒機、フライバイライトの機体だけど、1773を使っているのかな? デバイスメーカの「1773ターミナルを納品したよ」みたいな話は出てくるけど、それ以外の情報が見当たらない。
1773(1Mbpsモード)って1553と透過的に変換できるようなものなんだろうか? 例えば1773機器の開発が間に合わなかったら銅線を引いて1553で通信するとか、1553を通していたけど耐ノイズ性がほしい(or電磁放射を抑えたい)ところは1773に置き換える、みたいなことはできるんだろうか。
1553、基本的には2値のパルス位置変調だけど、データのSyncの取り扱いが難しそうな気がする。データはコマンドかステータスの直後にしか来ないから、隙間を開けなければ問題ないのかもしれないけど。というか隙間を開けるとZEROPLUSのプロトコルアナライザではエラーになるから、そもそも隙間を開けちゃいけないのかもしれない。とすると光化するときは単に2値をEO/OE変換するだけでいいのかな? 1553の場合、マンチェスタ符号はクロッキングには使用せず、単にトランス結合と相性がいい符号化としてしか使っていない感じ。
Wikipedia曰くクロックエラーは0.1%くらいまでだそう。1ワード20bitで最大33ワードまで伝送するから、1パケット660bitまで。0.1%だと0.66bitくらいのタイミングエラーになる。双方で0.1%ずれると1.3bitくらいずれるし、マンチェスタ符号だとその2倍で2.6bitくらいのズレ。さすがに正常動作は望めないから、せめてデータワードのSyncで再同期くらいは必要か。とはいえそれはUARTも同じ考え方だし、マンチェスタ符号のクロッキングは必要なさそう。
1773、NASAは1992年打上げの衛星(SAMPEX)で初めて採用したらしい。DS-1('98年打上げ)の一部コンポ(小型XPDR)や、EO-1('00年打上げ)のC&DHでも1773が使われていたようだから、90年代からの10年間くらいに打上げられた数機で採用されていた、程度なのかな。探せばもう少し出てくるかもしれないけど。
TRMM、降雨レーダは128素子のAESAで、数個の素子が壊れても大きな性能劣化がないことからAESAが選ばれたわけだが、結局17年(計画値の5.4倍)以上が経った運用終了にいたるまで、1素子の故障もなかったそうだ(信号処理装置は途中で故障し冗長系へ切り替え)。AESAは素子自体の出力が低めだし、真空管(TWTとか)みたいに経年劣化が大きいわけでもないし、ちゃんと設計・製造していればそうそう壊れるものでもないんだろうな。/* 降雨レーダは東芝製 */
***
小ネタ中の小ネタ
コロナで見えた市場戦略、DMG森の売上高1兆円への道筋 | 日経クロステック（xTECH）
欧州の前衛的なものづくりを間近で見ている当社は、将来の製造業の在り方を見通して、工程集約や自動化、DXに対応する5軸加工機や複合加工機などのハイエンド機種に注力していこうと決めたのです。シンプルな機能で低価格かつ短納期が求められる廉価機種の販売とは決別しよう、と。
M1は何だったのか…… コロナ禍でDXが急激に進む前に開発した機械だったのかな。
某テレビ局のサイエンス系を主に扱っている番組、海外の気象観測の話題で「放射線計測装置」みたいなのが出てきてなんだかなー。映像からすれば日照計だと思うんだけど、radiationとかを誤訳したのだろうか。理工学を主題に扱う番組であればそういう話題に強い人をスタッフに入れておくべきでわ。。。
EarthCare、ESAの打上げ予定が2023年ギアナVega-Cに更新されてる?(見逃してただけかな) なおen.wikipediaだと2024年第1四半期とのこと。EarthCareは打上げ質量2350kgで400kmのSSO(14:00/25日)あたり。古いユーザーズ・マニュアルだとVega-Cは400kmのSSOなら2460kgくらいまで打てるそうだから、EarthCareは100kgくらい余裕あるのかな?
Vegaは700km/i90に1430kgだそう。Vega-Cは同2300kgだそうだから、Cは6割増くらいか。ところで、M-Vは250km(31度)に1.85tくらい、Vegaは1500x200km(5.4度、円軌道だと850km相当くらい?)に1.9tくらいだそうだ。VegaはM-Vより少し高性能、Vega-CはM-Vの2倍弱、くらいの感じか。Vegaは今のレートで50億円くらいだから、M-Vよりだいぶ安い感じ。
Vega-Cは今年7月に1号機の打上げが行われた。今日(12月21日)にもう1機が打上げられる予定。Wikipediaのリストだと今年はこれが最後で、来年は9機(+従来Vega1機)の打上げが予定されている。EarthCareはその後。'23年はアリアン6とVega-C合わせて固体ブースタを20本くらい使う予定らしい。'24年は35本くらい。以降似たような感じ。順調に発注があれば簡単に数百本のオーダーに入るだろうし、それだけ作ればだいぶ安くなりそうだ。
ここ半年以上ずーっとPCのソフトウェアでばっかり遊んでいるので、そろそろハードウェアとか、せめて組み込みソフトとか、そういう遊びをやりたいなーと思っているのだけど、部屋が散らかりすぎて物を置く場所がないし、物がどこにあるかも分からないし。
げ、現代の通信はいかに乱雑に拡散するかという問題だから! 部屋が散らかっているのも拡散しているだけだから!! 逆拡散できなきゃ意味がないんだよなぁ。。。
ということで、久しぶりにSTM32を使ってみようと思い、今回もHyper-Vの中に開発環境を作ってるんだけど、色々手間取ってる。STM32CubeProg v2.12を入れたんだけど、ST-LinkがCLIから認識されない。v2.11に落とすとCOMポートは認識されるけど、ST-Linkは相変わらず認識されない。v2.10に落とすとCOMポート・ST-Link共に認識される。GUIで認識されないのはどのバージョンも同じ。ただしGUIから見えていなくても、ファームウェアアップグレードからはST-Linkが認識できる(Nucleoから割ったV2で最近はアップデートが無いので、正常にアップグレードできるかは不明)。Hyper-Vから使うならCubeProgは2.10で使うしかないかな。そんなアホみたいな開発環境使うなよ、って話なんだけど。開発環境用に気軽にOS入れ直せるようなコンパクトなPC欲しいなー。
とりあえず、CubeMXでコード生成してVS Codeで適当に編集してMakeでビルド、CubeProg(v2.10)CLIで書き込み、くらいは動いているかな。相変わらずVS CodeのC++拡張はv1.7.1じゃないと正常に動かないけど。
せっかくSTM32の開発環境を作ったので、STM32からMIL-STD-1553ライクな信号を出力
速度に余裕があるので本来の1Mbps(2Mbaud)で出力。今回はタイミング生成にSPIを使ってみた。綺麗に出てる。必要に応じてデコーダも書けば1553の受信もできるだろうけど、コアクロックが64MHzなので、1bitあたり64命令で処理する必要がある。かなり厳しそうな気がする。もう少し早いコアを使うか、ビットレートを下げるか。
今回はF303K8を使っているので、必要であれば、入力をオペアンプで差動増幅してシングルエンドに変換してからヒステリシスコンパレータで2値化して受信する、みたいなこともできるはず。出力は差動信号が出せないので、外部で差動化して高電圧に変換する必要があるけど、どうせ12Vとかはマイコンからは出せないし、外付けドライバくらいは受け入れねば。ということで、ゴリゴリ頑張れば1個数百円のチップに外付け回路(トランス類、入力周りの受動素子、高電圧のドライバ、クロック、パスコン、他)で1553トランシーバを作れるかな? という感じ。もっとも、いくら安いからと言って、高信頼性が求められる場所にソフト実装のコントローラなんか使えるのか、という問題はあるけど。
0 件のコメント:
コメントを投稿