MXG-9802Aは値段相応か？

前の記事に絡む低周波信号の測定の為、ぼちぼちと研究中。

その過程で、METEZ社のMXG-9802Aというファンクションジェネレーターを
引っ張り出してきました。
これ実は無期限の借り物なんですが、ファンクションジェネレーターを使う機会が
全く無かったもので、ずっと機材入れで眠っておりました。
それがなんと、今回初めて日の目を見たというわけです。

このMXG-9802A、ファンクションジェネレーターだけではなく、
周波数カウンターの機能も付いております。
しかしこれ、お得感を出す為ではなく、ファンクションジェネレーターとして使用時、
出力している信号の周波数を表示する為に、
周波数カウンターが内蔵されているだけの話かと思われます。

ですので、周波数カウンター専用機に比べたら、性能は　それなりかと。
まぁ、元々ファンクションジェネレーターですから、
そっちがきちんと動作してくれれば、文句言う筋合いも無いわけですね。

ちょっと話が逸れてしまいましたが、低周波信号の測定の研究で、
低周波信号のサンプルが欲しくなったので、MXG-9802Aに登場してもらいました。

初めて使う上に、マニュアルが全て英語。
ちょっと難儀しながら試行錯誤。

今回は１Hzくらいの信号を出したいわけですが、どうもうまくいきません。
周波数の調整ノブを回しても、スムーズに周波数が変わってくれません。

ややしばらく格闘後、出力信号がどうなっているのか確かめたくなり、
テスターを繋いでみました。
普通、こういう場合はオシロスコープを出すべきなんでしょうけど、
引っ張りだすのが　面倒だったもので・・・・・・・（笑）

で、テスターで見た結果は、きちんと低周波信号が出ておりました。
が、表示の周波数と　全く異なっております。
周波数調整ノブを回すと、きちんと出力の周波数は変わる模様。
しかし、表示の周波数だけが　おかしいのでした。

と、ここまで書くと、表示部の故障か、と思われるでしょうが、
実はなんと、故障ではないのでした。
周波数カウンターが低周波領域では正常に計測してくれないという問題でした。
つまり、ある程度周波数が上がると、表示も合ってくるのです。

低周波信号の周波数測定が大変なのは解りますが、
こんな性能の周波数カウンターを組み込まれても困惑しちゃいます。

とまぁ、さすが値段安いだけのことはあるなぁと実感した次第。

PICマイコンで32.768KHzを発振

最近のPICマイコンはメインクロック用のクロック発振器の他に、
セカンダリー発振器も持っております。

これは元々、タイマー１用の発振器として実装されたもの。
大抵の場合、タイマー１のクロック源としてメインクロックのシステムを使うと思いますが、
タイマー１専用のクロック源を用意することもできるようになっているのです。

とは言え、そんな使い方をするとすれば、タイマー１の元クロックを
32.768KHzにしたい場合くらいでしょうか？
タイマー１の元クロックを32.768KHzにすると、16bitカウンター構成のタイマー１が
ぴったり２秒周期でロールアップするようになります。
これにより、時間計測が簡単に行えるようになるわけですね。

そんなタイマー１用の発振器ですが、昔は32.768KHzのみならず、
上は200KHzくらいまでのクリスタルも繋ぐ事が出来るようになっておりました。
しかしさすがに需要が無かったんでしょうねぇ、PIC16F1938辺りになりますと、
タイマー１用発振器は32.768KHz専用になってます。

この32.768KHz専用のタイマー１発振器は非常に省電力で動作いたします。
これが、電池駆動システム等で　とても重宝することから、
タイマー１用発振器の32.768KHzをメインクロックとして利用しちゃおう、
という発想に繋がりました。

こうして、タイマー１用の発振器だったものが、セカンダリー発振器へ昇進のでした。

このセカンダリー発振器を使うのに必要なのは、
時計用として入手が容易な32.768KHzのクリスタルと、セラミックコンデンサー２個だけ。
とてもお手軽でございます。

さて、ここからが本題。

皆さんは、このセカンダリー発振器の発振周波数をどのように校正されますか？

クリスタル発振器の精度は非常に良いとは言え、無調整だと　それなりに誤差は出ますね。
そこで、誤差がシビアな装置だと、セラミックコンデンサーの代わりにトリマコンデンサーを付け、
それで発振周波数を微調整するのは常套手段。

もちろん、PICのセカンダリー発振器でも同様の事は可能です。
ただそこで、１つ問題に　ぶち当たるのでした。

セカンダリー発振器の発振出力が出てない。 

つまり、32.768KHzのクロックを直接測ることが出来ないのです。

特殊なプローブを使えば、クリスタルの足から発振信号を拾うことも出来ますが、
多少なりとも発振周波数に影響が出てしますので、いい方法ではありません。

さてそうなると、ソフトウェアにも１枚噛んでもらって、
セカンダリー発振器のクロックを取り出すしかない模様。
私が考えた手段は以下の２つ。

①CPUをセカンダリークロックで駆動し、任意のポートをトグル動作させる。
　　　　こうすると任意のポートからは命令サイクル長のクロックが出てきます。
　　　　しかし8bitPICの場合、命令サイクルは供給クロックの１／４ですので、
　　　　ポートから出てくるクロックは8.192KHzになってしまいます。
　　　　この8.192KHzの周波数を測定して誤差を調べる方法です。

②タイマー１のロールアップ時に任意のポートをトグル動作させる。
　　　　これにより、任意のポートから0.25Hzのクロックが出てきます。
　　　　0.25Hzということは、HもしくはLのパルス長は２秒ですので、
　　　　この時間を計測し、誤差を調べる方法です。

ここまで書くと、もうほとんど解決したじゃないかと思われるかもしれません。
しかしまだ問題は残っております。

まず、そもそもの話として、どれだけの誤差を調べたいかという話ですが、
水晶発振ですから根本的に誤差値は大きくありません。
たぶん、多くても数百ppmというところでしょう。
それ以上にズレが発生していたら、そもそも発振が停止してしまいます。

仮に100ppmの誤差を測定したいとすれば、少なくとも10ppm単位で測る必要があります。

そこで、上記の①と②を振り返りますと・・・・・・・・・・
8.192KHzのクロックや２秒のバルス長を10ppm単位で測定するのって、実はちょっと面倒なお話。
安いユニバーサルカウンターで低周波を測ると、10ppmレベルまで細かく測定できないのです。

ということで、ここでまた一捻りが必要なことに・・・・・・・・・

幕張にPlanetarianが来る！！

Planetarianの劇場での上映も、年内で終わりなんだろうなぁと思っておりました。
現状、地方での上映が細々と続いておりますが、それらも間もなく終了する見込み。
関東圏だとイオンシネマの多摩センターで上映されておりますが、それも９日で終了。

９月に公開された作品ですから、むしろここまでよく頑張ったと思いたい。
と、自分を納得させていたわけですが・・・・・・・・

ここにきて、まさかの情報が！！
イオンシネマの幕張で、１月に上映決定だそうな。

https://twitter.com/ac_makuhari/status/804282245343125504

いあもう、さすがにこれは　私もビックリ。

この幕張には、ULTIRAという特別スクリーンが有るそうですが、
これを使ったPlanetarianの上映も予定してるとか！！

もうこれは、万難を排しても　ぜひ観に行くしかありませんな。

最近、気が滅入ることが多い近況なのですが、
またしてもPlanetarianに元気を貰えそうです。

松屋のクリームシチュー定食

牛メシの松屋さんにて、１２月６日よりクリームシチュー定食が販売されるそうな。
ビーフシチューは　提供するお店が　そこそこ見受けられるものの、
クリームシチューってレアな気がするのは私だけでしょうか？

ともあれ、私はビーフシチューよりクリームシチューが好きな派なので、
今回の松屋さんの定食は　かなり嬉しいです。
味がダメだったら、ゲンナリですが・・・・・・（笑）

このクリームシチュー定食、ライスと味噌汁も付いてきます。
定食メニューの1つなので、まぁ判らないでもないですが、
シチューに味噌汁って、確かに不釣合いな気も。（笑）

それ以上に世間を騒がせているのが、ライス。
パンという選択肢が無いことに苦言を申してる方が居る模様。

確かにシチューって代表的な洋食ですから、パンとセットが本来なんでしょうね。
しかし私は子供の頃からご飯のおかずとしてクリームシチューを食べてました。
正直、ライスでも違和感を感じませんし、パンが欲しいと思ったことも無いです。
ライスとクリームシチューの組み合わせは、有りだと思いますよ。
まぁ、それに味噌汁は　どうかと思いますが・・・・・・・・

ＨＤＤがアカンらしい

先日から発生しているPCの不調。

3TBの大容量ドライブについては、S-ATAポートを変更してから落ち着いてる模様。

しかし1TBのドライブについては、またしても症状再発。
こうなると、ドライブ自体の不良と断定して間違いない感じ。

さてそうなると、ドライブ交換しかないわけですが、
手元の在庫は500GB品しか無い。（；；
しかし幸いなことに、この1TBのドライブは以前データー整理したおかげで、
180GBくらいしか使っていませんでした。
なので、500GBのドライブに置き換え可能！

ということで、現在置き換えの為の作業中。
今夜中にはデーターの移行まで可能かと。

これでまた、しばらく様子見ですね。

乾電池駆動システム

現在抱えてる案件の１つに、鍵の制御というのがあります。
制御する内容自体は単純なのだが、一番のネックは電源が電池という点。

ごく普通のアルカリ電池で約１年くらい　保たせる必要があるのですが、
最近のPICマイコン等は極省電力動作が考慮されてきてるので、
仕様的に無理な話ではありません。
（実際、こういう仕様の製品は既に存在していますし）

私の方で、何が一番問題になりそうかと言うと、
設計仕様上の電池寿命を　どうやって検証する？？という点。

１年とかって単位の話になる、平均消費電流がとんでもなく微少になるわけです。
そのくらいの領域になると、アルカリ電池の容量が計算できないんですね。

最低保証ラインの容量で計算しておくという手もありますが、
そうなると、とてもじゃないですが１年は保ちません。（；；

加速試験の方法というのも思いつきませんし、
さて、どうしたもんですかねぇ・・・・・・・

ＰＣ不調の続き

その後、色々確認していたら、S-ATAドライバーが　おかしな事になっているのを気づく。

このマザボはインテルのS-ATAコントローラーと
AsmediaのS-ATAコントローラーが載っているわけですが、
どちらもAsmediaのドライバーで動いてるような感じになってる。

なんでこんな状態になるのやら・・・・・・・

ドライバーの上書きを行っても状態は変わらず。
インテルのS-ATAドライバーのバージョンを上げてみることにしました。

このマザボ用に提供されているのは、Ver11.7.0.1013。
インテル曰くは、マザボメーカーからリリースされているドライバーを使用するのが
ベターとのことですが、前の記事に書いたようにAsmediaのS-ATAドライバーと
不具合を起こしてしまう代物でして、決してベターな状況では無い。！！

てか、マザボメーカーがリリースしているドライバーがぶつかるって、
どういう事態なのやら・・・・・・・・
ちゃんと確認しているんですか？AsRockさん。

愚痴はさておき、インテルのサイトでドライバーを探すと、Ver15.2.0.1020が最新。
早速落としてインストールしてみると・・・・・・・・
このチップはサポートしてないと言われてしまいました。
インテルさんのドライバーって、古いコントローラーはサポートしなくなるらしい。
ちょっと不親切ですねぇ。（；；

仕方無いので、少しずつバージョンを遡っていって、対応ドライバーを調べることに。
その結果、Ver14台も全て非サポート。

Ver13台は、インストーラーが .NET Frameworkの4.5を要求してきます。
このPCには4.6.1がインストールされているので、機能上は問題無いはずですが、
4.5がインストールされていないという理由で、ドライバーのインストールが出来ませんでした。
インストーラーのコーディングに問題があるようですねぇ。
かと言って、この為だけに　わざわざ4.5を入れるわけにもいかないので、
Ver13台も諦めることに。

次にVer12.9.0.1001をインストールしてみると・・・・・・・・・
無事にインストールが完了しました。
コントローラーの状態を見ると、きちんとドライバーが当たっています。
しかも、ラピッドストレージサービスも正常に動きます。
所謂、まともな状態になりました。（笑）

ということで、これで暫く様子見です。