移動用のオールモードトランシーバーが欲しい

と思いはじめ、いろいろ調べてみた。移動といっても車も自転車もないので、バッテリーやアンテナなども含め徒歩や公共交通機関で運搬可能な範囲でなければならない。

国内だと FT-817ND というリグがこの用途ではスタンダードなようでかなりたくさんの人が使っている。FT-817ND は2001年発売とかなので、おそろしく長く売ってる無線機となっていて、国内には競合製品がない。

ほかにも候補があるか?と思ってさらに調べてみると、アメリカ Elecraft 社の KX3 というのが良さそうだということがわかった。こちらは2012年?ごろに発売された比較的新しい無線機で、FT-817ND と同じぐらい小さい。

結論からいうと表題の通り KX3 を買ったが、以下のポイントで決めた

  • 変調/復調を全部DSPでやってる
    • クラシックなスタンドアロン無線機の外観だが中身は完全にSDRでかっこいい
    • I/Q信号 (直交信号) を出力する端子があるので、サンプリングデバイスさえあればPC SDRも可能
  • 消費電力がFT-817NDに比べて多少低い (特に待機電力は低い)
    • 移動に使いたいので少しでも効率が良いと嬉しい
  • 軽い
  • ファームウェア更新の頻度が高い
    • ちゃんとメンテされており、なおかつ更新して改善できるほどの柔軟性がある

問題は主にコスト面で、FT-817ND がフィルタ込みで9万円ぐらいで買えるのに対し、KX3 は必要なオプションを入れていくと1.5倍ぐらいになる。また、技適を取得していない無線機なので、局免をとるのに結構ハードルがある。

届くまで

特に何も考えず Elecraft に直で注文した。

  1. JSTで木曜日の午前中に発注 USPS Priority Mail Express International
    1. オーダー確認メールがすぐにくる
    • なんか他の人だとこのメールに返信してる人がいるけど、ただの確認なので返信する必要ないと思う
  2. JSTで金曜日の早朝に発送
    1. PST だと木曜日の午後なので、2営業日以上かかると書いてあったけどかなり早く発送された
  3. カリフォルニア州フリーダム → サンノゼ → サンフランシスコと移動
  4. 金曜日のうちに Processed Through Sort Facility / ISC SAN FRANCISCO (USPS) になる (サンフランシスコ国際空港から発送の状態)
    1. PST では金曜早朝
  5. その日のうちに航空便に乗るかなと思ったが乗らず5日(3営業日)経過
  6. 翌週、JST 火曜日の夜に東京国際郵便局に着
    1. USPS側ではステータスは更新されず、JP (Japan Post) 側だけ先に更新
  7. 水曜日午前中、通関手続中に
  8. 2時間ぐらいで次の通関手続中
  9. 木曜日午前中に国際交換局から発送に
  10. 金曜の早朝に配達店到着
  11. 金曜の昼ごろ到着

国外にあるうちは USPS のほうが細かくステータスがアップデートされるけど、国内に入った瞬間からJPのほうが早く更新されるようになるみたい。2時間ぐらい遅れてUSPSにも反映される。


オプションや価格

モジュールキットと完成品とがあるんだけど、せっかくなのでモジュールキットにした。地味にこういうの苦手なのでちょっと心配なんだけど、Elecraft の About ページ 見てたらキットにしなければならない気がしてきたのでそうした。

ケーブルセットは案外 L 型のコネクタが手に入りにくいので買っておいた。ルーフィングフィルターは自分の用途だとたぶん必要ないけど、CW メインでやるという意気込みをもって追加した (あとから追加すると調整が面倒)。アンテナチューナーはワイヤーアンテナでもいける感じのやつなので、最悪長いケーブルさえあれば出れるように追加した。

  • KX3-K KX3 160-6 M Xcvr (Modular Kit)
  • KX3-PCKT Accessory Cable Set
  • KXFL3 dual-Passband Roofing Filter
  • KXAT3 Internal, 20-W Automatic Antenna Tuner

なかなかかかる。無線機に関税はかからないけど、消費税は税関でかかる。

注文しちゃったあとで調べたら国内代理店だと、ちょうど代理店の手数料分1万ちょいだけ浮く感じだった。直販だと届くまでに日数がかかるのと、ちゃんと届くのが不安とかがあるので、代理店で買ってもいいレベルの差ではあるかもなあという印象。

組立

思いのほか小さい箱で届く。

検品からはじめて、最初に動かすまで4時間ぐらいかかってしまった。めちゃくちゃ難しいみたいなことはないんだけど、小さいだけあって中身が狭いので、ビス締めるのが微妙にむずかったり、ケーブルの接続がしにくいとかがあった。とりあえずちゃんと動いたのでよかった。

ビスの長さが一部 (スピーカーまわり) で違ったんだけどなんとかなったっぽい。アメリカンな感じ…

ファームウェアはなぜか最初から最新 (2014-07-11) の beta 版 (production 版と別れてるんだけど) が書きこまれていたのでアップデートはしていない。

  1. トップ
  2. ham
  3. Elecraft KX3

よくあるツールなんだけど、なかなか希望に叶うものというと見つけにくく、どうせなら自分で書いたらいいかと思ったので書いてみた。やってみたら割とすぐ書けた。

MacRuby のインストールが必要。1ファイルにしたかったので、XCode なしで使っている。あんまり XCode なしでの作例がないが普通に NSApplication.sharedApplication を取得したらいいだけだった。

NSEvent.addGlobalMonitorForEventsMatchingMask:handler: は「システム環境設定」→「セキュリティとプライバシー」→「アクセシビリティ」で macruby を許可しないと使えない。これができるということは、すなわちキーロガーが実装できるということなので、必要なときだけ許可するほうがいいと思う。

#!macruby

framework "Cocoa"

class MainView < NSView
	def init
		super
		@log = ""
	end

	def drawRect(rect)
		super
		NSColor.clearColor.set
		NSRectFill(bounds)

		font = NSFont.boldSystemFontOfSize(24)

		shadow = NSShadow.alloc.init
		shadow.setShadowColor(NSColor.blackColor)
		shadow.setShadowBlurRadius(2)
		shadow.setShadowOffset([0, 0])
		attrs = NSMutableDictionary.alloc.initWithDictionary({
			NSForegroundColorAttributeName => NSColor.whiteColor,
			NSFontAttributeName            => font,
			NSShadowAttributeName          => shadow,
		})

		y = 0
		@log.split(/\n/).reverse.each do |line|
			storage   = NSTextStorage.alloc.initWithString(line, attributes: attrs)
			manager   = NSLayoutManager.alloc.init
			container = NSTextContainer.alloc.init

			manager.addTextContainer(container)
			storage.addLayoutManager(manager)

			range = manager.glyphRangeForTextContainer(container)
			10.times do
				manager.drawGlyphsForGlyphRange(range, atPoint: [0, y])
			end
			rect = manager.boundingRectForGlyphRange([0, manager.numberOfGlyphs], inTextContainer: container)
			y+= rect.size.height
		end
	end

	def <<(log)
		@log << log
		@log = @log.split(/\n+/, -1).last(5).join("\n")
	end

	def clear
		@log.clear
	end

end

class AppDelegate
	attr_accessor :window
	def applicationDidFinishLaunching(a_notification)
		@enable = true

		prevKeyed = 0
		unless AXIsProcessTrusted()
			$stderr.puts "Require setting"
			system('open', '/System/Library/PreferencePanes/Security.prefPane')
			exit
		end

		NSEvent.addGlobalMonitorForEventsMatchingMask(NSKeyDownMask, handler: lambda {|e|
			return unless e.type == NSKeyDown

			mod = ""
			if e.modifierFlags & NSShiftKeyMask != 0
				mod += "⇧"
			end

			if e.modifierFlags & NSControlKeyMask != 0
				mod += "⌃"
			end

			if e.modifierFlags & NSAlternateKeyMask != 0
				mod += "⌥"
			end

			if e.modifierFlags & NSCommandKeyMask != 0
				mod += "⌘"
			end

			if (e.modifierFlags & NSControlKeyMask != 0) && (e.modifierFlags & NSCommandKeyMask != 0) && e.charactersIgnoringModifiers == 'l'
				@enable = !@enable
				@view.clear
				@view << (@enable ? "[enabled]" : "[disabled]")
				@view.needsDisplay = true
				return
			end

			if @enable
				if e.modifierFlags & (NSControlKeyMask | NSAlternateKeyMask | NSCommandKeyMask) == 0
					char = readable(e.characters)
					if Time.now.to_i - prevKeyed > 1
						@view << "\n#{char}"
					else
						@view << char
					end
				else
					@view << "\n#{mod}#{readable(e.charactersIgnoringModifiers).upcase}\n"
				end
				@view.needsDisplay = true
			end

			prevKeyed = Time.now.to_i
		})
		rect = [0, 0, 800, 500]
		@window = NSWindow.alloc.initWithContentRect(rect, styleMask: NSBorderlessWindowMask, backing: NSBackingStoreBuffered, defer: 0)
		@window.opaque = false
		@window.hasShadow = false
		@window.level = 1000
		@window.movableByWindowBackground = true
		# @window.ignoresMouseEvents = true
		@window.makeKeyAndOrderFront(nil)
		@window.orderFrontRegardless

		@view = MainView.alloc.initWithFrame(rect)
		@view.init
		@view << "Initialized"

		@window.contentView = @view
	end

	REPLACE_MAP = {
		"\r"   => "↵\n",
		"\e"   => "⎋",
		"\t"   => "⇥",
		"\x19" => "⇤",
		" "    => "␣",
		"\x7f" => "⌫",
		"\x03" => "⌤",
		"\xEF\x9C\xA8" => "⌦",
		"\xEF\x9C\x84" => "[F1]",
		"\xEF\x9C\x85" => "[F2]",
		"\xEF\x9C\x86" => "[F3]",
		"\xEF\x9C\x87" => "[F4]",
		"\xEF\x9C\x88" => "[F5]",
		"\xEF\x9C\x89" => "[F6]",
		"\xEF\x9C\x8A" => "[F7]",
		"\xEF\x9C\x8B" => "[F8]",
		"\xEF\x9C\x8C" => "[F9]",
		"\xEF\x9C\x8D" => "[F10]",
		"\xEF\x9C\x8E" => "[F11]",
		"\xEF\x9C\x8F" => "[F12]",

		"\xEF\x9C\x80" => "↑",
		"\xEF\x9C\x81" => "↓",
		"\xEF\x9C\x82" => "←",
		"\xEF\x9C\x83" => "→",
		"\xEF\x9C\xAC" => "⇞",
		"\xEF\x9C\xAD" => "⇟",
		"\xEF\x9C\xA9" => "↖",
		"\xEF\x9C\xAB" => "↘",
	}

	def readable(char)
		p char
		re = Regexp.new(REPLACE_MAP.keys.map {|i| Regexp.escape(i) }.join("|"))
		char.gsub(re, REPLACE_MAP)
	end
end

app = NSApplication.sharedApplication
app.delegate = AppDelegate.new
app.run
  1. トップ
  2. tech
  3. MacRuby でスクリーンキャスト用のキー履歴表示ツールを作る

電子負荷

電源のテストを行いたいときは、適当な抵抗を繋いだりするわけだが、特定の抵抗値を狙ってつくるのはめんどうくさく、また許容損失が大きいものはつくりにくい。

そこでパワーバイポーラトランジスタやパワーFETを使って可変抵抗にする、というのが電子負荷らしい。

仕様

電子負荷には定抵抗モード・定電流モード・定電力モードなどいろいろあるが、今回は面倒なので定電流モードのだけを考えてある。

  • 14V 3A (42W) ぐらい流したい
  • 温度によりシャットダウンをつけたい
  • 簡易電流・電圧・電力計をつけたい

完成

とりあえずこんな感じになった。

回路図

試行錯誤

メインのパワーFETは2SK1122に

  • 25℃時の許容損失が100W
  • エンハンスメント型かつ Vth が低い
  • 1個150円ぐらいで割と安い

許容損失は温度上昇に伴なって下がっていくが、このFETの場合 60℃ぐらいでは70W、90℃までいくと50Wになる。

放熱が必須なのでとりあえず安いCPUクーラーを買った。1000円もしないが PWM 制御のファン付きでお得

実験1

まず単体の 2SK1122 のゲートに可変抵抗で分圧した電圧を加えつつ、放熱器に貼りつけて 12V 2A 程度まであげつつ流してみた。

指で触れられないぐらい熱くなるということがまずわかったので、ちゃんと温度を測りながらにするため、直読温度センサーも一緒に貼りつけて温度を実測しながらに切り替えた。

FET単体でも定電流素子として使われることがある通り、これでもある程度は安定して流れてくれる。ただ、FET が定電流なのは温度が変わらないことや、負荷電圧が変化しないことが条件なので、温度上昇に伴なって電流量は増えていってしまい、電流量が増えるとさらに発熱するという、ある種の暴走状態になる。この実験では放熱器をつけて、電源側で最大2Aに制限しているので、65℃ぐらいで安定する感じだった。

実験2

電流制限を安定させるため、オペアンプのフィードバックをつけた。オペアンプは単電源でつかえて安い LM385 にした。動作が遅いので発振もしにくそう。

オペアンプの入力の +/- は常に同じ電位になるように調整される (バーチャルショート/イマジナリショート)

+ に入れた電圧と、抵抗上部の電圧が等しくなるようにオペアンプの出力が自動でいい感じに変化するという挙動になるため、+ に入れた電圧と抵抗の比 (I=V/R) にのみ依存する形で定電流動作をするようになる。いろいろ別に抵抗がついているのは動作安定のため (FETの入力の抵抗はオペアンプの出力電流を制限するため・帰還の抵抗は発振防止)。

入力側の分圧抵抗によってレンジを決めている。入力する最大電圧を設定することで最大電流を決められる。

実験3

放熱器に素子をもっと押しつけるといいみたいな話を聞いたので、FETまわりだけケースに取り付けることにした。CPU クーラーなのでプッシュピンがついており、固定にはこれを使える。だいたい 75mm の幅でM4の穴をあけると丁度いいみたい。

ただ、これだけだとFETがケースにちゃんと接触せず、圧力がかからないので、適当なナットを貼りつけて厚さを増やしている。

この状態で 2A 12V かけると 55℃程度で安定する。13.8V 5A かけると90℃ぐらいで安定する (69W 90℃なので許容損失はオーバーだけど)

その他実装

コントローラはAVRで、以下のような機能を実装してある

  • 温度によってファン速度の変更 (ヒステリシスに動く)
  • 電圧計・電流計・電力計
    • ボタンで切り替え
  • 現在温度からFETの許容損失を計算し、一定の範囲内から超えたことが観測された場合強制的に停止する
    • 強制的に温度表示に切り替わって点滅することで状態表示

表示は4桁の7セグを1セグごとにダイナミック点灯させている。1桁ずつ表示するのが普通っぽい?けど、部品を増やしたくなかったので、同時に電流が流れすぎないようにした。

やばそうなとき強制停止する機能をつけたかったので、オペアンプの入力用の電圧はAVRのポートから出している。ただ、あんまりこれは電圧が安定していないので、シャントレギュレータで基準電圧をつくってからボリュームで分圧してる。上側のボリュームは半固定で、最大値を調整するためにつけてる。実際操作するのは下側のボリュームになってる。

  1. トップ
  2. tech
  3. 今 (物理的に) 半導体が熱い!!! (電子負荷)

いまいちイメージがしにくくて理解したとはいいきれてない部分の覚書

平衡経路は差動信号、すなわち位相が反転した信号を2線に乗せ、接地せずに伝送する。

対して不平衡経路はシングルエンド、すなわり片方を接地させて信号を伝送する。

信号伝送の形式が違うので、当然直接接続してはいけない。直接接続した場合、不平衡側は GND を基準としているので、GND の変動はすなわち信号線にもGNDが変動しただけの変動が発生するということであり。これはコモンモードのノイズということになる。

バランによって平衡・不平衡を接続することができる。

電圧バラン(トランス)の場合、差動信号の入力は出力からすると単に信号がおおきくなったようにみえる。GND は絶縁されており、コモンモードは発生しない。

Uマッチというバランの場合、片方の伝送路を1/2λ遅延させることによって位相を反転させて逆相を得て平衡信号を作りだす

電流バランの場合、GND変動によって発生するコモンモード電流を遮断する形で機能する。性質上完全に遮断しにくいが、ロスも少ない。

  1. トップ
  2. tech
  3. バランの役目・平衡とは何なのか

AngularJS には $qっていう promise の枠組みがあるので、使っておくといいこと (ビューが自動的に更新されるだけだけど) がある。フレームワーク組込みの仕組みがあるのに別途 Deferred の仕組み、しかも thenable(笑) じゃない(笑) JSDeferred を読むのもバカにされると思うので、以下のように JSDeferred から Angular $q へ置き換える方法を記す。

基本

JSDeferred における global な next() 関数を $q.when().then() に置き換え、Deferred#next を then() に置き換えればだいたい動く

next(function () {
    alert(1);
    return next(function () {
        alert(2);
    }).
    next(function () {
        alert(3);
    });
}).
next(function () {
    alert(4);
});

こういうのを、こう

$q.when().then(function () {
    alert(1);
    return $q.when().then(function () {
        alert(2);
    }).
    then(function () {
        alert(3);
    });
}).
then(function () {
    alert(4);
});

parallel() は?

$q.all() を使え

loop() は?

頑張って書く。いろいろやりかたはあると思うけど、例えばこう

$q.when().then(function () {
	var list = [1, 2, 3], sum = 0;
	return $q.when().then(function loop () {
		if (list.length) {
			return $q.when(list.shift()).then(function(item) {
				console.log('item', item);
				sum += item;
			}).then(loop);
		} else {
			return sum;
		}
	});
}).
then(function (result) {
	console.log(result);
});

wait() は?

setiTimeout で頑張って書く

  1. トップ
  2. tech
  3. JSDeferred -> Angular $q 置き換え方法

name (flash/sram) cost

USB 対応

  • ATmega32u2 (32k/1k) 400円
  • AT90USB162 (16k/0.5k) 300円
  • 最大16MHz
  • USB ホストにもなれる
  • 12Mbps 対応
  • 外付け部品が少し簡単
  • 表面実装品しかない

V-USB

  • ATmega328p (32k/2k) 250円
  • ATmega168p (16k/1k) 200円
  • ATTiny2313 (2k/128) 150円
  • 最大20MHz (5V動作時)
  • USBスレーブにしかなれない
  • ファームウェアコードにいくらか制限あり (割込み頻度とか)
  • ドライバが GPL
  • DIPあり

感想

  • V-USB はファームウェアを GPL にするか、ライセンス購入する必要があるが、個人の趣味レベルではどうでもいい
  • 価格の絶対差はそれほどでもないが、同じ金額で1個買えるか、2個買えるかと考えるとだいぶ違いを感じる
  • よりスマートなのは USB 対応のを使うことだと思うが、見た目的にはどっちもワンチップで完結する
  • USB 対応品は、USB 周辺については 3.3V で動いておりレギュレータを内蔵している。V-USB は高いクロックで動かそうとするとVCCを5Vにせざるを得なくて、そこらへん泥臭くなってしまう

去年AVR で USB 接続の PC キーヤーを作るということをやったのだけど、結局ちゃんと形にはせず放置してしまっていた。最近なんとなく自分の中で PC キーイングの機運が高まってきたので、まじめに安定したものを作ろうと頑張って、ある程度成果がでてきた。

当然似たようなデバイスは既にあるので、改めて作る必要はないんだけど、自分で作れそうなものは、一回ぐらい自分で作りたいものですね。

ハードウェア

安定して動くように試行錯誤した結果、USB のデータラインに 100pF のパスコン (ノイズ対策)、リセットピンを外部プルアップ (USB のデータラインに電流が多く流れて、リセットされやすくなるので)、USB ラインのツェナーダイオードをちゃんと計ってから使う、18MHz の水晶 (CRCチェック用) とかになった。あとはもともとと同じだと思う。

ファームウェア

USB まわりを割と丁寧に実装しなおした。UI との整合性をとるため、機能をちょいちょい足している。usbFunctionWrite で -1 を返すと STALL の意味になるとか、V-USB のドキュメントをよく読んだほうがいい。

ソフトウェア

ドライバをカーネルレベルで書くのはデバッグが大変で嫌なので、最初から libusb 関係のものを使うことしか考えてなかった。最初は Chrome App から直接 chrome.usb で扱おうとしたのだが、いろいろあってやめて、ruby + libusb + em-websocket で WebSocket サーバを書いて中継している。

libusb の同期的インターフェイスは、実際のところ非同期インターフェイスのラッパーになっており、マルチスレッド環境で使うとレースコンディションが発生することがある。libusb のドキュメントにいろいろ書いてあるが、面倒なので ruby 側で mutex のロックをかけるようにしたら解決したので深く追ってない。

また、ホットプラグ対応もなんか刺さったりしてつらいのでやめて、デバイスが接続されていないときは定期的にポーリングするというクソっぽいけど正確に動く実装にした。

インターフェイス

そして WebSocket で通信するページをペライチで作って試してている。全部込みで動画にしてみた。

今後

まずは無闇にストールしたり、刺さったりしないという基本的な部分で安定することを目指して頑張った。「もう無理では……」と思ったこともあったけど、いつのまにか結構安定した。ただ、実際の運用まで行ってないので、インターフェアにどれぐらい耐性があるかはわかってない。試験電波を出してオシロで信号ラインを見た感じだと大丈夫そうだけど、よくわからない。

手持ちのユニバーサル基板に組んだので、作ってみたらケースを含めちょっと大きくなってしまった。内容的にはたいしたことがないので、フリスクケースに収まるような基板を作ってみたい。

あとは、ログツールとの連携をしたいと思っているけど、ログツールを作りなおしているので、まだまだ先になりそう。

  1. トップ
  2. tech
  3. 自作 USB CW キーイングデバイスを作る
  1. トップ
  2. ham
  3. 自作 USB CW キーイングデバイスを作る

ただ聴くだけのモールス練習に若干飽きてきて、MorseRunner というのを試してみたら、おもしろかった。Mac でも homebrew の wine で普通に動いてくれる。

コンテストを想定した練習ソフトみたいな感じになっていて、F1 で CQ を出して、呼んでくる局のコールサインを聴きとって入力し、RET を押すと、自動的に相手局にコンテストナンバーが送られ、相手局が返してくるコンテストナンバーを聴きとって入力したら1局終わり。

聴きとれないときは F7 押したりするともう一度打ってくれたりする。結構実際に交信しているみたいで楽しい。

以下の画像は HST モードで1時間やってみたもの。ぶっちゃけ15分ぐらいから辛くて早く終わってほしい感じになる。普段は 10分のシングルコールかパイルアップで遊んでる。シングルコールはあんまり頭使わないので、だんだん眠くなるけど、聴きとれるというのが楽しい。パイルアップは、とにかく2文字とって訊き返すというのが大事でおもしろい。

シングルコールがただ聴くだけだから一番局数は稼げる?と思うけど、自分の場合 30wpm でやると、だいたい10分で30局超えたらいいみたいな感じだった。しかし S と H の区別がはっきりつけられないので厳しい気持ちになることがある。

  1. トップ
  2. tech
  3. MorseRunner
  1. トップ
  2. ham
  3. MorseRunner

スクリーンキャストとカメラの同時録画 の動画を撮ったときは Mac 内蔵のカメラを使ったので、自由にカメラを動かせず難儀した。ウェブカメラが欲しいなーと思ったけど、よく考えたら優秀なカメラが既にあるので、利用できないかと考えた。

結論からいうと、直接ウェブカメラとして使うことは簡単にはできない。なので、

  • EOS Utility でライブビュー撮影モードにする (PC にカメラの画像がリアルタイムに反映される)
  • それをスクリーンキャスト用のツールでカメラデバイスにする

という方法をとる必要がある。


スクリーンキャストとカメラの同時録画をしたいというだけなら、単に EOS Utility のウィンドウを直接録画したらいいので、簡単。ただ、どうしてもちょっと映像が遅れるので、それを許容できる場合にだけ使える。

  1. トップ
  2. tech
  3. デジタル一眼レフ (EOS) をウェブカメラ的にとして使う

ハルロック(1) (モーニング KC) - 西餅

西餅

5.0 / 5.0

うっかりウェブに公開されているやつを読んでしまったら面白かったので買ってしまった。最近電子工作にハマってるのでタイムリーだった。

題材が電子工作で、そこらかしこに流行りワードがちらばっているけど、そういうのよりは主人公の女子大生が狂ってるのを楽しむ感じで、ゲラゲラ笑える。


なんともいえないのは、最初おじさん先生から PIC が出てくるんだけど、卒業すると登場するのが Arduino やら Raspberry Pi やら AVR になっていくので愉快な感じ。

自分も主人公ほどではないにせよ、小さいときに分解魔だったので (分解したからといって原理がわかるわけではない) そのへんも共感できた。

前までできなかったと思うんだけど、比較的簡単にできるようになっていた。

QuickTime Player に「ファイル」→「新規画面収録」というのがあり、これを使うと音声入力を含めてスクリーンキャストを録画できる。

外部カメラも同時にとる場合は「ファイル」→「新規ムービー収録」を選択するとカメラの状態が画面にでるようになる。この状態でも「新規画面収録」を行うことができ、カメラとスクリーンを同時に録画可能になっている。

収録しおわったら「編集」→「トリム」で不要な前後も簡単に削除できるので、あせって録画する必要はない。

試しに録画したもの


一つ欠点があって、できるあがるファイルが .mov なので、どっかにアップロードするなら

ffmpeg -i input.mov output.mp4

とか適当にしたほうがいいっぽい。

  1. トップ
  2. tech
  3. Mac で外部カメラとスクリーン録画を同時にやる (カメラ+スクリーンキャスト)

直近の Mac OS X Mavericks アップデートの直後あたりから (これが直接の原因かはわからないけど)、例え HID デバイスではなくても chrome.usb を単体で動かすことができなくなった。

今まではデバイス接続後に Chrome 全体を再起動することで openDevice が成功するという挙動だったのだが、今ではデバイス接続後に他の libusb を使ったプログラムを走らせて一旦 device を OS に認識させ、そのプログラムを終了し Chrome を起動する、という手順が必要になった。

つまり単体で再起動を繰替えしたりしてなんとか動かすということが不可能になり外部プログラムへ依存が必要になった。Chrome はどのようなコンテキストでも外部プログラムを実行することはできないので、打つ手はなくなった。

chromium のイシュートラッカーを usb 関係で検索してみると


あたりが関係していそう。 Canary を入れたくないので 35.0.1916.153 でしか試してない。stable で動かないものは「ない」と同じ。


このほか以下のようなバグがありそう

  • コントロール転送で8バイト未満をデバイスから返すと、データが化ける (こちらから送ったリクエストのバイナリ列になってしまう。謎)
  • インタラプト転送でずっとレスポンスしないでいると、デバイスにアクセスできなくなる。定期的に必ずなにか返答しないとだめ。

それとバグではないが、コントロール転送を out する場合、何も data を送りたくなくても、data : new ArrayBuffer(0) を渡さないと実行されない。罠。