JG1VGX

Philips HQ482 バッテリ交換

2020-12-30T13:49:00.004+09:00

年末年始の mission #1、古いシェーバ（ひげ剃り）の充電池交換に挑戦！

これは相当古いもので、現在ほとんど充電できず、ACケーブルをコンセントに差し込んでようやく弱弱しく使える程度でした。見た目がキタナイのはご容赦を。

筐体は特殊な六角ネジ（T8）１個で閉じられているだけでした。専用ドライバでネジを取り外し、プラスチックの爪を折らないように注意しながら筐体を開けます。

なんと、★1997年製★でした。よくも23年も捨てずに置いてあったものだ。基板は見るからに古いけれど、電解コンデンサの液漏れもありません。

ちなみに、矢印の上に見えるDIP IC（PHILIPS製）は、マイコンとかそんな上等なものではなく、100～240Vの商用電源に対応するバッテリ制御用のICのようです。

充電池はNiMH電池で、電極はラグで基板に半田付けされています。あらかじめ同一規格（1.2V、2200mAh）の代替電池をinternetで入手（税込300円）してありました。

基板を裏返し、バッテリの電極ラグのランドから吸い取り機を使って半田を吸い取り、ラグを起こします。

無事取り外せました。入手した新しい電池が外観的にも全く同じサイズであることを確認したので、基板に装着します。（＋極の茶色いのはただの保存用保護カバーです）

とても綺麗に換装できました！！

この後、筐体を閉じてシェーバの快調な動作を確認しました。充電できない電池のままACにつないで使うよりも全然力強い回転です。きっとこのシェーバは交直両用ではなく、充電専用だったのでしょう。

それにしても、このシェーバが自分と「23年間」もの人生を共にしたとは・・・、振り返ると感慨深いです。23年振りに元気を取り戻したこのシェーバのように、私もこれから頑張りたい！！

（免責事項）

シェーバの内蔵バッテリを自分で交換することは、ご自身の責任において行ってください。メーカも筆者も責任を持ちません。

QRQ (モールス・トレーナ by DJ1YFK) のご紹介

2015-12-21T00:18:00.000+09:00

先般の CQ WW CW Contest の惨敗に打ちひしがれたワタクシは、その原因が自分の普段のCW練習不足にあることを強く認識し、初心に帰り Morse trainersで練習をやり直すことにしました。

Morse trainersといえば、実戦形式の Morse Runner や Pileup Runner（いずれもVE3NEA作）が有名ですが、Morse Runnerは以前あった High Score table が（本日現在）何かの事情で無くなっています。順位表に自分のcallsignが載るのが楽しみなので、これは大変残念です。

一方、純然たるtrainer（早聞き練習）形式では、昔からある RufzXP（Vista/7/8/10でも問題なく動く）に加えて、JI0VWL作の CW Freak .NET が人気です。

RufzXPのToplistは、年齢・性別毎に部門が分けられていたり、顔写真が見られたり面白いのですが、反映が即時ではない（週1回更新とのこと）のと、やってみるとわかりますがscoreの送付がちょっと面倒です。Scoreはe-mailで送るのですが、Gmail使いの私の場合、「Use a Webmail service」を選んで、cut & pasteして送るしかないようです。（SMTP serverを指定する方法は、最近のSMTP serverは殆ど全てSSLかTLSなど使用していますが、RufzXPではuser/passwordを平文でしか送れないようで駄目でした。）まあこのscore送付が手動であることと、反映が即時でないことを除けば、RufzXPは特に問題はありません。

CW Freak .NETはscore送付がmenuから簡単に行える上、順位表もmenuからもweb上でもどちらでも見ることができます。特に面白いのは、順位表がAll Time/This Year/This Monthの３つに分かれていることでしょう。

QRQ by DJ1YFK

いろいろ検索していたら、別のtrainerを見つけました。作者のDJ1YFKはRufzXPのToplist上位にとんでもない高scoreを載せている強者です。

このsoftwareは見る限り2007年頃から開発されており、最新版は0.3.1（2013年1月）です。

上の画像はMac版ですが、このsoftwareは何とWindowsでもLinuxでも動作します。作者のsiteにはsourceもあるので、他のplatformでもきっと動かせるでしょう。

Installationは簡単ですから、詳しい説明不要と思います。

WindowsではいわゆるDOS窓で動きます。

日本語環境ではこんなふうに文字化けしてしまいます。枠線に1バイト文字（0x80～の高byte）が使われているからですね。動作には全く問題がないので、見た目を気にしなければこのままでいいと思います。

気になる方は、「地域と言語」control panel（intl.cpl）を開いて、「管理」tabの「Unicode対応でないプログラムの・・・」を「English（United States）」等に切り替えて再起動すると、枠線の文字化けは無くなります。但しこの操作を行うと、他のsoftwareの動作に影響を与えることがあります。

このsoftwareは一言で言うと、「RufzのLinux移植版」として開発されたものと思われます。使ってみると分かりますが、競技rulesはRufzXPと殆ど同じです。でも何故か、score計算方法は違うようで、RufzXPの数倍のpointsになります。

使い方はそれほど難しくありません。

F5 ... 設定画面へ

設定画面内の操作keyは、項目の右側に表示されています。

F2 ... 設定を保存

これを忘れないように。後述するqrqrcというfileに保存されます。

F10 ... 設定画面を抜ける。あるいはprogramの実行中止、終了。

また、実行中に使うF keyで大事なのがこれ。

F6 ... callsignの再送。

ただし1回だけです。得点は半減されます。

この「F6再送」はRufzXPにもある機能です。速度50wpm～の領域では必須かも。得点が半減されても、0点よりマシです。（CW Freakには再送機能はありません。）

ToplistへのScore送付方法

そんなわけで、このsoftwareをいたく気に入ったのですが、Toplist へのscore送付がどうすればいいのかが分かりませんでした。一応解決したので、作者の意図した方法かは分かりませんが、解説してみます。

作者のsiteには、設定（qrqrc）と得点順位表（toplist）はlocalの「.qrq」directory配下に保存されるとあります。しかしWindowsの場合は、このようなfolderは作成されません。隠しfolderでもありません。

調査したところ、Windows XP以前の場合は、Program Files配下の、QRQがinstallされるfolderの中にありました。

そして、作者はqrqscoreというPerl scriptでscoreを送付すると言っていますが、このscriptは見つかりません。そこで、Download siteのsource filesの中から持ってきます。

上記を参考に、「～.tar.gz」というsource filesをdownloadし、7-Zip等で解凍してください。その中に、「qrqscore」というPerl scriptが見つかるはずです。

ところが、普通のWindows usersの方は、Windowsの中にPerlなど入っていない筈です。これからWindowsにPerlを入れます。それが何を意味するか分からない方、不安な方は、ここで読むのを止めて、scoreをToplistに送付するのは諦めてください。（まあ、Javaを入れるようなものだと思えばよいのですが・・・。）

Windowsに入れるPerlとしては、いくつかありますが、Active Perlが良いと思います。無料です。指示通りにinstallしてください。何の設定も不要です。Install後、Perlが使えるようになります。

Windows XPの場合

比較的簡単です。Source filesの中から取り出した「qrqscore」fileを、Program Files配下の
QRQがinstallされたfolder（つまりqrqrc、toplistと同じ）に置きます。

そして、command promptを開き、そのfolderに移動し、

C:\Program Files\qrq> perl qrqscore -u

とtypeするだけです。成功すると、自分のhigh scoreとmergeされた新しいtoplistがsiteからdownloadされます。

Windows Vista/7/8/10の場合

QRQがinstallされる Program Files (x86)\qrq には確かにqrqrc、toplistがありますが、これらは全く更新されません。

実は、XPからVista以降に移行した際のからくりで、有名な事ですが、本来 Program Files (x86)\qrq 配下にあって更新されるべきqrqrc、toplistは、

C:\Users\{ユーザ名}\AppData\Local\VirtualStore\Program Files (x86)\qrq

という深いfolderの中にあります。ここにXPの場合と同様にqrqscoreのPerl script fileを置いて実行すれば良いわけです。

ただしいちいちcommand promptを開いてそんなところに移動するのは面倒ですから、下記のようなbatch scriptを書いてDesktopに置いておきましょう。File名は「QRQ_update.bat」とでもします。中身は、

cd C:\Users\{ユーザ名}\AppData\Local\VirtualStore\Program Files (x86)\qrq
perl qrqscore -u
exit

この3行だけです。このbatch fileをdouble clickすると、scoreが本家siteに送付され、即時で更新されます！

Debian Linuxの場合

APTのrepositoryの中にqrqがありますので、installationは簡単です。Terminal windowを開いて「qrq」で起動します。またqrqscoreもinstallされておりまして、

$ qrqscore -u

とtypeするだけでscoreがToplistにpostされます。

LinuxやMacの場合は、普通はPerlは元から入っているので心配ありませんね。

「LWP::UserAgent が無い」と言われた場合は、libwww-perl packageをinstallしてください。

Mac OSの場合

Installationはdmg fileを解凍してApplication folderに入れるだけなので簡単ですが、私の経験では再起動するとpathが変になるのか、qrq.appをdouble clickしてもerrorが出てQRQが起動しなくなることがありました。そういう場合は、再度dmg fileから解凍したqrq.appを上書きすれば大丈夫です。ちょっとした問題ですが、次版で改良されるとよいなと思います。

Mac版binaryにもqrqscoreは含まれておりまして、下記にあります。ただしLinuxと違い、pathが通っていません。

/Applications/qrq.app/Contents/MacOS/qrqscore

qrqrcやtoplistはLinuxと同じくuser directoryの「.qrq」配下にあります。特に指定しなくてもqrqscoreを実行するだけでtoplistは更新されます。Pathが通っていないqrqscoreを実行するには、aliasかscriptを使って下記を実行するようにすれば楽です。

/Applications/qrq.app/Contents/MacOS/qrqscore -u

まとめ

Terminal console上で動作し、Windows/Mac/Linuxのいずれでも動くのは大変良いです！WindowsでもPerlが必要であるとか、Score posting方法に改善の余地はありますが、Toplistへの即時反映は嬉しく、CW Freak .NETと並んで、しばらく病み付きになりそうです。

CQ WW CWのcondition（結果）

2015-11-30T12:00:00.000+09:00

先週のpost「週末のCQ WW CWに備える」で、conditionを占いましたが、実際の結果をdataと共に提示しておきます。来年にもきっと役立つはず。予想と比較してみてください。

今年（2015）の結果

地磁気の状態はこんなでした。（図はクリックで拡大、以下同）

ほぼK≦3とはいえ、完全には静穏とは言えず、特に後半にかけてはやや不安定な様子があります。月曜の朝はK=4に上がっていたんですね。

当blogではもうお馴染みの解析、日本と欧州/北米間のRBN spotsをViewProp（ZL2HAM）で時系列に図示してみました。

1日目（2015/11/28） SFI 96, SSN 36

2日目（2015/11/29） SFI 95, SSN 47

先週も書いたように、この時期（11月末）、東京では、日の出 6:30JST（2130z）、日没 16:30JST（0730z）、南中 11:30JST（0230z）です。

太陽指数は予想通り？下がってしまいました。10mはしんどかったですね。

感想

北米方面high bandsは（日本時間）土曜朝は10mはだめだめ、日曜朝は意外に良くて、月曜朝は今一つでした。
欧州方面hihg bandsは、両日午後とも10mは殆ど開かず、15/20mがmain bands。特に日曜は夜遅くまで20mが開けていたことがわかります。
Low bandsとくに40mは両日とも北米/欧州とも長時間に亘って開けまずまずでしたので、antennasさえ良ければ楽しめたのではないかと思います。

週末のCQ WW CWに備える

2015-11-25T20:37:00.001+09:00

昨年（2014）の状況は？

地磁気は下図の通り比較的静穏でした。（図はクリックで拡大、以下同）

日本と欧州/北米間のRBN spotsをViewProp（ZL2HAM）で時系列に図示してみました。

1日目（2014/11/29） SFI 177, SSN 156

2日目（2014/11/30） SFI 177, SSN 153

この時期（11月末）、東京では、日の出 6:30JST（2130z）、日没 16:30JST（0730z）、南中 11:30JST（0230z）です。

昨年はSFI 177もあったなんて、condition良かったんですね。どうりで10mが開けるはずです。

で、今年は確実にconditionが下がっています。

それでもCQ WW SSBの時（10月末、SFI 106、SSN 63~74）は少しは10mが使えました。この原稿を書いている現在（11/25）、SFI 112、SSN 66です。これ以下に下がりませんように！今のところflares/CMEsも発生しておらず、太陽活動も安定しているようです。

最近のcondition

2015/11/19（木）～11/25（水）までの最近一週間のRBN spotsを積算して、上と同様にplotしてみました。太陽指数は SFI 108~122、SSN 51~77 でした。

一週間を積算しても、CQ WW contestsと比べればspots数がかなり少なく、ギザギザになりますね。大体の傾向と見ていただければと思います。

週末の戦略

Time tableで考えてみました。自分用です。

UTC	JST	戦略	備考
0z~	9~	15mで北米run開始、呼ばれる限り続ける。（早ければ30分で枯れる？）　呼ばれなくなってきたら20mに下りる。　20mは早ければ2z、遅ければ4:30z頃枯れる。	10mが使える可能性は少ない
2z~	11~	一番暇な時間帯。	飯食う、寝る、ひなたぼっこ、等。
4z~	13~	10/15mほぼ同時にUA9/0聞こえ始めるので、行ったり来たりしてslow pacedにさばく。
6z~	15~	欧州が10/15mで本格的に開け始める。
7z~	16~	16:30JSTの日没前後が10mのpeak。15mのpeakは30分ほど遅れるがほぼ同時。
8z~	17~	17:30JSTにはほとんど10mは閉じるので、15mに下りる。　もう40mで北米も開いている。
9z~	18~	18JST頃には15mにも見切りをつけて20mに下りたほうがよいだろう。
11z~	20~	この頃には欧州20mも閉じる。　北米がgray lineに差し掛かるので40/80mを~0JST頃まで徹底的に。	北米gray lineは4hrsくらい掛けて遷移する。
15z~	0~	北米のgray line終了。欧州40mが聞こえ始めるかもしれないが、聞こえていないかも。二番目に暇な時間帯。	ちょっと休憩。
16z~	1~	欧州向け40mをダラダラと3JST頃まで。	低rateの忍耐の時間帯。
18z~	3~	早ければ欧州80mが聞こえるかも？？　聞こえなければ40m続ける。
20z~	5~	JAのgray lineなので、欧州80mに賭ける！	5:30JST頃から北米20mも開き始める。
21z~	6~	80mは6:30JST頃まで、40mは7JST頃まで可能性があるが、ダメなら諦めてhigh bandsへ。この時間帯は各bandsのcheckが忙しい。	北米20mもmultiとしては貴重なので、15mが開くまでは少し粘ってみる？
22z~	7~	北米15mのrun開始。10mが使えれば早めに上がる。10mが息切れるまではrunし続ける。	22~1zの北米runは最高のrateを叩き出す時間帯。
23z~	8~	10mにどこかで見切りをつけて15mに下りる。	10/15mのpeakはほぼ同時。

なお、contest用にHF帯伝播状況の実況中継を行っています。
スマホ・タブレットから見るには、http://prop.jg1vgx.net/ をbookmarkしておくと便利です。指でpinchして見やすい大きさにして御覧ください。

SparkFun Geiger CounterのArduino化

2015-01-10T12:00:00.002+09:00

先日設計上の不具合を何とか改修する事が出来たSparkFunのGeiger Counter SEN-09848だが、software（firmware）も製品購入時には非常に単純な物しか入っておらず、時間線量の算出・表示すら出来ない。

折角直したので、これを機会にいろいろprogramを書いて遊んでみたいので、ひとまずArduino化することにした。

ICSP pinheadersの取り付け

本品にはご覧のようにprocessorとしてATmega328P（flat package）、USB-TTL変換としてFT232RLが使われている。買った状態ではICSP端子にpin headersはついていないので、まず下図のように取り付けた。1番pinには細い線でmarkingされている。

ATmega328Pには外部発振子が付いていないので、内部RC発振を利用しているようだ。

さて、ICSP端子からbootloaderやfirmwareを書き込むには、ISP用のprogrammerが必要である。専用で安価なAVRISP mkII（3,200円@秋月電子）をお勧めしたいが、持っていなければ別のArduinoにISP用のsketch（Arduino IDEに付属）を入れてprogrammerにする方法や、FT232Rから必要な端子が出ていればFT232R Bit Bangingという方法でprogrammingする事も出来る。詳しいやり方は他所で解説されているので、「Arduino ブートローダ書き込み」等で検索してみてください。

本品はFT232RLを使用してはいるものの、Bit Bangingに必要なCTS、DSR、DCD、RIが結線されていないので、本品のFT232RLを使ってのBit Bangingは出来ないと考えた方が良いだろう。やるならCTS、DSR、DCD、RI端子が出ている別のFT232R搭載Arduino等を持ってきて、本品のICSP端子に接続して使う形になる。

なおICSP端子にはVCC/GND線も有りますが、AVRISP mkIIはここからtargetに電源を供給しません。逆にtargetが通電しているかどうかの検出に使っているようです。従って、targetには別途（本品の場合USB端子から）電源を供給して下さい。

Fuseの設定

早速programmerを繋いで、SEN-09848の購入時のfuseの状態を調べてみたところ、次のようだった。

Extended	0xF8 (0x00)
High	0xDF
Low	0xE2

なお拡張byteの3～7 bit目は使用されていないので、そこが1と見れば0xF8、0ならば0x00という事である。書き込みsoftwareにより、未使用bitsの表現が異なっている事がある。

AVR processorのfusesは「ONが0、OFFが1」と、通常とは逆になっているので、設定変更時十分注意しよう。間違ったfuse設定を書き込んでしまうと、AVR processorが2度と使用できなくなる恐れがある。

こちらの便利なsiteで上記bitsを解釈すると、fuseの状態は次の様になっていることが判る。

内蔵 RC回路 8MHz 発振、起動遅延時間 65msec
Boot用flash領域 256words、Boot Reset Vector OFF
電圧降下検出 VCC=4.3V ^(*)

^(*) なおここの拡張byteにある電圧降下検出（BODLEVEL）のbitsは間違っていて、本来有り得ない組み合わせになっている。

さて、bootloaderを使用するため、fusesを書き換えてみよう。筆者はAtmel Studio 6.2（旧AVR Studio）とAVRISP mkIIの組み合わせで行った。

Optibootを使用する予定なので、BOOTSZ = 256W（512bytes）のままとし、clockの設定（SUT_CKSEL）も変更しない。変更するのは、下記2箇所のみとした。

BOOTRSTをON（0）に（bootloaderを使用するのだから当然）
BODLEVELを2.7Vに（変更しなくても良いが、正しい値にしておく。他の値でも良い）

他のbootloaderを使用する場合は、sizeに合わせてBOOTSZを調節して下さい。そのbootloaderを使用しているboards.txtの項目を参照し、fuseの設定やupload.maximum_sizeの値からbootloaderのsizeが推測できます。（32768や16384といった値からupload.maximum_sizeを引いてみます。）

先程も述べたように、絶対に間違ったfuse設定を書き込まない事。特に、外部発振の設定にしてしまうと、Ceralockや水晶発振子を（flat packageに！）外付しないと動作しなくなり、programmerによるaccessも出来なくなります。またRSTDISBL、SPIENも絶対に変更してはいけません。

間違いが無い事をしっかり確認できたら、上記fusesの値を書き込み（Programし）ます。

Bootloaderの書き込み

Fusesの次はいよいよbootloader本体の書き込みです。まず、Optibootの開発siteから最新版v5.0aをdownloadしてきます。Desktopに解凍し、その中の「optiboot_atmega328.hex」というのをFlashに書き込み（Programし）ます。

以上で書き込み作業は終了です。ProgrammerからSparkFun Geiger Counterを取り外します。

Arduino IDEの設定

Arduino IDEの個人用Sketchbook location（Preferencesを見ると判ります。通常はDocuments folderのArduino配下）に「hardware」というsub folderが無ければ作って、その下にこのzip fileを解凍して出来た「SparkFun Geiger Counter」というfolderをそのまま置きます。

中に入っているのはboards.txtだけで、その中身はこれです。

##############################################################
# Sparkfun Geiger Counter w/optiboot
# ATmega328P, Int RC Osc 8MHz
##############################################################
sfgeigero.name=[Optiboot] Sparkfun Geiger Counter (8MHz Internal)
sfgeigero.upload.protocol=arduino
sfgeigero.upload.maximum_size=32256
sfgeigero.upload.speed=57600
sfgeigero.bootloader.low_fuses=0xE2
sfgeigero.bootloader.high_fuses=0xDE
sfgeigero.bootloader.extended_fuses=0x05
sfgeigero.bootloader.path=optiboot
sfgeigero.bootloader.file=optiboot_atmega328.hex
sfgeigero.bootloader.unlock_bits=0x3F
sfgeigero.bootloader.lock_bits=0x0F
sfgeigero.build.mcu=atmega328p
sfgeigero.build.f_cpu=8000000L
sfgeigero.build.core=arduino:arduino
sfgeigero.build.variant=arduino:standard
##############################################################

この後、Arduino IDEを起動すると、Tools -> Board menuに追加した項目が現れます。

13番pin LEDの追加

さて早速Blink sketchをuploadしてみたいところなのですが、SparkFun Geiger CounterはPB5、つまりArduino 13番pinにLEDが結線されていません。ですが幸い、このpin（PB5）はSPI clock用としてICSP端子に出ていますので、それを利用します。

つまり上図のようになっていますので、SCK pinとGND pinとの間にLED（と抵抗）を入れればOKです。

このようにすればBlink sketchの動作確認が出来る他、13番pin LEDはRESET buttonを押下した時にもbootloaderの動作で点滅するようになっているので、bootloaderが正しく書き込まれているかの確認にも使用出来ます。

Sketchのupload

さていよいよsketchのuploadです。しかしここにちょっと問題があって、筆者の所有しているSparkfun Geiger CounterのSEN-09848というversionにはauto-reset回路が無いのです。後継のSEN-10742、SEN-11345（現行）にはauto-reset回路が付いています。

Auto-reset回路というのは、FT232RLのDTR端子から0.1uFを介してATmega328PのRESET端子に結線されているだけなのですが、これを追加するのは両ICsともflat packageのため面倒かつかなり見た目が悪くなります。

そこで筆者は手動resetで我慢することにしました。

ところがこのreset button押下のtimingがかなり微妙で、慣れが必要です。

Arduino bootloaderはresetされると、ごく短時間serial通信を待機します。このtimingに丁度うまくArduino IDEから通信の試行が行われるようにしなければなりません。

まず、通信のやりとりを見えるようにするため、Arduino IDEの「環境設定（Preferences）」で書き込み時の詳細表示を選択します。

コンパイル（compilation）の方は詳細表示にしなくても良いでしょう。

Sketchをuploadしようとすると、「Uploading...」の終盤になって次のような橙色文字の表示が現れます。ここがresetのtimingです。

うまくやるためには「Uploading...」の途中からreset buttonを押したままにして、上の橙色文字が見えたらすかさず指を離して下さい。上図のようにmessage領域を大きく広げておくと見易いです。

成功するとdataのやりとりが行われ、uploadが無事完了します。

これがuploadが成功した時の表示です。またuploadしたsketchに従ってLEDがblinkしていると思います。

Blink sketchのloop内のdelay()値をその都度変更すれば、新しいsketchが動作しているかどうかが判ると思います。またsketch内の「13」pin指定を「A5」に変更する事により、先ほどわざわざ外付したLEDではなく、本体上の「Counter」のLEDをblinkさせる事が出来ます。外付けLEDでの動作が確認できたら、blink sketchをそのように変更し、外付けLEDは外してしまいましょう。

Arduino IDEのserial通信とreset button押下のtimingが合わないとuploadに失敗し、以下の様な表示となります。

「stk500_getsync(): not in sync: resp=0x00」というのが通信の同期に失敗した事を示しています。失敗していても、「Thank you.」「Done uploading.」等成功した時と同じような表示も出る事には注意して下さい。

筆者はbaud rateを他に色々変えて試しましたが、何故か57600bps以外では成功していません。また他のOptibootの.hex filesも用いてみましたが、成功したのはこの「optiboot_atmega328.hex」だけでした。

実際のresetのtimingはかなり微妙（体感では200～300msec位の範囲）ですが、慣れればわりと確実にupload出来るようになります。練習して下さい。

現行のArduinoは殆どauto-resetになっているので、通信待機時間を長く取る必要が無くなり、現行のbootloaderではそれが極端に短くなっているようです。本機のような手動reset用には、きっとbootloaderを再compileして待機時間を長く取るようにすれば良いのかもしれませんが、筆者にはまだその方法が判らないところです。

また先も述べたように後継機種であるSEN-10742、SEN-11345をお持ちの方は、auto-resetに対応していますので、reset buttonのtimingで苦労することは無い筈です。

他のbootloaderを用いる

Optiboot以外でも実はやってみました。本家TutorialのこちらからBreadboard.zipをdownload、展開し、前述の個人用Sketchbook locationのhardware folder配下に置きます。

Programmerを用いて、fusesとbootloaderをそれぞれ書き込みます。

Fuse設定は、Low 0xE2、High 0xDA、Extended 0x05（0xFD）

bootloaderのsizeは1024W（2048 bytes）

bootloaderはArduino IDEに付属の「ATmegaBOOT_168_atmega328_pro_8MHz.hex」

IDEのTools -> Board menuには「ATmega328 on a breadboard (8 MHz internal clock)」という名称で現れます。

試してみたところ、こちらのbootloaderの方がOptibootよりもややtimingに余裕がある感じでした。Optibootでどうしてもtimingが掴めない方にはお勧めかもしれません。なお通信速度はやはり57600bps以外では動作しませんでした。

Arduino化完了！

何とかSparkFun Geiger CounterをArduino IDEで簡単に扱えるように出来ました。

製品版のfirmwareのsourcesはGitHubにあります。取り敢えず、製品に入っていた検知間隔に応じて0と1を出力するだけの非常に単純なfirmware（v12）を、Arduinoのsketchに書き直してみました。

/*
SparkFun Geiger Counter
Official v12 firmware on Arduino

created 10 Jan 2015
by Rin FUKUDA
[email protected]
*/

// Constants
#define LEDPIN A5 // Counter LED (green)

// Variables
volatile long j=0; // Interval since the last count
volatile long jlast; // previous interval
byte cbit; // '0' or '1' for char output on terminal

void setup() {
// pin I/O settings
pinMode(LEDPIN, OUTPUT);

// Interrupts on INT0 (OUT)
attachInterrupt(0, onCount, RISING);

//Initialize serial and wait for port to open:
Serial.begin(9600);

// Wait to settle
delay(1200);
interrupts();
}

void loop() {
// turn off the LED (HIGH is the voltage level)
digitalWrite(LEDPIN, HIGH);
// wait for a short while for counting
delay(30);
j++;
}

void onCount() {
// blink LED
digitalWrite(LEDPIN, LOW);
delay(10);

// check intervals
if(jlast < j) cbit = 0;
if(jlast > j) cbit = 1;

// send byte char to console
Serial.print(cbit);

// reset intervals
jlast = j;
j = 0;
}

たったこれだけです。こちらにも置きました。Sketchをuploadしたところ、ちゃんとArduino化以前と全く同じ動作で検出～countする事を確認しました。Arduino IDEにはSerial Monitor機能が付いているので、別のsoftwareを起動せずに動作確認が出来、大変便利です。

さらに、dotによる簡易bar graphで時間線量（CPM, counts per minute）をserial出力するsketchを書いてみたのでここに置きます。

SparkFun Geiger Counterの改修

2015-01-03T22:00:00.000+09:00

震災の年にback-orderで注文し数ヶ月待って入手してあったSparkFunのSEN-09848というGeiger Counterだが、いざ届いて使おうとする前に、同製品のComments欄で「回路設計に重大な問題があり、そのままで使うと貴重なGeiger管に定格（450～650V）を超える過大な電圧（1,000～1,500V）がかかっている」という事が指摘され、物議を醸していた。

そこではいろいろ回路修正方法が議論されていたが、ともかく修正しない事には使えない代物だという事が判り、少しガッカリするとともに、いつか修正しようとして箱にしまったまま、忙しさに紛れて早3年以上過ぎてしまった。

しかし気になって仕方がなかったので、この正月休みに遂にその修復を試みてみる事にした。

SparkFun Geiger Counterの世代

SparkFunのGeiger Counterは原発事故後に当然ながら注目を浴びたが、これから述べる不具合をusersから指摘されたためその後改版を繰り返している。当方が入手したのは震災当時販売されていたSEN-09848という一番左の物である。

SEN-10742では、見て判る通り真ん中左の高圧印加用のswitchがより耐圧のある適正な物に変更されたが、過大電圧の問題や、後に述べる検出回路の誤りはここでも修正されていない。

現行品のSEN-11345になり、高圧回路には本来あるべき定電圧回路が挿入され（右端に新しく増えた黒い部品がZener diodes）、また検出回路がanode検出からcathode検出に変更され正しいpulsesを拾うようになった。SEN-11345の回路には問題は無いので、これから買われる方は安心して注文されて良いと思う。

一方、SEN-10742迄の製品をお持ちの方は、これから述べる回路修正が必要である。さもないとGeiger管を過大電圧により壊してしまう事になるかもしれない。なおSEN-09848の前にさらに古いversion（SEN-09298）もあるが、当然ながら不具合品である。

問題点

これは主に2つある。

（１）Geiger管に定格（450～650V）を超える高圧（1,000～1,500V）がかかっている。

高圧系の定電圧回路が省略されていることと、恐らく作者が設計時にtesterの誤用により適正な電圧であると誤解した事が原因と推測されている。

（２）検出回路の極性に誤りがあり、適正にpulseを検出できない。

anode検出を採用しているにもかかわらず、NPN transistorでinterfaceを組んでいる。

他にもswitchの耐圧の問題とかあるのだが、省略する。

SparkFunの製品siteのComments欄では主に（１）の問題しか議論されていないが、日本の「がた老AVR研究所」のblogで、（２）の問題とその対策が詳細に解説されていた。

当方は、この「がた老」さんの方法を参考に修正しようと考えていたが、基板のresistを削ったり、遠方から配線を引き回したりという手順がやや複雑に見え、そのまま放置してしまっていた訳である。

修正作業

修正前の状態

それでは修正作業について解説していきたいが、その前に修正前の状況をoscilloscope（DSO Nano v2）で確認しておく。SEN-09848の修正前の検出回路周りは次の様になっている。

OUTがATmega MPUに入る、transistorで整形された（はずの）trigger出力である。

まず、Geiger管のanode出力であるSIGをTP1で見てみる。

これが正規のpulseなのだろうが、高圧過ぎるためか雪崩効果（avalanche effect）が起き、次のような連続pulsesも頻繁に観測される。

実際にはSEN-09848のoriginalの状態では、上の正規pulseの方をcountしているのではなく、下の雪崩効果の連続pulsesをQ4の出力（collector）側の大容量capacitor C9で平滑してOUTに出力しているらしい。TP2（OUT）での観察結果を見てみよう。

このように雪崩効果の持続時間にもよるのだろうが、50～100msecの矩形pulseとなってQ4から出力され、これがATmega MPUに入力されていた。

しかしこれでは、本来のGeiger管のpulsesを計測しているのではなく、「雪崩効果」の数を計測している事になってしまう。そもそも0.1秒なんて長さのpulseは線量計測としてはどう考えてもおかしい。

途中経過

「がた老AVR研究所」の方法が正しいことは最初から判っていたが、blogに記載されているresistを削ったりする方法が面倒に思えてしまい、他の2、3の部品の交換だけで何とかならないか、最初試行錯誤していた。

問題（１）の高圧を適正化する方法は、C2 10uFを 0.5～1uFにすることで良いのだという。まずそれを行い、また検出回路のQ4のcollector側の平滑用のC9を0.33uFに下げてみた。しかしそれではpulseを殆ど全くcountしなくなってしまった。Oscilloscopeで見てみると、まずQ4のbase（TP1）ではこのような物が見られた。

Geiger管のpulseは真ん中の大きなnegative pulseであるが、それ以外に小さな周期性pulse（1.6msec周期くらい）を見るようになった。（なぜこういうのが出るようになったのかは今でもよく分からない。）Geiger管のpulseもovershootがあり、何だか不思議な形だ。

Q4の出力側（TP2）で見ると、それなりにpulseらしい波形であったが、何故かこのpulseではMPUが殆ど全くcountしてくれないのだった。Firmwareのsourceを見てみると、ちゃんとfalling edgeで入力pinをtriggerするようにprogramされているのだが。

最終修正

高圧の修正と平滑capacitorの値の修正だけでは結局駄目だと分かったので、意を決して検出回路の修正もすることにした。

やった事は、「がた老AVR研究所」のblogを参考に、こちらのsiteの「アノード検出方式のインターフェース回路」ほぼそのままに改めたのである。より具体的には、上に引用したSparkFunの回路図上で説明すると、下記のように修正を行った。

Q4 MPSA18（NPN）→ 2SA1015（PNP）に変更
R9 1k → 56k に変更
Q4 Emitter を VCC に配線
SIG と VCC 間に、R 2MとC 100pFを並列に挿入
R10 1k8 は削除
C9 47uF は R 100k に置換

お手本にした回路と少し抵抗値が違うのは、手持ち部品の都合である。

Resistを削るのはやや面倒だから、横着をしてtransistorの脚を1本空中配線して誤魔化した。

この修正により、見事にGeiger Counterとして正規のpulseをcountするようになった。もし「がた老AVR研究所」の記事がなかったら、筆者の知識だけでは到底修正し得なかった事である。「がた老」さんにはこの場を借りて心より御礼申し上げる次第である。

その正常動作を再びoscilloscopeで見てみよう。まずTP1だが、transistorをPNPに変えたためVCC基準で測定した。

先ほどの途中経過での不思議なpulseと違い、美しい正規pulseが入るようになった。周期性の小さなpulse（原因不明）は見られているが、これらはMPUでのcountに全く影響を与えないので気にしないことにする。C2 capacitorを都合で1uFにしてしまったためまだ電圧がやや高いのか2枚めの写真のような連続pulseを時に見ることがあるが、それほど計測に影響はないようである。C2は0.47～0.68uFが良いと思う。

検出transistorを通過したTP2での出力は次のように綺麗な100usec前後の矩形波pulseとなり、ATmega MPUできちんとcountされるようになった。

但しfirmwareではまだfalling edgeで検出するようにprogramされているようなので、rising edgeに修正するのが良いかも知れない。どちらでも同じようにはcountするけれど。

なおSparkFunがSEN-11345で行った検出回路の修正は、Q4はNPN transistorのまま、検出方式をanode検出からcathode検出に変更している。このためOUTでの出力はactive low（negative pulse）であり、falling edgeでのtrigger検出のままでprogram上も問題ない。同じ方式で修正するにはGeiger管周りの回路変更が必要で大がかりになりすぎるため、筆者は「がた老」さんと同じくPNP transistorによる検出方式とした。

あとがき

因みにこのGeiger Counterを設計したAaronという人は、もう転職してしまってSparkFunに居ないそうである。彼（a1ronzo）は最初問題に気付いていなかったようで、製品のComments欄で「電圧も高くないし、製品はずっと正常に動作している」としきりに不具合を否定していた。

このGeiger Counterは元々放射線量計測を目的としたというよりは、乱数発生器として企画された面がある。だから元から入っているfirmwareには時間線量を出力する機能は無く、ただpulseのcountに応じて0か1かを出力するだけの単純なprogram（countの間隔が前の間隔より長い時0、短い時1）となっている。

彼がこのGeiger Counterを設計・販売後に日本の原発事故が起こり、本製品が世界中から注目を集めることになり、結果的に設計ミスが白日の下に晒されることになったのは、彼にとっては不遇だったと言えよう。

日本のmakerだったら、非を認めて製品を無償交換するくらいの設計ミスだと思うが、海外には日本のような「謝罪文化」は無いので、問題点が指摘されても交換は行われないし、買った人もそれを強く要求するわけでもない。

日本人の感覚だとAaronの立場に立たされれば、責任を取って退職したのではないかと思う。

Aaronは途中から設計ミスを認める発言をするようになっていたし、結果的にSparkFunは設計ミスとみられる部分を完全に修正して現行品をreleaseしている。最後の改修品がAaronの手によるものかどうかは筆者には判らない。

筆者は、Aaronは日本人ではないから引責退職したわけではなかろうけど、自身の設計ミスがこれだけ大きく取り沙汰されてしまった事の責任を痛感してはいたと思う。だから彼は転職という形でそれを清算した（早く言えば「逃げた」？）のではないか、というのは上記の改修作業をしながらの筆者の空想である。

WAE SSB @JG1ZUY

2014-09-15T09:00:00.000+09:00

この記録的な悪conditionの事は、後々の為に是非とも記録に残しておこうと思う。

GOES-15衛星で観測された、9月10日に発生した巨大flare。
Plasmaが噴水のように放出されているのが見える。

CME（コロナ質量放出）と磁気嵐

下図（clickで拡大）のGOES-15衛星によるX線観測dataに見るように、9月9日 0z頃にM級、翌10日 18z頃X級flare（CME）が連続して発生していたのだが、今回筆者はこの事を知らずに9月13日（土）に現地入りしてしまっていた。

flareも「横向き」、つまり地球から見て「明後日の方向」に放出された物ならさほど大きな影響が無いが、今回のは最初の写真に見るように、もろに地球側を向いていた。

かくしてplasma流は下図（clickで拡大）に見るようにほぼ48時間かけて地球に到達し、「約束通り」に磁気嵐を引き起こしていた。9月9日 0zのM級flareに対応した地磁気変動は9月11日 0z頃から始まっており、9月10日 18zのX級flareに対応するものは9月12日 15z頃から現れているように見える。

48時間で地球に到達するということは、太陽・地球間距離は約1億5千万kmらしいので、秒速868km/sという速さでplasmaが飛んで来ている事になる。これでも光速の350分の1程度の速さらしい。（「光」は太陽から地球に到達するのに8分20秒かかっている。）

つまりWAEDC SSB Contest前の木～金曜日に、磁気嵐の「絨毯爆撃」を受けていたわけである。事前に宇宙天気をcheckしていなかった筆者は、9月13日の04z頃に仮眠から醒めて無線機のswitchを入れて初めて、このただならぬ事態に気付いた。

Contest開始後、つまり9月13日 00z以降は数値的にはK≦4となっていたが、実際にはその直前のK＝7の状況がかなり残っていて、05z頃でも全く何も聞こえず、06z前になってようやくUA9が聞こえ出し、欧州局をlog inしたのは下記のように20mでは0624z、15mでは0647zになってからであった。

QSO: 14275 PH 2014-09-13 0624 JG1VGX        59 0001   DR1D          59 0315
QSO: 14249 PH 2014-09-13 0625 JG1VGX        59 0002   UA7K          59 0185
QSO: 14180 PH 2014-09-13 0627 JG1VGX        59 0003   PI4DX         59 0012
QSO: 14214 PH 2014-09-13 0628 JG1VGX        59 0004   DF0HQ         59 0265
QSO: 14245 PH 2014-09-13 0632 JG1VGX        59 0005   SK3W          59 0062
QSO: 21253 PH 2014-09-13 0647 JG1VGX        59 0006   IK0PHY        59 0017
QSO: 21231 PH 2014-09-13 0701 JG1VGX        59 0007   HG7T          59 0267
QSO: 21237 PH 2014-09-13 0702 JG1VGX        59 0008   LZ9W          59 0306
........

Conditionが良ければJAでは03z前から強力な欧州局は聞こえるので、こんな事は本当に初めてだった。

Contest中の状況

1日目は結局15mは20局程度しか出来なかったが、その分皆20mに降りてきていたようで、このようなconditionにもかかわらず深夜の20mは比較的好調で200局程度log inする事が出来た。40mは時間も短く20局程度であったが、結局15～40mで合計280局程度で1日目を終えた。

2日目、日曜日の午後からは普段通りに近いconditionで15m（とわずかだが10mを）楽しむ事が出来た。ぐんぐん局数を積み上げる事が出来、1日目の分を挽回すべく飛ばしに飛ばしたが、JSTで日付が変わってからの20m、40mで思うように局数が伸ばせず、残念ながら1000Qには到達出来なかった。

太陽flareは9月11日以降は大きな物は発生せず、2日目はK＝1～0と非常に安定していたと言える。9月14日 03z頃に再びM級flareが発生していたが、これはもちろんcontest終了迄には地球に到達しなかったので問題は無かった。

太陽活動は次の様に比較的活発であったので、地磁気さえ落ち着いていれば良好なconditionだったと思う。

9/13 SFI=145, SSN=165, A=12
9/14 SFI=139, SSN=120, A=2

なお、75mは現在antennaが無く、運用しなかった。

結果

初日は、「もうこれは200局もいかないのではないか？」とさえ思っていたが、例年には明らかに劣るものの、2日目の追い上げで、十分に楽しめた内容となった。

                    WAE DX Contest, SSB

Call: JG1VGX
Operator(s): JG1VGX
Station: JG1ZUY

Class: Single Op HP
QTH: Chiba
Operating Time (hrs): 28.1
Radios: SO2R

Summary:
 Band  QSOs  QTCs  Mults
-------------------------
   75:    0     0    0x4
   40:   59    48   18x3
   20:  431   383   39x2
   15:  440   435   38x2
   10:    5    20    4x2
-------------------------
Total:  935   886    216  Total Score = 392,688

3830 reflectorへのpostはこちらです。

直前condition：AA Phone

2014-09-05T21:06:00.002+09:00

今回は時間がなかったので、手抜きの分析？である。

昨日、2014/9/4（UTC）のRBN raw dataをEU/NA方面にplotしてみた。たった1日分である。

（注）openしている筈のない時間帯にある1～2の孤立spotsはbustedと思われますので、無視して下さい。

朝の北米はダメダメだが、ここ数日停滞していたconditionが回復しているのか夕方の10m欧州方面にも少し期待が持てそうだ。

High bandsの北米は21～23zで頑張るしかなさそうだ。また15/20mが主力bandsである事に変わりはないが、40mも丹念にやった方が良さそうだ。

いよいよ秋のcontest seasonの幕開けか。楽しみである。

AP Sprint #58 (Summer, SSB) 敗因分析

2014-08-28T21:26:00.002+09:00

昨年に続いて参加したAP Sprint「夏の陣」（15/20m SSB）。今年も思うような結果が得られなかったが、昨年同様「一人反省会」を行ってみた。

2014年

6/14 SFI=143, SSN=159, A=6

振り返ってみれば、太陽指数は月周期のpeakに近い時期に当たったようで、比較的良好だった事になる。しかし、参加局数が少ない事もあるが、当日はconditionの良さを実感することは全く無かった。

Contest中（11~13z）ではK=1~2であったが、その前後を見ると少し地磁気は荒れ気味であった事が判る。

さて筆者の今年の成績である。

	15m	20m	Total
Asia-Pacific	18	17	35
Outside AP	9	13	22
Total	27	30	57

Claimedでは57Qsだったが、うち1Qは集中力を欠いてnumberを聞き落としてしまった物があり結果は56Qsとなった。

さて次が公式結果である。15/20mで交信、15mのみで交信、20mのみで交信と色分けした。Check Log局、Log非提出局は最下行に追加した。

Asia-Pacific

CALL       SCORE QSO PNTS MULT (Accuracy)
_____________________________________________________

JA7NVF

2624 64 64 41 (100.0%) *
BV1EL

2560 65 64 40 ( 98.5%) *
RT0F

2405 68 65 37 ( 95.6%) *
E20AX

2016 58 56 36 ( 96.6%) OP E21EIC
JM1NKT

2006 59 59 34 (100.0%)
JG1VGX 1960 57 56 35 ( 98.2%)
JH4UTP

1760 62 55 32 ( 88.7%)
JH6QIL

1643 53 53 31 (100.0%)
UA0DM

1550 52 50 31 ( 96.2%)
JH1EAQ

1428 51 51 28 (100.0%)
RW0UM

1395 47 45 31 ( 95.7%)
JF2IWL

1380 48 46 30 ( 95.8%)
E21YDP

1134 43 42 27 ( 97.7%)
9V1YC

1036 38 37 28 ( 97.4%)
BA3AX

594 29 27 22 ( 93.1%)
RA0LMK

459 28 27 17 ( 96.4%)
JF2FIU 432 24 24 18 (100.0%)
7K1CPT

361 19 19 19 (100.0%)
R0AD/P

266 22 19 14 ( 86.4%)
UA0LS

        208 24 16 13 ( 66.7%)
JE1CWQ       143 13 13 11 (100.0%)
JR1NKN       140 16 14 10 ( 87.5%)
JA7ADV        30   9   6   5 ( 66.7%)
HS3LSE        30   6   6   5 (100.0%)
JG1SWV        25   6   5   5 ( 83.3%)
JE1HTV        16   4   4   4 (100.0%)
JG1GCO        12   4   4   3 (100.0%)

JE8KGH - - - -
UA0DX - - - -

Outside Asia-Pacific

CALL SCORE QSO PNTS MULT (Accuracy)
_____________________________________________________

RA4I

800 42 40 20 ( 95.2%) *
UA1AFT

792 36 36 22 (100.0%)
RZ9YQ

350 30 25 14 ( 83.3%) *
R8UT

315 24 21 15 ( 87.5%)
R9YC

221 17 17 13 (100.0%)
K3ZO

200 20 20 10 (100.0%) *
YO3RU

156 17 13 12 ( 76.5%)
N5HC

121 13 11 11 ( 84.6%)
RA5B

81 10 9 9 ( 90.0%)
UB8QAA 1 1 1 1 (100.0%)

DO6LP - - - -
K2VV - - - -
K5PSO - - - -
N3RJ - - - -
RT9YW - - - -
RW9Y - - - -
UT7Y - - - -
VE6PAU - - - -

Asia-Pacific中6位、JA中3位、と昨年より順位が少しだけ上がったものの、まだまだ納得いくものではない。

昨年分析したように、このcontestはJA国内局との交信も重要で、この点で局数の多いJA1と交信し易いJA7やR0F、BVに比して不利になるのは止むを得ない。しかし、JA1のtopを僅差ながらも逃しているのは大いに努力の余地がある所だ。

またこのcontestは参加局が少なく、後述するように「時間が余る」contestである。この為2時間full-timeで参加する局とはCQを出し続けていれば早晩交信できる可能性が高いが、部分参加局や「味見程度」の参加局をどうtiming良く捕まえるかも重要になってくるだろう。

当日Esが発生していたかどうか、NICTのIonogram dataを見てみよう。

臨海周波数は稚内 4MHz、国分寺 8MHz、山川 6MHz、沖縄 8MHz程度と読める。決して強力では無いが、本州～沖縄では軽いEsは出ていたのかもしれない。国内交信には役立ったものの、上の成績表から判るように当局からJA2はskip気味であった事が判る。

10分間毎のrateをgraphにしてみた。

前半は呼ばれて結構楽しめるのだが、後半は交信し尽くしてしまっていて10分間に1Q程度の時間が続き、結構辛いcontestだという事が改めて確認出来る。

筆者の戦略

良い成績を残せていないのに戦略を論じるのは変かもしれないが、一つ言える事は本contestではS&Pの効率が悪いという事だ。理由は、

QSY ruleの為に、CQ局は1局と交信すると居なくなってしまう。この為、呼び負けた時は、呼び負けた局（次にCQをそこで出す可能性のある局）が未交信局で無い限り、そこで待つ意味が無い。
Asia-Pacific局（つまり自局も）はLow powerなので、結構呼び負ける事がある。近距離交信も多いので、power、antennaだけでなく、skipも影響する。

だから、前半の未交信局が多く、互いに呼び合う時間帯にS&Pを丹念にするのはあまり得策でない可能性がある。「If you're not CQing, you are LOSING!」の言葉通り、S&Pしている間はCQで自callsignを「露出」していないわけだから、呼ばれる可能性が無く、只々時間を無駄にする事になるのである。

だから筆者は、なるべくS&Pはせず、指定周波数だけQSYしてCQを連発する作戦を取っている。

S&Pするのは、特に前半は、QSYの為dialを回していて偶然未交信局を見付けた時に限るようにしている。
後半は、CQを出していても数分間全く呼ばれなくなるので、band scanのように短時間searchしたり、2つのbandsの間を行ったり来たりして、何とか1局でも積み重ねるようにしている。それでも恐らくCQ連発で「露出」していた方が、見付けてもらえる可能性は高くなるのかもしれない。band幅が限定されているのは、band scanが短時間で出来て有り難い事である。

しかし、結局の所「時間が余る」contestなので、「CQ連発作戦」がscoreに貢献しているのかどうかは筆者にもよく判らない。

筆者のLog

さて、本当に筆者の戦略が正しいのか、logを眺めてみよう。色付けしたのはCheck Log局、Log非提出局と、交信時に当局より相手局の方がserial numberが大きかった局である。

QSO: 21368 PH 2014-06-14 1102 JG1VGX 59 001 JM1NKT 59 004
QSO: 21356 PH 2014-06-14 1103 JG1VGX 59 002 JH4UTP 59 007
QSO: 21363 PH 2014-06-14 1104 JG1VGX 59 003 JA7NVF 59 009
QSO: 21369 PH 2014-06-14 1104 JG1VGX 59 004 UA0DM 59 007
QSO: 21361 PH 2014-06-14 1105 JG1VGX 59 005 RA4I 59 006
QSO: 21353 PH 2014-06-14 1105 JG1VGX 59 006 RA5B 59 003
QSO: 21362 PH 2014-06-14 1106 JG1VGX 59 007 UT7Y 59 003
QSO: 21368 PH 2014-06-14 1109 JG1VGX 59 009 RW0UM 59 003
QSO: 21361 PH 2014-06-14 1110 JG1VGX 59 010 RT9YW 59 005
QSO: 21374 PH 2014-06-14 1110 JG1VGX 59 011 RZ9YQ 59 004
QSO: 21358 PH 2014-06-14 1111 JG1VGX 59 012 RT0F 59 017
QSO: 21352 PH 2014-06-14 1112 JG1VGX 59 013 JH1EAQ 59 011
QSO: 21359 PH 2014-06-14 1114 JG1VGX 59 014 YO3RU 59 004
QSO: 21366 PH 2014-06-14 1118 JG1VGX 59 015 DO5LP 59 002
QSO: 21358 PH 2014-06-14 1118 JG1VGX 59 016 E20AX 59 017
QSO: 21367 PH 2014-06-14 1120 JG1VGX 59 017 R0AD/P 59 004
QSO: 21355 PH 2014-06-14 1120 JG1VGX 59 018 UA0DX 59 005
QSO: 21367 PH 2014-06-14 1122 JG1VGX 59 019 UA0LS 59 003
QSO: 21353 PH 2014-06-14 1123 JG1VGX 59 020 E21YDP 59 018
QSO: 21360 PH 2014-06-14 1124 JG1VGX 59 021 JH6QIL 59 014
QSO: 14256 PH 2014-06-14 1127 JG1VGX 59 022 UA0DM 59 019
QSO: 14262 PH 2014-06-14 1128 JG1VGX 59 023 JH6QIL 59 018
QSO: 14262 PH 2014-06-14 1129 JG1VGX 59 024 E20AX 59 027
QSO: 14262 PH 2014-06-14 1130 JG1VGX 59 025 JF2IWL 59 019
QSO: 14268 PH 2014-06-14 1131 JG1VGX 59 026 BV1EL 59 031
QSO: 14259 PH 2014-06-14 1132 JG1VGX 59 027 R9YC 59 005
QSO: 14252 PH 2014-06-14 1134 JG1VGX 59 028 RW9Y 59 010
QSO: 14262 PH 2014-06-14 1135 JG1VGX 59 029 RT9YW 59 011
QSO: 14273 PH 2014-06-14 1137 JG1VGX 59 030 N5HC 59 006
QSO: 14267 PH 2014-06-14 1137 JG1VGX 59 031 K3ZO 59 006
QSO: 14274 PH 2014-06-14 1140 JG1VGX 59 032 JE8KGH 59 014
QSO: 14274 PH 2014-06-14 1141 JG1VGX 59 033 RT0F 59 039
QSO: 14253 PH 2014-06-14 1141 JG1VGX 59 034 N3RJ 59 001
QSO: 21355 PH 2014-06-14 1144 JG1VGX 59 035 7K1CPT 59 014
QSO: 21355 PH 2014-06-14 1145 JG1VGX 59 036 UA1AFT 59 011
QSO: 14274 PH 2014-06-14 1147 JG1VGX 59 037 JA7NVF 59 033
QSO: 14274 PH 2014-06-14 1148 JG1VGX 59 038 UA0DX 59 018
QSO: 14257 PH 2014-06-14 1149 JG1VGX 59 039 K5PSO 59 001
QSO: 21356 PH 2014-06-14 1155 JG1VGX 59 040 BA3AX 59 016
QSO: 14272 PH 2014-06-14 1158 JG1VGX 59 041 UA0LS 59 013
QSO: 14272 PH 2014-06-14 1159 JG1VGX 59 042 JH4UTP 59 040
QSO: 14258 PH 2014-06-14 1159 JG1VGX 59 043 JM1NKT 59 046
QSO: 14251 PH 2014-06-14 1200 JG1VGX 59 044 UA1AFT 59 018
QSO: 14257 PH 2014-06-14 1201 JG1VGX 59 045 RW0UM 59 035
QSO: 14263 PH 2014-06-14 1202 JG1VGX 59 046 K2VV 59 007
QSO: 14276 PH 2014-06-14 1204 JG1VGX 59 047 VE6PAU 59 001
QSO: 14255 PH 2014-06-14 1208 JG1VGX 59 048 9V1YC 59 029
QSO: 21362 PH 2014-06-14 1212 JG1VGX 59 049 9V1YC 59 033
QSO: 21362 PH 2014-06-14 1213 JG1VGX 59 050 BV1EL 59 056
QSO: 21359 PH 2014-06-14 1215 JG1VGX 59 051 K3ZO 59 012
QSO: 14274 PH 2014-06-14 1228 JG1VGX 59 052 R8UT 59 022
QSO: 14264 PH 2014-06-14 1230 JG1VGX 59 053 RZ9YQ 59 026
QSO: 14254 PH 2014-06-14 1231 JG1VGX 59 054 RA4I 59 036
QSO: 14257 PH 2014-06-14 1238 JG1VGX 59 055 RA0LMK 59 027
QSO: 14257 PH 2014-06-14 1238 JG1VGX 59 056 JH1EAQ 59 048
QSO: 14255 PH 2014-06-14 1248 JG1VGX 59 057 E21YDP 59 041
QSO: 21360 PH 2014-06-14 1259 JG1VGX 59 058 RA0LMK 59 032

これを見て、気付いた点は、

当局はstart dashでかなり出遅れている。開始2分でNKT局が004、3分でUTP局が007、4分でNVF局が009を送ってきた。彼らの戦略はどんなものであろうか？

前述したとおり筆者は開始時から「CQ連発作戦」だったが、最初の2分間は何と全く呼ばれなかったのである。
使用したN1MM Loggerは当該交信がCQだったかS&Pだったかの目印が残らない。次回以降は後日の分析の為、その区別が残るloggerを用いた方が良いかもしれない。
開始10分以降は、serial numberで負けた局は、全て結果が上位の局ばかりであった。これは順当と考えられる。

開始後47分でのJA7NVF局との交信時、何と当局が4局差で優位に立っていた！しかしその後「逆転」され、最終的に（claimedで）7局差を付けられる結果に終わった。

Start dashが素晴らしかったNVF局も、その後一時「停滞」したのだろうか？しかしその後終盤に追い上げてtopでfinishされているのは流石である。

参加局数が限られ「時間が余る」現況では、戦術にかかわらず最終結果は平準化されてしまうのかもしれない。また、大多数の局が「CQ連発作戦」を取ったら、S&Pに回る方が有利であろう。

今後も何とか上位局に学んで、更なる順位向上に努めたいものである。

N1MM Loggerを日本語鍵盤で使いこなす

2014-08-12T21:48:00.000+09:00

N1MM Loggerを日本語鍵盤で使用する時の問題

N1MM Loggerは英語鍵盤を使っている米国人が開発しているため、他の言語環境での使用には十分に配慮が行き届いていない面がある。

日本語環境の場合、programの基本的動作に殆ど問題は無いが、日本語鍵盤で使用する場合、key配列が異なる為、いくつかの問題が生じる。例えば、

一部の特殊keysが正しく動作しない。

気付いてない方も多いと思うが、例えばF keyの再送に用いる「=」（equal）は日本語鍵盤の「=」key（Shift+「-」）を押しても動作しない。Shift keyを一緒に押しても押さなくても、どちらでも駄目である。

「全角パニック」・・・ Running中等に、「Esc」や「F1」を押そうとしてうっかり「半角/全角」keyを押してしまいこれに気付かないと、callsign欄に全角文字が入力され、文字化けしてpanicに陥る。

そこでこの「全角パニック」の防止と、特殊keysを正しい動作に近付ける方法について考察してみる。

Key配列の違い

問題の原因は、英語（US）鍵盤と日本語（JIS）鍵盤とでkey配列が違う事にある。

keyboardの個々のkeyには「key code」という番号が割り当てられていて、これが英語鍵盤と日本語鍵盤とでは異なる。

「key code」は正しくは「仮想key code」と言い、各keyに固有の番号であって、「文字code」の事ではない。

同じ番号のkey codeであっても、各言語による鍵盤の仕様により、文字labelの全く違うkeyに割り当てられている事がある。
鍵盤を打鍵した時発生する、より物理的なcodeは「scan code」と言い、「key code」とは又異なる。「scan code」をOSのkeyboard driverが変換した物が「key code」である。Softwareが扱うのは「scan code」ではなく「key code」の方である。

Shift、Ctrl、Alt等の修飾keyと一緒に押しても、key codeは変化しない。（一部例外がある。またノートパソコン等ではmakerによる変則的な割り当てもある。）

ではkey codesがどの様になっているのか見てみよう。但し日英鍵盤で配列が同じ所や、今回の議論に関係のない部分については省略する。

英語（US）鍵盤

日本語（JIS）鍵盤

黄色のkeysに着目して欲しい。文字そのものの割り当てもかなり違うが、key codeも大幅に異なっている。同じkey codeなのに割り当てられた文字が全く違っていて、何故共通の番号なのか分からないのもある（例：222）。
参考まで水色のkeysは、特殊keysのうち、日英鍵盤とも同じ位置にあり、key codesが変わらない部分を示した。Labelの文字割り当ては少しだけ違っている。
黒枠で囲まれたkeysは、touch typing（blind touch）の際の両手のhome position。

N1MM Loggerでの特殊key配列

英語鍵盤でのdefault配列

N1MM Loggerを本来の英語環境（英語鍵盤のPC）でinstallした時のkey配列は次の様になっている。

「INS代替」key ・・・ N1MM Loggerでは、running時の「His call（F5）+ Exch（F2）」がINS keyに割り当てられている。これは固定されていて変更できない。また更に別のkeyを、設定によりINSと同一の機能に割り当てる事が可能である。N1MM Loggerでの具体的な設定方法は後述する。

Defaultではkey code 186の「;（semicolon）」keyになっている。Home positionで右手小指の位置にあり、touch typingしているなら使い易い場所である。
ESM modeを使用するなら、もちろんEnterを押せば済む話である。（だから大抵の方はこのINS key、INS代替 keyとも使用していなかったと思う。）

「TU/Log」key ・・・「TU（F3）+ Log（Enter）」に相当する物だが、ESM modeではEnter keyで済む。しかしこれも別のkeyが設定により割り当て出来る。

Defaultではkey code 222の「'（single quote）」keyになっている。Home positionで右手の小指の1つ右、Enterとの間にあり、これも押し易い。Enterと押し間違えても機能がほぼ同じだから問題無い訳である。
英語鍵盤は（日本語鍵盤よりも）home positionからEnter keyが（小指で）押し易い事が特徴だが、「TU/Log」を「'（single quote）」keyにも割り付ける事で更に小指の移動距離が短くて済む。

「再送」key ・・・日本語鍵盤では動作しない（様に見える）から使ってない人も多いと思うが、manualに記載のある通り、英語鍵盤では「=（equal）」keyで直前のF key messageを反復できる。

S&Pで何度も自分のcallsignを繰り返す時や、exchangeの再送等に使える。
INS（F5 + F2）は1 setとして再送される。
Programにhard codeされており、他のkeyに設定変更は出来ない。

この他に、SO2Rで用いる次のkeysも、日英鍵盤のkey配列の違いにより影響を受ける。こちらもhard codeされており、変更が出来ない。

「RX focus」toggle ・・・左右のradiosをRX focus（Entry focus）だけ入れ替えるkeyである。TX focusは動かない。

「\（back slash）」（key code 220）に割り当てられている。Enter keyの直ぐ上の使い易い位置にあり、しかも他のkeysより少し幅広になっている事が多く、打鍵し易い。
TX+RX focusを入れ替えるkeyは（上図には載っていないが）「Pause」keyである。

「Stereo」toggle ・・・両方のradiosが受信状態にある時、RX focus（Entry focus）のある側だけをmonauralで両耳で聴くか、左右のradiosを片耳ずつstereoで聴くかをtoggleして切り替えるkey。

微弱信号は両耳で聴いた方が当然聞き取りやすいが、Entry focusの無い側のradioも聴いていた方が、両方から同時に呼ばれた時に対応しやすく、また周波数防御の点でも都合が良い。
「`（grave accent）」（key code 192）に割り当てられている。英語鍵盤では、左上隅の、日本語鍵盤で「半角/全角」keyがある位置にあり、非常に押し易い。筆者は通常stereo modeで聴いているが、微弱局の信号を拾う時だけmonauralに一時的に切り替えている。この切替はかなり頻繁で、受信中は何時でもこのkeyを押せるように指先を待機させている感じとなる。

日本語鍵盤でのdefault配列

一方、N1MM Loggerを日本語環境にinstallした時のkey配列はdefaultで次の様になる。

「INS代替」key ・・・英語鍵盤のように「;（semicolon）」keyではなく、その右隣の「:（colon）」keyになる。これは、defaultで設定されているkey code 186が日本語鍵盤では「:（colon）」keyだから。

小指を1つ右に動かさなければならないが、慣れれば十分これでも使い易い。このまま使っている人も多いと思う。
設定により他のkeyにも変更可能である（後述）。

「TU/Log」key ・・・ Defaultではkey code 222であり、何処にあるのかと思ったら何と上段の「^（caret）」keyである。

これはちょっと、ESM modeのEnter keyと比べて押し易い位置にあるとは言えない。
設定により他のkeyにも変更可能である（後述）。

「再送」key ・・・日本語鍵盤では「=」（Shift+「-」）を押しても動作しない事は既述の通りである。何処にあるのか分からず使っていなかった人も多いと思うが、実は「;（semicolon）」（key code 187）がそれである。

分かってしまえば、home positionで右手小指の位置にあるので意外に使い易いのかも知れない。
Programにhard codeされており、設定で変更は出来ない。

SO2R専用keysについても、英語鍵盤とかなり違っている。これらも変更が出来ないので英語鍵盤と比べて使い難さを我慢しなくてはならない。

「RX focus」toggle ・・・ Key code 220だが、日本語鍵盤では「￥（円）」keyである。

「Back space」の左隣。英語鍵盤程使い易くはないが、慣れれば何とか使える。

「Stereo」toggle ・・・ Key code 192で、日本語鍵盤では「@（at mark）」となる。

「P」の隣のやや奥まった位置にあり、上述の英語鍵盤での使い易さと比較するとかなり操作性が悪い。

解決方法

（方法１）　外付けの英語（US）鍵盤を取り付ける

但し、ただ「取り付けただけ」では、実は全く解決にならない。

外付けのUSB英語鍵盤を買ってきて日本語のPCに取り付けると、まず何が起こるかというと、英語鍵盤が日本語配列として認識される。

これを確認するには、例えば次の様にする。

「[」key（「P」の右隣）を押すと、「@（at mark）」が入力される。
Shift+「2」（文字labelは「@」）を押すと、「"（double quote）」が入力される。

以上の状態なら、日本語配列として認識されている。

この状態では、key codesは実際には次のように割り当てられている。

既述の日本語鍵盤での配列とよく似ているが、次のような特徴がある。

左上の「`（grave accent）」のkey codeは229になる。これは日本語鍵盤の「半角/全角」keyと同じ（場所も同じ）なので、ここを押してしまうと「全角パニック」に陥る。折角英語鍵盤にしたにも拘らず！！
日本語鍵盤とは完全には配列が同じではない。英語鍵盤の方がkey数が少ないため、一部日本語鍵盤にあったkeysを割り付けられず、入力出来ない特殊文字が発生する。

入力出来ない文字は、「\（back slash）」、「_（underscore）」、「|（pipe）」の3つ。幸い、contestsで使う物は含まれていない。
理由は、日本語鍵盤のkey code 220（円）、226（back slash）に相当するkeysが無いからである。
文字入力用のsoftware toolを使えば何とか入力は出来る（例えば、「プログラム」→「アクセサリ」→「システムツール」→「文字コード表」）。

英語（US）配列として正しく認識させれば、上記の問題は全て解消できる。方法は後述。

この状態でN1MM Loggerを使った場合、特殊keysの割り当ては次のようになる。

「INS代替」key ・・・「'（single quote）」になる。日本語鍵盤では「:（colon）」となっているkeyで、位置は同じ。

N1MM Logger内の設定で他のkeyに振り替え出来る（後述）。

「TU/Log」key ・・・「=（equal）」keyとなる。日本語鍵盤で同じ位置にある「^（caret）」keyと同じ機能。

N1MM Logger内の設定で他のkeyに振り替え出来る（後述）。
紛らわしいが、「=（equal）」keyは「再送」keyにはならない訳である。

「再送」key ・・・「;（semicolon）」となる。位置は上述の日本語鍵盤の場合と同じである。

Hard codeされており、変更できない。

「Stereo」toggle ・・・「[（open bracket）」で、これも日本語鍵盤の「@（at mark）」と同じ位置にある。

これもhard codeされており、変更出来ない。

「RX focus」toggle ・・・この接続状態では該当のkey code 220が現れないため、何と、使用する事が出来ない！！これではSO2R運用には不便だろう。

英語配列で「RX focus」に割り当てられていた「\（back slash）」keyは、日本語鍵盤の「￥（円）」keyと互換性があるように動作する事もあるが、この状態で認識した場合はkey codesが異なっており（220 vs 221）、「RX focus」としては動作してくれない。

外付けの英語鍵盤を使用する場合は、次に述べる英語（US）配列への設定変更を是非とも行うべきである。そうする事で初めて英語鍵盤として正しく動作するようになる。N1MM Loggerでも、開発者が前提としていたような最も使い易いkey配列で使用できる様になる。

（方法２）　日本語鍵盤を英語（US）配列として認識させる

これは、外付け英語鍵盤を買ってこなくて済む方法である。日本語鍵盤だけでなく、（方法１）の英語鍵盤を英語（US）配列として正しく認識させるのも、全く同じ方法を用いる。

Windowsの「言語バー」を右clickして設定画面を開く。下記のような画面が現れる。

皆さんのWindowsでは、初期状態で「日本語（日本）－ Microsoft IME」というのしか入っていないかもしれない。筆者は上図のように色々追加しているが、ここで必要なのは「英語（米国）－ US」というkey配列だけである。

「追加（D）・・・」buttonで簡単に追加できる。

追加後は、言語（key配列）を「Shift + Alt」で切り替え出来るようになる。英語（US）配列に切り替わると、task barに次のような表示が出る。

「Shift + Alt」による切り替えは、大変便利な事にapplication毎に保持される。例えば、同時にbrowserを立ち上げている場合、N1MM LoggerをUS配列に切り替えても、browserの方は通常の日本語配列のままなので「半角/全角」keyもIMEも有効で、browser内での日本語入力に支障は無い。
但し、application（N1MM Loggerも含め）を一旦終了してしまうと設定は保存されず、次回起動時には既定の入力方法（通常は日本語配列）に戻ってしまう。Contest中に何度もLoggerを立ち上げ直す訳ではないから、起動した時にUS配列に切り替える癖を付けておけば良い。

さて、この状態でどのようにkey配列（key codesの割り当て）が変わったかを見てみよう。日本語鍵盤を、英語（US）配列として認識させた場合である。

前述の英語（US）鍵盤本来の配列と大変よく似ている。
「半角/全角」key ・・・英語（US）鍵盤の「`（grave accent）」と同じkey code（192）となった。

これにより、「半角/全角」keyとしては動作しなくなり、「全角パニック」が回避できるようになる。
英語（US）鍵盤の「`（grave accent）」と同じように、SO2R用の「Stereo」toggle keyとして動作するようになる。既述した通り、日本語配列のまま用いた時の「@（at mark）」keyの位置よりこの位置の方が断然操作性が上である。
間違ってこのkeyが押された場合でも、SO2Rでは「Stereo」toggleが切り替わるだけであり、「全角パニック」程大きな影響は無い。またSO2Rを行っていなければ何の動作もしないので、更に安心である。

右側の特殊keys群のkey codesは英語（US）鍵盤とよく似ているが、次の点が異なる。

「Enter」keyの形状が変わった関係で、key code 220のkeyは「Enter」の直上ではなく、左下に来ている。このkeyは「RX focus」toggleに割り当てられるので、本来の英語鍵盤と比べて少しだけ操作性が下がる。
英語鍵盤には無い、key code 193「\（back slash）」、255「￥（円）」の2つのkeysが出現するが、英語環境で開発されているN1MM Loggerでは当然ながら、何の機能にも割り当てられていない。

まあまあ押し易い位置にあるので、好みにより、後述する方法で「INS代替」keyや「TU/Log」keyに割り当ても可能である。

この状態でのN1MM Loggerにおける特殊key配列を整理すると次図のようになる。

既述した通り、「Enter」keyの形状が変更になった影響で、「RX focus」toggleが少し使い難い位置に移動した事を除けば、本来の英語（US）鍵盤に極めて近い操作感となる。
筆者はこの状態で使用しており、皆様に最もおススメしたい設定だ。

（方法３）　N1MM Logger内のConfigurerでkey配列を（一部）変更する

これは開発者が、利用者の好みや言語環境の違いに少しでも対応させる為に取り入れた機能ではないかと思う。

Configurerの「Function Keys」tabで、

「INS代替」key
「TU/Log」key

のみ、そのkey codesを変更できる。逆に言えば前述してきた中で、

「再送」key
SO2R「RX focus」toggle key
SO2R「Stereo」toggle key

の3つについては、program内でhard codeされている為、この方法を用いても変更は出来ない。

Key配列変更software tool（例：AutoHotkey）を使えば如何様にも変更は出来るが、筆者はやっていないし、今回はその話は割愛する事にする。どうしてもやりたい方はご自身で挑戦してみて欲しい。

さて、N1MM Logger設定画面での変更方法であるが、default状態では恐らく下図に似た状況になっている筈である。

Key codeの変更に関係があるのは、緑の枠で囲った部分で、defaultでは

「INS代替」がkey code 186（日本語鍵盤で「:（colon）」）
「TU/Log」がkey code 222（日本語鍵盤で「^（caret）」）

に割り当てられている筈である。

該当欄にcursorを置き、変更したいkeyを押すと、自動的にそのkey codeが入力される。Key codeをいちいち覚えている必要が無いから、これは便利だ。

しかし、以下のような制限・不便さが残る。

他の特殊機能にhard codingで割り当てられているkeysに重ねて指定する事は出来ない。具体的には下記の3つ。無理に割り当てても無視され、本来の機能が優先される。

key code 187「;（semicolon）」・・・「再送」key
key code 192「@（at mark）」・・・「Stereo」toggle（SO2R）
key code 220「￥（円）」・・・「RX focus」toggle（SO2R）

英語（US）鍵盤で「INS代替」にdefaultで使われている位置のkey「;（semicolon）」が、日本語鍵盤では「再送」keyにhard codeされてしまっているのが何とも残念である。
つまりこの設定画面で変更したとしても、英語鍵盤の配列に近付ける事は決して出来ないのである。

「半角/全角」keyは有効なままなので、「全角パニック」を抑止出来ない。

「半角/全角」のkey code 229を上記の「INS代替」若しくは「TU/Log」に割り付けてみると、何とそれらの機能と「半角/全角」切り替えが同時に機能してしまい、最悪な状態（message送信と同時に入力が全角に切り替わる）になる。

Default状態を保つ事の利点

N1MM Loggerのdefault状態では、前述したように英語（US）鍵盤の使い易い位置に「INS代替」、「TU/Log」は割り付けられている。英語鍵盤での多くの利用者は、特に変更は行わず、きっとこのdefaultの状態のままで使っていると思われる。
これをわざわざ個人の好みで特殊な位置に変える事はsingle opであれば自由であろうが、multi op環境など、多数の方が同じLoggerを使う場合には合意が得辛く、混乱を招く恐れがある。Multi op環境ではdefaultのままの方が良いかも知れない。

まとめ

要約すると、「日英いずれの鍵盤を、日英いずれの配列で使うか」によって4種類の組み合わせがある事が分かった。N1MM Loggerにおける使い勝手の良さの順に並べると以下のようになる。

第１位　英語鍵盤を、英語配列で使う

日本語PCでは、USB外付け英語（US）鍵盤を買ってきて、言語設定でkey配列を英語（US）鍵盤用に変更する。（これはapplication毎に一時的に変更できるから、他のapplicationsの入力作業には影響を与えない。）
N1MM Logger開発者が意図した本来のkeyの位置とlayoutで使用出来、最高！
「半角/全角」key（key code 229）が無いから、「全角パニック」は起こらない。
敢えて欠点を言うなら、laptop PCでは外付け鍵盤が邪魔になるかもしれないこと、desktop PCで英語鍵盤だけにしてしまうと、日本語入力が少し不便になること、等。

第２位　日本語鍵盤を、英語配列で使う

上記に解説したとおり、日本語鍵盤のままでkey配列を英語（US）鍵盤用にする。
「再送」と「RX focus（SO2R）」の位置には少し不満が残るかもしれないが、上記環境と似た状態で使用出来、実用上ほぼ満足がいくだろう。
「半角/全角」keyのkey codeが変わるので、「全角パニック」は起こらなくなる。
外付け鍵盤を使用せずに済むのも利点。

第３位　日本語鍵盤を、日本語配列で使う

日本語のPCに普通にN1MM Loggerをinstallした状態。（多くの人がこのままで使っていると思われる。）
key codeの事を知らない人は、配列がどう変わったのかがよく分からない。（文字labelを見ても想像が付かない。）
keysの位置が分かったとしても、使い難い位置に移ったものがあり、不便なのを我慢しなくてはならない。
また、問題の「全角パニック」が生じる。

第４位　英語鍵盤を、日本語配列で使う

USB外付け英語（US）鍵盤を買ってきて取り付けただけの状態。
左上にある「`（grave accent）」のkey codeが「半角/全角」keyと同じ（229）になってしまうので、「全角パニック」が生じる。
日本語鍵盤より操作性が良くならない上、SO2Rでは「RX focus」toggle keyが使えなくなる。最悪！

英語鍵盤を使うなら、英語（US）配列への変更（前述）が必須です。

WAE CW @JG1ZUY

2014-08-11T09:00:00.000+09:00

台風11号が直撃

このcontestはこれで4年続けてのentryになる。台風11号（Halong）がこの週末に日本列島を直撃する事は判っていたが、西日本に上陸・横断する予報であったので、影響は少ないと見込んで躊躇いなく参加する事にした。

当contestは、9日9時から11日9時まで

実際には、予想通りの進路で東日本を直撃する事は無かったが、やたらと暴風域の大きな台風で、列島を横断した2日目は千葉でもかなりの長時間暴風雨が続いた。「台風が日本海側に抜ければ関東地方は大抵無風快晴になるだろう」と甘い見通しを立てていたが、実際には日本海に抜けてからもかなりの間暴風雨が吹き荒れ、これは帰宅準備を始める11日午前3時頃まで続いていた。

当shackは低山のほぼ山頂にあるが、幸い風速は最大でも15m/s（54km/h）前後にとどまっていたと思う。Towers周辺は木も生い茂っていてantennas自体はかなり強風に耐えられるので心配はしていなかったが、実は心配だったのは麓に下りる迄の山道の状況である。暴風雨の為に崖崩れが起きてもおかしくはなく、倒木でもあって動かせなければもう車では麓まで下りられず、帰宅出来ない事確定なのである。

月曜日は有給休暇を取ってはおらず、朝4時まで運用し片付けてから帰宅し、朝8時には職場に居るつもりだったので、contest終盤は暴風雨の中、帰られなくなる恐怖に気を取られながらの運用だった。

実際には帰りの山道には多少の倒木や落石はあったものの、3～4回車から降りて手で片付けられる程度で、麓まで下りられた時は本当にホッとした。

さて、本題のcontest reviewに移る。

宇宙天気は下図のようであったらしい。（clickにて拡大、以下の図も同様）

2日目終盤にやや地磁気が不安定となっているが、後で述べる様に早めに切り上げてしまったのでconditionの悪化を感じる事は無かった。

しかし全体を通しては、夏のごく平均的なcondition、SSNも100台から下降気味で、パッとしない印象だった。

RBNのspots解析を見てみよう。

1日目（8/9）：SFI=113, SSN=111, A=3

2日目（8/10）：SFI=108, SSN=64, A=8

背景の暗い部分は筆者の休憩時間である。

最初から月曜朝4時に（5時間を残して）QRTする予定で、36時間運用する為に残り7時間の休憩をうまく取るつもりだったが、実際には欧州が開いている時間が少なくて、合計約17時間も休憩を取ることになった。
従って運用時間は約31時間であった。
2日目に15mがまだ開いているのに1時間程休憩しているのは、やり尽くしたのか余りにrateが下がったので、疲労回復の為「食事& refresh」休憩としたものである。

普段運動もせず、体力のない私は、休憩時間を取らないdie hardな運用は自分には無理だと諦めている。無理して体調を崩したり、仕事に影響を与えてはいけない。この為たとえ真剣なfull参加であっても、体力を温存し余裕のある運用を心掛けている。

こんなconditionでも10mが両日ともわずかながら開いたのは幸いだった。後述するように31局、11 countriesと交信が出来た。（SO2RによるDueling CQが有効だった。）
40m、80mが開くのは短時間だが、multiの比重も高く、周到な運用でここできちんとcountriesを稼ぐ事がscore向上には重要だろう。

筆者の場合、40mはそこそこ努力をしたが、80m迄は殆ど手が回らなかった。
この時間帯は日中から始まって徹夜の連続運用（14～5時間）で疲労が溜まっている時間帯であり、集中力を保ってSO2R（S&P）をするのは大変難しい。
仕事の都合で月曜午前4時に運用終了した事で、2日目のopeningは半分以上逃した事が判る。

まとめ

とは言え、大きなtroublesもなく無事運用出来、安全に帰宅出来た事は、筆者にとって大満足であった。台風による悪天候のお陰で、酷暑では無かったのも幸いだったかも知れない。

Call: JG1VGX
Operator(s): JG1VGX
Station: JG1ZUY

Class: Single Op HP
QTH: QM05bg
Operating Time (hrs): 31
Radios: SO2R

Summary:
 Band  QSOs  QTCs  Mults
-------------------------
   80:    5     0    2x4
   40:  111   114   23x3
   20:  467   424   37x2
   15:  711   763   41x2
   10:   31     0   11x2
-------------------------
Total: 1325  1301    255  Total Score = 669,630

3830 reflectorへのpostはこちら。

6mのDX Openings

2014-07-17T00:00:00.000+09:00

当局は殆どHF contests専業である為、6mの事がよく分かりません。

皆さん6mのDX openingsで盛り上がっているけど、いつ何処が開く可能性があるか、という基本知識もないのです。

そこで今回、

JA局がspotした

2014-6-17 ～ 7-14（4週間）の6m DX spots

（skimmer spotsではなく、従来のDX cluster spots）

を分析してみる事にしました。使用したDX cluster spots dataはここにあります。

日毎の大陸別spot数

以下の表で、ASは次の2 groupsに分類しました。

AS nearby = HL, BV, BY, 極東Russia
AS other = 他の全て（主に中央Asiaや中近東）

日によって大きなばらつきがありますね。良いconditionは数日持続する事が分かります。
7/3 23z～7/4 00zにかけてOXが開きました。
AFは全てEA8です。
SAは一度もspotされていませんでした。

時間毎の大陸別spot数

HF high bandsとほぼ同じと考えて良いようですが、NAについては05～09zというかなり遅い時間（西海岸の夜）にも再度開いているのは興味深い所です。

IARU HFのcondition

2014-07-14T09:00:00.000+09:00

今年は何とか磁気嵐の直撃は免れたのですが、1週間前にSSN=256迄上昇した太陽指数（contest当日は145→102）から想像するには何となく今一つなconditionでした。（もしかすると各地域で発生するEsもF層伝搬に影響していたのかもしれません。）

K値に明らかな影響はありませんでしたが、contest開始前数時間に電子流の変動が見られています。

2日間の宇宙天気指数は、

7/12 SFI=145, SSN=145, A=4
7/13 SFI=126, SSN=102, A=5

でした。

次に、RBN spots解析です。過去のdataはこちら（2013年、2009～2012年）ですが、昨年迄と違って、今年はbarsの高さを、欧州/北米でそれぞれ最大のbandに合わせてscalingしているので比較の際は注意をして下さい。Contest開始時間が真ん中の縦線の12zです。その右側が1日目のdata、左側が2日目のdataです。画像をclickすると拡大されます。

事前予測（7/1～7/10のRBN dataによる）とは、だいぶ違ってしまいました。事前予測の方法に無理があったものと思われます。参考にして運用された方、御免なさい。

実際の当日dataから読み取れるconditionを纏めてみます。

	EU	NA
10m	・はっきりしたopen無し。（予想通り）	・はっきりしたopen無し。（予想通り）
15m	・初日の出だしは良かったが、14z台をpeakとして信号が下がり、19zにほぼ閉じてしまった。・翌日も聞こえ出すのが05z頃と遅く、08z頃peakを迎えた後は信号が下がり、contest終了間際まで持ち直す事が無かった。	・20~23z台に開いたが、予想よりも悪く例年通りだった。・特に0zを過ぎると、殆ど閉じてしまった。
20m	・弱いながらも殆ど1日中開いていた模様。・特に夜間は長時間しっかりと開き、15mにも勝る。peakは17z台。	・05~18zにかけて長時間、EU程ではないが比較的しっかりと開いた。・07z台、14~15z台に二峰性peaksを持つ。
40m	・16~20:30zに開いたが、NAよりは劣る。・peakは19z台。	・08z~14:30zに比較的しっかりと開いた。・peakは10~11z。
80m	・16~19:30zにわずかに開いた。	・10:00~12:30zにほんの少しだけ開いた。

今年の事前予測よりも、昨年までのcontest当日のdataに似ていたと言えます。

Conditionの下がる来年以降は、20~40mが主力bandsとなる傾向が強まるでしょうか？

IARU HFのcondition予測

2014-07-11T20:33:00.002+09:00

今週末のIARU HF Championship contestの運用に備えて、

7/1～7/10（7/5,6=週末を除く）

つまりここ数日間の積算RBN（Skimmer）dataをViewPropというsoftwareに流し込み、JAから欧州（EU）、北米（NA）へのopen状況を時間chartで視覚化してみました。（↓図をclickで拡大）

Contestは12zから始まりますので、真ん中の縦線の所を開始位置として右向きに眺めてみてください。なお、dataの中にはbusted spotsが含まれています。ありえない時間にもspotsが見られるのはこの為です。小さな数字は無視してください。

上図を見ながら、ざっくりと各bandのcondition、open予想をしてみましょう。

	EU	NA
10m	・はっきりしたopenは無い。	・はっきりしたopenは無い。・可能性として20:30~22:30z。
15m	・00~04zに閉じるのを除いて、他の時間はだらだらとほぼ1日中開いている。・何峰かのpeaksを持つ浮沈のあるcondition。・朝20~22zはNAと同時に開けており要注意。	・朝のopenは20:00z頃から本格化。開き始めて間もなくの20~21z台にpeakがある。00zを過ぎるとかなり弱い。・夜12~16zに20mと重なってEUと同時に開けている。
20m	・15z頃から徐々に強くなり19~20z台にpeakを迎え、やや急速に閉じ22:30zにはほぼ消える。	・05z頃から弱く開いているものの、11zから急速に上昇、peaksを迎え、15:30z頃に閉じる。
40m	・17~20zにpeak。	・09~14zにpeak。
80m	・18~19zの非常に短いpeak。	・10:30~12:30z、殆ど開かない。

ご周知のように7/6頃をpeakに太陽指数は上昇していましたが、現在少し下がり始めています。地磁気もK=1～3と比較的静穏に推移していたものの、やはり夏だけあって伝播状況は期待したほどには良くなかったようです。

	7/1	7/2	7/3	7/4	7/5	7/6	7/7	7/8	7/9	7/10	7/11	7/12	7/13
SFI	151	169	178	187	193	201	197	201	198	177	?	?	?
SSN	152	180	179	199	213	256	197	209	183	159	?	?	?
A	3	3	6	5	2	3	7	6	7	6	?	?	?

IARU HFの過去のconditionは別記事（2009～2012年、2013年）にありますのでご参照ください。

このcontestはここ数年磁気嵐に見舞われているのですが、今年は今のところ太陽活動が活発にもかかわらず、big flaresやCMEsの報告は無いようです。

Kenwood TS-590、TS-990からのLinear Amplifier制御

2014-06-11T21:37:00.004+09:00

Kenwoodのexciters、TS-590やTS-990からlinear amplifiersをstand-by制御するには2通りの方法があります。

TS-990のREMOTE connectorの端子配列は次のようになっています。（TS-990徹底解説集より）

機械式relayを使う方法

REMOTE connectorのpin 2,4,5がexciter内部の機械式relayに繋がっており、送信時にMKE（pin 4）がCOM（pin 2）に接続されるので、これをlinear amplifierのSEND（TX GND）等に接続します。

この方法は接続が単純ですが、欠点は機械式relay音が五月蠅い事です。またこの端子の定格が取扱説明書等に見当たりませんが、TL-922（stand-by端子の定格 DC100V、40mA）が接続できるとしていることから、それを優に超える定格があるものと推測されます。

（2014/12/18 追記）Kenwoodのrigsでlinear amplifier駆動に使用されている機械式relayはDS1E-M-DC12V（Panasonic, NAIS）で、定格は次の通りと分かりました。

60W or 125VA
DC 220V or AC 250V

3A

半導体switchを使う方法

一方REMOTE connectorのRL（pin 7）には半導体switchを介してstand-byに連動して電圧が出るようになっています。

但し、上図のActive Low論理用のFETはTS-990だけに追加されており（MENUで切替可能）、TS-590や従来機種ではbipolar transistorによるActive High論理の出力しかありません。

従ってTS-990の場合は「Active Low」の設定（後述）にする事で送信時にpin 7をGNDに落とし、amplifiersを駆動する事が出来るようにも思えます。しかし問題は取扱説明書によると許容電流が10mAしかない事です。

よく使われている（solid state）linear amplifiersのstand-by端子の定格を調べてみると次のようでした。

IC-PW1	DC 5V, 0.1A
JRL-2000F	DC 12V, 5mA

つまり、JRL-2000FはOKと思いますが、

IC-PW1はTS-990のRL端子（pin 7、Active Low論理）からは直接駆動出来ない

ことになります。実際、IC-PW1の取扱説明書には次のように記載されています。

IC-PW1のACC端子の説明にはSEND端子の流出電流は「20mA以下」とも記載されていますが、それにしても10mAを超えますのでやはり直接接続は出来ないと考えた方が良いでしょう。

又、TS-990のActive Low論理の場合の耐圧はDC 15V迄という事ですので、後述の「リニアアンプ・コントロール設定」でTX Delayを加えた場合でも、TL-922等の真空管式amplifiersは駆動出来ません。

これはちょっと残念な話ですね。他社のexcitersの半導体stand-by端子の定格を調べてみると次の通りでした。

IC-7600	250V, 200mA
FT-1000MP MkV	DC 40V, 150mA

従ってこれらのexcitersからは、以下に述べる緩衝回路無しに、半導体switchから直接にIC-PW1、JRL-2000F等のamplifiersが駆動できます。（IC-7600は真空管式amplifierもstand-by出来ます。）

なお、JRL-3000F/TL-933のstand-by回路の定格は調べられませんでした。ですが、取扱説明書によるとTL-933はTS-590/990のRL端子から（Active High論理で）直接駆動できるとしていますので、流入電流定格は10mA以上あるものと思われます。

IC-PW1用緩衝回路入りLinear Amplifier制御cableの製作

以上の考察から、TS-990に内蔵の半導体switchを利用してIC-PW1を駆動するには緩衝回路が必要と判りました。「実際には10mAも電流は流れないだろうから直接繋いでも大丈夫じゃないか？」と言う人も居ますが、ICOM側が保証していない以上、TS-990の半導体switchを焼損してしまいたくはありません。

IC-PW1（2台）のSEND端子の流出電流を実測したところ、8.0～9.8mAでした。10mAは辛うじて超えていませんでしたが、定格10mAのTS-990のRL端子にはやはり繋がない方が良いでしょうね。（2014/6/14）

またTS-590の半導体switch回路には元より「Active High」の論理しかありませんから、論理を反転しない事にはSEND（TX GND）がGNDに落ちる事によって送信になるような通常のamplifiersを駆動できません。

そこで、2種類のcablesを作ってみたので報告します。緩衝回路により論理を反転し、exciter側は「Active High」の論理で動作するものです。どうせ作るのなら汎用性の高いcableにしておきたく、ALC制御線に加えて、通常の機械式relayによるstand-by線も一緒にDIN connectorに組み込むことにしました。IC-PW1だけでなく、どんなlinear amplifiersにも接続できるようにです。

Photo relayを用いる方法（高耐圧版）

TLP222GF（写真：秋月電子通商）

この版では東芝のTLP222Gというphoto relayを用いました（秋月電子通商で@110円）。出力側定格は350V、120mAと特に耐圧に余裕があります。他社にも同等品があるとは思いますが、通常のphoto couplersでは出力側の耐圧（50V程度）が低過ぎて、TL-922等stand-by端子に高圧（DC 100V）がかかるnon-QSKのtube linear amplifiersには使用できません。もちろん、IC-PW1の駆動にはphoto coupler程度でも問題ありませんが、どうせ作るなら高耐圧の物が良いですね。

Photo deviceにより完全に絶縁されているので、次に述べるtransistor版に比べてshack内の電波障害にやや有利ではありますが、部品点数の関係でDIN plug内部に回路を埋め込むのは難しいでしょう。

Digital Transistorを用いる方法（低耐圧版）

DTC124ESATP（写真：マルツパーツ館）

Open collectorのtransistor switchは無線ではCW/PTT/FSKのinterfaceにもよく使われていますが、何とbias抵抗がtransistorのpackageに埋め込まれたdigital transistorという便利なdeviceがある事をJA7UDE 大庭OMに教えて頂きました。

Digital transistorsにも各社の製品がありますが、digital回路用のためか入力耐圧が5～10V程度の物があって本用途には使用できません。筆者は、大庭OMに教えていただいたROHM社のDTC124ESAという物を用いました。入力側耐圧は-10～40Vと負電圧でもOKですし、出力側定格は50V、100mAですのでIC-PW1の駆動は問題無いでしょう。（ただし、さすがにTL-922は駆動できません。上の高耐圧版を用いるか、素直に機械式relayで駆動しましょう。）

このcableの利点は、部品がたった1個しか無いことです！Sizeは通常のTO92 packageのtransistorよりも少し小さい位ですので、余裕でDIN plug内に組み込め、smartなcableが作成できました。

Kenwood exciter側の設定

MENU設定だけですが、これがちょっとややこしいので解説しておきます。

TS-590の場合

上表（TS-590徹底解説集より）のように3つのON設定（1,2,3）があり、「リニア・アンプ制御（RL端子）」というのが半導体switchを指し、「リレー制御（COM/BRK/MKE端子）」というのが機械式relayを指しています。この辺の用語の使い方をもっと分かり易くして欲しいですね。

機械式relayで制御する場合

「2か3」の設定にします。そうしないとrelayがONになりません。
Solid stateのfull-QSKのamplifiersの場合は、「2」でいいでしょう。
真空管式（TL-922等）は遅延時間を取って、「3」にします。

半導体switchで制御する場合

「1」にします。そうするとrelayの騒音から解放されます。
TL-922等遅延が必要なamplifiersを半導体switchで静穏に駆動する事は、そういう設定が無いので出来ません。もし「1」に遅延時間を加える設定があれば、photo relay版のcableを用いて出来たのですが、遅延時間を加えるには「3」を選ぶしかなく、そうするとRL端子（半導体switch）を用いて制御したとしても使わないのにrelay音が鳴ってしまいます。

TS-990の場合

上表（TS-990徹底解説集より）のようにTS-590よりも設定の種類が2つ増えています。「Active High」「Active Low」という従来機種には無かった言い回しもあります。「RL出力」が半導体switchを指し、「リレー制御」が機械式relayを指しています。

結局の所、上の3つのON設定はTS-590の「1,2,3」に相当します。TS-590や従来機種はRL端子（pin 7）は「Active High」論理であって、TS-990になって初めてFET open drainによる「Active Low」論理が追加されたのです。（尚、遅延時間がTS-590では25msでしたが、TS-990ではSSB、FM、AMは45ms、それ以外[CW、FSK、PSK]では25msとなっています。）

この追加された「Active Low」論理というのは、機械式relayの動作を伴わず、送信時GNDに落ちるという事でまさしくlinear amplifierのSEND（TX GND）端子に直接接続するのに良いように思われますが、残念ながら上述のように許容電流が10mAであるため、この論理で直接IC-PW1を駆動することは出来ません。

機械式relayで制御する場合

「Active High + Relay Control」か「Active High + Relay & TX Delay Ctrl」にします。そうしないとrelayがONになりません。
Solid stateのfull-QSKのamplifiersの場合は、「Active High + Relay Control」でいいでしょう。
真空管式（TL-922等）は遅延時間を取って、「Active High + Relay & TX Delay Ctrl」にします。
ここでいう「Active High」は次の半導体switchの動作の事を指していますので、機械式relay動作の場合には何の意味もありません。機械式relay自体は言わばActive Low論理で動作するので、非常に紛らわしい表現だと筆者は思います。

半導体switchで制御する場合

TL-933の場合は、専用cableで繋いで「Active High」にするそうです。（具体的回路は解りませんが、Active High論理で動作するinterfaceになっているのだと思います。）
筆者製作の上記2種類のcablesはいずれも緩衝回路で論理が反転しますので、SEND（TX GND）がGNDに落ちる事によって送信状態となる通常のlinear amplifiersに接続する場合、「Active High」を選択します。これによりrelayの騒音から解放されます。
但し、真空管式などnon-QSK amplifiersの場合は遅延が必要です。所が残念ながらTS-590の場合と同様の状況で、設定項目の問題で、このcableを使っても半導体switchを用いて遅延時間を付加して静穏にamplifierを駆動する事が出来ません。「Active High + TX Delay Control」（Relay無）という選択肢が無いのです。Active High論理で遅延時間を取るには「Active High + Relay & TX Delay Ctrl」を選択するしかなく、そうすると使わないのにrelay音がしてしまい、半導体switchで駆動する意味がありません。

CQ WPX CW @JG1ZUY

2014-05-26T09:00:00.000+09:00

表題のcontestに房総丘陵のshackから参加した。

今回は、昨年から導入しているがまだ余り使いこなせていないmicro2Rを使ったSO2Rの練習を存分にする事にした。

WPX Contestの面白さ

DX Contestの王様と言ったら「CQ WW DX Contest」と言う事でほぼ異論は無いだろうと思う。季節的にもDXのbest seasonに鎮座し、参加局の多さ、rare multiを落とす事の楽しさと言ったら右に出る物は無い。

それに比べて「CQ WPX Contest」はやや地味なcontestだとずっと思っていた。しかしやってみるとこれはこれで面白い。

あらゆる面で平等。無数にあるprefixがmultiというのはある意味面白みが無さそうだが、WW DXのようにrare countryの局だけが特別呼ばれるということが無いのは却って公平で良い事とも言える。だから、このcontestに参加するために（呼ばれるために）わざわざCaribbeanとかAfricaに行く人も居ないわけである。
「Number contest」の競争感覚。延々と同じexchange（zoneや年齢など）を送る他のcontestsと違い、いわゆるnumber contestsでは即時に成績を交換し合っているようなもので、これが競争感覚を煽って楽しい。Rivalsに勝っているか負けているかすぐに分るのである。負けていれば何とか差を詰めて、追い越したいと思う（なかなかそうはいかないが）。また番号が少しずつ増えていくというのも何ともaddictiveで射幸心（？）を煽るものだ。
Single op.の36時間制限は助かる。中高年の筆者は、48時間のcontestsは体力的にかなりしんどい。WW DXのように48時間single op.で無睡眠で戦うのは、sportsman並みのdie hardな体力が必要で、頭でっかちな戦略だけでは到底勝てない。
国内交信が出来る。DXのCW/SSB contestsでは国内交信は得点にならない物が多い。RTTY contestsでは逆に国内交信も得点になるのが普通で、お世話になっている知人各局との「ご挨拶交信」もその楽しみの一部である。Contestだから、冗長なmessage交換は不要だが、有名contestersも自分を呼びに来てくれるのは中々良い気分だ。
Contestの基本技術を養う。このcontestはWW DXよりも初心者にお勧めしたいcontestだ。上記のruleが比較的平等である、国内交信が出来る等に加えて、number交換と言う基本的なcontest交信技術が磨かれる。SSBでもCWでもRTTYでもこれは基本技術だと思う。こう言うとなんだが、非常に基本的な交信練習に適したcontestである事は間違いない。

一方、悪い点を敢えて言うなら、SSBについては3月末と言うのはDX conditionとしては最高なんだけど、社会人としては年度末と言う最悪の時期で、いつもしんどい思いをして参加している。また、3月はmajor contestsが多過ぎる。新年のmajorは2月のARRL DX CWを皮切りに本格的なcontest seasonを迎えるが、3月は第1週のARRL DX SSBの後、第3週に今や「準major級」のRussian DXがあり、2月からずっとこれらに全力で参加しているとRussian DX辺りで「完全燃焼」してしまっていて、年によったらその翌週に来るWPX SSBはちょっと食傷気味になっているのである。

それに比べてWPX CWの方は5月末だから「暫く振りのmajor」という感じがして全力参加が出来る。また黒点上昇期はhigh bandsが夜遅くまで開く等夏型のconditionの始まりが楽しめるのも良い。

Sub antenna（[email protected]）の設置

2 bands同時運用する都合上、sub antennaが必要な為、ナガラ TA-31（14/21/28 RDP）を仮設した。諸般の事情によりtower上に設置できなかったので、下図のように伸縮poleを用いてpanza mastに立てかけて5.4mHに設置した。

[email protected]" imageanchor="1" style="margin-left: 1em; margin-right: 1em;">[email protected]" height="640" width="376" />

これでは低すぎて飛ばないし指向性も出ない（20mは1/4λ、15mは1/3λの高さ）かと思ったが、意外に飛んでくれて、昨年苦労して上げた釣竿vertical+ATUよりはよっぽど役に立った。

尚、rotaryではなく固定である。南北（0°/180°）に指向性が出るように設置する積りが、適当に作業したので偶然にも欧州向け（330°/150°）の設置角になった。この為欧州やZL方向（FW/FK等）から大変よく呼ばれnoiseも少なかったが、北米からはただの1局も呼ばれなかった。十分に指向性が出ていたとみられる。

申告score

                    CQWW WPX Contest, CW

Call: JG1VGX
Operator(s): JG1VGX
Station: JG1ZUY

Class: SOAB HP
QTH: Chiba
Operating Time (hrs): 35.5
Radios: SO2R

Summary:
 Band  QSOs
------------
  160:    0
   80:   35
   40:  193
   20:  547
   15:  870
   10:  142
------------
Total: 1787  Prefixes = 750  Total Score = 3,726,750

QTH: Kimitsu, Chiba (QM05bg)
Antennas:
- 3.5 trapped RDP
- 7/14/21 Create 714XX trapped tribander (3/5/5)
- 28 7L monobander
- 14/21 trapped DP (for sub)
Power: genuine legal 1kW
SO2R with micro2R
Logged by N1MM Logger 14.4.1

3830 reflectorへのpostはこちら。

SO2Rでscoreを伸ばせると期待したにもかかわらず、結果的は非常に月並みな、というか悪い結果に終わってしまいました。その理由の分析と反省は以下にSO2Rの運用形態と関連付けて考えてみる事にします。

当日のcondition

Contest開始前に行った過年度のcondition分析は別postをご参照下さい。
（以下、画像はclickで拡大すると見易くなります）

地磁気はcontest開始前に磁気嵐が出てK=5まで上昇し、「2013、2011、2010年のようにまた磁気嵐の再来か！」と危惧しましたが、始まってみるとK<=2以下に推移してくれて、良好なconditionだったようです。

両日の太陽指数と、RBN spotsの欧州/北米方面の解析dataを示します。背景の濃い部分は筆者の休憩時間です。SSNは直前5/22に70まで落ちましたが、何とか底を打って上昇に転じてくれました。

1日目(5/24)：SFI=118, SSN=130, A=4

2日目(5/25)：SFI=113, SSN=133, A=4

筆者のtime chart

月曜日通常出勤を予定していた為、19z（月曜朝4時）には運用を中止して渋滞が起こらないうちにアクアラインを抜けて東京に戻る必要があった。従って最後の朝のoff timeを5～6時間と見て、あと6～7時間必要なoff timeを、土日それぞれ朝北米の終了する02z辺りから昼前後の3時間程度2日に分けて取る計画を立て、それ自体はうまく行ったと思う。

前週から睡眠不足気味であったものの、1日目の開始後2時間位で仮眠を2時間程度取る事が出来、起床してからは1日目の約21時間に亘る連続運用をこなす事が出来た。2日目はやや長めに昼の休憩を取り、起床してみたら10/15mが欧州迄開いていて慌てて運用再開したが、その後13時間を越える連続運用もそこそこ呼ばれたおかげで食事休憩を入れながら続ける事が出来た。

最終日の朝のoff timeは仕方が無いとして、昼前後に両日off timeを取った事は上のRBN dataと見比べると問題は無かったと思う。

SO2R練習の実際

1RではCQとS&Pしかないが、SO2RではCQとS&Pをどの様に組み合わせるかによって、様々な運用形式がある。

その中で今回は、最も疲労度の少ない「Dueling CQ」に限定して練習をする事にした。上にも書いたように月曜日は有給休暇を取っておらずfull timeで仕事があるし、前週も睡眠不足であったから36時間運用するためには疲労を最小限に食い止めたかった。

100% Running

S&PはCQに比べて疲労度が高い。ましてやnon-assistedだと、searchも自分でdialを回して既QSO局もtypeしてband mapにcallsignを残していかないといけない。これは大変に疲れる。またそもそもWPX Contestはmultiをわざわざ追いかけるほどの必要は無いのである（と思っていたのは実は間違いだった。WPXでもmultiを稼げばきっと得点増に繋がっただろう）。

というわけで、ただの1度もS&Pをしなかったのである。

98% Dueling CQ

また、練習なのでdueling CQにも拘った。普通rateが上がれば1Rの方が効率が良いと言われている。しかしrateが上がっても、両方から呼ばれても対処できるように、ずっと敢えてdueling CQを続けた。しかしpanicになり、せっかく呼んで頂いた局を困惑させたり、不必要に待たせたり、逃げられたりする事もあったので、終盤頃にはhigh rateの時に少しだけ1Rに切り替えた。それでも98%はdueling CQでやった。

SO2Rの利点

1Rであれば、2つ以上のbandsが開いている時間帯は、どちらのbandで運用するか迷う。

例えば夕方の15m欧州方面と40m北米方面はどうするのか？1Rでは10/15m欧州向けで行ったり来たり忙しく、40m北米方面を疎かにしてしまい易い。

しかし2Rなら、両方運用出来るから問題無い。3 bands以上開いている時は、2 bandsのうちrateの上がらない方のbandを3番目のbandに切り替える。そうやって順繰りにbandを入れ替えていく事により、常にrateの高い2 bandsで運用できるわけだ。

Dueling CQの場合、入れ替えたいと思っているrateの低いbandのCQを止めて、一時的にrateの高い方で1R Runningにする。その間CQを止めた側のrigでbandを切り替え、QSYしたbandで空き周波数を探す。見付かったら、dueling CQに戻して再開する。

両方から呼ばれてしまった時は・・・

Dueling CQをしていると、当然ながら両方から同時に呼ばれる時がある。交互にうまくexchangeを送ったりして捌けると良いのだが、まだまだ当局にはそんな事は出来ない。

実際には、片方は無視するか、お待ち頂く事になる。

この時の対策の為に、筆者はN1MM LoggerのF keyの1つに[AS]を仕込んでおいた。N1MM Loggerでは、Ctrl+Fxのように「Ctrl」keyを一緒に押す事で、TX focusの無い側のradioにF key macroを送信する事が出来る。

同時に呼ばれた時、優先した局と交信する合間にCtrl+Fxを押して反対側に[AS]を2回位送信するのである。合間というのは例えば、優先した局がexchangeをこちらに送っている間（こちらは聞いているだけで送信していない）である。Ctrl+Fxを押して反対側で送信しても、RX focusは移動しないのでexchangeを聞き逃すことは無い。

しかし、この方法で成功した（相手局が[AS]を理解し、待っていてくれた）のは1/3程度であった。残りの2/3は[AS]を?と聞き違えるのか更に何度も自分のcallsignを打ってきたり、そのまま居なくなってしまった。[AS]を打たれたからといって相手が待つ義理は何処にも無い。だから逃げられてもこちらは文句を言う筋合いでは無いのである。

[AS]を反対側に打つのは周波数防御にも使えた。非交信側で「QRL?」を打たれたり、それも無しにCQを始められた場合である。

Headphones振り分けについて

SO2Rを行う時、両方のradioをそれぞれ左右の耳でstereoで聞く人と、SO2R controllerのlatch機能を用いて状況により左右radioを交互にmonauralで聞く人が居るらしい。筆者はどちらかと言えば後者のtypeだ。

N1MM Logger / micro2Rではstereo/monoの切り替えに対応しており、日本語鍵盤では「@」keyで切り替えが出来る。詳細は過去記事を参照されたい。

Stereoで聞く事は、常に両bandsの状況が把握出来て周波数防衛にも有利である反面、非交信側の信号やnoiseが邪魔して、交信側が微弱信号の場合反復が増えて効率が低下する等の問題がある。WPX Contestの場合、片耳でexchangeを聞き取っている時に、非交信側で全く関係ない信号を打たれたりすると混乱する。

実際には、stereoを基本にするとしても、微弱信号時はmonoに切り替える等するのが良いと思った。「@」keyは日本語鍵盤では「Enter」の近くにあって、結構操作しやすかった。

やっていて疲れないのはmonauralの方である。Stereo受信に疲れた時はしばらくmonoに切り替えたりした。

Dueling CQの欠点

Runningする側には利点の方が多いと思うが、呼ぶ側からすると迷惑な面が多いのがSO2Rである。

先ほどの、Running局が他局と交信している間「待たされる」可能性がある点。

またdueling CQは反対側のbandで呼ばれた時、突然CQが中断される。これはS&Pしている側からすると迷惑な話だ。「TEST JG1VGT」などと符号の途中で途切れる場合もあるから、そこで呼んできたS&P局側にはcopy mistakeが生じてしまう。

敗因について

1Rを中心に運用したと思われる他局とtime chartを比較すると、peak時間帯のrateの差が目立っていた。筆者が2Rやdueling CQに拘り過ぎた余り、rateがかなり影響を蒙ったようだ。
「S&Pを一切しない」という方針を立てたため、runningでrateが落ちてくるとmain antennaでのrunning bandを頻繁に変更した（21->14、21->28等）。本来ならQSYではなく、S&Pを一回りしてくるなど、rateの一番高いbandに居座り続ける戦術が必要だったかもしれない。Contestを通してのmain bandである15mの局数が競合他局に比べて明らかに劣っていたのはこの為かと考えている。
次回以降は2Rだけに拘らず、S&Pやhigh rate時の1Rへの切り替えなどを柔軟に組み合わせて雪辱を期したいと思う。

その他の感想

IF filterは300Hz位が適当だと感じた。結構運用局が詰まっていて、それ以上filterが広いと隣局が五月蝿い上に隣局を呼ぶ局を自局を呼んだものと誤解して交信してしまう。Tempoの良い交信だと、意外にtimingは合ってしまう。
国内がskipするhigh bandsでは、空いていると思った周波数が実は他の強力な国内局が使っていて、上と同じような勘違い交信があった。Assistedならband mapを見てQSYするのでこういう事は余り起こらないが、non-assistedではある程度は止むを得ないものであろう。
BY局の躍進が目覚しい。HLやBVに比べてもcontest好きが多い様に感じられる。どんどん東亜細亜のcontest activityを高めてもらいたいものだ。

直前condition分析：CQ WPX CW

2014-05-23T22:50:00.000+09:00

週末に迫ったCQ WPX CW contestに備えて、conditionの分析をしてみた。宇宙天気dataから得られた情報と、Reverse Beacon Networkの生spot dataをViewProp（by ZL2HAM）で図示し、JAと欧州及び北米間のband毎のopen状況を調べたものである。

過去のdata

昨年以前のdataを見てみよう。まず「その年のcontest前日から終了までの3日間の地磁気data」を示し、その後に「contest 2日間のRBN data plot（欧州、北米方面）」を示す。

記憶が不確かだが、RBN本家serversがcontest中に過負荷でdownしたと思われる時間帯があった。下記に示したdataはこの点で欠落を含んでいる可能性がある事をご了承願いたい。

2013年

1日目(5/25)：SFI=121, SSN=107, A=37

2日目(5/26)：SFI=120, SSN=92, A=18

1日目の終わりから2日目の最初にかけてRBN本家に過負荷による何らかのtroublesがあったものと推測している。
個人的には、こちらのpageに書いてある通り、初めてu2Rを使ったSO2Rに挑戦したが、磁気嵐が出たり途中で東京まで数時間かけて忘れ物を取りに帰ったりと、散々な目に遭った年だった。
10mのspotsが殆ど見られないが、これは磁気嵐の影響を受けて開いていなかったのか、WPX contestの特徴としてrateの高いbandsに運用が集中するためなのか？
15mも磁気嵐の影響をかなり受けてopenが乏しかったようだ。20～40mは比較的影響が少なかったと見られる。

2012年

1日目(5/26)：SFI=110, SSN=70, A=2

2日目(5/27)：SFI=110, SSN=83, A=2

この年は非常に地磁気が静穏で、数々のrecord更新が生まれた（http://cqwpx.com/records.htmで検索できる）。今年もこういうcondxであってもらいたい！
main bandの15mは午後～早朝まで殆ど一日中欧州に開けている。
10mがもっと開いていてもおかしくないが、spotsが少ないのは2013年の所にも書いたようにWPX contest ruleの影響か？

2011年

1日目(5/28)：SFI=100, SSN=91, A=40

2日目(5/29)：SFI=110, SSN=100, A=32

これまた酷い磁気嵐の年だったようだ。15mが振るわず20mがmain bandになっていたのは今見ると興味深い。
Skimmerの数は2012年以降と比べてまだ少なく、spotsの総数は半数程度で、graphが粗く見えるのはこの為だ。

2010年

この年以前はJAにskimmerの設置も少なく、RBN dataの数が不足しているため、宇宙天気dataのみ掲載する。

1日目(5/29)：SFI=73, SSN=43, A=33
2日目(5/30)：SFI=73, SSN=40, A=19

どうやらWPX CWは磁気嵐に当たる確率が随分と高いようだ。

2009年

1日目(5/30)：SFI=68, SSN=0, A=3
2日目(5/31)：SFI=68, SSN=15, A=3

この年は静穏だったように見えるが、まだ太陽活動の最低期のようだ。

micro2Rの接続と設定

2014-05-06T22:05:00.000+09:00

microHAM社のスグレモノのSO2R controller、micro2R（以下u2Rと略）を買ってから大分経つが、接続～設定がやや難しいのと、contestsをやる機会が最近あまり無かったため、全然使いこなせないでいた。

先日のARI International DX Contestは珍しい3 modes (CW, SSB, RTTY)のcontestだったので、各modeでSO2Rを試す丁度良い機会だと本番でいろいろ実験してみたが、CW以外まともに動かせられなかった。

そこでcontest後になってしまったが、反省を込めて、大型連休を利用してManualに全部目を通し、接続・設定を再確認し、各modes一通り運用できるようにしたので、ここに備忘録として書き留めることにした。

結線図

電波形式によっては全てを結線しなくてよいので、配線を色分けしてみた。

PCとu2R間のUSB cable等、一部の配線は省略している。
これはradio 1台分の配線。実際にはもう1台のradioも同様に配線される。
赤と青の矢印は、信号の向きを示す。

赤　Radioへの入力、u2Rからの出力
青　Radioからの出力、u2Rへの入力

ACC端子の「DIF-3 cable」というのは、筆者がTechnical ShackのDIF-3 Digital Interface用の接続cableを流用（改造）したものを使っているからで、DIN端子から必要な信号を取り出せればどんなcableであっても良い。

電波形式毎の運用

CW

一番簡単である。上図凡例の「ALL」と「CW」の配線を接続する。

ただしPTTを配線しないこの状態では、USB Device RouterでPTTをtriggerする設定をしても当然だがPTTは駆動されないので、rig本体のbreak-in機能を使うことになる。

Break-inだと高速CWでは少し符号の頭が途切れがちになる場合があるので、できればCWでもPTTは配線し、送受信をPTTで制御した方が良いだろう。PTTは8pin MIC端子か、背面のACC端子経由で配線する。

Paddle接続はお好みに応じて。

Voice (SSB)

CWとは異なり、音声系の配線が必要になる。上図凡例の「VOICE」を含む一連の配線を行う。

FOOTSWはあった方が便利でしょう。SEND→PTT INの配線はrig側からu2RにPTT信号を送るもので、u2Rの正しいVOX動作の為に必要になります。

Microphoneについて

Dynamic/Electret elementsの切り替えは本体内部のjumperで行います。Electretの場合、bias電圧をtip/ringのどちらに印加するか選択できます。
Electretの場合、mic端子が

3.5mm monoの物（Heil iC等）は当然ですがtipに印加します。
3.5mm stereoの物（通常のPC用multimedia headsets）はringに印加します。

（参考）PCのMIC IN端子はtipとringの両方に約2～3Vのbias電圧が出ています。

FSK (RTTY)

FSKだけならCWの次に配線が少なくて済みます。

USB audio codecを内蔵している最近のrigsの場合、受信音声はCATと同じUSB cable経由に出来ますので、後はFSKとPTT信号を配線するだけです。PTTは8pin MIC端子経由でも良いのですが、FSKと同じ背面のACC端子経由としてしまえば配線が1本減らせます。

MMTTY等のapplication内で受信音声（録音）を該当のUSB deviceに正しく設定します。

EXTFSKは使用しません。u2Rが正確なFSK信号を生成しますので、MMTTYの「PTT & FSK」では直接COM port（USB Device Routerで指定した物）を指定します。
最近のN1MM Loggerでは、ConfigurerでDigital port（FSK送信 port）の設定が不要になり、MMTTY等のapplication内で設定する方式になったようです。（Configurerで設定しても動作に影響は無いようだが、無視されている？）

AFSK (PSK等)

基本的にはVoice用の配線と同じです。

受信音声（録音）は、FSKと同様にUSB audio device経由にします。（出来ない場合は下記「USB audio codecを内蔵していないrigsの場合」を参照。）
送信音声（再生）はUSB audio device経由には出来ません(*)。これは、u2Rでlevel調整などを行えるようにするためです。RigsのALC表示を見ながら、送信音が過変調にならないように前面のツマミで音声levelを調節します。（つまり送信音声はanalogとなります。）

MMVARIやN1MM Logger等の該当設定で、送信・受信音声deviceを正しく設定してください。送信（再生）はPC内蔵のsound card device、受信（録音）はUSB audio deviceないし下記LINE IN deviceとなると思います。

(*)と書きましたが、その後N1MM Logger/MMVARIを使用して、送信音声（再生）をUSB audio device経由にしても使える事が判りました。

N1MM LoggerのDigital Interface Windowの「Setup/Settings」→「MMVARI Setup」で「Output Soundcard（DI1/DI2）」をそれぞれのrigの内蔵USB audio codecにします。受信（Input Soundcard）と同じになるはずです。
送受信音声ともUSB cableを経由しますので、u2RとPC間の「SC OUT←→PC PHONES」、「SC MIC←→PC MIC IN」の2本の配線、「u2R（DB9）→rigのMic端子（8p）」への音声配線は不要になります。
送信focus（PTT）はN1MM LoggerとUSB Device Routerが制御してくれますが、rigへのPTTの送り方には複数の方法があります。

1. 前面MIC端子または背面ACC端子経由で結線（hardware PTT）

u2R（USB Device Router）を介して制御します。このやり方が一番確実です。

2. CAT commandsによるsoftware PTT

PC（N1MM Logger）からrigを直接制御します。

3. Digital VOX

USB経由音声に対するrigのVOXです。

後2者の方法では、以下のいずれかを行わないとu2RはPTT状態を検知できません。ですが検知できなくてもN1MM LoggerがrigsのPTT制御を直接行うので、SO2R運用自体に影響はないものと思われます。

PCからu2Rにhardware PTTを同時に出す。
rigのSEND→PTT IN（DB9）の結線をする。

送信音声はu2Rを経由しませんので、前面のツマミで送信音量（変調の深さ）を調整することは出来ません。Rigsに内蔵されたUSBの音量調整機能を使って下さい。

（2014/5/21 追記）

USB audio codecを内蔵していないrigsの場合

FSK、AFSKの受信には、rig背面のACC端子のAF OUTからのanalog音声を用います。配線は下図の様に一部変更されます（右上の深緑色の部分）。

PCのMIC IN端子はmonauralであるうえUSB Device RouterのVoice録音機能により既に占有されていますので、stereoのLINE IN端子を用います。Laptop PCsには通常付いていませんので、安価な外付けUSB audio device（単なるMic端子付ではなく、LINE入力の付いているもの）を使いましょう。

また、ground loop noise対策として、isolation transformer等を挟む方が良いでしょう。

JIDX CW準備：県別希少度調査

2014-04-09T16:02:00.001+09:00

今週末に迫ったJIDX CW Contestを前に、都道府県multiのrare度について調べてみた。

下表は昨年（2013）のJIDX CW Contestの結果よりQTHを総務省検索やQRZ.com、各種blog等を参考に推定し、集計したものである。Log提出した366の国内局の都道府県別内訳、88,490総QSOの都道府県別内訳、それらの対全国比率%を示した。

なお数局はQTHを推定したが、大部分は合っていると思う。但し4局だけはarea内移動（例：JQ5QQQ/5）でdatabaseから移動地をどうしても特定できなかった。（1、2、5、0 area各1局ずつ）

佐賀や福井が希少なのはわかるが、熊本からのQRVがzeroだった事には驚いた。全般に九州からは参加が少ない傾向があるようだ。

FTDI USB<->Serial(TTL)変換Cableを用いた、Kenwood TS-450/690/790/850/950用Rig Control Cableの製作

2014-02-22T20:18:00.001+09:00

この時代のKenwoodのrig control interfaceは、背面のDIN 6pin connector（ACC1）にserial信号がTTL負論理で出ているという大変特殊なものである。

TS-950を使う機会があったので、秋月電子通商で入手できるFTDI USB<->Serial(TTL)変換Cable（税込み 1,340円）を用いて、rig control cableを自作してみることにした。秋月のこのFTDI USB cablesには5V品と3.3V品がありますが、今回使用するのは5V品です。間違えて3.3V品を買わないように・・・（もしかしたら動くかもしれないけど[未確認]）。

DIN connectorは秋月では売ってませんので、隣の千石電商かマルツパーツ館等で入手しましょう。
なお、同じideaの物はeBay等で手頃な値段で販売されていますので、こうした完成品を買われても良いと思います。

製作の際には、TS-950SDXの取扱説明書（パソコンコントロールの頁、端子信号表がある）の他、こちらのKL7NAのpageが大変参考になりました。

作り方

秋月のFTDI USB<->TTL Cableのpin端子側をばらし、DIN connectorに配線します。GND、TxD、RxD、CTS、RTSの5本を配線し、FTDI Cable側のVCC 5Vはもちろん配線しません。

注意すべきなのは、TxDとRxD、CTSとRTSはstraight配線ではなくcrossさせることです。

なお、CTSとRTSは配線せず、Kenwood ACC1側のDIN connectorの4（CTS）と5（RTS）を短絡せさせておくだけでも動作します。（つまりこの場合GND、TxD、RxDの3本しか配線しません。）

次に、Kenwoodのrig control通信のTTL負論理に対応させる必要があります。これにはFTDI社提供（無料）のFT_PROGという専用toolを用いてcableに内蔵されているFT232R chipの信号論理を反転させます。EEPROM書き換えですが、特別な治具は不要です。

Download後、USB cableをPCに接続し、FT_PROGを起動します。
EEPROM tabのDevices > Scan and Parse (F5)でcableが認識されるはずです。（認識されないようなら先にFTDI USB cableのdriverをinstallしてください。）

上図のようにHardware Specific > Invert RS232 Signalsと辿り、TxD、RxD、RTS、CTSの4つの信号に反転のcheckを入れ、Devices > Program (Ctrl+P)を実行するだけです。

以上で完成です！！

FTDI USB<->TTL Cableの利点

USB Serial変換chipはFTDI（Glasgow, Scotland）の他、Prolific（台湾）、Silicon Labs（Texas, USA）等が有名所です。後2社の方がcost performanceは良いのですが、信頼性ではFTDIがピカ一のようです。

Prolificは安価なUSB Serial変換cablesによく採用され、人気のある秋月の900円のcableもこのchipですが、困ったことに中国製の偽造chipsが広く出回っています。Prolific社は最近のdriverでは識別対策を取るなどしており、またWindows 8でchipの古いversionには対応しないなど不便な点が出てきています。残念ですが秋月cableはHXAというこの古いversionに該当し（偽造chipではありません、念の為）、Windows 8では動作しなくなっています。（古いdriverなら動作する可能性がありますが、推奨できません。Windows Updateを行うと新しいdriverに上書きされるでしょう。）

FTDIはWindowsの全てのversionに対応していますので、このような心配もなく安心して使えます。

また本記事の応用例として、同じcableを用いてKenwoodだけではなくICOM CI-VやYaesuのTTL信号形式（FT-817/857/897等）用のcableも、同様に作成することが出来ると思います。

Buffalo外付けUSB HDDの修理

2014-02-01T23:00:00.000+09:00

3年以上使ったとは思うBuffaloの外付けUSB HDD（HD-CN1.5TU2）の調子が2～3週前から悪い。自動的に切断、再接続を繰り返す。そろそろ寿命かと思い急いで代替品を注文したが、届く前についにaccess出来なくなってしまった。まずい、まだback upしていない。

症状だが、HDD unitの電源を入れても、PCから全然認識出来ない。とにかくunitの故障なのかHDD本体の故障なのか、開筐して調べることにした。HDDが生きていたら、dataを吸い上げることが出来る。

そういえば、今回は特にHDD故障の時によくある異音は全くしていなかった。Unitの故障だといいのだが・・・・。

開筐はとても簡単で、筐体下面前方のネジ1本を外し、前面coverを外すだけ。Coverの上部は爪で固定されているだけ。後は左右coversを引き抜く。HDDはinchネジ2本で簡単に外れる。

まずHDDを取り外し、別のSATA-USB interfaceを付けてみた。今度は問題なくPCで認識できた。異音もしない。これでdata救済は成功だ。良かった。

ならunitの故障だろう。比較的スカスカの筐体の中にはinterface基板と電源基板しかないが、壊れるものといったら電源基板しかないだろう。

やはりだ。電源基板に超怪しげなcapsを発見。

液漏れしてるし、こりゃダメでしょうな。ちゃんと電源供給出来なくなって切断・再接続を繰り返していたわけだ。

容量・耐圧は2200μF 10Vと1000μF 16V、一応105℃品のようだ。部品を探さなくてはならないが、基板にぴたりsizeなので計測してみる。φ10mm☓20mm高である。交換用capsは直径が1mmでも大きいと入らない。

完全にぴたりではないが、秋月電子で同規格の物（ルビコン、国産品）が簡単に入手できた。高さが同じではないが、直径はφ10mmの物だ。部品代たったの110円也。

2日後、届いたので交換してみる。

少し背が高いのと低いのになったが、スカスカの筐体なので問題ない範囲である。

外したcapsは台湾Ltec（輝城電子股份有限公司）というmakerのLZG series。検索してみると液漏れで有名らしい。規格表によるとφ10mm品は寿命6,000時間だが、うちのPCは常時電源ONに近いから、それ位は確かに使ったかもしれない。しかし105℃で使っていた訳ではないから、やはりこのcaps、寿命は短すぎるよね。

筐体を組み戻したところ、問題なく動作した。成功だ。

CT1BOH Spot Quality Filterを使ってみる

2014-01-02T11:02:00.002+09:00

CT1BOHが考案し、AB5KがAR-Cluster（V6）に新機能として実装し、N4ZRが普及促進しているものです（link先pageの前半はCC Clusterの話ですが、後半に図入り解説があります）。N1MM Loggerでの使い方はこちら。（他、こちらやこちらやこちらやこちらの記事も参考になるかもしれません。）

まずこちらのpage等を参考にしてAR-Cluster（V6）に接続してください。

初期設定ではtagsは表示されていません。また選別filtersは何も掛かっていません。Dupe込みのdataが流れてきます。Filterを使うにはまず、次のcommandを入力します。

set dx ext skimmerquality

するとtagsがcomment欄右端に表示されるようになります。Tagsは?、V、Q、Bの4つがあります。その意味はこちらのpageで解説しました。Bustedの場合は正しいと思われるcallsignがtagの横に括弧付きで表示されます。

余りに流れが速いので、まずdupesのみ抑制するには次のようにします。

set dx fil not skimdupe

これで「流速」がかなり落ち着くと思います。

実際のコンテスト運用では、例えば次のようにしてB(usted spots)やQタグを除きます。

set dx fil not skimdupe and not skimbusted and not skimqsy

かなりすっきりしたdataになりました。まさにcontestでlogging programに取り込むのにお勧めの設定です。（Qタグには未確定のQSYやI/Q imageが含まれるのですが、残しておくべきかは難しいところです。）

一方、B(suted spots)だけを試しに眺めてみたい時は、次のようにします。

set dx fil skimbusted

面白いbusted callsignsが見られますが、時には誤判定もあるようです。

現在のfilter設定を確認するには、次のcommandを使います。

sh dx fil （又は sh fil）

Telnet DX Clustersの使用法

2014-01-01T16:18:00.002+09:00

当局が運用している下記3つのTelnet DX Clusters nodesの使い方について、別のpageにまとめてみました。

Node Call	Node Software	Host Name	Port	RBN Spots
JG1VGX-7	CC Cluster	ccc.jg1vgx.net	7373	有
JG1VGX-8	AR-Cluster V6	arc.jg1vgx.net	7000	有
JG1VGX-9	DXSpider	dxc.jg1vgx.net	7300	無

それぞれcommands体系がかなり違っているので、接続後にfilters等細かい設定をされる方は上記の解説pageを是非御一読下さい。

どのclusterに接続するか？

Skimmer (RBN) spotsが欲しい方は、JG1VGX-7か-8に接続して下さい。どちらも源流はreversebeacon.netですので、流れてくる物は（原則として）同じです。

現在RBN spotsを流す事が出来るnode softwareは、AR-Cluster V6とCC Clusterの2つだけです。
DXCluster.INFOの一覧表上で (+CW Skimmer) と表示されている各国のnodesは当局のnodesと同様にRBN spotsが流れてくる物が多いでしょう。

各node softwareの特徴

CC Cluster (VE7CC)

専用のuser program (CC User)があります。Filters設定等、command lineでの操作は煩雑になりかつ見辛いので、このCC Userの使用がお勧めです。但し慣れる迄に少々時間がかかると思います。

GUIで非常に細かいfilters設定が出来、EmailによるDX spotsお知らせ機能もあります。DX huntingにもcontestingにも便利でしょう。

Skimmer dupesは初期設定では除かれています。（許可することも可能。）

AR-Cluster V6 (AB5K)

大量のdataを高速かつ軽量に処理出来るため、RBN基幹serversのsoftwareにも採用されています。
こちらも専用のclient program (AR-Cluster Client)がありますが、残念な事に現versionは日本語環境では動作しません。Control Panelで英語localeに設定すれば動作しますが、今の所それ程多機能なprogramではないようです。
RBN spotsについてCT1BOH考案の品質分析algorithmsが実装されています。特にcontests終盤で悩ませられる各種のbusted spotsや強力局のI/Q imageによる誤spotsを除く事が出来、品質の高いspotsが得られます。

具体的な使用法については別記事にしました。

DXSpider (G1TLH)

最も広く使われているので、このsoftwareのcommands群に慣れている方も多いのではないかと思います。

コマンド早見表 (JG1VGX)

Skimmer技術が出来る前の時代に作られ、Perlという比較的遅い文字列処理言語で書かれています。この為高速化、scalabilityに限界があり、大量のRBN spotsを扱う事が出来ません。

それでもつい最近迄、2つのRBN基幹serversのうちの1つはDXSpider（を改修した物？）上で動いていました。しかし、2013年のCQ WW CW Contestの際に遂に負荷に耐え切れなくなりpacketsの遅延、lock up等の重大な不具合が生じました。現在は2つの基幹servers共AR-Cluster V6上で動作しています。

軽量Linux distroの比較

2013-12-28T18:29:00.001+09:00

既に現役使用から引退している2009年modelのネットブック（下記：dynabook UX/27、XP搭載）に軽量Linuxをinstallしてみようと思い、いろいろ試してみた報告である。

来年以降もXPを使い続けることにはやはり不安がある他、4年も使い続けたネットブックはapplicationsてんこ盛りで遅くて使用に耐えない物になっていた。

筆者は15年程前よりLinuxを使い始め、今もAmazon Cloud上の2台のDebian serversでAPRS-IS serversやDX Clusters等を運用しているが、ここ数年Linuxを使うのはserver用途が主で、desktop Linux OSを試すのは本当に久し振りである。

選択のpoints

使い古した遅いmachineにinstallするので、「軽量」であることが最優先。
Debian（またはUbuntu）系。これは私の好み。

Linux Mint　★★☆☆☆

Version: 16 (Petra), MATE desktop

調べてみると、現在最も人気が高いdistributionという評価が多く、真っ先にinstallしてみた。複数のwindow managersが選べるというのも良いかもしれない。今回は最新版GNOME 3に準拠したCinnamonの方ではなく、GNOME 2に準拠しより安定性の高そうなMATEというwindow managerのversionを選択した。

しかし次の点で私の好みに合わないため、残念ながら真っ先に削除してしまった。

重い。無駄が多すぎる。

あらゆるapplicationsがpre-installされている事が特徴らしいが、逆に言えば不要な物まで最初から入っているという事である。例えば、LibreOffice等必要であれば簡単にinstallできるのだから、「全部入り」がmeritとは余り思えない。筆者はこのblogのtheme選択を見れば分かるようにかなりのminimalistであるから、筆者の嗜好に合わないのである。
Windowsと同じ操作性を求める方には、この点は確かに良いのかもしれない。Core i7等搭載の新鋭機であれば、速度の点は問題にならないと思う。しかし速度やresourcesにcriticalな陳旧機向きではない。

Designが好みでない。

目障りな黄緑色とかmetallic silverが筆者の審美眼に全く訴えかけない。そう言えば似たようなthemeがXPのdefaultにもあったなあ・・・。これは機能とは全く関係が無いが、毎日使いするには筆者にとっては重要なpointである。

Xubuntu　★★★☆☆

Version: 13.10 (Saucy Salamander)

Ubuntu派生distributionの一つ。Window managerに軽量なXfceを使用している。これはかなり良かった。

Designがsimpleで美しい。

minimalistの筆者に十分に訴えかけるsimpleさと機能性である。

完成度がかなり高く、最小限の利便性も備える。

次に述べるLubuntuに比べて、Settings Manager（WindowsのControl Panelに相当）や画面下部のlauncher等、若干便利な点があると思った。

しかし、次の点に不満が残った。

Ubuntuと比べてそれ程軽くない。

自分で実験した訳ではないが、他siteのbenchmark dataを見たところ、memory使用量について次のような結果があった。

Ubuntu ≒ Xubuntu ＞ Lubuntu

ただし筆者は2G RAMをinstallしてあり、これを使い切るようなheavyなtestはしておらず、実感としてはLubuntuと比べて必ずしも遅いとは感じられなかった。（Linux Mint PetraはXubuntu、Lubuntuより明らかに遅かった。）

Lubuntu　★★★★☆

Version: 13.10 (Saucy Salamander)

これもUbuntu派生distribution。軽量化を主眼に開発されたLXDEという専用のwindow managerが使われている。これまで挙げた3つのdistributionsのうちでは最も筆者の趣向に合うものだった。

Ubuntu派生distributionの中では最も軽量（多分）。

起動もかなり速い。
ただし、少し前のversionsに比べてやや遅く（重く）なっていると記載されたsitesもあった。筆者自身が比較していないので実際のところは分からない。

Designがsimpleで美しい。

Xubuntuと同じ濃青を基調とした目に優しいdesktopは大変好感が持てる。
Xubuntuのような集約的なControl Panelは無いが、特に困るものでもない。
Launcherとしては、WindowsのQuick Launch Toolbarのように、頻用applicationsへのshortcutsを並べることが出来る（画面左下）。

CrunchBang Linux　★★★★★

Version: 11 (Waldorf)

最後にinstallしたのだが、ついに筆者の理想のdistributionに辿り着いた、という感じである。「もう絶対コレしか無い！」と思っています。

一切の虚飾を排し、軽量化を極限まで追求した形。

起動はめちゃめちゃ速いです。
Ubuntuより更にbasicなDebianをbaseにしています。

Simpleで見た目が最高に美しい。

違いの分かるminimalist専用のdistributionでしょう。Openboxという超軽量window managerを使用。
Ubuntuの茶色でもなく、Mintの緑/銀でもなく、Xubuntu/Lubuntuの紺でもなく、monotonousなgrayscaleをsiteにもdesktopにも採用。この潔さ。

使い易い。

Launcherはありません。Hotkeyです。特に、普段使い道のない"Windows" key（"Super" key）を使えるのは良いと思う。Browserも、terminalも、file managerも、hotkeyで一発呼び出しです。スゴイ！
Conkyというsystem monitorがdefaultでinstallされていて、desktopにmemory使用状況、CPU使用率、Shortcut Keys hintなどが表示（＋更新）されていて、とても便利です。

感想とまとめ

数年振りに各distributionsをinstallしてみて、昔と比べてdesktop Linuxの完成度はかなり上がっていると感じた。

昔からLinuxはinstallまでは簡単だが、bugsや制約も多く、日本語入力環境を構築するのさえ苦労した。Devicesも対応していない物もあり、printersを動かすにも大変だった。
昔、VineLinuxという完成度の高い日本製distributionがあった。（今もあることに少し驚いた。）日本語環境がちゃんと動く、唯一の「使い物になる」Linux distributionだったと思う。海外発distributionsも、今はdefaultで日本語対応がなされ、ほぼあの水準の完成度に達していると感じた。
日本語環境は、ibus-anthyやibus-mozcを事後にinstall、設定する必要があったが、何の支障もなく動いた。Defaultで「全角/半角」keyが動作するのには、昔のLinuxを知る筆者はちょっと感激した。
Printersはmakersのsitesからdriversをdownloadし、指示通りにinstallしたらCUPSでそのまま動いた。これは素晴らしい事だと思う。ほぼWindows並にprintersが使えるのだから。

しかし今でも、筆者はLinuxがWindows代替になるとは思っていない。

完成度は確かに上がった。しかし、所詮freeの物であるから、bugsはたくさん残っている。正式対応されていないdevicesもまだまだ多い。kernel levelのbugsも少しはあってもおかしくない。
実際に、筆者の環境でもいくつかの不具合があった。例えば、無線LANが頻繁に途切れたり。しかし大抵の場合は、Google先生に聞けば5～60分以内に問題は解決できた。昔は解決法を検索するのに丸一日～数日かかったり、解決できない問題もかなりあった。
対策はconfig filesの修正等のcommand line levelの作業となり、そういうのに慣れていない方には難儀に感じる所かも知れない。しかし、Linuxを使う以上は、そうした作業はまだまだ避けられないと思う。つまり、まだ一般向けとは言えない、という事だ。
Linuxが簡単に動くようになったとは言っても、Windows用applicationsが簡単に動くようになったわけではない。世の中はcloud basedになったから、web browser（とflash player）さえ動けば、日常のある程度の作業は出来るようになった。この意味で、sub machineとして、あるいはネットブックとして（つまりweb検索とemail送受信が主）なら十分に使えるとは思う。

Windows XP support終了後も、筆者のmainのPCはLinuxでもMacでもなく、Windows（7または8）だと思う。趣味、仕事を問わない。

MicrosoftやWindowsが好きでも無いのだが、やはり日常作業の生産性が一番高いのはWindowsである。Macに比べて市場価格もこなれており、machinesの性能も高い。

Linux distributionは軽量でなくてはならないと思う。

新しいCore i7のmachineを購入して、Windowsを消してLinuxを入れて日常作業に使う人がどれだけ居るのだろう？筆者は勿体無くてそんな事は絶対に出来ない。
となると、desktop Linuxの利用価値は、今回のように使い古したmachinesを再生する等の用途が多いのではないだろうか？そうすると、Linux Mintのような「全部入り」の重いdistributionよりは軽量distributionsの方が利用価値が高いと思う。そもそも、Windows XPが使い続けられてきた理由の一つは、Vista等後継OSに比べて軽量で安定しており、陳旧機にも使えて、またdevicesにも多く対応していた事なのだから。

N1MM LoggerとMorse Runnerとの連携

2013-12-11T21:00:00.000+09:00

以前そんな事が出来ると聞いた事はあったが、やり方が分からなかったが、ようやく分かったのでここにご紹介したい。これはN1MM Loggerを使う方にとって、CW contestsの事前練習として最適だ。せめて先月のCQ WW CWの前にこれを知っていれば・・・。

用意するもの

この2つは、ここを見ている皆さんのPCにはもう既にinstallしてあることと思います。
さらに必要なのはN1MM LoggerとMorse Runnerとの連携プログラムで、K7OG提供の物です。

N1MM to Morse Runner Connector (by K7OG)

詳しい事は作者K7OGの解説をお読みください。（読まなくても動作させられますが。）YouTube動画もあります。
なお、AutoHotkey（freeware）をinstallしてscript fileを使う別法もありますが、上記のexeファイルを使用する方法が簡単です。（AutoHotkeyのinstallは不要。）

手順

で、使い方は超簡単。上記3つのprogramsを起動させるだけです。（N1MM Logger -> Connector -> MorseRunner の順に起動します。）また、次のように設定すると使いやすいです。

N1MM Logger

ConfigurerでCWを送出する設定にしておきます。Rigは接続されていなくて構いません。DummyのCOM portでOKです。（普通にN1MM LoggerでCW運用する設定のままRigをOFFにしておく。）実際のCW（音）はMorse Runnerが発生させます。
Run modeにしておいてください。（Alt-U）
ESMはONが良いです。
LogとしてCQWPXCWで新しいlogを作成しておきます。何度も繰り返して練習する時は、Morse Runnerのstart前にN1MM LoggerでWIPELOG（Entry窓にそう入力）するとlogが初期化されます。

Morse Runner

Run buttonを押してstartさせるだけです。

おまけ（窓の整理の仕方）

N1MM LoggerのBandmap等の窓はこの「練習環境」では不要ですので、例えば上図のように窓を並べると使いやすいでしょう。Morse Runnerの窓も見えていないといけません。普段使っているN1MM Loggerの窓の位置に影響を与えないようにするには次のようにします。

普段使いのN1MM Loggerの窓配置を保存するために、まず「Tools」>「Save Window Positions」を実行します。
「OPON」（又はCtrl-O）のoperator切り替え機能を用いて適当なoperator名（例「MRUNNER」）にoperatorを変更します。Info窓で確認してください。
上図は一例ですが、好みの窓位置に配列しなおしたら、再度「Tools」>「Save Window Positions」を実行します。
この状態で、operatorを切り替えることにより、普段使いのN1MM Loggerの窓配置と、このsimulator用の窓配置を切り替えることが出来るようになります。Hooray!

	5/12	5/13	5/14	5/15	5/16	5/17	5/18	5/19	5/20	5/21	5/22	Avg
SFI	162	159	163	152	138	133	127	116	117	113	111	135
SSN	164	138	162	130	136	164	138	130	126	100	70	132
A	7	4	4	3	5	3	4	5	3	2	8	5

JG1VGX

Philips HQ482 バッテリ交換

QRQ (モールス・トレーナ by DJ1YFK) のご紹介

QRQ by DJ1YFK

ToplistへのScore送付方法

Windows XPの場合

Windows Vista/7/8/10の場合

Debian Linuxの場合

Mac OSの場合

まとめ

CQ WW CWのcondition（結果）

今年（2015）の結果

1日目（2015/11/28） SFI 96, SSN 36

2日目（2015/11/29） SFI 95, SSN 47

感想

週末のCQ WW CWに備える

昨年（2014）の状況は？

1日目（2014/11/29） SFI 177, SSN 156

2日目（2014/11/30） SFI 177, SSN 153

最近のcondition

週末の戦略

SparkFun Geiger CounterのArduino化

ICSP pinheadersの取り付け

Fuseの設定

Bootloaderの書き込み

Arduino IDEの設定

13番pin LEDの追加

Sketchのupload

他のbootloaderを用いる

Arduino化完了！

SparkFun Geiger Counterの改修

SparkFun Geiger Counterの世代

問題点

修正作業

修正前の状態

途中経過

最終修正

あとがき

WAE SSB @JG1ZUY

CME（コロナ質量放出）と磁気嵐

Contest中の状況

結果

直前condition：AA Phone

AP Sprint #58 (Summer, SSB) 敗因分析

2014年

筆者の戦略

筆者のLog

N1MM Loggerを日本語鍵盤で使いこなす

N1MM Loggerを日本語鍵盤で使用する時の問題

Key配列の違い

英語（US）鍵盤

日本語（JIS）鍵盤

N1MM Loggerでの特殊key配列

英語鍵盤でのdefault配列

日本語鍵盤でのdefault配列

解決方法

（方法１） 外付けの英語（US）鍵盤を取り付ける

（方法２） 日本語鍵盤を英語（US）配列として認識させる

（方法３） N1MM Logger内のConfigurerでkey配列を（一部）変更する

まとめ

WAE CW @JG1ZUY

台風11号が直撃

1日目（8/9）：SFI=113, SSN=111, A=3

2日目（8/10）：SFI=108, SSN=64, A=8

まとめ

6mのDX Openings

日毎の大陸別spot数

時間毎の大陸別spot数

IARU HFのcondition

IARU HFのcondition予測

Kenwood TS-590、TS-990からのLinear Amplifier制御

機械式relayを使う方法

半導体switchを使う方法

IC-PW1用緩衝回路入りLinear Amplifier制御cableの製作

Photo relayを用いる方法（高耐圧版）

Digital Transistorを用いる方法（低耐圧版）

Kenwood exciter側の設定

TS-590の場合

TS-990の場合

CQ WPX CW @JG1ZUY

（方法１）　外付けの英語（US）鍵盤を取り付ける

（方法２）　日本語鍵盤を英語（US）配列として認識させる

（方法３）　N1MM Logger内のConfigurerでkey配列を（一部）変更する

Linux Mint　★★☆☆☆

Xubuntu　★★★☆☆

Lubuntu　★★★★☆

CrunchBang Linux　★★★★★