XI-IV再び（２６）

昨日の湘南地方は、雷雨でした。午後のXI-IVパスの間だけ、雨はひどいが雷は止まっていたので、データ受信を行いました。本日のデータと合わせて、次のような画像となりました。左は生データ、右は補正後です。
 
雲の下に陸地らしきものが見えるような気がしますが、いかがでしょうか。
ところで、本日はパソコンが起動しなくなり、この対応で半日つぶれてしまいました。原因は不明ですが、メモリーの再抜き差しやドライブのケーブルの差込直しで動くようになりました。時々このような症状がでるので、そろそろ新しくすることも考えないといけないかもしれませんが、今はVistaパソコン主流のため、使用中のソフトが使えなくなるおそれがあるので、どうしようかという状況です。何とかメンテナンスしながら、使い続けるしかないかなと思っています。
このような状況のため、本日はAVRマイコンによるモデムレスTNCの実験はできませんでした。

AVRでTNC（１２）

８月１７日の最後にATmega88の２８ピンを４０ピンに変換するアダプタについて書きましたが、これを本日作成し、Ver.1のTNCに組み込みました。アダプタにはISP（組み込んだままでプログラムの変更ができる仕組み）用の端子を取り付け、マイコンを外さなくても、内蔵プログラムが書き換えできるようにしました。
アダプタを作成して最初に組み込んだとき、パソコンのターミナルソフトに表示されるスタートメッセージがきちんと表示されなくなったため、配線を直したり悩んでいましたが、マイコンの設定を変更し、水晶発振器を使用するようにしたところ、問題なく表示されるようになりました。おそらく、内蔵発信器では周波数が安定しないことから、RS-232Cのクロックタイミングが合わなかったのではと推測しています。
また水晶発信器を使用した場合、サンプル音声等でのデコード率がよくなり、エラーデータが減少しました。モデムICレスのTNCは、内蔵発振器ではなく外付水晶発信器を使用し、周波数の安定を図る必要がありそうです。作成したICのアダプタと組み込んだ様子を掲載します。

左から、アダプタの裏面、表面、マイコンを差し込んだところです。これをVer.1のTNCに取り付けると次のようになります。

次回のSRLL受信が待ち望まれます。ただ、土日でないと受信できないので、チャンスは先になりそうです。それまでの間に、モデムICレスの受信専用機、送信機能（とはいってもAFSKなのでCUTE-1.7+APDIIのアップリンクには使えませんが）の追加とGMSKの対策を考えて行こうと思っています。

追伸：昨日今日とハムフェアでした。今日はあいにくの雨模様でしたが、他の方のブログによると、盛況であった様子がうかがえます。時間に都合がつけば、中須賀東大教授のお話等聴きに行きたかったです。

AVRでTNC（１１）

昨夜のSRLL受信データは東工大へ報告しました。受信者にいつ記載されるか、楽しみにしているところです。
その受信データを少し検証してみました。

受信フレーム数：２３２
CRC一致により正しいと認められるもの：２０４
正解率：８７．９％

誤りビット数については、プログラムを再確認したところ、計算誤りがありましたので、検証からは除外しました。プログラムの訂正後、テストデータ及びJA0CAW局の録音ファイルで再確認したところ、平均１００ビット以上、１文字１２ビットあたり２ビット前後の誤りがあるようでした。ビットデータの取得部分に、何か問題あるかもしれませんが、SRLLの強力な誤り訂正機能により、高い正解率が得られたのだと考えています。

TCM3105による受信はここまでで区切りをつけ、当初の目標であるモデムIC無しの実験を少し試しましたが、結果は惨憺たるもので、テストデータでもJA0CAW局の録音ファイルでも、デコードデータがひとつも出力されませんでした。
こちらについては、更なる検討が必要と思いますが、明日以降はここ１週間のように時間が取れそうも無いので、今後の進展速度はかなり遅くなりそうです。

まずは、TCM3105によるTNCを１台のTNCとして、Ver.1のマイコンと今回のマイコンを差し替え出来るよう準備を進めようと思います。具体的には２８ピンのICを４０ピンのICソケットに差し込めるよう、アダプタを作成することとなります。いつ出来上がることか・・・。

AVRでTNC（１０）

８月１６日の午後９時台のCUTE-1.7+APDIIパスでは、SRLL送信がありました。昨日のプログラムを１日かけて改良し、受信に臨みました。結果、大成功を収めることができました。ログの一部を掲載します。

【ASCII表示】
[2008/08/16 21:11:39R] JQ1YCZ0JQ1YTC0ﾐACK RX
【バイナリ表示】
[2008/08/16 21:11:39R] 4A 51 31 59 43 5A 30 4A 51 31 59 54 43 30 07 D0 41 43 4B 20 52 58 （途中省略）41 2A 41 2A 5A 0D

バイナリ表示の青太字が送信されたCRC、緑太字が受信データから再計算したCRCです。一致しているので正しいデータであると判断できます。また、赤太字はエラービット数です。かなりの数がエラーとなっています。計算方法を再確認してこの数字でいいのか検討する予定です。
受信状況は次の写真のようでした。モデム部分はVer.1のSRLL用TNCを使用し、マイコンは評価ボードを使用しています。

評価ボードの下部に見えるLEDの一番右は１２００Hzと２２００Hzの信号により点滅し、右から２番目以降は３２、６４、９６バイトのデータのときにそれぞれ点灯します。６４バイトのデータを受信しているときは、次のようになります。

これでやっと念願であったSRLLVer.2の受信環境を整えることが出来ました。マイコンをVer.1のものと差し替えできるようにする予定です。足の数がVer.1では４０本のマイコンを使用し、今回は２８本なので、アダプタの作成を考えています。

AVRでTNC（９）

夜までかかって誤り訂正とCRC再計算を追加しました。デコード結果は次のようになりました。

【東工大作成テストデータ】
（受信した生データ）JA!YTC0JQ1YCZ0'CONG You're A Meo`ER o譬SRLL Rdbeivers!
（誤り訂正後データ）JQ1YTC0JQ1YCZ0'CONG You're a Member of SRLL Receivers!

これをバイナリ表示すると次のようになります。
（受信した生データ）4A 41 21 59 54 43 30 4A 51 31 59 43 5A 30 27 43 4F 4E（途中省略）80 80 00 00 00 90 CD
（誤り訂正後データ）4A 51 31 59 54 43 30 4A 51 31 59 43 5A 30 27 43 4F 4E（途中省略）00 00 00 00 00 90 CD 90 CD

赤文字部分が誤り訂正機能により訂正されています。また、誤り訂正後データの末尾２バイト（太字緑文字）は訂正後データから再計算したCRC値で、その直前の受信したCRC値（太字青文字）と一致しているので、このデータは信頼性がある（正しいものである）ことがわかります。出力されている文字だけ見ると正しいように見えるデータであっても、CRCが一致していないものもあります。

JA0CAW局のブログ掲載のWAVファイルのデコードデータについても、検証してみました。

【６４バイトデータ】
（受信した生データ）JQ1YCZ0JQ3[TC0$€A` EEEE（以下省略）
（誤り訂正後データ）JQ1YCZ0JQ1YTC0$ﾀ` EEEEE（以下省略）

このデータは一見誤り訂正で正しいデータ得られたのではと思われますが、バイナリ表示すると次のとおりとなっています。
（受信した生データ）4A 51 31 59 43 5A 30 4A 51 33 5B 54 43 30 24 80 41 60（途中省略）00 00 00 00 00 D6 63
（誤り訂正後データ）4A 51 31 59 43 5A 30 4A 51 31 59 54 43 30 24 C0 01 60（途中省略）00 00 00 00 00 D6 63 B7 B9

CRCが一致しないので、正しくないデータと判断されます。

【３２バイトデータ】
（受信した生データ）JQ1YCZ0ﾊﾑ1YTC0 SR\\ T%3t（以下省略）
（誤り訂正後データ）JQ1YCZ0JQ1YTC0 SRLL Test（以下省略）

これをバイナリ表示すると、次のとおりです。
（受信した生データ）4A 51 31 59 43 5A 30 CA D1 31 59 54 43 30（途中省略）00 00 10 64 2F
（誤り訂正後データ）4A 51 31 59 43 5A 30 4A 51 31 59 54 43 30（途中省略）00 00 00 74 2F 74 2F

赤文字が訂正され、CRCが一致しているため、正しいデータとなっています。

以上に誤りビット数をカウントした結果を末尾に表示するよう付け加えれば、受信機能のできあがりです。東工大紹介のプログラムと機能（表示形式）が一部異なりますが、しばらくはこのデータ形式で受信報告していく予定です。デコード率がよくないので、表示項目の改善と合わせて検討を進める予定です。

AVRでTNC（８）

昨日の続きで、インターリーブの解除に取り組んでいます。現在、データ部分のインターリブ解除に成功しました。東工大のウェブサイトからのテストデータで次の表示を得ることができました。残念ながら、７フレームのうち５フレームしかデコードできていません。
[2008/08/15 15:07:57R] JQ0XVA0HS1YCZ0'CONG YOU'bu a Membmz of SRLL Receivdss!        析
[2008/08/15 15:08:03R] jQ1YTC0JQ1YCZ0'CONG /u're a Member of SRLL Receivefg!          設
[2008/08/15 15:08:05R] JQ1YTC0JQ1YCZ0'CONG You're a Meifer of SRLL Receivers!          析
[2008/08/15 15:08:07R] ji・・璢・ｩﾋB・G・.M3・尉@・鮓ﾏ､[b0pｵ・ zQﾊhTp@ﾘﾌX・0ﾘ
[2008/08/15 15:08:10R] JQ1YTC0JQ1YCZ0'CONG You're a Member of SRLL Receivers!        析

また、JA0CAW局のブログに2008年7月24日付で紹介されていたSRLL送信音の音声ファイルをお借りして試したところ、６４バイト長と３２バイト長双方のデータを次のとおり得ることができました。（一部抜粋）
【６４バイトデータ】
[2008/08/15 15:14:10R] JQ1YCZ0JQ1YTC0ｰ (48€ 6ｨﾊ枷)&ｶj>｢       !          $   s
【３２バイトデータ】
[2008/08/15 15:15:34R] JQ1YCZ0JQ1YTK8 SRTT Pawp     t/
[2008/08/15 15:15:38R] JS3YCZ0JQ1YTC0 SRLL Test @@     t/

あと誤り訂正とCRCチェックを付け加え、データの出力形式を整えれば、受信部が完成します。今年７月１９日からプログラム開発をスタートして、やっとここまでこぎつけました。

AVRでTNC（７）

昨日に引き続き、本日もAVRでTNCに挑戦しました。昨日のブログに書いた不具合の原因が、以前気になっていたタイマ割込み機能にあることが判明し、プログラムを組みなおしたところ、東工大のブログに掲載されていたサンプルサウンドから、やっとSRLLのヘッダ４バイトを正しく取得することが出来ました。
１２００分の１秒タイマ割込みを発生させるために、昨日までのプログラムでは特殊なレジスタに設定した値になると割込みが生ずるというCTC割込みという機能を使っていました。以前使用したAVRにはこの機能は無く、タイマオーバーフローによる割込みで対応していました。CTC割込みは本来PWMを発生させるためのものであるので、CTCをやめてオーバーフローによる割込みを使用するようにプログラムを変更したところ、SRLLのヘッダを確認することができたしだいです。使い慣れた機能を利用したことが、解決の糸口となりました。
本日は、これに続いてスクランブルを解除する機能まで進むことが出来ました。後残っているのが、インターリーブへの対処と、誤り訂正です。Ver.1のTNCでもそうでしたが、この２つが最大の難関です。Ver.1と異なり、SRLLのVer.2ではパケット長が３２、６４、９６の３種類に対応しないといけないので、時間がかかりそうです。
Ax.25のデコードであれば、それほど手間がかからずにできそうですが、SRLLの受信を成功させてから、モデムIC無しへの挑戦と同時に、Ax.25についても考えてみようと思います。

AVRでTNC（６）

今週は時間がとれたので、AVRでTNCの検討jを少しまとめて進めました。しかし、思ったようには動かず、先になかなか進めません。CUTEー17＋APDIIのSRLLに対応したTNCを作ることを目標としているのですが、SRLLの手前のデコード部分(物理層及びネットワーク層の手前くらい)がうまくいきません。テスト音声をデコードのするたびに、表示される結果が異なってしまいます。Ax．２５の信号をデコードしてみて、検証してみようと考えています。このような状況なので、今の時点でブログに書ける内容がありません。また、進展がありましたら、発表します。

AVRでTNC（５）

JQ2RVNさんのコメントからヒントを頂き、受信音が１２００Hzから２２００Hzに変化する（及びその反対に変化する）場合（下の図のAのタイミング）に、受信データとして０をすぐセットすると共に、次のデータ読み込みをするタイミングを１２００分の１秒の１．５倍後（下の図のBのタイミング）とするプログラムに変更しました。また、それ以外の場合は、１２００分の１秒ごとの割込み処理で受信データとして１をセットする事としました（下の図のCのタイミング）。

言い換えると、通常は１２００分の１秒ごと（BからCへのタイミング）の割込み処理で（変調音の変化がないので）受信データを１として取得し、変調音の変化があった場合（Aのタイミング）に割込み処理で受信データに０をセットすると同時に次の割込みのタイミングを１２００分の１秒の１．５倍後（AからBへのタイミング）に設定するということになります。

また、AVRによるTNCはゼロクロス検出は一旦棚上げにし、TCM3105でデモジュレートしたデータをSRLLとして捕らえることから先に実施することにしました。SRLLVer.2.0ではスタートフラグが３種類（３２バイト長データの場合は７C-３D-３８-4D、６４バイト長だとF１-７３-８５-７８、９６バイト長だと４０-２B-８１-３B）あるので、まずはこれを捕らえることが第一歩と考えました。
Ver.1.0でもそうでしたが、上記のスタートフラグは下位バイト（それぞれ４D、７８、３B）から送信されます。デコード誤りへの対策は別途考えるとして、この３つのうちどれがデコードされたかをLED表示（４Dは１番目、７８は２番目、３Bは３番目のLEDが点灯）するようプログラムして試してみました。
その結果、東工大ブログに掲載されていたサンプル音では、変調音の頭の部分で、３２バイトデータのスタートフラグに含まれている４Dが検出されました（と思います）。
なお、ゼロクロスによる周波数検出を利用したプログラムでは、同じ音量という同条件であっても、検出出来るときと出来ないときがあり、やはりこの方法は難しい部分があると感じました。

XI-IV再び（２５）

今朝、珍しく早起きし、XI-IVからのデータを受信しました。ここ１か月ほどのデータから、次の画像を得ることができました。右下に地球がぼやっと写っているようです。ちょっと幻想的。
 

CUTE-1.7+APDII、SEEDS、DELFI 、COMPASS（２９）

今朝９時半頃のCUTE-1.7を受信待機していましたが、運用はされなかったようです。仰角ほぼ天頂で混信も無く、いい受信環境でした。管制局に何かトラブルでもなければいいのですが。続いてのSEEDSIIはパスの半ばから、デジトーカ＋SSTVが運用されたので、SSTVを久々に受信しました。MMSSTVで２回同期をとりなおしながら、３つの画像を取得しました。ちょうど２分おきにSSTVが送信され、左から、0942、0944、0946JSTの画像です。

２つ目はまずまずの画像だったと思っています。