Is there a way to use a PDM mic?

[slevin22]

Hi, I'd like to use this on an m5 atom u which has a PDM mic built in. I know the official microphone component has a PDM option. Is there any support for a PDM microphone in this component?

[stas-sl]

Hi, currently it does not support PDM mode and I don't have such mics around to test it, but looking at the official implementation, seems like the only difference is in a single boolean flag set upon driver initialization. So I can add it, but, as I said, I can't test if it actually works, or more modifications are needed. So you'll have to test it on your own, and let me know whether it works. Or if you are aware of any other PDM specifics that should be handled let me know also.

[stas-sl]

I've just added it to a separate branch pdm_support (I'll merge into main, if it works), so you can try it by specifying branch name at the end of source url and set pdm: true for i2s section:

external_components:
  - source: github://stas-sl/esphome-sound-level-meter@pdm_support

# ...

i2s:
  # ...
  pdm: true

# ...

But this is fully untested, so it might work or not.

[slevin22]

Wow, thank you!! I'll let you know if it works! :) Great project by the way. I use it to close my blinds when my dog barks.

[slevin22]

Hmm, so with PDM on, I get a consistent LZeq_1s reading of 135.92473 dB +/- 0.00001 dB

This is a different result than with it off, so it's definitely doing something! I'm going to play with the configuration and see if I can get any different results.

If you're interested in testing hardware with a PDM microphone, let me know. I'd be happy to sponsor the hardware for you. I'm using an M5 atom u, and it's a neat little device.

[stas-sl]

I use it to close my blinds when my dog barks.

Interesting application )

I'd be happy to sponsor the hardware for you

Thanks ) It will probably take a month or more to ship it here, let's first see if we can make it work sooner.

1. Can you show me the config you are using? What are sample rate, bits per sample, bits shift, sensitivity, pins?
2. Is there any documentation/examples for this device saying what these values should be?
3. Have you tried to use it with official ESPHome i2s_audio /microphone components? If it works, then can you show the config?

I have found this example https://github.com/m5stack/M5AtomU/blob/master/examples/Audio/STT/EchoRest.ino - based on it, I would recommend trying these settings:

  ws_pin: 5
  din_pin: 19
  sample_rate: 16000
  bits_per_sample: 16
  bits_shift: 4

There are other small differences, which I'm not sure whether they are critical or not. For example it sets BCK_PIN to -1 (unused) which, I don't think is possible currently with my component.

[slevin22]

Hm, interesting. The device has microphone pins listed as data: 19 clock: 5 so I was assuming that clock would be bck. The only documentation I found lists the microphone as a SPM1423 the aforementioned pins.

Testing with the settings you suggested gives a reading that ranges from 107 to 109 dB
It doesn't appear to be correlating to real audio levels.

Here's my exact configuration as I just loaded it:

  name: "atomu-1"
  friendly_name: m5 atom u 1
#packages:
#  esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/esp32-generic.yaml@main

external_components:
  - source: github://stas-sl/esphome-sound-level-meter@pdm_support

esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
  platform: ESP32
  board: m5stack-core-esp32
ota:
  password: "xxxxxxxx"
api:
  encryption:
    key: 

logger:
  level: DEBUG


wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password


i2s:
  bck_pin: 21 
  ws_pin: 5
  din_pin: 19
  pdm: true
  sample_rate: 1600            # default: 48000
  bits_per_sample: 16           # default: 32
  dma_buf_count: 16              # default: 8
  dma_buf_len: 512              # default: 256
  use_apll: true                # default: false
  bits_shift: 4                 # default: 0

sound_level_meter:
  id: sound_level_meter1

  # update_interval specifies over which interval to aggregate audio data
  # you can specify default update_interval on top level, but you can also override
  # it further by specifying it on sensor level
  update_interval: 60s           # default: 60s

  # you can disable (turn off) component by default (on boot)
  # and turn it on later when needed via sound_level_meter.turn_on/toggle actions
  is_on: true                    # default: true

  # buffer_size is in samples (not bytes), so for float data type
  # number of bytes will be buffer_size * 4
  buffer_size: 1024             # default: 1024

  # ignore audio data at startup for this long
  warmup_interval: 500ms        # default: 500ms

  # audio processing runs in a separate task, you can change its settings below
  task_stack_size: 4096         # default: 4096
  task_priority: 2              # default: 2
  task_core: 1                  # default: 1

  # see your mic datasheet to find sensitivity and reference SPL.
  # those are used to convert dB FS to db SPL
  mic_sensitivity: -22dB        # default: empty
  mic_sensitivity_ref: 94dB     # default: empty
  # additional offset if needed
  offset: 0dB                   # default: empty


  groups:
    - filters:
        - type: sos
          coeffs:
            - [ 1.0019784 , -1.9908513  , 0.9889158 , -1.9951786  , 0.99518436]

      groups:
        - sensors:
            - type: eq
              name: LZeq_1s
              id: LZeq_1s
              update_interval: 1s


switch:
  - platform: template
    name: "Sound Level Meter Switch"
    lambda: |-
      return id(sound_level_meter1).is_on();
    turn_on_action:
      then: sound_level_meter.turn_on
    turn_off_action:
      then: sound_level_meter.turn_off

my experiments earlier all used din_pin: 19 ws_pin: 21 and bck_pin: 5 and your defaults. I tried the following deviations, one at a time with everything else at the default settings:

bits_shift: 0
use_apll: false
sample_rate: 9600
bits_per_sample: 24

I haven't tried with the official i2s_audio/microphone components. I'll give that a shot next.

I think that answers all of your questions. Let me know if I left anything out :) I really appreciate your help.

[stas-sl]

1. 16 bits per sample is the safest option, which should work for most mics, so I wouldn't advice trying 24 or 32 bits before 16 bit works.
2. There is a typo in sample rate: 1600, where it should be 16000
3. You don't need any filters for dBZ. It should produce sensible readings without filters. And you can't use those filters from example configs because 1) they depend on sample rate (which is 48000 in my config) 2) they depend on specific mic (INMP441 in my case), so it makes no sense to use them with other mics
4. You can omit lots of settings for shortness, if you don't change default values. I exposed them for flexibility, but in many cases you don't need to modify them.
5. I updated component to make bck_pin optional, so you can try leaving it out completely (not setting to -1, just delete the line), just be sure you pulled latest commits by setting refresh: 0s in external_components

Summing it up, the config should look smth like this:

external_components:
  - source: github://stas-sl/esphome-sound-level-meter@pdm_support
    refresh: 0s # to ensure that it will pull the latest version

i2s:
  ws_pin: 5
  din_pin: 19
  pdm: true
  sample_rate: 16000
  bits_per_sample: 16
  use_apll: false
  bits_shift: 4

sound_level_meter:
  update_interval: 1s

  mic_sensitivity: -22dB
  mic_sensitivity_ref: 94dB

  groups:
    - sensors:
        - type: eq
          name: Leq_1s

Though, I not sure about pins and whether you need bck_pin set or not. If it will not work like this, I would search for more documentation/examples.