NoiseMeter: Difference between revisions

From RevSpace
Jump to navigation Jump to search
 
(17 intermediate revisions by the same user not shown)
Line 27: Line 27:
Other interesting stuff:
Other interesting stuff:
* My brother looked inside three inexpensive sound meters: https://twitter.com/jrsikken/status/1779225176464392685
* My brother looked inside three inexpensive sound meters: https://twitter.com/jrsikken/status/1779225176464392685
* Heatmap of my noise sensor over the past 24h: https://vmi612554.contaboserver.net/b3-grafana/d/zCKDN4oVk/heatmap-spectrum?orgId=2&refresh=1m&var-vsensor=soundkit-023&var-vtype=LZ&var-vfreq=All&from=now-12h&to=now


== Hardware ==
== Hardware ==
Line 92: Line 93:
== Experiments ==
== Experiments ==
=== Uni-T UT353 BT noise meter ===
=== Uni-T UT353 BT noise meter ===
This thing has a bluetooth interface.
This thing has bluetooth.
 
==== serial interface ====
Interpreting serial port data on Linux is not straightforward, since Linux treats a serial port as a terminal so by default it does terminal-specific stuff to the data.
The data below may have been corrupted by the Linux tty subsystem trying to escape/unescape certain byte sequences. 
 
There is an internal serial interface (9600 bps).
Use the following to configure the serial port on linux
  stty -F /dev/ttyUSB0 raw 9600 -echo
Then dump using
  cat /dev/ttyUSB0 |hexdump -C
or
  jpnevulator --tty=/dev/ttyUSB0 --read --width 23 --ascii
 
When in bluetooth mode, there is data going over this interface:
<pre>
01 fc 12 13 aa bb 10 05 3b 20 20 34 34 2e 31 64 42 41 3d 34 00 04 14
01 fc 12 13 aa bb 10 05 3b 20 20 34 30 2e 34 64 42 41 3d 34 00 04 13
01 fc 12 13 aa bb 10 05 3b 20 20 33 39 2e 30 64 42 41 3d 34 00 04 17
01 fc 12 13 aa bb 10 05 3b 20 20 33 38 2e 35 64 42 41 3d 34 00 04 1b
01 fc 12 13 aa bb 10 05 3b 20 20 33 38 2e 34 64 42 41 3d 34 00 04 1a
01 fc 12 13 aa bb 10 05 3b 20 20 33 38 2e 38 64 42 41 3d 34 00 04 1e
01 fc 12 13 aa bb 10 05 3b 20 20 33 39 2e 31 64 42 41 3d 34 00 04 18
01 fc 12 13 aa bb 10 05 3b 20 20 33 38 2e 39 64 42 41 3d 34 00 04 1f
01 fc 12 13 aa bb 10 05 3b 20 20 33 39 2e 35 64 42 41 3d 34 00 04 1c
01 fc 12 13 aa bb 10 05 3b 20 20 33 39 2e 32 64 42 41 3d 34 00 04 19
</pre>
 
Dividing into "frames", starting with 01 fc 12 aa bb:<br>
<pre>
01 fc 12 13 aa bb 10 05 3b 20 20 34 34 2e 31 64 42 41 3d 34 00 04 14 => "44.1dBA"
01 fc 12 13 aa bb 10 05 3b 20 20 34 30 2e 34 64 42 41 3d 34 00 04 13 => "40.4dBA"


In short, as I interpret it:
<---------header--------->
* a "Generic Attribute Profile" service, like all BLE devices have
01 fc 12 13 aa bb 10 05 3b
* a service related to bluetooth parameters, also looks fairly standard, and not related to the measurements themselves
                          <------------ascii------->
* a "Device information" service
                                  X  X  .  X  d  B  A
* a custom vendor-specific service, where I suspect the noise-meter specific data is
                                                      <--- footer-->
                                                      3d 34 00 04 ??
</pre>


==== serial interface ====
Footer
Internally the following is sent over a serial connection (9600 bps):
<pre>
<pre>
00000000  01 fc 12 aa bb 10 05 3b  20 20 34 31 2e 35 64 42  |.......;  41.5dB|
3d 34 XX 04 YY
00000010  41 3d 34 00 04 15 01 fc  12 aa bb 10 05 3b 20 20  |A=4..........;  |
^--- ????
00000020  34 30 2e 33 64 42 41 3d  34 00 04 12 01 fc 12 aa  |40.3dBA=4.......|
  ^--- is 34 in slow mode, 33 in fast mode
00000030  bb 10 05 3b 20 20 33 39  2e 33 64 42 41 3d 34 00  |...;  39.3dBA=4.|
      ^--- buttons pressed: 01 = hold, 04 = min, 08 = max
00000040  04 1a 01 fc 12 aa bb 10  05 3b 20 20 33 39 2e 30  |.........;  39.0|
        ^--- always 04?
00000050  64 42 41 3d 34 00 04 17  01 fc 12 aa bb 10 05 3b  |dBA=4..........;|
            ^--- varies between 10, 11, 12, 13, 14, 15, 16, 17, 19, 1B
00000060  20 20 33 39 2e 30 64 42  41 3d 34 00 04 17 01 fc  |  39.0dBA=4.....|
00000070  12 aa bb 10 05 3b 20 20  33 38 2e 37 64 42 41 3d  |.....;  38.7dBA=|
00000080  34 00 04 1d 01 fc 12 aa  bb 10 05 3b 20 20 33 38  |4..........;  38|
00000090  2e 37 64 42 41 3d 34 00  04 1d 01 fc 12 aa bb 10 |.7dBA=4.........|
000000a0  05 3b 20 20 33 38 2e 33  64 42 41 3d 34 00 04 19  |.;  38.3dBA=4...|
000000b0  01 fc 12 aa bb 10 05 3b  20 20 33 38 2e 31 64 42  |.......;  38.1dB|
000000c0  41 3d 34 00 04 17 01 fc  12 aa bb 10 05 3b 20 20  |A=4..........;  |
000000d0  33 37 2e 38 64 42 41 3d  34 00 04 1d 01 fc 12 aa  |37.8dBA=4.......|
000000e0  bb 10 05 3b 20 20 33 38  2e 38 64 42 41 3d 34 00  |...;  38.8dBA=4.|
000000f0  04 1e 01 fc 12 aa bb 10  05 3b 20 20 33 38 2e 31  |.........;  38.1|
</pre>
</pre>


Dividing into "frames", starting with aa bb:<br>
Each frame is 23 (x017) bytes long
 
With the Android app connected, it sends smaller frames, like
<pre>
<pre>
aa bb 10 05 3b 20 20 34 31 2e 35 64 42 41 3d 34 00 04 15 01 fc 12
AA BB 10 01 3B 20 20 34 35 2E 34 64 42 41 3D 33 04 04 17            ....;  45.4dBA=3...
aa bb 10 05 3b 20 20 34 30 2e 33 64 42 41 3d 34 00 04 12 01 fc 12
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15           ....;  45.2dBA=3...
...
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            ....;  45.2dBA=3...
aa bb 10 05 3b 20 20 33 38 2e 38 64 42 41 3d 34 00 04 1e 01 fc 12
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            ....;  45.2dBA=3...
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            ....;  45.2dBA=3...
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            ....;  45.2dBA=3...
</pre>


header
When toggling the hold button on the Android app, we see
      ????????
<pre>
              <----------ASCII--------->
AA BB 04 FF 00 02 68
                                          3d 34 ..
</pre>
</pre>


Each frame is 22 bytes long (0x16)
It now becomes more obvious that the AA BB sequence is a header, followed by a length byte


==== BLE interface ====
==== BLE interface ====
This thing has a bluetooth interface.
FCC report on the bluetooth part: https://fcc.report/FCC-ID/2AWEE-8762-01/4740558
In short, as I interpret the BLE configuration:
* a "Generic Attribute Profile" service, like all BLE devices have
* a service related to bluetooth parameters, also looks fairly standard, and not related to the measurements themselves
* a "Device information" service
* a custom vendor-specific service, where I suspect the noise-meter specific data is
In raw format:
In raw format:
* <b>service 00001801-0000-1000-8000-00805f9b34fb: Generic Attribute Profile</b>
* <b>service 00001801-0000-1000-8000-00805f9b34fb: Generic Attribute Profile</b>

Latest revision as of 09:19, 29 April 2024

Project NoiseMeter
File:NoiseMeter.jpg
Measuring audio noise as citizen science
Status Initializing
Contact bertrik
Last Update 2024-04-29

Introduction

This project is about measuring environmental audio noise as citizen science.

For example, noise can be:

  • road traffic noise (cars, mopeds, etc)
  • air traffic noise,
  • industrial noise, like building activities

Existing sound/noise meter projects:

This project page considers a kind of clone of the Amsterdam Sounds project.

Other interesting stuff:

Hardware

Nano33 IOT

Nano33 IOT pinout

Hardware is a nano33 iot board.

Connections
SPH0645 nano33 iot Remark
SEL - leave unconnected
LRCK A2 (16) - I2S FS sample clock
DOUT D4 (4) - I2S SD data
BCLK A3 (17) - I2S SCK bit clock
GND GND
3V 3v3

Software

The software is based on Arduino, a kind of clone of the Amsterdam Sounds project, modified to use WiFi (instead of LoRa), written by Rene Kuijf.

My modifications consist of a platformio configuration, for easy building.

See AdamSoundsInflux-slim-nano-33 github repo for the source code.

Casing

Microphone protection

To protect the microphone, use a membrane, like:

Junction box

Simple junction boxes sold by Gamma:

A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.

Sensor.community casing

See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg

Dimensions:

  • microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long
  • main piece is 25mm, length 160mm
  • some other connecting piecess

"RIVM" test casing

Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein

My guess:

  • microphone is on a 10mm diameter pipe, length 100mm
  • main case is a 40mm diameter pipe, length 200mm

Experiments

Uni-T UT353 BT noise meter

This thing has bluetooth.

serial interface

Interpreting serial port data on Linux is not straightforward, since Linux treats a serial port as a terminal so by default it does terminal-specific stuff to the data. The data below may have been corrupted by the Linux tty subsystem trying to escape/unescape certain byte sequences.

There is an internal serial interface (9600 bps). Use the following to configure the serial port on linux

 stty -F /dev/ttyUSB0 raw 9600 -echo

Then dump using

 cat /dev/ttyUSB0 |hexdump -C

or

 jpnevulator --tty=/dev/ttyUSB0 --read --width 23 --ascii

When in bluetooth mode, there is data going over this interface:

01 fc 12 13 aa bb 10 05 3b 20 20 34 34 2e 31 64 42 41 3d 34 00 04 14 
01 fc 12 13 aa bb 10 05 3b 20 20 34 30 2e 34 64 42 41 3d 34 00 04 13 
01 fc 12 13 aa bb 10 05 3b 20 20 33 39 2e 30 64 42 41 3d 34 00 04 17 
01 fc 12 13 aa bb 10 05 3b 20 20 33 38 2e 35 64 42 41 3d 34 00 04 1b 
01 fc 12 13 aa bb 10 05 3b 20 20 33 38 2e 34 64 42 41 3d 34 00 04 1a 
01 fc 12 13 aa bb 10 05 3b 20 20 33 38 2e 38 64 42 41 3d 34 00 04 1e 
01 fc 12 13 aa bb 10 05 3b 20 20 33 39 2e 31 64 42 41 3d 34 00 04 18 
01 fc 12 13 aa bb 10 05 3b 20 20 33 38 2e 39 64 42 41 3d 34 00 04 1f 
01 fc 12 13 aa bb 10 05 3b 20 20 33 39 2e 35 64 42 41 3d 34 00 04 1c 
01 fc 12 13 aa bb 10 05 3b 20 20 33 39 2e 32 64 42 41 3d 34 00 04 19 

Dividing into "frames", starting with 01 fc 12 aa bb:

01 fc 12 13 aa bb 10 05 3b 20 20 34 34 2e 31 64 42 41 3d 34 00 04 14 => "44.1dBA"
01 fc 12 13 aa bb 10 05 3b 20 20 34 30 2e 34 64 42 41 3d 34 00 04 13 => "40.4dBA"

<---------header--------->
01 fc 12 13 aa bb 10 05 3b
                           <------------ascii------->
                                  X  X  .  X  d  B  A
                                                      <--- footer-->
                                                      3d 34 00 04 ??

Footer

3d 34 XX 04 YY
^--- ????
   ^--- is 34 in slow mode, 33 in fast mode
      ^--- buttons pressed: 01 = hold, 04 = min, 08 = max
         ^--- always 04?
            ^--- varies between 10, 11, 12, 13, 14, 15, 16, 17, 19, 1B

Each frame is 23 (x017) bytes long

With the Android app connected, it sends smaller frames, like

AA BB 10 01 3B 20 20 34 35 2E 34 64 42 41 3D 33 04 04 17            	....;  45.4dBA=3...
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            	....;  45.2dBA=3...
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            	....;  45.2dBA=3...
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            	....;  45.2dBA=3...
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            	....;  45.2dBA=3...
AA BB 10 01 3B 20 20 34 35 2E 32 64 42 41 3D 33 04 04 15            	....;  45.2dBA=3...

When toggling the hold button on the Android app, we see

AA BB 04 FF 00 02 68

It now becomes more obvious that the AA BB sequence is a header, followed by a length byte

BLE interface

This thing has a bluetooth interface. FCC report on the bluetooth part: https://fcc.report/FCC-ID/2AWEE-8762-01/4740558

In short, as I interpret the BLE configuration:

  • a "Generic Attribute Profile" service, like all BLE devices have
  • a service related to bluetooth parameters, also looks fairly standard, and not related to the measurements themselves
  • a "Device information" service
  • a custom vendor-specific service, where I suspect the noise-meter specific data is

In raw format:

  • service 00001801-0000-1000-8000-00805f9b34fb: Generic Attribute Profile
    • ...
  • service: 0000ff12-0000-1000-8000-00805f9b34fb: Unknown
    • characteristic: 0000ff01-0000-1000-8000-00805f9b34fb Unknown
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb Characteristic User Description "Data In"
    • characteristic: 0000ff02-0000-1000-8000-00805f9b34fb Unknown
      • descriptor: 00002902-0000-1000-8000-00805f9b34fb Client Characteristic Configuration
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb Characteristic User Description "Data Out"
    • characteristic: 0000ff03-0000-1000-8000-00805f9b34fb Unknown
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb Characteristic User Description "Baud Rate"
    • characteristic: 0000ff04-0000-1000-8000-00805f9b34fb Unknown
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb Characteristic User Description "Link Interval"
    • characteristic: 0000ff05-0000-1000-8000-00805f9b34fb Unknown
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb Characteristic User Description "Pair code"
    • characteristic: 0000ff06-0000-1000-8000-00805f9b34fb
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb "BT Name"
    • characteristic: 0000ff07-0000-1000-8000-00805f9b34fb
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb "Pair Code En"
    • characteristic: 0000ff08-0000-1000-8000-00805f9b34fb
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb "Adv interval"
    • characteristic: 0000ff09-0000-1000-8000-00805f9b34fb
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb "TX Power"
    • characteristic: 0000ff0a-0000-1000-8000-00805f9b34fb
      • ... "MCU Delay"
    • characteristic: 0000ff0b-0000-1000-8000-00805f9b34fb
      • ... "Mode Control"
    • characteristic: 0000fff0-0000-1000-8000-00805f9b34fb
      • ... "Factory Set"
    • characteristic: 0000fff1-0000-1000-8000-00805f9b34fb
      • descriptor: 00002901-0000-1000-8000-00805f9b34fb "Reset"
  • service: 0000180a-0000-1000-8000-00805f9b34fb Device Information
    • ...
  • service: 0000d0ff-3c17-d293-8e48-14fe2e4da212 Vendor specific
    • characteristic: 0000ffd1-0000-1000-8000-00805f9b34fb Write
    • characteristic: 0000ffd2-0000-1000-8000-00805f9b34fb Read, typically 40C1F6049BD7
    • characteristic: 0000ffd3-0000-1000-8000-00805f9b34fb Read, typically 01901468
    • characteristic: 0000ffd4-0000-1000-8000-00805f9b34fb Read, typically 21100048
    • characteristic: 0000ffd5-0000-1000-8000-00805f9b34fb Read, typically ...?
    • characteristic: 0000ffd8-0000-1000-8000-00805f9b34fb Write
    • characteristic: 0000fff1-0000-1000-8000-00805f9b34fb Read, typically 0501000700080000F00F0000
    • characteristic: 0000fff2-0000-1000-8000-00805f9b34fb Write
    • characteristic: 0000ffe0-0000-1000-8000-00805f9b34fb Read, typically 00 00 00 01 01 00 00 00 01 90 14 68 21 10 00 48