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

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

デフォルトだと、信号がありそうなところを適当に追跡してデコードする。上のスペクトラムをクリックで、その周辺の周波数領域のデコードだけをするようになる。一度に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 して全チャンネル同時デコードとかも、ギジュツリョクがあればできるだろうけど、できてない。

  1. トップ
  2. tech
  3. HTML5 Web Audio でモールスを解読する
  1. トップ
  2. html5
  3. HTML5 Web Audio でモールスを解読する
  1. トップ
  2. audio
  3. HTML5 Web Audio でモールスを解読する
  1. トップ
  2. dsp
  3. HTML5 Web Audio でモールスを解読する
  1. トップ
  2. ham
  3. HTML5 Web Audio でモールスを解読する
  1. トップ
  2. モールス
  3. HTML5 Web Audio でモールスを解読する

なんかエクセルで計算できるのがでまわっているっぽいのだけれど、HTML で計算したいので JavaScript で書きなおした。

自分で書いたら欲しい機能増やせるし便利。特に、計算したパラメータから、必要な材料の長さを出したりしたかったので canvas で全体像をレンダリングしている。

コイルも密巻きの場合を簡単に求められるようにしたりした。ただ、細長いコイルはQ値がさがってよくないらしいので低い周波数では調整する必要があるのかもしれない。でもそれでどの程度効率が変わるのかがわからない。

7MHz MicroVert アンテナを制作

φ25mm φ22mm のアルミパイプそれぞれを 1m ずつ買ってきて作った。設計上は 1m + 0.85m で 15cm ほど重ねるイメージ。

コイルを設計通りに巻くのがかなり難しく、はじまりとおわりの処理の仕方がよくわからなくて、これはうまくできたとは言い難い。

7MHz だとカウンターポイズが 8.3m 必要だけど、なんとなく買っておいた 10m の 5D-2V があったので頑張って計って切った。コアは 50MHz 用のコブラアンテナを試作したときのを流用した (12ターン 3D-2V がW1JR巻きで FT240 #44 に巻いてある)

ちなみに、設置ロケーションは給電点地上高 2m 程度で、建物からは 30cm 程度しか離すことができないので全く SWR が落ちないような予感がしていた。やってみなければわからない、と自分を励ましつつやったが、案の定全く下がらなかった。

複素インピーダンスを広域で一覧するとだいぶ下 (6.8MHzヘルツぐらい) に同調しているような感じだったのでエレメントを短くしてみたりしたが、なかなかうまくいかず。

カウンターポイズのはわせかたを変えたり、エレメントの長さを変えたりいろいろ試行錯誤しまくったあげく、7MHz 付近でエレメントは共振しているようだが SWR は下がらない (リアクタンスがないけどインピーダンスの実数が低すぎる)、という状態になったので、カウンターポイズを動かし、ようやく 1.5 程度まで下がった。

インピーダンスが低めに出ていたので、カウンターポイズをできるだけエレメントから離すように置いたら効果があった。

エレメントの長さによっては、特定の周波数 (だいたい6.8MHzぐらい) で SWR が 1.0 程度になったりした一方、7MHz 以上では SWR が下がりきらなかった。たぶんコイルの巻きすぎ?だと思うが、ほどくのが大変面倒なので、一度コイルには手をつけずエレメントだけで調整し、7.000〜7.200MHz、すなわち 7MHz 帯全域で SWR 2.0 以下にできた。最低 SWR 点が 1.5 程度なのがちょっと微妙だけど、とりあえず気にしない。

しかしその後一旦コイルの固定やらで取り外すことにしたので、コイルも1ターン巻き戻して再調整したところ、7.0MHz 付近で SWR 1.1〜1.2 ぐらいまで落とすことができた。もう1ターン戻してもよかったかもしれないが、メインで運用しているのはバンド下限あたりなのでこれでよさそう。

帯域が広いのは事前情報で知ってはいたけど、なんとなく信じていなかったので、設計時に 7MHz をターゲットにしたのがよくなかった。今回の場合 7.1MHz ぐらいをターゲットにして作る (計算上はコイルが1ターン減るだけ) と丁度よかったかもしれない。

制作上思ったこと

  • できれば調整部分は手の届く範囲にすべき
    • 1段目を短めにしたほうが調整しやすい (70cmぐらい?)
  • LCR メータがあったほうがいい (自分は持っていないのでコイルのインダクタンスがどんなものなのか、計算でしか求められない。アナライザーでも一応測れるけど結構ナイーブで値が信用しにくい)
  • アナライザーなしでは調整が困難
    • カウンターポイズを使うアンテナでは必須だと思った
  • マストと固定するため、塩ビパイプのコイルから下側は長めにしたほうがいい

使用感

UHV-6 という 2m 程度の短縮マルチバンドアンテナとの比較しかできないが、今のところ感じるのは以下の通り

  • 信号は UHV-6 と同じか、それより弱く聴こえる
  • SN は UHV-6 より少しよく感じる
    • 特に、7.01MHz 未満では、UHV-6 はなぜかノイズが常時ひどくで聴こえなかったのが、MV で聴こえるようになった。設置位置の関係かもしれない
  • とにかく帯域が広くて 7MHz ならどこにでも出れる。UHV-6 はチューナーなしだと 7.00 から 7.025 ぐらいまでしか出れないので、嬉しい感じ。

ベランダのスペースの関係上、UHV-6 と今回作った MicroVert アンテナは開けている方角が違うので、相手局の位置によって変わりそう。もうすこし耳が良いのを期待したけど、それに関しては少し期待はずれだった。短いアンテナなので、結局その点に関しては短縮ホイップと同じなのかもしれない。

  1. トップ
  2. ham
  3. MicroVert アンテナの設計ツール
  1. トップ
  2. javascript
  3. MicroVert アンテナの設計ツール

まずやはり終わって思うのは、LTとしてすら発表しなかったのが反省だな〜 と思った。「今年 Perl 関係でおもしろいことしてないし……」と思って応募できなかったけど、わりとみんな Perl 関係ないこと話してるので、堂々と JS の話すればよかったと後悔。他人が話しているのを見ると話したくなる。というか Teng の話があったな!と会期中に思いだした。

結構毎年顔ぶれが変わっているのか、オープニングで今年初めて参加した人として手を上げた数が想像よりもずっと多いことに驚いた。なんとなく印象としては普段 Perl を書きまくっている人というよりは、他のコミュニティの人が Perl 文化を見にきてる感じがした。

Google

  • https://plus.google.com/connectedaccounts で、接続して公開設定にしていると、プロフィールに表示される (これは確実にアイデンティティが関連付けされている)
  • ↑ とは別に任意のURLをプロフィールに登録できる

Facebook

  • メッセンジャーアプリのID、任意のURLしか登録できない

Hatena

  • 任意のURLが登録できる
  • Twitter、Facebook と連携でき、公開される可能性があることに留意しろという注意書きはでるが、一覧ページなどはなく、プロフィールにも表示されない

Github

  • 任意のURLが登録できるだけ

Twitter

  • 外部連携機能がない。リンクは1つのみで、だいたいの人は自分のサイトへのリンクぐらいしか貼ってない

アイデンティティ抽出

それぞれのサイトで任意のURLの登録は比較的自由。なので、それらが一致するものを抽出できればある程度アイデンティティが関連づけられそう。ただ、クロールしないとできないのでつらい。

それなりにユニークなのはメールアドレスだけど、表示されないことが多い。なにかいい方法はないか

交信ログの一部を公開するようにした。ずっとやってないと恥ずかしい感じになる。

交信ログのとりかた

Windows なら Turbo HAMLOG for Windows というのがあって、大変使いやすいし、それでいいのだれど、Mac だと無料で丁度いいのがない。有料で超高機能、みたいなのはあるけど、そこまで必要がないし、こういう「データ」が主のもので、データ管理とかが実際どうなっているのかもよくわからないソフトウェアに金を払いたいと思わない。

なので、自分に必要最低限の機能を実装しようと、SignalReports というロギングツールを自分で書いて使ってる。ローカルで動くウェブアプリの形式にした。

機能的には大変シンプルでただとにかく記録していくだけの機能がついてる。あえて「機能」と呼べるようなものはコールサインを入れると地域を表示したりするぐらい。この程度でも別に困ってない。QSL カードを発行する人は印刷機能とかいるんだろうけど、当面発行する予定もないのでこれでいい。

データのもちかた

データは単に SQLite の DB に入れるようにしてる。プロジェクトディレクトリをまるごと Dropbox に入れているので、DB ファイルも Dropbox 上でバックアップ・履歴管理される。

交信ログ公開の仕組み

Dropbox 上に DB ファイルが置いてあるので、Dropbox の API でその DB をダウンロードして、Perl で適当に HTML にして static に吐いている。特に変なことはしていなくて、あとは cron に登録してある。

  1. トップ
  2. ham
  3. 交信ログを公開