2014年 08月 23日

エアコンからアマチュア無線に混入するノイズ

ノイズ源の特定までやったはいいが、うまい対策をうたなければならない。

このノイズ源特定のときは、とりあえず電源ラインに内径1cmぐらいのパッチンコアを挟んでみたが、うまくいかなくて悲しい、という状態で終わった。その後、対策を考えなおした。

  • 室内機の電源ラインにもっと大きなコアを巻いてみる
  • 室内機と室外機とを繋ぐ線にCMFを入れる

室内機の電源ラインにもっと大きなコアを巻いてみる

ハムフェアにて内径19mm外形40mmの大型のコアを購入したので、これを5ターンほどエアコンの電源ラインに巻いてみた。

これは効果が抜群だった。(コアは内側を1回通る=1ターンなので、この画像で5ターン)

対策前

対策後:

コアを閉じた瞬間から減りはじめて感動的な体験をする

室内機と室外機とを繋ぐ線にCMFを入れる

かなり狭い領域かつパッツンパッツンなので、あまりコアを入れる余地がない。

とりあえず1ターン入れてみたが、あまり効果が見られなかった。複数個入れれば違うのかもしれないけど、入れるスペースがなかったためひとまず諦めた。

基本的に巻数の2乗に比例してインピーダンスが上昇するので、複数回巻けないというのはかなり厳しい。5ターンのコア1つと同じインピーダンスを1ターンのコアを複数で解決しようとすると単純に25個必要になる。

今回の教訓

1回小さいコア入れたぐらいで諦めず、複数回巻けるコアでも試してみる。

あと根本的にコアのデータシートから「このぐらいのインピーダンスが主流」っていうのを感じとっておいて、巻数でどれぐらいインピーダンスが上がるか、目安程度でも感覚的に想像できるようになると便利そう。最近得た知見としては

  • ローバンドほど対策が厳しい
    • 元々低い周波数だとコアのインピーダンスが低いので、かなり巻きまくる必要がある
    • 例えば7MHzで20Ωのインピーダンスのコアだと、1つのコアに13回巻かないと目安となる3kΩにならない。
  • 巻きすぎるとハイバンドでの特性が悪化する

村田製作所がコアの選定方法というページを公開していて便利

移動用パドル

移動用の小さいパドルが欲しいなと思っていた。あまり使わないと思うので最低限キーイングができればいいかな、というぐらいの温度感だけど、割と高価なものが多い (最低でも10k) ので買ってなかった。最悪PCキーイングだけでなんとかするというのでもいいけど、割と考えが保守的なのでキーなしで運用とかビクビクしてしまう。

ハムフェアで何かいい感じのを自作している人がいたら買ってみようと思っていたが、いろいろ悩んだ結果「どこでもパドル MINI」というのを買ってみた。Wood のキットバージョンで3000円だった。

大変可愛いらしい見た目で、メインの機構はマイクロスイッチになっており、これは板バネなので細かい調整はできないが、使ってみると思ったよりかなり気持ちいい。

キットで買ったのだけれど、無鉛ハンダまでついていて親切感がだいぶ高かった (露出して手が触れやすいところにハンダ付けする必要があるための配慮のようでかなり嬉しい)

土台は買わなかったので、手元にあった金具でKX3の本体ローレット部分に固定してみた。結構いい。けど、振動でローレットとかがゆるむので、もうちょっといい形で固定したい。

縞黒檀を選んだけどかなり可愛い。自分は渋いのが好きらしい。

2014年 08月 20日

192kHz サンプリングのUSBオーディオデバイス

バンドスコープ を作ったのはいいが、41.1kHz サンプリングだし、0Hz付近にUSB オーディオデバイス由来の強力なノイズが入ってるのがイケてないので、良さげな192kHz サンプリングのUSBオーディオデバイスが欲しくなった。

SDR 用サウンドカードのまとめ みたいなページを見てみたけど、現状手に入るなかでよさそうなのは Steinberg UR22 というのしかない。これも注釈がついてて「ノイズがあるよ」って書いてあるけど、HFでは問題にならなそうとのことなので、買ってみた。

asin:B00B19JBW2:detail 3

独自のドライバが必要で (UAC2 とかじゃない) 嫌な感じだけど、普通に Mac 用の提供されている (Yamaha Steinberg Driver とかでググる) のでそこらへんではハマらなかった。

しかしこれ、用途的に宅録みたいなの向けなので、入力や出力がちょっとややこしい。入力はXLR(キヤノンコネクタ)バランス入力・3極標準プラグ (ステレオ標準プラグ = 6.3mm) バランス入力・2極標準プラグ (モノラル標準プラグ = 6.3mm) アンバランス入力といろいろ対応されている。KX3 の出力は 2.5mm ステレオジャックでこれはアンバランスなので、2.5mm ステレオジャックからモノラル標準ジャック2本へ変換が必要になる。

2.5mm ジャック -> 3.5mm プラグへの変換は KX3 注文時に一緒に買ってあるので、以下のように3.5mmジャック・ジャックと、3.5mm プラグ → 6.3mm プラグ×2 の変換を買った。

asin:B003UXCZHA:detail 4

asin:B000UDADBI:detail 4

入力なしのとき

ちょっとノイズが立ってるところがあるけど、全域でだいぶノイズが少なくなった。中心周波数付近のノイズが皆無になったのはデカい…

±30kHz 付近のノイズは電源のスイッチングノイズで、直接オーディオインターフェイスに飛びこんでいるっぽい。それ意外の 60kHzぐらいから90kHz までのノイズはUSBインターフェイスのノイズっぽい。

入力いれたとき


両端に向かってゲインが下がっていくのは KX3 のマニュアルにも書いてあって、KX3 出力時点でこうなってしまう。FFT したあと補正するのがいいと思うけど、まだやってない。

The RX I/Q outputs from a receiver are not “flat” over an infinite frequency range; the signal-conversion process results in some slope (decrease in gain) as you move farther from the center frequency. In the case of the KX3, the signal will be reduced by about 2.5 dB at +/- 24 kHz, 4 dB at +/- 48 kHz, and 7 dB at +/- 96 kHz. The spectrum amplitude on the display, including the apparent noise floor of the receiver, will “roll off” by these amounts.

KX3 Owner's man Rev B4

192kHz の範囲が一望できるのがなんかすごい広くなる。

96kHz サンプリングだとあんまり気にならない範囲になる。狭くなるけど CW の場合 96kHz ぐらいで見たほうが選局しやすい気がする…

だいぶいい。

身近なノイズ源を特定する

ウォーターフォール表示で遊んでいて、アマチュア無線のバンド全域に繰り返し強いノイズが入っていたり、部分的に超強力なノイズが入っていたりすることがあって、気になっていた。

少し自分の周辺機器をみまわして電源を切ったり入れたりしたらかなり変わったのでメモしておく

主要機器を切った状態

切れそうな機械の電源をだいたい切った状態


すぐ電源切れないデバイスも結構あるけど、かなり静かになった。

エアコン

規則的なノイズが全域に入る。エアコンはどのバンドでもノイズが入るけど、14MHz帯が一番ひどい。

空気清浄機

ダイキンの空気清浄機の電源を入れるとエアコンと似たようなノイズがかなり強く全域に入る。

モーターのブラシノイズなんだろうか? よくわからない。放電ノイズっぽくはないけど

スイッチング電源のノイズ

特定の周波数ごとに強力なノイズが入る。負荷に応じてノイズが揺らぐのが特徴っぽい。7MHz や 10MHz あたりが一番ひどい。ハイバンドになるほど強度が下がっていく。

蛍光灯のノイズ

14MHz帯に入っていた。画像はつけた直後で、なんか周波数を変えながら「ログインしてきました!」って面してるのが蛍光灯ノイズ。

これとは別に蛍光灯のデスクライト(インバーター制御)もあって、それはそれでこれとは違うノイズの入りかたをする。デスクライトのほうがだいぶ広範囲でひどい。

その他

USB HDD か、その電源アダプタ(スイッチング)かがノイズを出していたが電源ケーブルにコアを巻いたら、これはかなり改善した。HDD 側のノイズが電源ラインに戻ってたのかな?

今回、

  • 扇風機
  • MacBook Proの電源アダプタ

はノイズ源ではなかった。

2014年 08月 19日

golang で event emitter/dispatcher 的なもの

golang で JS 的な addEventListener/dispatchEvent 的なことをしたいときどうするか?

emission

JS にあるようなのと全く同じ様に「イベント名」でイベントの種類を識別して任意の「イベントオブジェクト」をやりとりする。

On/Off/Once とか jQuery にあるような便利メソッドがついてる。

リフレクションで型変換は隠蔽されているが、もしリスナーとエミッターとで型が食い違っていると、実行時エラーになる。

package main

import (
	"github.com/chuckpreslar/emission"
	"log"
)

type ClickEvent struct {
	button string
}

type KeyEvent struct {
	key string
}

func main() {
	emitter := emission.NewEmitter()
	emitter.On("click", func (ev *ClickEvent) {
		log.Printf("onclick %v", ev)
	})
	emitter.On("key", func (ev *KeyEvent) {
		log.Printf("onkey %v", ev)
	})

	emitter.Emit("click", &ClickEvent{ button : "left" })
	emitter.Emit("click", &ClickEvent{ button : "right" })
	emitter.Emit("key", &KeyEvent{ key : "A" })

	// panic
	emitter.Emit("key", &ClickEvent{ button : "right" })

	// or also panic
	emitter.On("key", func (ev *ClickEvent) {
		log.Printf("onkey2 %v", ev)
	})
	emitter.Emit("key", &KeyEvent{ button : "right" })
}

go-pubsub

Pub/Sub/Leave というメソッドが生えている。Pub は Emit/Dispatch, Sub は addListener/On, Leave は removeListener/Off に対応する。

「イベント名」というパラメータが存在せず、型の選択によって自動的にディスパッチされる。よって型がマッチしなければリスナーは実行されないので、原理的に型変換の実行時エラーは発生しない (もし間違えた場合単に実行時になって「呼ばれない」ことに気付く)

package main

import (
	"github.com/mattn/go-pubsub"
	"log"
	"time"
)

type ClickEvent struct {
	button string
}

type KeyEvent struct {
	key string
}

func main() {
	ps := pubsub.New()

	ps.Sub(func(ev *ClickEvent) {
		log.Printf("onclick %v", ev)
	})
	ps.Sub(func(ev *KeyEvent) {
		log.Printf("onkey %v", ev)
	})

	ps.Pub(&ClickEvent{button: "left"})
	ps.Pub(&ClickEvent{button: "right"})
	ps.Pub(&KeyEvent{key: "A"})

	time.Sleep(100 * time.Millisecond)
}

サンプルコード書いてて気付いたが、Sub に登録した関数は Sub を呼んだ順あるいは Pub を呼んだ順に関係なく実行されうる? (ref. 登録された関数を go で呼んでる)

下記コードのように time.Sleep の代わりに Pub/Sub によって終了を待とうとするとたまに失敗する。(完全に終了を待つ方法がわからなかった)

package main

import (
	"github.com/mattn/go-pubsub"
	"log"
)

type ClickEvent struct {
	button string
}

type KeyEvent struct {
	key string
}

func main() {
	ps := pubsub.New()

	ps.Sub(func(ev *ClickEvent) {
		log.Printf("onclick %v", ev)
	})
	ps.Sub(func(ev *KeyEvent) {
		log.Printf("onkey %v", ev)
	})

	ps.Pub(&ClickEvent{button: "left"})
	ps.Pub(&ClickEvent{button: "right"})
	ps.Pub(&KeyEvent{key: "A"})

	// waiting for processing all messages
	// -> FAIL
	done := make(chan bool)
	ps.Sub(func(b bool) {
		ps.Close()
		done <- true
	})
	ps.Pub(true)
	<-done
}
2014年 08月 18日

蚊取り線香

【防除用医薬部外品】アースノーマット 60日用 蚊取り 蚊とり黒ブタ - アースノーマット

アースノーマット

5.0 / 5.0

これを寝室とリビングの1つずつ買った。黒いブタバージョンで可愛い。電源ケーブルが「しっぽ」になっているのも地味にいいデザインだなあと思う。昔ながらの陶器のブタの蚊取り線香って僕は現実で見たことがないけど、それでもブタの形が「蚊取り線香」をイメージさせるというのは、なんかおもしろい。

アースノーマットって、動いている気配が一切ないのでちょっと不安だけど一応効いてるみたい。

2014年 08月 17日

OpenGL で PBO 使ってテクスチャ更新するときの型式

なんかいまいちよくわからない (以下はgolangでのコードだけど、特にgolangに限らないはなし)

// PBO 作成
buffer := gl.GenBuffer()
buffer.Bind(gl.PIXEL_UNPACK_BUFFER)
gl.BufferData(gl.PIXEL_UNPACK_BUFFER, width*height*4, nil, gl.STREAM_DRAW)
buffer.Unbind(gl.PIXEL_UNPACK_BUFFER)

// テクスチャ作成
texture := gl.GenTexture()
texture.Bind(gl.TEXTURE_2D)
gl.TexParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.LINEAR)
gl.TexParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR)
gl.TexImage2D(gl.TEXTURE_2D, 0, gl.RGBA, width, height, 0, gl.RGBA, gl.UNSIGNED_INT_8_8_8_8_REV, nil)
texture.Unbind(gl.TEXTURE_2D)

以上のように初期化して、

texture.Bind(gl.TEXTURE_2D)
buffer.Bind(gl.PIXEL_UNPACK_BUFFER)
bitmap := *(*[]uint32)(gl.MapBufferSlice(gl.PIXEL_UNPACK_BUFFER, gl.READ_WRITE, 4))
// ... do something
gl.UnmapBuffer(gl.PIXEL_UNPACK_BUFFER)
drawBuffer.Unbind(gl.PIXEL_UNPACK_BUFFER)


buffer.Bind(gl.PIXEL_UNPACK_BUFFER)
gl.TexSubImage2D(gl.TEXTURE_2D, 0, 0, 0, fftBinSize, historySize, gl.RGBA, gl.UNSIGNED_INT_8_8_8_8_REV, nil)
buffer.Unbind(gl.PIXEL_UNPACK_BUFFER)

以上のように更新をしてる。

このとき、TexSubImage2D の引数にある gl.RGBA 及び gl.UNSIGNED_INT_8_8_8_8_REV を正しく(?)指定しないと余計に CPU 負荷がかかる。つまりGPUがネイティブに取り扱えるかどうかで決まると思うんだけど、何が GPU ネイティブなのかがよくわからない…

多少試した感じだと

  • gl.RGBA/gl.UNSIGNED_INT_8_8_8_8_REV
  • gl.BGRA/gl.UNSIGNED_INT_8_8_8_8_REV

の場合だけ高速に動作する。gl.RGBA/gl.UNSIGNED_INT_8_8_8_8 とかだとダメ。gl.RGBA は OpenGL ネイティブがこの型式だかららしいけど、gl.BGRA でもいけるのがよくわからない……

2014年 08月 16日

golang で websocket

websocket.JSON を使った場合

JSON をやりとりする場合専用の方法がある

(JSON-RPC ライクな実装を書いてみた場合)

package main

import (
	"fmt"
	"log"
	"net/http"

	"code.google.com/p/go.net/websocket"
)

type JSONRPCRequest struct {
	Method string      `json:"method"`
	Params []interface{} `json:"params"`
	Id     uint        `json:"id"`
}

type JSONRPCResponse struct {
	Id     uint        `json:"id"`
	Result interface{} `json:"result"`
	Error  interface{} `json:"error"`
}

type JSONRPCEventResponse struct {
	Result interface{} `json:"result"`
	Error  interface{} `json:"error"`
}

func main() {
	port := 51234

	http.Handle("/", websocket.Handler(func(ws *websocket.Conn) {
		log.Printf("New websocket: %v", ws)
		var req JSONRPCRequest
		for {
			if err := websocket.JSON.Receive(ws, &req); err != nil {
				break
			}
			log.Printf("Request: %v", req)
			res := &JSONRPCResponse{Id: req.Id}

			switch req.Method {
			case "echo":
				res.Result = req.Params
			default:
				res.Error = "unkown method"
			}
			log.Printf("Response: %v", res)
			websocket.JSON.Send(ws, res)
		}
		log.Printf("Closed websocket: %v", ws)
	}))
	log.Printf("websocket server listen: %d", port)
	err := http.ListenAndServe(fmt.Sprintf(":%d", port), nil)
	if err != nil {
		panic(err)
	}
}

websocket.Message を使った場合

JSON だけやりとりするなら必要ないけどこのようにも書ける

  • websocket.Message.Receive(ws, &in)
  • websocket.Message.Send(ws, string(out))

をつかう。websocket.Message.Send の第2引数は byte[] だと JS 側では Blob を受けとれ、string だと JS 側では string を受けとれる。

バイナリを扱う場合、必然的にこちらをつかうことになる

同じことを冗長にやったコード

package main

import (
	"encoding/json"
	"fmt"
	"log"
	"net/http"

	"code.google.com/p/go.net/websocket"
)

type JSONRPCRequest struct {
	Method string      `json:"method"`
	Params interface{} `json:"params"`
	Id     uint        `json:"id"`
}

type JSONRPCResponse struct {
	Id     uint        `json:"id"`
	Result interface{} `json:"result"`
	Error  interface{} `json:"error"`
}

type JSONRPCEventResponse struct {
	Result interface{} `json:"result"`
	Error  interface{} `json:"error"`
}

func main() {
	port := 51234

	http.Handle("/", websocket.Handler(func(ws *websocket.Conn) {
		log.Printf("New websocket: %v", ws)
		var in []byte
		for {
			if err := websocket.Message.Receive(ws, &in); err != nil {
				break
			}

			log.Printf("Request: %s", in)
			req := &JSONRPCRequest{}
			json.Unmarshal(in, req)
			res := &JSONRPCResponse{Id: req.Id}

			switch req.Method {
			case "echo":
				res.Result = req.Params
			default:
				res.Error = "unkown method"
			}
			out, err := json.Marshal(res)
			if err != nil {
				panic(err)
			}
			log.Printf("Response: %s", out)
			websocket.Message.Send(ws, string(out))
		}
		log.Printf("Closed websocket: %v", ws)
	}))
	log.Printf("websocket server listen: %d", port)
	err := http.ListenAndServe(fmt.Sprintf(":%d", port), nil)
	if err != nil {
		panic(err)
	}
}

KX3 の KY コマンド

KX3 はシリアル通信経由で直接 CW をエンコードして送信できる。つまりいわゆる専用の CW USB インターフェイスが必要がない。(RTTY も KX3 側でエンコードしてくれるので、これによって送信できる)

使うのは KY コマンドで

KY text;

の型式で送る。KY に続く空白を W にした場合、このコマンドで指定した文字列の送信が終わるまで、後続のコマンドの実行が保留される。(一旦キーの速度を変える場合に便利)

コマンドのリファレンスには「@ を送ると即時送信停止になるよ」というようなことが書いてあるが、これは K2 というリグの話で、KX3 ではあてはまらない。

KX3 では @ は常に @ のモールス符号が送出されるようになっていて、即時停止には RX コマンドを使う。RX コマンドは即時に送信を止めて受信モードに戻る (送信中符号の送信完了も待たない)

KX3 側のバッファはあまりないみたいだが、TB コマンドで今何バイトバッファに入っているかを知ることができる。ただ、9文字以上だと常に9になってしまうので、正確にはわからない。

この機能を使って PC キーイングを作る場合以下のようになりそう

  • TB コマンドを頻繁にポーリングして状態更新しつづける
  • 送信したい文字列はバッファにいれ、5文字程度までで分割して KY 実行
  • 残り2文字程度になったらバッファから残りを KY

KX3 側に保持されているバッファの内容を取得することはできず、残り送信文字数だけしかわからない。なので同期が正確にできないと厳しい。この機能は送信中にコマンド実行する必要があるので RFI が比較的でやすく信用できるかというと微妙な気がする。

とりあえず既に USB CW インターフェイスを作ったときの UI があって、WebSocket の互換サーバーさえ書ければ動かせるので、試してみる。

Mac はかっこいいんだけど、無線機とかのボタンとツマミがいっぱいあるかっこよさとは方向が違うんだよな。

スタイリッシュであることは翻っておもねり的ダサさも感じさせるから、そうじゃないボタンとツマミにまみれたナードデバイスというのは安定のかっこよさを持ってる。