こん○○は、よふかしわーくすの、よふかしさんです
よふかしさんは、とある騒音問題があって対応しています
騒音問題は客観的証拠を残すことが必要なのですが
それはなかなか容易ではないわけでして
今回はそのエビデンス残しの環境構築をしてみた過程を記録しておこうと思います
騒音測定アプリと市販機器の比較
Android騒音計アプリでのテスト
まずは、手っ取り早い方法としてAndroidスマホアプリの騒音計を使ってみました
Google Playを見ると、たくさんヒットするかと思います
よふかしさんは右上のSmart Tools co.の、騒音測定器:Sound Meter、を昔から使っていました

静かにしているときは40dB付近、
スマホ触ったり、咳払いした時なんかは、近いのもあってバッと数値が上がります
耳で感じる騒音があるときは
安定の40dB付近から50dB近くまで上がるので、意外と精度もよさそうです

という訳で、そんなに数値的にはおかしくなさそうですが、スマホはスマホなので、
試しに専用機器を購入してみることにしました
UNI-T UT353でのテスト
ひとまず、お安いのでお試ししたかったので、
アリエクでUNI-TのUT353を購入することにしました
当時の価格で、送料込み2000円以下でしたね

購入時は、Bluetooth付きのUT353BTはなかった気がしますが、あったかもしれません…?
こちらをテストした結果、スマホと同等の音量は測定ができました
右上のボタンでFASTモードにすると、より高速に表示できます
例えば、スピーカーから動画や音楽再生していて、隣の部屋にどの程度の音量が聞こえているか?
窓の外にはどれくらい漏れているか?
など、簡易的な使い方としては結構ちゃんと使えます
一般的な単4電池3本で運用できるのもよきでして
スタンダードの白eneloopでも問題なく動作していました
一方で、この機種はログ機能がないので
ひとまずGoProなどのカメラで騒音計の画面を録画して経過をみてみましたが
連続的な音は記録できるものの
断続的、もしくは単発的、瞬間な音は映像に残せないシーンがありました
やはり、画面表示のリフレッシュレートによるところがあるので、限界があるようです…
電池駆動なので超長期に渡って記録ことはできないため、定期的に電池交換が必要です…
ということで、次はきちっと取り逃さずにログできる環境を検討する運びとなりました
DT-8852の導入手順と測定設定の実例
サトテックDT-8852を買ってみた
これはもう本当に清水の舞台から飛び降りる勢いです
なんせ、お値段30000円弱…
これを選定した大きな理由は下記となっております
- データログ機能
- 専用のSound Level Meterアプリを使用してPCで記録可能
- サンプリング性能
- PC接続では最大40000サンプリングまで記録可能
- サンプリング周期のバリエーションは、
0.1s、0.2s、0.5s、1s、1.5s、2s、2.5s、3s、5s、10s
- 電源供給
- ACアダプタ接続により、電池切れの心配がない
例えば、Yahooショッピングだと、下記の通り、公式の佐藤商事さんから購入可能です
本体の測定設定
まずは、ログしたい状態に本体の設定をします
電源を入れた後、今回は、FASTモード、A特性、測定レンジはAUTOに設定しました
ざっくりした説明は下記の通りです
- FAST
- 瞬間的な音のピークレベルを拾いたい場合に使用
- 音の変動に対して素早く追従したレベルを表示する
- SLOW
- 連続的な音、ゆっくりと変動する音の場合に使用
- 音の変動に対して緩やかに追従して、平均的なレベルを表示する
- A特性
- 一般的な騒音測定に使用
- 低音、高音をカットして中音域を重視
- 人間の耳の感じ方に近い測定値
- C特性
- 低周波の騒音計測に使用
- 音域によるカットしないため、比較的そのままの音を測定する
- 衝撃音や振動音の場合に有効
Sound Level Meterアプリをダウンロードする
Sound Level Meterアプリは下記からDownloadできます
下記までスクロールして、ソフトウェア&ドライバをDLできます

UART用のチップにCP210xが採用されているので、公式から最新ドライバを入手することも可能です

Sound Level Meterアプリを立ち上げると下記の初期画面が立ち上がります

今回は、
・最速の0.1sで40000サンプリング
という設定を実施してログを開始してみました
Sound Level Meterの問題点
ここで、Sound Level Meterツールを使用してログ取得を試行してみたところ
期待するデータが取れていないことがわかりました
実際に複数回テストしてみた代表結果が下記です
このデータは、横軸が時間、縦軸が1秒当たりのサンプリング回数となっておりまして
ログ開始から30分程度は設定通りに0.1sサンプリングでログできています
但し、その後は徐々にサンプリング回数が減っていき、最後は半減している感じとなっています…

対策ですが、Sound Level Meterアプリを明示的に管理者権限で起動することによって
この現象を低減できることがわかっています
長時間継続して安定的にログしたい
Sound Level Meterアプリでは、先の通り40000サンプリングしかログできない仕様のため
0.1sサンプリングの場合は、理論上では1時間程度でまたログを再開する作業をしないといけません…長時間ログしたいので、その対策を考えてみました
まずは、Sound Level MeterアプリのGUIを自動化する作戦です
いつものPythonさんを使用して、PC起動時に自動的にログ開始、
40000サンプリングのログが終了したら、再度開始、といったGUI操作アプリを作ってみました
ただ、やはりGUI操作ということもあって
たまぁに不測の理由によって失敗することもありますし
40000サンプリング後の停止、再開の間にはラグがあるわけで連続データとも言い切れないです
というわけで、安定的かつ連続的に運用したいなぁと思い始めた次第です…
DT-8852のシリアル通信仕様とデータ構造の解析
DT-8852の通信仕様は?
高速、かつ安定的にデータログするためのことを考えると
公式のSound Level Meterツールに見切りをつけることになりました
というのも、インストール時のドライバからもわかる通り、デバイスマネージャーでは
“Slicon Labs CP210x USB to UART Bridge (COM X)”
と、表示されるものでして
つまり、WindowsではCOMと認識されるシリアル通信でPCと通信しているわけです
そうであれば、これを解析して独自アプリを作ってしまおう!
という魂胆にたどり着いたわけです
DT-8852のシリアル通信のデータ構造を解析してみた結果
さて、ここからが本題です
専用ツールを使わずに独自ツールでデータ取得するためには、データ構造の解析から始めないといけません
一応、取扱説明書には、
・本製品のUSB信号出力は、9600 bpsシリアルインターフェイスです
ということだけは書いてあります
さらに、本体のSETUPボタンを押すと、常時垂れ流しでシリアル送信してくれるので解析は容易ですw
というわけで、シリアル通信内容の解析結果は下記です
- ボーレート
- 9600bps
- データ長
- 8bit
- パリティビット
- なし
- ストップビット
- あり
- RTS/CTS
- なし
- DSR/DTR
- なし
- トータルデータ長
- 18 or 20 or 22 Byteのデータ
- 0
- 同期先頭ヘッダ(0x00)
- 1~2
- 時間ヘッダ(0xA5, 0x06)
- 3
- hour
- 4
- min
- 5
- sec
- 6~11(6~13)
- 何らかの設定値と思われる(0xA5, 0xXX…)
- 12~13(14~15)
- 音量ヘッダ(0xA5, 0x0D)
- 14(16)
- 音量上位Byte
- 15(18)
- 音量下位Byte
- 16~17(16~19、18~21)
- 何らかの設定値と思われる(0xA5, 0xXX…)
A/C特性などを変更すると上記不明データ部分は可変するのですが、今回は不要なのでSkipします
用途的には音量データだけを取得できればよく、時分秒はPC側で取得できた方が正確ですが
簡単だったので記録しておきます
- 時
- 0x01~0x11
- 1~17時
- 0x12
- 0時
- 0x21~0x29
- 13~21時
- 0x30~0x31
- 22~23時
- 0x32
- 12時
- 0x01~0x11
- 分
- 0xXXを文字列として、その文字列を10進数に変換する
- 例:0x23は23分
- 秒
- 0xXXを文字列として、その文字列を10進数に変換する
- 例:0x45は45秒
- 音量上位Byte
- 音量の2桁以上の整数部
- 0xXXを文字列として、その文字列を10進数に変換し、10倍する
- 例:0x12の場合、120
- 音量の下位Byte
- 音量の1桁以下の整数部+小数部
- 0xXXを文字列として、その文字列を10進数に変換し、1/10倍する
- 例:0x34の場合、3.4
- 音量
- 変換後の上位Byteと下位Byteを合計する
- 例:0x12, 0x34の場合、123.4[dB]
時だけは特殊として、他は16進数で見た場合に、
人間がわかりやすい様に文字列的に見える仕様となっていました
オリジナルのシリアル受信プログラムを組んでみる
まずは、DT-8852側の送信周期を見てみます
- 平均してみると、50msベースと思われる
- 但し、30ms程~100ms程度までバラつきあり
音量だけ取得したいのであれば、送信同期ヘッダ+時間ヘッダを先頭として、18Byte取得すればよさそうです
ただ、これだとかっこ悪いのと、今後、不明データ部分も解析することを鑑みて可変長のデータを正しくひとつのパケットとして取得したいと思います
というわけで、送信間隔の隙間をみて判断するロジックを検討してみます
- 9600bpsのデータ転送速度:
- スタートビット、データ8ビット、ストップビット = 10ビット
- 10bit / 9600bps = 1.04ms
- パケットの送信時間:
- 18バイトのパケット: 18×1.04ms = 18.7ms
- 20バイトのパケット: 20×1.04ms = 20.8ms
- 22バイトのパケット: 22×1.04ms = 22.9ms
ざっくり、5~10ms程度の隙間を検出すれば、ほぼ取りこぼさずに受信できそうです
ちなみに、サンプルプログラムを組んで試してみたところ、
Time, dB, Date, PC Time
21:38:56, 37.4, 251116, 21:38:43.276532
21:38:56, 37.5, 251116, 21:38:43.326350
21:38:56, 37.4, 251116, 21:38:43.370346
こんな感じで記録できましたので、
DT-8852本体としてもちゃんと50msで音声の値を更新して送信している様です
終わりに
こんな感じで、サトテック、DT-8852の音量計測データログ環境をオリジナルで構築できました
但し、実際にどんな音が発生していたかという
音声データはログできないわけでして、それと紐づける作業は別途必要になります
それに関しては、別の記事で解説してみたいと思いますです

コメント