ラジオペンチ

大型の台風19号が近くを通過しそうだったので、気圧の変化の記録を取ってみました。

やり方は以前と同じで、LPS-25Hを使ったアナログ表示の気圧計から10分間隔でシリアルに流しているデーターを、TeraTeram を使ってタイムスタンプ付きでパソコンに記録しました。データーがPCに記録出来ればこっちのもの、エクセルで簡単にグラフにすることが出来ます。

▼気圧の値をＰＣに記録中


▼台風19号の気圧変化

規模が大きい台風だったので、気圧が下がってから元に戻るまで1日半くらいかかっています。

記録されていた最低の気圧は965hPaで、私がこれまでに観察した中で一番低い値でした。なお、気圧の値は海面気圧に換算した値です。ちなみに、台風の経路図を見るとほぼ中心、つまり目が通過していて、目の通過中は風が収まっていました。

▼気圧計の針がスケールオーバー

この気圧計の最低側は980hPaまでしか目盛りが無いのですが、それを超えて（下回って）針が振れました。まあメカニカルなストッパーがあるわけではないので、機械的には問題ありません。

◆まとめ
台風の中心が通過するなんて、めったにないこと、しかもかなり大型の台風です。その気圧変化をきっちりと記録出来てよかったです。そうは言っても、被害にあった方がいらっしゃるので、よかったと書くのは不謹慎ではあります。

気圧変化のグラフは滑らかな変化では無く、変曲点があったりコブのような不連続な変化があるようです。以前記録したデーターでもそんな感じでした。これって、ひょっとしたら台風の気圧分布には螺旋形の溝みたいな構造があるのかも知れません。銀河の渦には腕のような構造がありますが、それと同じようなことがもし台風の渦にもあったら、興味深い話です。

久しぶりにアナレンマの話です。この観察を始めてからもうすぐ3年が経過するのですが、今でもしぶとく続けています。というか、何もしなくても勝手にデーターが ambient に蓄積されるので手間がかかるわけではありません。

なお、アナレンマの観測の話はアナレンマのカテゴリにまとめてあるので興味のある方はご覧ください。

▼アナレンマの観察ユニット

太陽光発電パネルの電圧をこのユニットで測定し、日の出日の入り時刻を割り出しています。得られた情報はWiFi経由で ambient に送っているだけなので、とても簡単な仕掛けになっています。

さて、突然アナレンマの話が出てきた理由ですが、最後にグラフを公開してからかなり時間が経ったということが第一にあります。あと、最近パソコンの入れ替えをやったのでいろいろアプリを入れ直しているのですが、その中に ＲStudio があり、久しぶりにこれを使ってみたかった、というのがもう一つの動機です。

▼最後に作成したアナレンマのグラフ


この図を作ったのは2017年の12月で、エクセルの散布図でプロットしています。このグラフでは月別にプロットの色を変えることで時間の経過を表現していますが、本当はもっと滑らかに色を変化させたかったです。しかし、エクセルではこれくらいの表現が限界だと思います。そういうことはVBAやPythonなどでプログラムを書けば確実に出来るはずですが、環境の立ち上げが面倒なのでそのままになっていました。

前述したように、今回新しいPCにもＲ (RStudio) をインストールしたので、これを使って最新の観察データーでアナレンマの作図を行ってみました。R のグラフの表現力は優れているので、欲しかったグラフが簡単に作れることを期待しました。

以下おさらいを兼ねて、データーのダウンロードから順に作業を振り返ります。

▼Ambient で公開中のグラフ

開始からもうじき3年。天候の影響でノイズが載っていますが、太陽の南中時刻の変化がはっきりと捉えられています。

データーは ambient のサーバーに自動アップロードしているので、そこからダウンロードします。なお、このデーターは、ambient の中に私が作った公開チャンネル 日の出・日の入り時刻でアナレンマを描く (チャネルID: 200)に入っているので、グラフを見るだけならて誰でも閲覧出来ます。

昔は一括でデーターのダウンロードができたのですが、さすがにサーバーへの負荷が重過ぎるのでしょう。現在は一度にダウンロードできるのは最大35日に制限されています。ローカルに過去分のデーターを保存しておき、新しく追加された分だけダウンロードして全データーを準備します。

現時点で約1300点のデーターがありますが、これをエクセルで前加工してCSVのファイルに変換し RStudioに読み込みます。

▼RStudio


RStudioから散布図作成コマンドの plot で作図しました。そのコマンドはたったこれだけで済みました。(不等号＞は全角に修正しています）

＞ data = read.csv("c:/Myfiles/Rdata/anaremaSorted.csv")
＞ par(bg=rgb(0.8, 0.8, 0.8))
＞ plot(data$MidTime, data$DayLength, col = hsv(data$dayN/365, 1, 1), pch=20, tck=1)

最初の行でデーターをファイルから読み取り、2行目でグラフの背景を灰色に指定、3行目で散布図を書いています。ここですばらしいのは、要素の塗分けを hsv( , , )パラメーターで色相を直接指定出来ることです。色相は0から1の範囲の値で指定するので、年間の日付連番を365で割るだけで、1年周期の色環でプロット点を塗り分けることが出来ました。

▼アナレンマ　（2019年10月10日時点）


以前作ったものに比べ、データー数が増えたと共に、色の変化が滑らかになって格好良くなりました。

◆まとめ
久しぶりにRでグラフを作ってみたのですが、思いのほかうまくいきました。世界中で多くの人が使っているので、コマンドのオプションが豊富で、欲しいと思った機能はほとんどそろっている感じです。VBAでやらなかったのは正解でした。

このところPCの入れ替え作業をやっているので電子工作の方は進展がありません。そんな中で、あまり手間を掛けずに出来ること、ということで、RTC(DS3231)の誤差の時間変化を測定してみました。

以前の記事で DS3231 の偽物は時間精度が悪く、短時間でもふらふらとタイミングが変化しているという話を書きました。これが実際にどれくらいの変化なのか、定量的に比較してみましょう、というのが今回の記事の目的です。

▼測定方法


左のArduino UNO で作った DS3231を使ったデジタル時計から出ている1秒パルスと、窓際に置いたGPSモジュール (neo-8m) から引っ張ってきた1PPSパルスとの位相差を中央の Arduino UNOで測定し、右側のタブレットで記録しました。
RCTモジュールはコネクタで差し替えが可能なので、簡単にモジュールの違いによる特性の差を比較することが出来ます。

以下は測定結果で、1200秒（20分間）の位相の変化と、位相の変化率です。

位相の変化率は1秒値当たりの位相の変化量で求めていて、これはＲＴＣの絶対誤差と考えることが出来ます。なお、この変化率は、60回（60秒）の位相データーを使って最小二乗法で求めた近似直線の傾きの値です。なお、この値は Arduino で計算してシリアルに出力しています。

◆モジュールＡ　(本物、と思われるもの）
・位相変化

位相差は4μsステップの値でしか出力されないので、階段状のグラフになっています。

・誤差変化

位相の測定結果は4μsステップの離散値しか得られません。でも最小二乗法で求めた直線近似直線の傾きには、見えなかったた傾向が見えてきているようです。

時々大きな揺らぎがありますが、それを除くと変動は±0.02ppm 程度に収まっているようです。あと、少し右上がり傾向なのは温度変化の影響なのかも知れません。

◆モジュールＢ（偽物と思われるもの）
・位相変化

エージングレジスタの値が十分調整出来ていないようで、右上がりの位相変化があります。ちなみに、位相差が増えているので、ＲＴＣのオシレーターの周波数が低いことになります。

・誤差変化

右上がりの位相変化があるので、グラフの中心が 0.3ppm くらいゼロから上にシフトしています。変動幅は、±0.2ppm くらいあって、Aのモジュールの約10倍もあります。こういうデーターを取ると、偽物の化けの皮が剥がれてきます。

◆モジュールＣ（偽物と思われるもの）

・位相変化

4μs の階段状に値が変化していますが、Aのモジュールより振れ幅が大きくなっています。エージングレジスタが適切に調整されていたようで、中心値はほぼ一定になっています。

・誤差変化

変動は±0.4ppm くらいはありそうです。やはりこれも偽物です。

◆まとめ
本物（と思える物）と偽物の DS3231 の誤差変動を詳しく測定してみました。偽物の変動範囲は本物の10倍程度あることが判りました。そうは言っても 1ppm 以下の話なので、細かいこと言わなければOKなレベルではあります。

こういう測定を簡単に出来るのは、GPSモジュールから出ている正確な1PPSパルスのおかげです。これが7ドルちょっとで手に入るのだから、良い時代になったものです。残念なのは、このモジュール(u-block neo-8)が日本製では無いことです。

最小二乗法による傾向の抽出は思ってたよりうまくいっている感じです。Arduino UNO のCPU (ATmega328P) で計算した場合の1回の処理時間は50ms程度でした。これ以外に過去データーを蓄積しないといけないのでレスポンスが悪化します。そんなことで、タイミング的に厳しい場合は無理ですが、そうでなければこのテクニックはけっこう使えると思います。なお、計算精度が32ビット浮動小数点なので、桁落ちには注意が必要です。

今回調べたのは20分程度の短期変動です。もっと長時間では傾向が変わってくるかも知れません。多分それ以上に、温度変化の影響の方がずっと大きいと思います。