1996/08/27 〜 1996/09/07
ＣＭＴファイルはチノンの付属ソフトにあり、コダックの付属ソフトにない 画像フォーマットだが実際の中身はどうやらカメラから送られてくる画像データに ヘッダーを付けただけのもののようだ。実際、先頭１２８バイト以外はカメラからの フルイメージと同じで枚数情報まで入っている(^^;)。
ちなみにファイルヘッダーは
0000000 43 4f 4d 45 54 00 00 00 00 80 00 01 e8 00 07 10 0000010 cc 00 0a 2d 00 00 00 00 00 00 00 00 00 00 00 00 0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00というようなものだそうだ。（各画像によって、どれだけ異なるかは不明）
前述の吉田さんは、具体的なＣＭＴファイルのフォーマットまで研究されていて、 お話では、フルイメージは１ライン５１２バイト×２４２行で構成されており、 はじめの行を０行と考えた上で、各行が
ただ、それだけの変換では付属ソフトの作り出す奇麗な画像にはならず、ソフト の方で高度な変換処理を行っているのではないかと推測されていた。 また、付属ソフトの変換を真似するのが難しいなら、変換自体は付属ソフトで行う ようにしてもよいのでは？とおっしゃっていた。
私も今の(フルイメージ)解析作業を止めるつもりはないが、当面吉田さんの
おっしゃるような形でソフトを作成していこうと思っている。
実際、ＣＭＴファイルの作成は簡単そうなので、まずこの形式のファイル出力を
作成しようと思っている。そうすれば、母艦にフラッシュなどで転送して付属ソフト
を使ってｔｉｆなりｂｍｐに変換することが可能になる。
（もちろんＥＳ１０００ユーザーのみ、その恩恵を受けることができる）
ＥＳ１０００以外のユーザー（ＤＣ２０など）は上記のようなことができないので、 ＬＸでＤＣ２０をシミュレートして付属ソフトに画像をシリアル転送することで 我慢しよう。
上記の話でＤＣ２０とＥＳ１０００が同等のものという表現をしているが、具体的 なところはまだ不明。今作成中のＬＸ上ソフトを吉田さんにテストして頂いて、同様 な制御ができるか確認をお願いするつもりである。今日は妻の具合が悪いのでここまで。明日はボーレートをどこまで上げることが 可能かの実験をすることにする。
今回は全て吉田さんの解析の力によるものです。吉田さんに感謝！！！
今日は自宅で仕事だったので久々にワンダースコープ(R)を立ち上げ、９６００→ １９２００の切り替えをモニタすることにした。（うちのＮＳ／Ｅでは９６００ボー までしか出ないので切り替え前を監視した）また、ＮＴマシンで付属ソフトの送信 状況だけモニタすることにした。（こちらは１９２００ボーだけ）
付属ソフト〜ＤＣ２０では、リトライもなくすぐにボーレート変更できている ようだった。モデム制御線が接続されていない以上なんらかのシーケンスがある はずだが...「をや？」ＤＣ２０を見つける為のパケットが変だぞ。最初は
41 00 96 00 00 00 00 1Aが２つ出て、その後で
41 00 19 20 00 00 00 1Aが出てボーレート変更している(つまり文字バケしている)。 ３、４バイト目の「96 00」「19 20」はボーレート じゃないか？試しに、５７６００ボーにすると、
41 00 57 60 00 00 00 1Aになってる！！なーんだ。簡単じゃねーか！！(^O^)
ということで、カメラを見つける為の(?)パケットの３、４バイトとボーレートの 関係は以下の通りとわかりました。(コードは全て１６進数)
早速ＮＴ上での解析用ソフトに組み来んでみると、おお早い早い。今までの遅さが うそだったようにスーっと転送してくれる。これなら実用上全然問題なさそうだ。
今度はＬＸ上のソフトにその機能を組み込んでみると、こちらも面白いように ＤＣ２０からデータを吸い上げてくれる。ただ、１１５２００ボーはやはり無理がある らしく、途中で取りこぼしの為エラーとなってしまった。読み込み中にゲージ表示 しているので(だって９６００ボーでは必要だったんだもん)、これを外せばもう少し いけるかもしれない。５７６００ボーでは実用に耐える速度で安定して転送できた。 （ＬＸは倍速済み）
さあ明日はサーバーモードのＬＸ組み込みだが、納期前で時間がなさそう （納期前に何やってんだか）。時間がなければ、今日ちょびっとだけ説明したように 他のパケットの内容についても説明しようと思う。乞うご期待。
最初は安全の為パケットの説明を希望者にだけ行おうかと思ったのだが、やはり 参考情報として意味あると思い、公開することにした。くり返しになるが、この解析 情報が正しいとは限らないし、万が一この情報によって被害を受けたとしても当方は 一切関知しない。また、この情報に基づきメーカー等に問い合わせ等をすることは絶対 におやめ下さい。
以前にも述べたがＤＣ２０と付属ソフトとの間では以下の通信条件で通信を行って いる。
付属ソフトからＤＣ２０へ送られるパケットは(現在わかっている限り)以下の通り である。 （名称は私が勝手につけています。本来の名称とはきっとかけ離れているでしょう）
命令用のパケットは全て８バイトで構成されており、最後が必ず 0x1A で終わる。 逆にＤＣ２０から返されるパケットの長さは可変であり、複数のブロックに分割 されて送られる場合もある。
ＤＣ２０から付属ソフトに返されるパケットを大別すると以下のようになる。
昨日ボーレート設定の話の時に出たパケットである。このパケットは付属ソフトが 何かする前に必ず発行される。また、何等かの命令パケットを送った後にも必ずとい って良いほど発行される。多分、不意の電源断などを考慮してのことだと思う。
初めてこのパケットが発行される時には、必ず
0x41 0x00 0x96 0x00 0x00 0x00 0x00 0x1Aというパケットが(通信速度９６００ボーで)発行される。 ＤＣ２０は電源投入時は９６００ボーとなっており、この状態で、正常応答のパケット (0xD1)を返す。また、確認の為だと思うが、付属ソフトは再度
0x41 0x00 0x96 0x00 0x00 0x00 0x00 0x1Aのパケットを送出している。ボーレートを９６００ボー以外に変更したい場合は、 この後に、
0x41 0x00 0x19 0x20 0x00 0x00 0x00 0x1Aのパケットを送出し、 正常応答(0xD1)のパケットを得た後で、 両者が(上記の場合)ボーレートを１９２００ボーに変更する。 （以後１９２００ボーにて通信）
付属ソフトは、９６００ボー以外でカメラチェックを行った時に、正常応答を 受信できなかった場合、リトライを１度した後、９６００ボーに通信速度を落として リトライする（２回）。それでも反応がなかった場合には、エラーとなる。だから、９６００ボー以外で付属ソフトを立ちあげている間に、ＤＣ２０の電源を落と して再度電源を投入すると、最初のカメラチェックは失敗し、９６００ボーでの カメラチェックで正常応答する。その後付属ソフトは、設定してあるボーレートに なるようボーレート変更する。
0x7F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1A（今までのところ特にパラメータはなさそうだ）
このパケットを受信するとＤＣ２０は自分の状態を付属ソフトに報告する。 この状態取得の流れは、
(注)「→」は付属ソフトからＤＣ２０への命令パケット、「←」はＤＣ２０ から付属ソフトへの応答パケットである
状態応答のパケットは、２５６バイト固定長で、その後にチェックサム が１バイト付く。
チェックサムは２５６バイトのデータの排他的論理和をとっただけの 簡単なものである。パケットの内容は先頭から、
のようになっている。付属ソフトの内容から判断して、上記不明部分に電池の残量 情報が含まれているはずだが、よくわからなかった。0x01, 0x20 : 固定らしい(変更するとエラーになる) 0x01 : ファームウェアバージョン整数部 0x00 : ファームウェアバージョン小数部 0xAD : 不明 0xC2 : 不明 0xCD : 不明 0xA2 : 不明 HH : 撮影済み枚数の上位バイト LL : 撮影済み枚数の下位バイト HH : 撮影可能枚数の上位バイト LL : 撮影可能枚数の下位バイト 0x85 : 不明 0x00 : 不明 0x00 が３８バイト続く 0xFF が最後まで続く
カメラチェックとカメラ情報パケットをサポートすれば、付属ソフトのカメラ情報 の機能はカバーできる。
今日はここでおしまい。明日は撮影と、簡易イメージ要求のパケットについて 説明する。
撮影は簡単だし手軽にコーディングできるのだが、一つだけ困った点がある。 それは、撮影パケットを送った後の正常応答がどうやら９６００ボー固定で行われて いるようだからだ。というのはボーレートを９６００ボー以外にした場合、正常応答 のコードが必ず化けてしまうからだ。（その後の０ｘ００は問題ない）
多分ＤＣ２０のバグだろう。いちいちこの時だけボーレート変更するのもイヤなの で、ＬＸ用の制御ソフトでは、スリープしてその間の受信内容を無視することに した。実際それで問題は発生していない。
なお、付属ソフトでは、付属ソフトからの撮影後、撮影した画像の簡易イメージを 自動的に取り込むようにしている。
ＤＣ２０を使ったことのない人に説明すると、簡易イメージとは付属ソフトから ＤＣ２０で何を撮影したか調べるときに表示されるグレーの画像のことだ。
この画像は横８０ドット縦６４ドット（実際に内容があるのは６０ドット）の ２５６階調のグレースケールデータで、表示するとそれなりに内容が把握できる 程の品質を持っている。カラーのフルイメージを表示する前に内容を確認するとき 非常に役立つものだ。（ＬＸのＤＢで表示させる程度の(小さい)画像なら、この 画像だけでも十分である）
さて具体的な転送手順について説明する。付属ソフトの場合ＤＣ２０内の画像を 一度に全て転送してしまうのだが、カメラ内の各データを撮影枚数分転送するだけ なので、１枚の簡易イメージ転送について説明する。
転送は、カメラチェック・カメラ情報要求の後、以下の手順で行われる。
説明もれがあった。簡易イメージ要求の４バイト目は取得したいイメージの番号 をあらわしている（１〜）。この値によってカメラ内の任意位置のイメージを取得 することができる。計５回の転送で、1024*5 = 5120 バイトの画像情報を取得できる。これは、 横８０ドット×縦６４ドット×１バイト（２５６階調）のデータをそのまま含んで いる（先頭が画面左上端）。
簡単ですばやい転送が可能なので、ＬＸなどでは画像付きＤＢなどと組み合わせると 面白い使い方が可能になりそうだ。
今日はここまで。次回は、画像消去と標準／スナップ切り替えについて説明する。
エラーの場合は、正常応答の後、即座に「0xE2」が返される。エラーは、あらかじめカメラ状態の取得ではじくようにした方が無難だろう。
もしカメラ内に画像が残っている場合はエラーとなり、正常応答の後、即座に 「0xE2」が返される。
イメージ情報要求とフルイメージ要求の４バイト目は取得したいイメージの番号 をあらわしている（１〜）。この値によってカメラ内の任意位置のイメージを取得 することができる。※ 「簡易イメージ要求」 の項も参照のこと
フルイメージの内容は、まだほとんどわかっていないが、各パケットに２ライン分 のデータが入っているようだ。また最初と最後の５１２バイトは無意味なデータの ようだ。データの内容については、 1996/08/27 の日記 を参照して欲しい。
これで一通りパケットの説明が終わったので、次回からはまたＬＸ版制御ソフト の進捗の話題に戻る。
現在の機能をメニューから列挙すると
結構多くなってしまった(^^)。ファイル管理等が面倒だったので、File Save as CMT ... CMTファイルで保存 Delete ... ファイル削除 Rename ... ファイル名変更 Exit ... 終了 Camera Info ... カメラ情報取得 Table ... カメラ内の全簡易イメージを取得 Take ... 撮影 Timer ... タイマー撮影 Erase ... カメラ内のイメージ消去 Image ... カーソル位置の簡易イメージ取得 Full ... カーソル位置のフルイメージ取得 Special Redraw ... 画面再描画 Local ... ローカルモード移行 Camera ... カメラモード移行 Server ... サーバーモード移行 Option Setup ... 各種設定値変更 9600 ... ボーレート変更 19200 38400 57600 115200 Quit ... 終了 Help About ... コピーライト表示
またサーバーモードでは上記ローカルモードで表示される画像を付属ソフトの動く ＰＣ上に転送できるようになっている。（つまりＤＣ２０のフリをする）
とりあえず、こんな感じでＤＣ−２０のサポートができるようになっている。 そろそろ公開に向けて準備せねば。
以前 カメラ情報要求 で、カメラから返される状態応答について不明点が多かったが、２つの点について わかったので以下に示す。
電池切れは単なる１ビットの情報だったようだ。さて気になる使用時間だが、 どうなんでしょ。カタログの４００枚は撮影した憶えがないけど、普通の数倍の 転送を行っているハズだからこんなものかな？多分撮影枚数は１００枚程度、 転送回数は３００回位だと思う（根拠レス）。明日は電池買ってこなきゃ(^^;)。0x01, 0x20 : 固定らしい(変更するとエラーになる) 0x01 : ファームウェアバージョン整数部 0x00 : ファームウェアバージョン小数部 0xAD : 不明 0xC2 : 不明 0xCD : 不明 0xA2 : 不明 HH : 撮影済み枚数の上位バイト LL : 撮影済み枚数の下位バイト HH : 撮影可能枚数の上位バイト LL : 撮影可能枚数の下位バイト 0x85 : 不明 0x00 : 不明 0x00 が９バイト続く XX : 標準モードの時0x00, スナップモードの時0x01 0x00 が５バイト続く XX : 電池切れの時0x01, そうでない時0x00 0x00 が２２バイト続く 0xFF が最後まで続く
それともＡＣアダプタを買ってこようかな...(^^;)
来週はＬＸＤＣの公開をしようと思っている。動作のチェックやドキュメントの 整備に追われそう。（でも何より TRAIN データの公開準備の方が大変。そちらの 方も乞うご期待）
（なんだか解析ネタが少なくなってきたので日記の間隔も長くなりそうです。）
