ebay で注文した OCXO が届いたのでテストしてみました。このぐらいの小さな OCXO です。

MORION MV102 10MHz +12V OCXO

出力は HCMOS 矩形波 (10kΩ 39pF 負荷) となっています。正弦波出力が欲しかったのですが間違えて買ってしまいました。バッファしてフィルタすればいい気はします。とりあえずデジタル回路に直結でき、軽くテストするには便利なのでこれはこれで良いことにします。

GND          Us

RF   Uref   Uin

というピンアサインになっています。Us は +12V入力、RF は出力、Uref はリファレンス電圧(5V)、Uin はVCOの入力のようです。

Uin には 0〜5V で入力し、これにより±4e-7 (±4Hz) 調整できるというスペックです。

とりあえず 12V 加えるだけで 10MHz の出力が得られます。約 200mA ぐらい (2.5W程度) の消費電力があります。2時間ぐらい通電してみましたが特に下がりませんでした。クソ寒い部屋でやっているせいかもしれませんが…

OCXO なので結構熱くなります。しばらく触っていられるぐらいなので45〜55℃ぐらいでしょうか…

GPS の 1PPS で周波数カウントしてみる

GPSモジュールはこの前試した NEO-6Mです。3pin から線を別途引き出して使っています。窓際でやっているので、あまり安定した受信とはいえませんが、3D Fix したタイミングで計ってみました。

MPU として LPC1114FN28 を使って、以下のようなコードを書きました。ハードウェアカウンタは mbed の API からは使えるようになっていないので、データシートを読む必要があります。

本当は、ハードウェアでカウントしつつ、1PPS シグナルのキャプチャ信号でカウンタをキャプチャレジスタに自動的に入れて、同時に割込みを発生させてその値を読み出すみたいにしたかったのですが、少なくとも LPC1114 においてはそういうことはできないようでした (2つ以上のキャプチャピンを持っていない・外部入力カウンタとして使う場合、キャプチャレジスタを使用することはできない)

なので、実際のコードでは 32bit のカウンタを外部入力(10MHz)でフリーランカウントさせ、GPS の1PPSのタイミングでカウンタの値を読みこんで、前回との差分をとって周波数を求めています。

1PPS ごとの表示なので、簡単なコードですが、GPS同期の正確なゲート時間1秒周波数カウンタとして動いています。

#include "mbed.h"
#include <stdint.h>

constexpr uint32_t CLOCK = 10000000;
constexpr uint16_t HISTORY = 1000;

int16_t errors[HISTORY];
uint16_t error_index = 0;
uint16_t error_count = 0;

volatile bool updated = 0;
Serial serial(USBTX, USBRX);

InterruptIn gps1pps(dp25);

int main() {
	// enable 32bit counter
	LPC_SYSCON->SYSAHBCLKCTRL |= (1<<9/*CT32B0 32bit counter clock*/);

	// Capture pin dp14
	LPC_IOCON->PIO1_5         |= (0b010<<0/*FUNC=CT32B0_CAP0*/);

	// Match output (not used)
	//	LPC_IOCON->PIO1_6         |= (0b010<<0/*FUNC=CT32B0_MAT0*/);
	//	LPC_IOCON->PIO1_7         |= (0b010<<0/*FUNC=CT32B0_MAT1*/);
	//	LPC_IOCON->PIO0_1         |= (0b010<<0/*FUNC=CT32B0_MAT2*/);
	//	LPC_IOCON->R_PIO0_11      |= (0b011<<0/*FUNC=CT32B0_MAT3*/);

	LPC_TMR32B0->PR  = 0;
	LPC_TMR32B0->CCR = 0;
	LPC_TMR32B0->CTCR =
		(0b01<<0/*Counter/Timer Mode=Counter, Rising Edge*/) |
		(0b00<<2/*Count Input Select*/);
	LPC_TMR32B0->TCR = (1<<0/*Counter Enable*/);

	gps1pps.rise([]{
		static uint32_t prev = 0;

		uint32_t count = LPC_TMR32B0->TC;
		uint32_t pps_counter;
		if (prev < count) {
			pps_counter = count - prev;
		} else {
			// overflowed
			pps_counter = (0xffffff - prev) + count + 1;
		}
		prev = count;
		serial.printf("pps_counter: %lu\n", pps_counter);

		int16_t error = static_cast<int32_t>(CLOCK) - static_cast<int32_t>(pps_counter);
		error_index = (error_index + 1) % HISTORY;
		errors[error_index] = error;
		if (error_count < HISTORY) {
			error_count++;
		}
		updated = 1;
	});

	// NVIC_SetPriority();

	serial.baud(115200);
	for (;;) {
		if (updated) {
			updated = 0;
//			serial.printf("last: %d\n", errors[error_index]);
//
//			uint32_t sum = 0;
//			for (int i = 0; i < error_count; i++) {
//				sum += errors[ (error_index + HISTORY - i) % HISTORY ];
//			}
//			uint32_t error = sum * 1000 / error_count;
//			serial.printf("sum(%ds): %d\n", error_count, error);
		}
	}
}

結果

VFC 端子を 0V〜5V まで可変させて周波数を読んでみました。仕様上は の調整範囲 (±4Hz) があると書いてありました。実際やってみると以下のように ±5Hz ぐらいの可変ができるようです。

0〜5V の範囲で10Hz可変なので、2 Hz/V、2mHz/mV です。DAC で 1mHz 単位ぐらいで電圧を設定するなら、最低でも14bit程度の精度が必要そうです。

  1. トップ
  2. tech
  3. OCXO の VFC ピンでの可変範囲を GSP の 1PPS を使って調べた

答: デフォルトではしない

ARMのNVIC (Nested Vector Interrupt Controller) は名前の通りネスト可能ですが、実行中の処理よりも優先順位が高いものだけがネストします(ネストとは割り込み処理中にさらに割り込みが発生すること)。

mbed の場合、優先度を設定するAPIはないため、全割り込みは同一優先順位となり、他の割り込みがネストすることはありません (ライブラリ側でやってる場合を除く)。

優先度をつけるには

もし優先順位をつけてネスト可能にする場合、CMSIS(ARM規定のAPI群)のAPI (NVIC_SetPriority()) を使えば可能です。ただ、このAPIを使うためには、mbedのどのAPIでどんな割り込みを設定しているかを把握している必要があります (mbed 側のコードを全部読む必要がある)。

Cortex-M0 の NVIC の割り込みの優先の仕組み

優先順位は0から3までの4段階あり、0が最も優先です。

デフォルトでは全ての割り込みが0に設定されているので、相互に割り込みがネストすることはなく、通常処理が動いている間だけ割り込みが発生します。

また、通常処理についても、__disable_irq() を呼ぶと一時的に優先度0のコードになり、割り込みが発生しなくなります。__enable_irq() で元の優先度に戻ります。

外部ピン変化割り込みで情報が失われるケース

割り込み発生から、次の割り込みまでの間に2回ピン変化が起こると、2つめの変化による割り込み情報は失われます。

ある割り込みを優先した場合、その割り込みと同じ優先度の割り込み(その割り込み自身を含む)の処理時間だけ考えればいいことになります。

  1. トップ
  2. tech
  3. mbed InterruptIn はネストするか

iRobot Roomba 自動掃除機 ルンバ 770 -

5.0 / 5.0

2013年の3月に買ったルンバをオフィシャルメンテナンスに出しました。約3年ぐらい、平日は毎日稼動させていました。

最近どうもガタガタ、ガタガタと言うときがあり、調べてみると後退したり旋回するときに、片方のモーターが動いていないような挙動でした。前進のときは問題なく、特定の場合だけなります。

一応一通り分解して清掃はしてみましたが、おそらく一番の原因であろうタイヤユニットまわりは中まで分解できるようになっておらず、他全てを綺麗にしても直りませんでした。

この時点では2つの選択肢がありました。

  • タイヤユニットだけを買って交換する 約6000円 (ただし直るかわからない)
  • オフィシャルメンテナンスに出す 定額だと約13000円〜 (直る)

前進は大丈夫で後退だけがダメ、なおかつ片方だけという状態だったので、なんとなく内部のDCモータードライバ回路の一部がおかしいのではないかという疑いもありました。もしそうならタイヤユニットを買っても無駄になってしまいます。

ということで自力で頑張るのは早々に諦めてオフィシャルメンテナンスに出しました。

結果

(途中で「バッテリーもヘタっているから変えるか? 変えるなら18000円のプランになるが良いか?」という趣旨の電話がありました。差額が5000円なので、まぁどうせだからと思い18000円のプランに変えました。オフィシャルバッテリはそもそも10000円ぐらいするので差額5000円なら互換品なみに安い)

返ってきたルンバは全体的に綺麗になっていました。メンテナンスの結果のレポートによると

  • 内部基板ユニットの交換
  • タイヤユニットの交換
  • エッジクリーニングブラシユノットの交換
  • メインブラシユニットの交換
  • フィルタの交換
  • バッテリーの交換(新型のXLifeバッテリーになった)

という感じで、ダストボックスと本体以外ほとんど全部変わってました。内部基板ユニットの不具合がやはりあったみたいで(モータードライバかどうかはわかりませんが)、自力でどうにかできる範囲ではなかったので今回に関しては判断は正しかったようです。

バッテリの寿命も伸びたみたいなので、とりあえずこれであと2年ぐらいは元気に動いてくれることを期待します。

オフィシャルメンテナンスは高いか?

メンテナンス費用には送料も含まれています。だいたい往復で3000円ぐらいかかるとすると、約10000円(ブラシパック)/15000円(サービスパック)が実際の工費になります。

700シリーズ メインブラシ+フレキシブルブラシ + エッジブラシ1本 -

3.0 / 5.0

メインブラシ及びエッジクリーニングブラシが約1500円

ルンバ(Roomba)iRobot(アイロボット) 700シリーズ専用フィルター2セット(4個) -

3.0 / 5.0

フィルタが1セットあたり約600円

はブラシパックの場合必ず交換、サービスパックの場合は必要に応じて交換

Roomba ルンバ エンハンスドクリーニングヘッド 【並行輸入品】 -

3.0 / 5.0

もし壊れているなら上のようなモジュール(6000円〜)が交換

ルンバ用バッテリー 長寿命3年 長時間稼動 500・600・700・800シリーズ対応 【1年保証付き Orange Line 】【互換品】 -

3.0 / 5.0

サービスパックの場合バッテリーが必ず交換 (↑これは互換品ですが)


ということで、単体として高いかというとそうでもなく、点検修理の工数を考えるとむしろお得ぐらいの価格設定です。


ただ、修理の場合実際あたまに浮かぶのは買い替えでしょう。別のルンバに買い替えるなら修理のほうが当然安くすみます。他社製品は今回検討しませんでしたが、もし安くていいのがあれば修理と競合しそうです。

any() 系のマッチャは常に「あらゆるオブジェクト」にマッチします。この挙動は Javadoc にも書いてあって、もしかすると将来的に変更するかも、みたいなことが書いてあります。

じゃあなんで any(Class) とか anyString() とかあるのか?という気持ちになるわけですが、これはたぶんオーバーロードで複数の選択肢がある場合に、ある特定のメソッドを確定するときに便利だからだ、と思います。

なお、あるクラスのインスタンスかどうかをチェックするマッチャは isA(Class clazz) のようです。

  1. トップ
  2. tech
  3. Mockito の any(Class<?> clazz) や anyString() や他の any ナンチャラは型チェックはしない

一定時間で何かをする、といえばタイマーの割込みを使うことでしょうが、タイマーを使いたくないないし使えないということもあると思います。

そういうときループをぶんまわしながら、時刻などを比較して一定時間ごとに処理をするという方法をとったりすることがあります。今回はそれを簡単に書けるスニペットを考えたという話です。

他のライブラリでどうにかする

こういうことをするライブラリを調べてみると、Metro というのがあります。これは以下のようにして使うライブラリのようです。

Metro interval250 = Metro(250); 

void loop() {
    if (interval250.check()) {
        // ここで 250msごとの処理
    }
}

もちろん悪くはないのですが、変数宣言と実際の処理が分かれており、余計な変数を宣言する必要があってなんか嫌です。(変数名をいちいち考えたくないという意味です)

loop() でいきなり使える定期実行

そこで以下のようなスニペットを考えました。interval class が本体です。

template <uint16_t time>
class interval {
	uint32_t next_run = 0;

	template <class T>
	void _run(T func) {
		uint32_t now = millis();
		if (next_run < now) {
			func();
			next_run = now + time;
		}
	}

	interval() {}
public:

	template <class T>
	static void run(T func) {
		static interval<time> instance;
		instance._run(func);
	}
};

void setup() {
	Serial.begin(9600);
}

void loop() {
	interval<250>::run([]{
		Serial.println("250ms 1");
	});

	interval<250>::run([]{
		Serial.println("250ms 2");
	});

	interval<1000>::run([]{
		Serial.println("1000ms");
	});

}

loop() 内でいきなり適当な書きかたをするだけですみます。

interval クラス

事前準備 (グローバル変数やstatic変数を自力で宣言したり) をせず、いきなり静的な関数ないしメソッドを読んで使うことができるようにするため、以下のような感じになっています。

まず、interval クラスは time をテンプレート引数にとっているので、time ごとに別のクラスが作られます。

各 time を持つ interval クラスには、さらに引数 func の型をテンプレート引数にとる run() という static メソッドを持っています。

run() は内部で static 変数として interval

func には lambda 式を書くことを想定しています。lambda 式の型は書く度に違うものになるので、同じ time を持つ処理も複数書けます。

つまり、テンプレート引数を使うことで、グローバルな状態を複数作っています。自分で余計な変数を宣言せずに「状態」を持つためにはこのような小細工が必要なようです。

これにより、各 time と引数 func ごとに interval

  1. トップ
  2. tech
  3. Arduino で一定時間ごとに何かをする interval クラス

FT82-43 に20ターンでやってみましたが、結果が芳しくありませんでした。

そこで、FT82-61 に 30 ターンという、おそらくこれが最善だろうと思われる組合せでやってみることにしました。昔に

FT82-61 (AL= 79) のほうが透磁率がちょうど良さそうだけど、手元になかった。

http://lowreal.net/2014/11/11/1

と書いていました。このとき実はコアを買って巻くところまではやったのですが、実際に換装するところまでやっていませんでした。1年ちょっと越しの挑戦です。

結果

SWR / リターンロス

結合器自体の SWR/RL です。

全く問題ない感じです。

方向性など

FT82-43 T20
測定周波数 kHz IN [V] OUT [V] FWD REF IN [W] OUT [W] FWD [W] REF [W] Insertion Loss Coupling Isolation Directivity
1910 51 51 2.490 0.060 52.02 52.02 0.124002 0.000072 0.00 -26.23 -58.59 -32.36
7010 49 49 2.470 0.090 48.02 48.02 0.122018 0.000162 0.00 -25.95 -54.72 -28.77
28010 52 53 2.700 0.278 54.08 56.18 0.145800 0.001546 -0.17 -25.69 -45.44 -19.75
50010 55 52 2.970 0.530 60.50 54.08 0.176418 0.005618 0.49 -25.35 -40.32 -14.97
FT82-61 T30
測定周波数 kHz IN [V] OUT [V] FWD REF IN [W] OUT [W] FWD [W] REF [W] Insertion Loss Coupling Isolation Directivity
1910 49 49 1.671 0.004 48.02 48.02 0.055845 0.000000 0.00 -29.34 -81.76 -52.42
7010 49 49 1.666 0.005 48.02 48.02 0.055511 0.000001 0.00 -29.37 -79.82 -50.45
28010 52 53 1.850 0.008 54.08 56.18 0.068450 0.000001 -0.17 -28.98 -76.26 -47.28
50010 52 53 2.132 0.013 54.08 56.18 0.090908 0.000003 -0.17 -27.74 -72.04 -44.30


下側が FT82-61 での結果です。

50MHz でも 44dB とれています。 (SWR 計としては 25dB 以上なら良い)

精度

正確な信号源があるわけではないので精度というのもあれですが、以下のようになりました。

スペアナの 0dBm 出力と、FT-450D の 40W 出力を使って

solve([2188 * a + b = 2109, 1050 * a + b = 959], [a, b]);

という連立方程式を maxima に解かせてキャリブレーション値を求めています。KX3 の表示電力と出力電力はあんまり信用していないのでキャリブレーションに入れていません。KX3 以外では誤差が10%範囲に納まっています。

仕様変更

30ターンにしたので、カップリングは -29.54dB になっています。アッテネータとあわせて 45.64dB の減衰。-26.36〜61.64dBm (2μW〜1458W)

感想

センサー部分としては十分上出来になったと思います。すくなくとも前回作ったときよりは、かなり良くなりました。

これで I2C 接続の SWR 計ができたことになるので、インターフェイスをうまいこと作ってあげたいという気持ちになりました。

  1. トップ
  2. tech
  3. 自作 デジタル SWR 計(再) 2 | 方向性結合器の改善編