2013年 11月 19日

モールス練習 進捗

練習開始から111日。練習のモチベーションはかなり落ちているんだけど、割と習慣化できているので、1日に少なくとも5分程度はやってると思う。習慣化というか、せっかくここまで頑張ったんだし……っていうサンクコスト的な感じで続けざるを得ない。

前回書いたときから3週間ほど経ったけど、あいかわらず 100% をとらない限り次に進まない、というのを続けてる。23wpm で 100% を出して、今は 24wpm で 100% を狙っている。90%以上はコンスタントに出せていて、あとは運が良ければ100%とれるかな?という感じ。たまに 25wpm、26wpm をやってもまぁ90%ぐらいはとれる感じ……

というのはランダムの話で、やはり単語聞きとりになるとかなり精度が落ちる。80〜90%ぐらいになってしまう。符号の聞きとりだけじゃなくて、単語の認識をしようとして処理速度が追いつかない感じ。ただ、速度を落とせば聞きとれるかというと、そういうわけではなくて、頭に浮かんだ文字の一時記憶が数msecなので、遅いと遅いで単語が聞きとれない。

あと、「business」とか、「conversation」とか、長い単語になると、さらに辛い。単語は i e s あたりが本当に頻出なので、速度が1.5倍ぐらいになるインパクトがある。ss は特徴があるので覚えやすい。hh とか ii という列は普通ないので、ss は s 単体よりも正確に聞きとりやすい。process とか discuss とか possible とか、よくでてくる。

初期のころからやって聞き慣れつつある th からはじまる頻出単語 (the then they them this there their) は結構聞きとれるようになってきた。初期のころこれ無理だろ、って思ってたけどかなり時間をかけて慣れてきてる…… とはいえ、これらの中でも this there their は難易度が高い……

2013年 11月 01日

モールス練習

練習開始から93日、ほぼ3ヶ月ぐらい経っているので経過を書いておく

  • 10月09日: 25wpm ランダムまで90%をとれ次第すぐ進むぐらいの勢いでやる。
    • 1ヶ月で、20wpm ランダムならぎりぎり90%をとれるぐらいになる
    • 2ヶ月で、25wpm ランダムならぎりぎり90%をとれるぐらいになる
  • 26wpm からどうも急に難しくなったように感じられる
    • 一部の符号の聞き間違えが足を大きくひっぱっている (特に S H 5)
  • 20wpm まで戻り、100% がとれ次第次のスピードに進むという基準に変更
    • 基礎練習
    • S H 5 を特に意識してやる
    • 3 7 z あたりも苦手だったけど、全体的に精度が上がるのは感じられる
  • 22wpm ← 今ココ
    • あいかわらず S H 5、1 J で間違えることが多い。

22wpm でもランダムなら、ほぼ90%はとれる、という状態にはなっている。ただし単語聞きとりだと、短い符号が多くなっておいつけなくて、もっと低く80%代なことも多い。それに身体状態に大きく左右されるのも変わりない。寝る前とかだと95%もとれなくなる。

最近急がしくて交信を聞く暇がなく、とにかく朝と夜の聞きとり練習だけをやってる。実感としては正直、ラバースタンプレベルでも余裕でとれるような感じではない。タイピングまではできても、意味まで理解して聞きとろうとすると単語単位で落としてしまう。それに、実際の交信だと25wpmはあたりまえな感じなので、現状の能力では全く足りない。

ラバースタンプでも、名前と住所は必ずちゃんと聞きとる必要があるところなので(住所はJCCで送ってることが多いからそれほどでもないけど)、それぐらいは1発でとれるようになりたい。それに、ラバースタンプとはいえ、何を送ってこられるかわからないのは怖い。緊張するとさらに聞きとれなくなると思う。

2013年 10月 21日

AVR で USB 接続の PC キーヤーを作る

PC からモールス符号を発生させて無線機に入力するものが欲しいと思っていた。当然既にそういうのはあるんだけど、どうも気に入るのがないので、必要な機能だけ自分で実装する。

基本の要件としては

  • クロスプラットフォームであること
    • というか Mac で動くこと
  • USB バスパワーで動くこと

なので、簡単そうでいろいろ教材としても楽そう。

クロスプラットフォームで面倒なドライバを書かなくてすむ方法は HID デバイスとして作ることだと思うので、そのように作ることにした。また、USB 用の外部チップとか用意したくないので V-USB (AVR マイコン上で USB を処理できるライブラリ) を使うことにした。

いろいろやってなんとか2日ぐらいで最低限の機能の実装ができたのでいろいろメモしておく。

回路図とコード

コード: https://github.com/cho45/AVR-USB-CW


現状制作途中のものなので、実際使う際に必要なリレー部分とかは書いてない。

現状だとダイオード2本で約1.4V程度電圧降下させて 3.3V〜3.6V 程度を作りだす方法を使ってる。V-USB の Wikiに書いてある方法の1つ。

左下のはそのうち試してみたい回路で、AVR自体には5Vをそのまま供給して、信号ラインだけ 3.6V にツェナーダイオードで電圧降下させる。電源電圧を3.3V程度にしてしまうと、動作周波数が 12MHz 程度までしか保証されないので、16MHz や 20MHz で動かすならこちらのほうが安定しそう。

V-USB

まず examples/hid-{data,mouse} を動かして、ふむふむと思いながらやってみたけど、なかなかハマった…… HID デバイスを作ろうとするとデフォルトの usbconfig.h から結構書きかえないといけないんだけど、それを知っていないとだめなのでつらかった。

usbconfig-prototype.h から作るのではなく、example/hid-* のをコピってくるほうが確実に動くと思う。

まだコントロール転送しかできてない。少なくともインタラプト転送はやることになりそうだけどデバッグがだいぶ大変 (追記:インタラプト転送は Mac + libusb だとできなかった)。

あと、自分で設定している割込みの頻度が高すぎると STALL しやすい…… クロック周波数にしても、こういった処理にしても結構シビアなので気を使わざるを得ない……

HID のレポートデスクリプタ定義は、大本の仕様書がどこにあるのかわからないのでコピペと感で書いて試した。

V-USB を妨げない delay_ms

_delay_ms は定数しかスリープできないのと、ビジーループなのでその間割込み以外何も走らなくなってしまう。V-USB は usbPoll() を少なくとも50msecに一回は呼ばないといけないとかなので、これは使えない。

なので、まず割込みで時間を測るタイマー変数を作る。

必要な精度以上のタイマー(あまり短くないほうがいい)を用意 (この例だと1ms) して、グローバルな timer という変数をインクリメントするようにする。(F_CPU / 分周設定 / OCR0A) CTC のほうが自由に時間を設定できて楽

	/**
	 * timer interrupt
	 * CTC 16MHz / 64 / 250 = 1kHz = 1msec
	 */
	TCCR0A = 0b00000010;
	TCCR0B = 0b00000011;
	OCR0A  = 250;
	TIMSK0 = 0b00000010;
unsigned long timer;
ISR(TIMER0_OVF_vect) {
	timer += 100;
}

以下のようなマクロを用意して DURATION(msec) で、引数に与えた時間が timer 換算でいくつになるかを出す。浮動小数点演算を使った瞬間、出てくるバイナリサイズが長大になるのでそうならないようにしてる。

#define DURATION(msec) (unsigned int)(msec * 100)


delay_ms を実装する。_delay_ms におけるビジーループ部分が任意に書けるので、ここで usbPoll() をする。

void delay_ms(unsigned int t) {
	unsigned long end;
        cli();
	timer = 0;
        end = timer + DURATION(t);
        sei();
	while (timer <= end) {
		wdt_reset();
		usbPoll();
	}
}

これでナイーブに delay_ms() を使ったコードでも可読性と効率をそこそこ両立できそう。しかし、なんかもっといい感じにコード書けそう。。普通どうやるものなのかよくわからない。

I2C 液晶

デバッグするとき、何かしら文字を表示できるインターフェイスがないとつらいため導入。シリアルポートに出力してデバッグするのがたぶん一番楽なんだと思うけど、レベル変換が必要で手元にあるものではできなかった。


I2C を使うにあたって、原理を理解していないのと、なおかつそれを AVR で実現する方法がわからないのと、さらには「デファクトスタンダード」な通信プロトコルも存じあげないため、全ての箇所でハマりにハマった。チップは ATmega168P なのでそこまで細かい原理を知っていて実装できる必要はないけど、だいぶハマった。

やり終わってみれば、別に難しくはないんだけど、どこに問題の原因があるのかが、見える現象が少なすぎて大変だった。面倒でもいちいちLEDチカチカさせて動作確認をすべき。

以下に I2C 液晶 (アドレス 0x7c) を操作するコード。何をするにせよ、とにかくデータシートをよく読んで理解するのが大変に重要だと実感した。

#include <string.h>

#define START 0x08   
#define ReSTART 0x10   
#define MT_SLA_ACK 0x18   
#define MT_DATA_ACK 0x28   
   
#define MR_SLA_ACK 0x40   
#define MR_DATA_ACK 0x50   
#define MR_DATA_NACK 0x58   
   
#define SLA_W 0xA0   
#define SLA_R 0xA1   
#define ADDRESS 0x00   
#define DATA 0x55   

void Error () {
//	unsigned i = 0;
//	for (i = 0; i < 3; i++) {
//		set_bit(PINB, 0);
//		_delay_ms(500);
//		clear_bit(PINB, 0);
//		_delay_ms(500);
//	}
//	clear_bit(PINB, 0);
}

void i2c_start () {
	// start
	TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN);
	while (!(TWCR & (1<<TWINT)));
	if ((TWSR & 0xF8) != START) return Error();   
}

void i2c_stop () {
	TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);
}

unsigned char i2c_write (unsigned char data) {
	TWDR = data;
	TWCR = (1<<TWINT) | (1<<TWEN);
	while (!(TWCR & (1<<TWINT)));

	switch (TWSR & 0xF8) {
		case MT_SLA_ACK:
		case MR_SLA_ACK:
		case MT_DATA_ACK:
			return 1;
		default:
			Error();
			return 0;
	}
}

void display_write_instruction (unsigned char address, unsigned char data) {
	i2c_start();
	i2c_write(address);
	i2c_write(0b10000000);
	i2c_write(data);
	i2c_stop();
	_delay_ms(1);
}

void display_write_data (char* string) {
	unsigned int i = 0;
	unsigned int len = strlen(string);

	display_write_instruction(0x7c, 0b00000001);

	i2c_start();
	i2c_write(0x7c);
	i2c_write(0b01000000); // Co=0 RS=1

	for (i = 0; i < len && i < 8; i++) {
		i2c_write(string[i]);
	}
	i2c_stop();

	_delay_ms(1);

	i2c_start();
	i2c_write(0x7c);
	i2c_write(0b10000000); // Co=1 RS=0
	i2c_write(0b11000000); // set ddram address to line 2
	i2c_write(0b01000000); // Co=0 RS=1
	for (; i < len && i < 16; i++) {
		i2c_write(string[i]);
	}
	i2c_stop();
}

void display_init () {
	TWBR = 0x24;
	TWSR = 0b00000001;
	TWCR = 1<<TWEN;

	display_write_instruction(0x7c, 0b00111000); // function set to 0 (default)
	display_write_instruction(0x7c, 0b00111001); // function set to 1 (extended)
	display_write_instruction(0x7c, 0b00010100); // internal osc frequency
	display_write_instruction(0x7c, 0b01110000); // contrast set
	display_write_instruction(0x7c, 0b01010110); // power/icon/contrast control
	display_write_instruction(0x7c, 0b01101100); // follower control
	_delay_ms(300);
	display_write_instruction(0x7c, 0b00111000); // function seto to 0
	display_write_instruction(0x7c, 0b00001101); // display on/off control
	display_write_instruction(0x7c, 0b00000001); // clear all

	_delay_ms(10);
}

ハマり

ハードウェアが絡むコーディングは、一度ハマると

  • 配線ミス
  • コーディングのミス

のどちらで発生しているかの見極めができないとかなりつらい…… 配線ミスはあってはならないので、最初の段階でよくよく確認しておかないとあとあとつらい。どんなに確認しても確認したりないぐらい確認する必要がある。あと配線後は必ずテスターをあてたほうがいい……

USB コネクタのピンの半田付けを適当にしすぎたせいで、試している最中に1本がはずれて通信できなくなるということがあった。こういうアホみたいなことでもコーディングミスを疑ったりすると時間を食ってしまう。

PORTB, PINB

出力を操作したいときは PORTB なのに、PINB と書いていてしばらく気付かなかった。この場合、微妙に出力されたりされなかったり、みたいな不安定な挙動になって、全く動かないわけでもないのでなかなかコーディングミスであることに気付けない。

Mac 環境で Ruby + libusb を使って HID デバイスを操作する

最初は feature レポートだけでごにょごにょしていたのでよかったけど、インタラプト転送をしようとしたところで、claim_interface が ERROR_ACCESS エラーを出して止まることがわかった。ググった感じだと、HID デバイスの場合、そのへんの処理を OS のドライバが握っているため、ユーザレベルだと直接扱えないらしい。

とりあえずどうしようもないっぽいので、feature レポートだけで情報をやりとりするように変えた。現状のプログラムだとそれでも問題がないっぽい。

2013年 10月 05日

モールスコードを再生できるだけのページ

をつくった。

だいたい、符号って長点短点を可視化して見せてしまっていることが多いんだけど、あれはモールス学び初めの人には害でしかないので、そういったものが一切ない、すなわちそれぞれ音だけ聞けるページが欲しくて、作った。

20wpm 固定で鳴らしてる。Web Audio なので対応ブラウザならスムーズに鳴るし、スマートフォンでも問題なく鳴る。

2013年 09月 30日

最近のモールス訓練

23wpm で文字+数字、数字だけ、文字だけ、をそれぞれ90%なんとかとったので24wpmでやりはじめてる。20wpmだと完全ランダムでだいたい90%前後がとれるようになったけど、普通文だとそれほどとれないので辛い。十分単語に慣れた人なら普通文のほうがとれるみたいだけど、単語に慣れていない場合、普通文のほうが短い符号の文字が多いので頭が追いつかない。

これが、実際に交信になると、テンパってしまって速度が遅くてもほぼ聴き覚えがある符号しかとれなくなる。599BK 式で、余計な符号がほぼ入らなければなんとか交信できる。CQ を出して、呼んでもらう場合、18〜20wpm なら2回コールしてもらえばとれる感じ…… CQ を出している局は 22〜30wpm あることが多いので4回〜6回聴かないと確定できない……

599BK で CQ を出している局を呼ぶか、自分で CQ を出して 599BK に付きあってもらうか、どっちもメリットデメリットがあってつらい。

CQ 出している局を呼ぶ場合

大抵、599BK でやっている局は JCC サービスなので、パイルになってることが多い。この場合、こちらからの電波が相手に十分届いているか、ある程度パイルが捌けるまでわからないので、非常に効率が悪い。

コールサイン、JCC などまで聴きとった状態で呼ぶので、ほぼ聴きとる必要がなくて気は楽だけど、何か想定外のことを打たれた場合、速度が早くて返せないので、その点で緊張する。

自分で CQ を出す場合

まず第一に、相手にメリットがほぼない (こちらのロケーションは政令指定都市なので別に珍しくもないし)。なおかつ、18wpm 程度で CQ を出すと、相手はラバースタンプ程度の長さを期待する (と思われる) ので、599BK で終わらせると偲びない。

ちょっとやった感じだと、相手の QTH が JCC/JCG で送られる場合、案外聴きとれるけど、それ以上に何か送られるとつらい。なのでだんだん申し分けない心持ちになってくる。

今後の予定

とにかく結構辛いんだけど、CQ 出している局を呼んで、自分のコールサインが呼ばれたとき結構嬉しいのがいい。電波届いたのも嬉しいし、「あっおれだ」っていうのが分かるのも嬉しい。

訓練は続けつつ、599BK であっても CQ を出すのに慣れるのがいいかなあとは思ってる…… けどほんとメンタルが弱すぎて聞きとれるものも聞きとれない。メンタルを強くする方法はわからないので、とにかく聞きまくって慣れるしかないかなと思う。それまで続けられるか心配。

2013年 09月 26日

HTML5 Web Audio でモールスを解読する

というのをちょっと前に作ったけど日記に書いていなかった。

デモ (音アリじゃないとよくわからない):

デフォルトだと、信号がありそうなところを適当に追跡してデコードする。上のスペクトラムをクリックで、その周辺の周波数領域のデコードだけをするようになる。一度に1つのデコーダーだけが動く。

何もハッシュをつけない場合マイク入力からになる。あと Chrome でしか見てない。

Web Audio で信号処理

Web Audio を使って、マイク入力を信号処理しようと思うといくつか躓くところがあった。

  • サンプリング周波数を指定できない
  • AnalyserNode を任意のサンプリングタイミングで呼ぶことができない?
    • あとサンプリング周波数が指定できないので分解能に限界がある

モールスのデコードに高いサンプリング周波数は必要ない。しかしサンプリング周波数は Web Audio 側で固定になっているので、自力でダウンサンプリングしている。これは ScriptProcessorNode の onaudioprocess を使い、Float32Array にリングバッファ状に落としこんでる。なんかもっといい方法ありそうだけど、わからなかった。

まだ onaudioprocess の挙動が不安定で、データがこなくなったりすることがある。毎回 onaudioprocess に対してコールバックを代入しなおしたりいろいろやったけど、最近直ったような気がしないでもない。

FFT も AnalyserNode のを使うのではなく、このダウンサンプリングした信号に対し、JS レベルで実行してる。これは dsp.js を使ってる。

モールスデコード部

それなりに工夫して作った。最初のころ Description of RSCW's algorithms というのを見つけてよく読んでみたけどよくわからないことも多くて、僕でも実装できる程度に落としこんで結局以下のようになってる。

  • 適当にデコードしたい周波数を決める
    • 直近で信号強度が強い周波数
    • または手動 (スペクトラムをクリック)
  • その周波数に対し、2位相ロックインアンプ相当の処理をする
    • 本当に単純にその周波数の矩形波を90°ずらして合成してローパスフィルタにかけて、、というのをナイーブにやってる
  • 適当に閾値を決めて2値化する (むずかしい……)
    • ここまでで 0/1 になる
  • 0 の連続または 1 の連続のうち、最小の長さを見つける (モールスの符号単位)
  • 符号単位の2倍以上なら長点、そうでなければ短点として表から符号をデコードする

デモのようなホワイトノイズ + それなりの強さの信号でかつ、機械的に綺麗な符号なら、結構いい感じにデコードできるけど、実際の交信だと思ったより厳しい。

  • SN比がもっと悪い。フェージングで信号強度がよく変化する
  • 符号が綺麗なことが少ない

なので、なんらかの統計的な、機械学習のような要素を入れこんで (隠れマルコフモデルとか?) やりたいけど、そのような技術力がない。あと、別に全域常時 FFT して全チャンネル同時デコードとかも、ギジュツリョクがあればできるだろうけど、できてない。

2013年 09月 07日

モールスの入門本

モールスの学習はヘタな入門本を買うよりもThe Art and Skill of Radio-Telegraphy (PDF 和訳: 無線電信の巧みと技)を読むべきだと思った。2版が和訳されて公開されていて簡単に読むことができる。すごく気を使って書かれていて、何度読んでもおもしろい。モールスに限らず、技能修練に関する習慣付けについて発見があって素敵だと思う。

この本は初版1992年 (21年前!)、非商用に限り再配布自由、というようなライセンスになっている。著者は残念ながら2003年に亡くなってしまっていて電信を覚えてこの人と交信しようというのは叶わない。

2013年 08月 29日

モールス学習 進捗

20wpm/10wpm でレッスン40まで行ったあと、20wpm/11wpm から 20wpm/18wpm まで徐々にあげてみてる。調子がいいときと悪いときとで全然正確さが違う (70%〜90%) ので、いかんともしがたい。いまいち、ちゃんと成長しているという実感がない。

実際の交信も聞くだけ聞いて、とにかくコールサインだけでもとろうとやっているけど、まず一発ではとれない。ないしは複数回聞いてもエリアまでしかわからないことも多い。ただ、送信側が気をつかってコールサインのときだけ文字スペースを長めにしてる場合があって、これだと1発でとれたりする。しかしコールサインがとれても本文が殆どとれない。599 5nn とか、交信終了時の E E は特徴があるのでわかるけど、BK あるいは K、もうっかりしてると聞きのがす始末。

実際、プレーンテキストを 15wpm/15wpm で聞いてみると、60〜80% 程度しかとれない。プレーンテキストの場合、E S T I など短い符号が頻発するので、難易度が増すように思う。とにかく聞き慣れるしかなさそうだけど、結構萎える。

2013年 08月 22日

なぜ今僕がモールスを学習するのか

僕はベースとしてコミュニケーションに興味がある、というのがまずあって、そのためウェブサービスでも CGM 的なサービスが好きだったりするわけです。

一方僕はコミュニケーションというのが滅法苦手というか嫌いでもあります。ただそれは「現状あるコミュニケーション手段」が嫌いなだけであって、コミュニケーション自体は好きなのだと感じている。なので、何らかの「良いコミュニケーション手段」が発明されることを願ってる。

お互い良く理解しあうことは良いことで、そのためには「厚い」コミュニケーション手段が必要だ、と信じられている。インターネットによって、コミュニケーション手段は結構大変に「厚く」なったきたわけですが、根本的にそれが良いことなのかどうなのか、どうも疑問が沸いてきた。何もかも全部お互いに解りあえればそれは良いことだろうが、実際はそんなこと不可能であるし、むしろ中途半端に厚いコミュニケーションで「分かった気になる」ことの害を感じる。

そういうインターネットのコミュニケーションの厚さに対して、薄いコミュニケーションであるモールス通信に興味がでた。モールスは毎分100字ぐらいが標準というぐらいに通信速度が非常に遅く、少しのことを伝えるにも大変な時間がかかる。そのため、電文は極力「完結」「短縮」に重きをおかれている。このような通信手段で「ゆっくり」コミュニケーションするのはどんな気持ちなのだろう?と思った。

とかいうのは特になくて、単にお盆近くになって、通信兵だったじいさんが帰ってきただけだと思う。

2013年 08月 20日

モールス最初の一歩

モールスの練習をはじめて20日ほど経った。LCWO.net のレッスンをまずは一通り (1文字ずつ増えていく、41文字40レッスン) 終わらせることを第一目標としていたがなんとか終わった。ただ、符号速度 20wpm に対しワードスペースが 10wpm 程度なので、今度はワードスペースを狭くして続けていく必要がある。実感としても、最初のほうにやった符号や、わかりやすい符号 (Y、F、L はわかりやすい) は瞬間的にとれるぐらいになっているけれど、数字や数字とまぎらわしい V J Z あたりの符号が苦手に感じている。しかしやりはじめる前に比べると雲泥の差で符号が聞こえてくるようになった。

さて、実はレッスン36をクリアしたあたりでリグ (無線機) を買ってしまっていた。結局、FT-450DM を買った。50MHz 以下にしか出れないのが逆にいいかもしれない、と思った (そもそも最近は 144MHz, 430MHz には人がいないらしいけど)。秋葉原に行って値段を聞いてみたら思ったより安くて (家電とかと違って実店舗のほうが安い…)、ざくっと一式買ってしまった。

Vertex Standard スタンダード HF/50MHz オールモードトランシーバー FT-450DM(HF・50MHz/50W) - YAESU

YAESU

3.0 / 5.0

アンテナは UHV-6、あまり店舗で売ってないみたい。調整が面倒なアンテナだから?

Comet UHV-6 HF/50/144/430MHzマルチバンド UHV6 - コメット

コメット

3.0 / 5.0

アンテナ基台はとりあえずモービル用のやつを買って、M-5DL をつけてみてるけど、長いアンテナなので安定しなくて失敗だった。ベランダ用のマストを注文中。

ケーブルは 5D-2V を 10m ぐらいと、MP-5 を別途買って自分で適当な長さのを作ってる。ただ、エアコンの穴が使えない感じなので、ウィンドウスルーケーブルを別途買って中継に入れてる。

Comet CTC-50M COMET コメット ウィンドウスルーケーブル - NICOCO

NICOCO

3.0 / 5.0

電源は DM-330MV、特に悩むところがない。32A とれて、スイッチングだけどノイズもそうでもないと定評がある。比較的軽い。

アルインコ DC/DCコンバータ スイッチング式 32A DT-830M - アルインコ(Alinco)

アルインコ(Alinco)

3.0 / 5.0

SWR 計 (SX20C) も一応、一緒に買っておいた。ほんとは四角いやつが良かったんだけど、四角いやつは最低測定電力が6Wからで、5W から測りたい気持ちを持っていたのでやめた。クロスニードルタイプだと校正がいらないらしい。

第一電波工業 ダイヤモンド クロスニードルSWRパワー計 SX20C - Diamond Multimedia

Diamond Multimedia

3.0 / 5.0

ダミーロードは DL-50A。最初とりあえずいらないかと思ったけど、ケーブルがちゃんとしているかとかの測定にも使うし結局買った。

第一電波工業 ダイヤモンド ダミーロード DL50A - ダイヤモンドアンテナ

ダイヤモンドアンテナ

3.0 / 5.0

そしてパドルに GHD GN507 を買った。かなりかっこいい。しかしだいぶ高級品であるので、自分には過ぎたものだ。

 -

3.0 / 5.0

とりあえず買ってすぐ、技適シールを眺めながら電子申請をした。免許がくるまで電波を出せないので、アンテナの調整はできない。受信とエレキーの練習をして遊んでる。楽しい。

備考だけど、電子申請 (総務省 電波利用 電子申請 届出システム Lite) は Google Chrome だと「電波の形式並びに希望する周波数及び空中線電力」の項目以降に進めないので要注意だった (最低である)。Windows 起動して Internet Explorer でやったらうまくいった。Firefox に対応してるって書いてあるけど、終わってから気付いたので試していない。ほんとに対応してるのかな?

実際電波を出せるまでの道程がそこそこ長い。免許がきたらアンテナを調整しつつ、インターフェアが出ていないか慎重に確認しながら出力をあげたり、対策をしたりする必要がある。リグを置いているまわりにかなりノイズ源が多いので、電源ラインにフィルタも必要そうだと思う。結構めんどう。