先週末に奈良に行った。
子供が歩く前に一回どっか行っておこうということで、1週間前ぐらいに急に予定を決めて1泊した。
いったところ
1日目
- 春日大社
- 東大寺 (大仏殿)
- 法隆寺
2日目
- 大神神社 (大和国一宮)
- 石上神宮
- 伏見稲荷大社
奈良、無限に歩けるならいいんだけど、子供抱っこして歩くには案外坂が多くてきつく、1つ1つのポイントが離れているので、厳しいかった。
先週末に奈良に行った。
子供が歩く前に一回どっか行っておこうということで、1週間前ぐらいに急に予定を決めて1泊した。
いったところ
1日目
2日目
奈良、無限に歩けるならいいんだけど、子供抱っこして歩くには案外坂が多くてきつく、1つ1つのポイントが離れているので、厳しいかった。
LTSpice に慣れようということで、いくつか代表的なヘッドフォンアンプの回路をシミュレーションし、全高調波歪率 (THD / Total Harmonic Distortion) を出してみた。
オペアンプには単体で70mAまで電流をとれる NJM4556A で全て統一し、増幅率もほぼ同じになるように組んだ。
THD=0.000134%
部品点数が少ないし、普通に使うぶんには完全に十分そう…
THD=0.000131%
THD=0.000150%
ヘッドフォンアンプだと良く使われるバッファ
THD=0.000055%
オペアンプ2つを使ったものだけど、パラにしているわけではなく、ホイートストンブリッジを使い電圧増幅するオペアンプと電流増幅するオペアンプとで役割をわけたもの。実際に作る場合、最初のオペアンプは殆ど負荷がかからないようになっているので、もっと低歪みのオペアンプを使う。
電流に余裕があるオペアンプなためバッファなしで十分良いという感じになった。
.four コマンドは .tran 解析の後、指定した回路のポイントをFFTして高調波歪を求められる。出力はログ (Cmd+L) に出る。デフォルトでは第9高調波まで算出するが、十分っぽい。最後に THD が表示される。
.option plotwinsize=0 を指定しないと、ものすごい数字が出てしまい、ハマった。このオプションはLTSpiceに対し、解析結果のデータ圧縮を無効にする効果がある。LTWiki の FAQ にもなっていた。歪み率を算出したいのに、データ圧縮が効いているとどうしようもない。
Comment と Directive が同じ画面で編集になっているという点に気付く。
つまり、解析コマンドのまとまりごとに別の Directive のまとまりを作り、必要ないものは Comment に切替えておくという手段をとるのが一番簡単。いちいち行頭にセミコロンを付けてまわるとかしなくて良い。
.param ディレクティブを使えば、任意の数値に名前をつけられる。参照するときは {name} とすれば良い。
LTSpice でヘッドフォンアンプを解析する | tech - 氾濫原 の続き
NJM4556A は 70mA と余裕があるオペアンプだが、こんなに電流とれるオペアンプはそれほどないので、もう少し普通のオペアンプで試してみる。
OPA2134 (= OPA134) という低歪みなオペアンプで試す。これは出力電流が±35mAと、丁度 NJM4556A の半分となる。
THD=19.97%
電流が足りず、クリッピングしてる。
THD=0.000041%
THD=0.000116%
THD=0.000022%
片方は電流ソースになるので NJM4556A のままにしてある。THD はこれが最低。
マイク入力の音質を改善したいという場合がときどきあるかもしれない。例えば
とか。
アナログでやろうとすると割と高価な機材が必要だが、現代はDSPでなんとでもなる。
Mac には標準で AU (Audio Units) という機能があり、簡単なフィルタとかはこれでできる。AU はプラグインとなっており、使うためにはアプリケーションが必要。標準アプリケーションだと Garage Band で使えるが、AU だけ使いたいのに Garage Band というのは重すぎるしめんどうくさい。
しかし、実は Apple はAU Labというソフトウェアを提供しており、標準添付ではないのだが、これをインストールすると入力を AU を通して別のデバイスに出力というのが簡単にできる。
エクスパンダないしノイズゲート・コンプレッサないしピークリミッタ相当のことをできる。
グラフ中の下側の点2つを動かすことでレベルが低い環境雑音の音量を下げる(ないし完全カット)することができる。リアルタイムにグラフのどの状態にあるかも表示されるのでとても設定しやすい
上の点2つを動かすとコンプレッサをかけることができる。入力が低すぎる場合 Master Gain をあげる。Master Gain をあげつつコンプレッサがかかる閾値を下げると常にコンプレッサがかかり出力を一定の状態にできる。
4つにわけられた帯域ごと(帯域幅は任意に変更できる)にコンプレッサレベルを変えて設定できる。設定帯域ごとのイコライザ相当の機能もついてる。エクスパンダ的機能はついていない。
高域の上限を下げたりすれば、サ行のうるささが軽減される (ディエッサーとして使える)。
他のでもできるが、このあたりを使うのがわかりやすい。ただ、イコライザはベストを見つけるのは非常に難しい。永遠に時間がかかるしだんだんゲシュタルト崩壊してくる。
自分の上げたい/下げたい周波数帯域が、聴きながらわからない場合、AUParametricEQ を入れると、特定帯域幅だけドラッグしつつ上げたり下げたりできる。目的周波数をさがすだけなら AUGraphicEQ より楽。
少しだけリバーブをかけると聞きやすくなるらしいんだけど、AUMatrixReverb は設定が難しく、少しでもかけすぎると気持ち悪い感じになるので、素人は手を出さないほうが良さそう。
AU Lab で、入力 → AU → 出力はできるのだが、出力を別のアプリケーションの入力として使いたい場合、これだけではできない。
要は一旦出力したものを、別の入力に入れればいいのだが、ハードでやると (すなわちケーブルをループバックさせる感じになる) ノイズ的に不利だし、接続が煩雑になる。
ソフトウェアとしては Sound Flower というのが良く使われている。これは Mac 上で仮想オーディオデバイスとして働くもの。しかし Yosemite ではクリッピングノイズのようなもの (プチプチ音) が発生することがあり、この問題は未だ解決していない。どうしても気になる場合ハードに一度デジタルで出してしまうのが確実そう。
もともとアマチュア無線の音声通信の了解度を、何らかの手軽な方法で上げられないかと考えて調べたはじめた。
アマチュア無線で、特にSSBという変調方法の場合、声の大きさがそのまま送信パワーになる (無音時 0W・最大で設定した出力電力)。なので、昨今の SSB 無線機には必ずスピーチプロセッサというのがついている。
スピーチプロセッサは何をしているか? というと、基本はただのコンプレッサーで、音声のダイナミックレンジを圧縮している。小さい声も大きい声もできるだけ一定の大きさに保たれるようにして、平均送信電力を上げている。
凝った人は、このスピーチプロセッサ部分を無線機組み込みではなく、外部でやってより自由に調整するらしい。特にSSBで凝ったことをやってる人場合、Hi-Fi SSB とか言ってるらしい。
アマチュア無線では占有周波数帯域幅を抑えるため、上限 3kHz 程度までで音声周波数をカットして送信 (SSBの場合、音声の帯域幅≒占有周波数帯域幅) しているので、Hi-Fi とはいっても、原音に忠実という本来の意味ではなく、了解度の向上(相手が聞きとりやすいこと・複数人同時送信されていても、耳につきやすいこと)を目指しているようだ (周波数帯域的に原音忠実というのは不可能)
(ちなみにAM中波放送の場合、音声信号は上限約10kHz程度の帯域、FM短波放送の場合約15kHz で切られている。)
音声の通信を聴いていると、確かに人によって聞きやすかったり、そうでなかったりする人がいる。声質や滑舌もあると思うが、何らかの前処理によって了解度が向上するなら、それは良いことだ。
実際のところ、あまりやれることはなくおおざっぱに言うと以下3点になりそう。
しかしそれぞれ調整するとかなり時間がかかる。
ノイズを減らすのは必須。余計なノイズを送信すれば確実に了解度は下がる。しかし一番確実な方法というのがないので、発生している場合減らすのはなかなか難しい。以下のような方法を全て試す。
イコライザは声にあわせて設定する必要がある。了解度向上という意味では150Hz以下には殆ど声としての情報がないので完全に切って良く (ただのノイズになる)、200〜300Hz は上げると少し落ち着いた感じなるが、音が籠って了解度は下がる。400〜800Hz は人によるがあまりいじらないのが良いようだ。
SSBでは原理的に「無音」を送信することができず、常に喋っていないと受信機側のAGCによってノイズでうるさくなってしまって悩ましい。同じく AGC によって、受信側で強制的にコンプレッサ相当のことが起きるため (小さい音は大きく、大きい音は小さく)、送信時に最大限コンプレッサをかけたほうがSN比が向上し了解度はあがる。
無線機に入力する直前の信号を聴いても、実はあまり意味がない。他の無線機で送信される電波そのものをモニタするほうが良い。というのも、受信機側のAGCのかかり具合に印象が大きく影響されるので、送信機に入力する信号とかなり印象が変わってしまうからだ。
実際のところダミーロードをつけて漏れた電波を聞くか、同軸切替器(アイソレーションが60dB程度あっても十分漏れてくる)とダミーロードを使う。
声の特性を知って適切で効果的なスピーチプロセッサをかけられる知識は、エンジニアリング的な範囲の音声による通信技術のひとつといえそう。
ただし、機械処理に頼った了解度向上策には限界があると感じる。滑舌が悪かったり、声が出てなければ結局意味がない。アナウンサーという職業があるように、明瞭な音声を出せることというのは、それ自体がある程度特殊な技術であるし、これもまた音声通信の技術向上であると感じる。
アマチュアは、スピーチプロセッサの使いかたのようなエンジニアリング的部分と、声の出しかたのようなオペレーション的部分を、一人で行うので、了解度向上のためには、総合的なこれら通信技術の向上が必要に思う。
CW に比べ音声は喋るだけなので技術がいらないと思われた (実際敷居は低い) が、ノイズが多く、限られた周波数帯域で了解度を上げるには、実際は思った以上の技術がいると感じる。CW は遠くに効率良く届けるという意味では、技術的難易度は音声よりも案外低いのかもしれない。
Behringer(ベリンガー) ベリンガー ダイナミックマイク ボーカル ULTRAVOICE XM8500 cho45
use strict;
use warnings;
use utf8;
use Encode;
sub encode_with_limit {
my ($encoding, $str, $limit) = @_;
$encoding = Encode::find_encoding($encoding);
my $encoded = '';
for (my $i = 0; $i < length($str); $i++) {
my $chr = $encoding->encode(substr($str, $i, 1));
if (length($encoded . $chr) > $limit) {
last;
} else {
$encoded .= $chr;
}
}
$encoded;
}
use Test::More;
is encode_with_limit('UTF-8', 'あいうえお', 1), encode_utf8('');
is encode_with_limit('UTF-8', 'あいうえお', 2), encode_utf8('');
is encode_with_limit('UTF-8', 'あいうえお', 3), encode_utf8('あ');
is encode_with_limit('UTF-8', 'あいうえお', 4), encode_utf8('あ');
is encode_with_limit('UTF-8', 'あいうえお', 5), encode_utf8('あ');
is encode_with_limit('UTF-8', 'あいうえお', 6), encode_utf8('あい');
is encode_with_limit('UTF-8', 'あいうえお', 9), encode_utf8('あいう');
done_testing; こうしたんだけど、もっと簡単にできないんだろうか…
#!/usr/bin/env perl
use strict;
use warnings;
use utf8;
use Encode;
sub encode_with_limit {
my ($encoding, $str, $limit) = @_;
$encoding = Encode::find_encoding($encoding);
my $encoded = $encoding->encode($str);
my $short = $encoding->decode(substr($encoded, 0, $limit), Encode::FB_QUIET);
$encoding->encode($short);
}
use Test::More;
is encode_with_limit('UTF-8', 'あいうえお', 1), encode_utf8('');
is encode_with_limit('UTF-8', 'あいうえお', 2), encode_utf8('');
is encode_with_limit('UTF-8', 'あいうえお', 3), encode_utf8('あ');
is encode_with_limit('UTF-8', 'あいうえお', 4), encode_utf8('あ');
is encode_with_limit('UTF-8', 'あいうえお', 5), encode_utf8('あ');
is encode_with_limit('UTF-8', 'あいうえお', 6), encode_utf8('あい');
is encode_with_limit('UTF-8', 'あいうえお', 9), encode_utf8('あいう');
done_testing; もっと簡単に書けたけど、効率は悪そう。
WebAudio での通信用に使おうと思って書いていたけど、やる気が失せてしまった。WebAudio 非依存部分だけ習作的に書いた。思ったよりややこしいデコード方法になることがわかった。
プリアンブルとして 1 (01) を n 回連続して送信したあと、0 (10) を送信してクロック同期をとり、任意長のビットをデコードするかたち。(イーサネットのプリアンブルとは互換性なし)
ManchesterEncoding = function () { this.init.apply(this, arguments) };
ManchesterEncoding.prototype = {
/**
* @constructor
*/
init : function (opts) {
var self = this;
self.clock = opts.clock;
self.preamble = opts.preamble || 8;
},
/**
* @param {Array|ByteArray|string} bytes
*/
encode : function (bytes) {
var self = this;
var preamble = self.preamble;
var clock = self.clock;
if (typeof bytes === 'string') {
var tmp = [];
for (var i = 0, len = bytes.length; i < len; i++) {
tmp.push(bytes.charCodeAt(i));
}
bytes = tmp;
}
var data = [];
var current = 0;
function sendBit(bit) {
// Send 1 as 01 (_-)
// 0 as 10 (-_)
for (var i = 0; i < clock; i++) {
data[current++] = bit ? -1 : 1;
}
for (var i = 0; i < clock; i++) {
data[current++] = bit ? 1 : -1;
}
}
// preamble: send repeated 1
for (var i = 0; i < preamble; i++) {
sendBit(1);
}
// start bit: after repeated 1 sync with logic 0
sendBit(0);
for (var i = 0, len = bytes.length; i < len; i++) {
var byte = bytes[i];
for (var b = 0; b < 8; b++) {
// msb first
if (byte & (1<<(7-b))) {
sendBit(1, 1);
} else {
sendBit(0, 1);
}
}
}
return data;
},
/**
* @param {Function} callback
* @return {{ reset: function(), decode: function(Array|ByteArray) }}
*/
decoder : function (callback) {
var self = this;
var logic = true, count = 0, clock = self.clock;
var sync = false, syncAvg = 0, syncCount = 0;
var byte = 0, bitCount = 0, bit;
var short = 0, long = 0;
var state = 'start';
return {
reset : function () {
// reset and re-wait for preamble
this.decode = self.decoder(callback).decode;
},
decode : function (data) {
for (var i = 0, len = data.length; i < len; i++) {
var current =
data[i] < -0.5 ? false :
data[i] > 0.5 ? true :
current;
var logicChanged = logic !== current;
if (logicChanged) {
// clock adjustment
if (clock * 0.5 <= count && count <= clock * 1.5) {
syncAvg += count;
syncCount++;
clock = syncAvg / syncCount;
} else
if (clock * 1.5 <= count && count <= clock * 2.5) {
syncAvg += count / 2;
syncCount++;
clock = syncAvg / syncCount;
} else {
// ERROR
clock = self.clock;
sync = false;
syncAvg = 0;
syncCount = 0;
}
logic = !logic;
if (!sync) {
// surely synchronized with preamble clock
// and detect transition to logic zero
// ~_-_-_-_-_--_
if (syncCount >= self.preamble && clock * 1.5 < count) {
sync = true;
bit = logic;
}
} else {
if (count <= clock) {
short++;
} else {
long++;
}
if (long === 1) {
long = 0;
bit = !bit;
if (bit) {
byte = byte << 1 | 1;
} else {
byte = byte << 1;
}
bitCount++;
} else
if (short == 2) {
short = 0;
if (bit) {
byte = byte << 1 | 1;
} else {
byte = byte << 1;
}
bitCount++;
}
if (bitCount == 8) {
callback(byte);
byte = 0;
bitCount = 0;
}
}
count = 0;
}
count++;
}
}
};
}
};
for (var clock = 1; clock < 10; clock++) {
var code = new ManchesterEncoding({ clock: clock });
var data = code.encode([1, 0, 24]);
var result = '';
var decoder = code.decoder(function (byte) {
// console.log([byte, String.fromCharCode(byte)]);
result += String.fromCharCode(byte);
});
var data = code.encode("Hello, World");
var noise = [];
for (var i = 0; i < 100; i++) noise.push(Math.random() < 0.5 ? 1 : 0);
decoder.decode(noise.concat(data));
console.log(result === 'Hello, World');
}
Google+ の画像自動バックアップは、デフォルトだとカメラで撮影されたものしかアップロードされない。(いつのまにかこういう仕様になってた)
なので、スクリーンショットや、他のアプリケーションが独自に保存する画像がアップロードされない。
ググると Google によるドキュメント中に「他のアプリの写真をバックアップする(Android のみ)」というのがある
ここに書いてある「フォト」アプリというのは、Google+ をインストールすると作られるショートカットのこと。
最初「メーカーカスタマイズのギャラリーアプリしかねーよ!!」と思って、設定する方法がないのかと絶望しかけた。
「フォト」アプリが見つからない場合、Google+ アプリから以下の方法で該当する画面を開ける。
手持ちのドリルは 6mm までなので、少しおおきめの穴をあけたいときはそこからリーマーで広げていたのだけれど、手動でリーマーというのは大変疲れるとともに、だんだんひっかかりが生じて星型の穴になってしまうことが多々あった。
なので、ステップドリルというのを買ってみたら、予想以上に便利だった。今迄がんばってリーマーであけてたのはなんだったの?というレベルですぐに目的の穴をあけられるし、なおかつ真円に近い綺麗な穴になった。
いわゆる鉄工用ドリルのように勝手に進まないので、電動ドリルであけるとき急に食いこんでウオッっと思うこともなくて良い。
なお空転しないように六角軸のものを買ったけど正解っぽい。
前年は技術的にはエレクトロニクス関係のスキルセットを多少上げることができたのが、自分の中では非常に大きかった。
ソフトウェア関係ではファームウェア書いてIOいじったりするのがアプリケーションレベルではできるようになったが、アルゴリズム関係が根本的に苦手なので、ファームウェアはあまり得意になれそうな気はしてない。
go 言語で自分的には実用的なアプリケーションを書いて毎日使っているので、そういうのは良かった。
これら、残念ながら本業のウェブ開発には一切生かせていないし、ウェブ開発まわりで自分の中で技術的に進歩があったかなというのは Web Audio まわりの信号処理だけで、これまた一切仕事に生かせなさそう。
抱負とか考えても、実際のところ3日も経てば忘れてしまうが思っていることだけ書いておく。
とりあえず、引き続きエレクトロニクス関係でできることを増やしたい。具体的にはアナログ回路まわりの設計を多少でもできるようになりたい。
単純に「おもしろい」という感じのことをしたい。エレクトロニクスに絡むともっと面白い気がしてるけど、それに限らずに、とにかくおもしろいことをして、おもしろいことを共有したい。
冬は寒い。寒いとブレッドボードに向きあったりするのはとても辛い。なので、布団に入っていても回路と格闘できるようにするため、回路シミュレーションツールである LTspice に手を出した。
LTspice は Linear Technology (半導体メーカー) が提供している回路シミュレーションソフトウェアであり、Windows 版と Mac 版がある。Mac 版しか触ってないが、検索すると Windows 版の画面ばっかり出てくる。UI は Windows 版と Mac 版で結構違う。
回路シミュレーションツールは、だいたい全て SPICE というソフトウェアを元にしており、元のソフトウェアの記述形式がデファクトスタンダードになっているっぽい。LTspice は比較的使いやすい UI 及び、自由度が高く、なおかつ無償のため、アマチュアで良く使われるっぽい。
Mac 版の場合、ショートカットを覚えないと、絶対に呼びだせない機能が存在する。特に罠なのは GND で、Components には存在しないし、メニューから追加できなくて困るが、キーボードショートカットの「G」で配置できる。
いずれにせよキーボードショートカットを覚えないと著しく作業効率が悪いので、公式に提供されているpdf を開いておいたほうがよさそう。
何も考えずに RUN しても、エラーしかでない。Windows 版だと親切なダイアログが出るらしいが、Mac 版では出ない。
シミュレーションコマンド を、キーボードショートカットの「S」を押して出てくるダイアログに入力して、画面内に配置することで、RUN が可能になる。
この S で出てくるダイアログの入力エリアを右クリックすると Help me Edit というメニューがあり、シミュレーションコマンドを対話的に入力できる。
RUN をすると、回路図上の任意のポイントで、ポインターがプローブの形に変わる。クリックするとその部分の電圧または電流が見れる。続けで他のポイントをクリックすると、波形が追加される。同じポイントを2度クリックすると、それだけを表示させることができる。
デフォルトで入っていないオペアンプを使いたい場合、追加する必要がある。
オペアンプの場合、最初から、汎用の opamp2 というシンボルが用意されている。これは中身(マクロモデル=等価回路) の設定されていないテンプレみたいなやつ (だと思う)。
この opamp2 を配置した上で、Value にマクロモデルの名前を指定することで、指定したマクロモデルを持つオペアンプにすることができる。
ただ、マクロモデルを適当なディレクトリに置いただけでは読みこまれないので、SPICE directive を追加し、.lib コマンドで使いたいライブラリを読みこむ必要がある。
また、提供されているマクロモデルのピンアサインが、opamp2 と一致するようにする必要がある。
よく使う JRC のオペアンプを追加する。今回は NJU7043 を使いたかった。
JRC はマクロモデルで無償提供しており、これは (本来の対象ではないが) LTspiceでも使うことができる。展開して適当に配置する (lib/sub 以下に配置すると .lib コマンドのとき比較的パスを指定しやすい)
mv ~/Downloads/Operational_Amplifiers_Macromodel ~/Library/Application\ Support/LTspice/lib/sub/JRC_OPAMP
そして、
1. Components から opamp2 を選択して配置する
2. 配置されたオペアンプを右クリック
3. Value を nju7043_s とする (サブサーキット名と一致させる)
4. S を押して SPICE directive を追加し .lib JRC_OPAMP/NJU7043/nju7043_2.lib とする (パスを指定)
OK
サブサーキット名は
grep SUBCKT JRC_OPAMP/NJU7043/nju7043_2.lib
で名前とピン配置をさがせる。
この .SUBCKT の指定は、opamp2 とピンの順番を一致させる必要がある。ピンの名前 (VDD とか VSS とか) は元のままで順番だけ一致させる。opamp2 のピン配置は右クリックして Open Symbol して、Netlist Order を全部見ていくとわかる (一発でわからない?)
結果として
.SUBCKT nju7043_s IN+ IN- VDD VSS OUT
みたいになる。
このオペアンプはオフセット電圧が最大10mVと結構大きいので、それがよく出てる(と思う)
最近 NXP Smartphone Quick-Jack Solution というドキュメントを読んだ。要約すると
というもので、特に電源をヘッドフォンジャックからとってしまおうというところが、自分の中では結構びっくりだった。確かにヘッドフォンを駆動しているわけで、多少の電流はとれるだろうけど、マイコン動かすほどとれると思っていなかった。
このソリューションの良いところは
ウェブエンジニア的には後者は特に夢が広がるところで、デバイスを用意してもらって、繋いでもらえれば、普通のウェブページから直接ハードウェアを殆ど面倒な手続きなしで利用できる (マイク入力が必要な場合だけブラウザの確認画面がでるぐらい)。もし何かしら出力してマイコンに処理させたいだけならば、権限取得的なことが一切いらない (ただし、音量は上げてもらう必要がある…)
やってみたといっても、特に気になる電源部分だけ。
手元にある HTC J butterfy (旧) を実際に使い、オーディオ出力を最大にして、どれぐらい電流をとれるか、LED を光らせることはできるか? を検証した。
とりあえず、無負荷時の出力をとっておいた。こんな感じで電圧は出ていた。
回路図書かずにさくっとやってしまった。
NXP のドキュメントだとチャージポンプ+LDOなのだが、チャージポンプ部分で無極性10uFのコンデンサを要求しており、手元にないので、この通りやるのはさっそく面倒になった。
なので、効率は落ちると思われるが手元にあるもので
という方法で3.3Vを得た。
これに200Ωの抵抗と高輝度な白色LEDを繋いだところ、冒頭の写真のように十分 (というか眩しく) 明るく光ってくれた。最近のLEDは微小な電流でもクソ明るい…
LED 光らせてるて安定した状態でこんな感じだった。黄色はステップアップ後の電圧 (ちょっと3.3Vより下がってる)、赤色は整流後の電圧 (600mV程度になってる)。
適当な大きめの抵抗負荷をかけてみた感じ、今回の構成では最大でも5mA程度が限界のようだった。
あとやっていて気付いたのだが、20kHz の出力を使うとなぜかしっかり電流がとれず、10kHz のほうが良い結果になるみたいな現象があった。ちょっとよくわからない。
突発的にやる気を出して2時間ぐらいでやったので、もうちょっと検証したいが、またやる気がでたらにする。
NXP のドキュメントのように大きなチャージポンプを組むほうが効率が良い?のだろうと思うのでやる気がでたらやりたい。
WebAudio でのコミュニケーションは作ったらまぁできるだろうという感じだけど、これもやる気がでたら (つまり良いアプリケーションが思いついたら) やりたい。
KX3 は、自宅に置いてる間は ACC1 (シリアル接続) と RX I/Q を Mac に接続しており、普通に繋ぐとグラウンドループが発生する。(KX3 -> ACC1 -> Mac -> RX /IQ -> KX3 のループ)
純正のシリアルケーブルだとあまりノイズは気にならないのだけれど、他のシリアルケーブルを転用したところ、シリアル信号にあわせたノイズが激しく観測され、ちょっと我慢ならないレベルだった。そこで (効果があるかは定かではないが) まずグラウンドループを対策することにした。
使ったのは ST-71 (600Ω:600Ω) で、ステレオなので2個使って絶縁を行った。低周波領域は比較的ロスが大きいが、試したところそこまで気にならなかった。RX I/Q は現在 96kHz でサンプルしていて、ST-71 はオーディオ帯域 (20kHz) までしか特性が書いてなくてちょっと心配だったが、帯域も問題なさそう。
でもって、絶縁してみたところ、完全にノイズが消えてくれた。どうやら本当にここのグラウンドループが原因だったようだ。
やはり無線機から出るケーブルはできる限り全て絶縁するのが良さそう。もちろんコストはかかる (トランスは500円ぐらいして案外高価)。
この他、気になるところを全部やるとすると、アンテナ線以外で
現状では対処策はないので諦めるしかない。
ref.
https://github.com/RogueAmoeba/Soundflower/issues/19
をやるとプチプチノイズがなくなる