AN-000298, T583x MEMS Microphone Acoustic Activity Detect User Guide

Hello,

My apologies for the delay and thank you for your patience while we bring this forum up-to-date.

We are working on some updates and corrections to this app note and should have this available in the coming weeks.

In the meantime, do you have specific concerns or questions regarding our Acoustic Activity Detect that I can help you with?

Regards,

Mike

Dear Mike,
the protocol you are using for setting up AAD modes is not I2C but "onewire" with CLK and THSEL as Data I/O.
I would need a uC library for implementation in a Platform. Could you provide that?
regards
Stefan

i have a question about ACOUSTIC ACTIVITY DETECT ANALOG i'm wondering if the output when using this mode is analog or pdm pulsation or it just use for turning wake pin high or low I'm also wondering when about the AN-000298 documentation will be available ,
best reagrds

Stefan,

Thank you for reaching out. I am not aware of an existing uC library that we provide. I am making a note of your request and will get back to you if I have any updates on your question.

Regards,

Mike

Hi,

Thanks for your questions.

When AAD Analog mode is enabled, there is no audio signal output from the microphone. This allows the microphone to run at the absolute lowest power for AAD, ~20 µA. If an output is needed from the microphone, AAD Digital 1 can accomplish this as it can be enabled in the microphone's Low Power Mode.

With regards to the App Note, AN-000298, this is still in the works but, unfortunately, I don't have a firm date on this. I will make sure to update the thread here when it is available.

Regards,

Mike

Hello Mike,

I am also interested in the availability of a library or even sample code for your T583x.

Regards,
Rob

Dear MOD_Mike, dear TDK

  We have problems enabling and configuring the AAD D2 (Digital 2) mode! We implemented the CLK+THSEL protocol and verified that AAD A (Analog) works fine, and the mic "sees" our configuration (namely the threshold AAD A) but we are unable to do the same for AAD D2! First and foremost the register listing on page 27 of the datasheet (both versions 1.0 and 1.1) is IMHO incorrect. It tells to set register 0x36 (which is for AAD Analog), and what's worse it shows to set 0x29 to 0x01 which is for AAD D1 (Digital 1). After some time we discovered that setting 0x29 to 0x0F enables, what we believed, is AAD D2 but then we were unable to change the thresholds, min pulses and the floor (there's no change in the WAKE pin output whatever we set). Can you provide us with a better example of register values for AAD D2? Thanks!

Dear TDK

From my development findings both D1 and D2 modes don't work at all. There are obvious mistakes in datasheet, but trying everything configuration wise, microphone just doesn't trigger when in either D1 or D2 AAD mode.

Lack of documentation and state of it isn't helping.

AAD A mode does work.

lukasziiomicous: I have also received info about writing 0x0F to enable D2 mode (I believe you wrote to my colegue), that is not actually the case! By writing 0x0F to device, you are enabling AAD A mode in parallel and getting trigger of of that mode, not actual D2 mode. 0x02 is correct value to enable D2 mode (seen by device current consumption)

Thank you for your questions and for highlighting these typos. We're in the process of updating our documentation and, as you mentioned, there are corrections to be made to the example sequences for AAD D1 and D2. I have attached an updated sequence of writes that should bring up AAD D2 with the parameters shown. Note that the numbering of the register writes has been changed, compared to the current datasheet tables, to put them in sequential order but in practice the order with which you write them should not matter.

Please let me know the status once you have tried this updated sequence.

Regards,

Mike

Thank you also for your question and feedback. Please see the above reply that includes an updated sequence of register writes that should enable AAD D2.

As I mentioned, we are working to update the documentation for AAD and plan to have these updates available soon.

Please let me know your progress with this corrected sequence.

Regards,
Mike

Rob,

Unfortunately, at this time we do not have software libraries available. I will update if there is any change to this.

Regards,
Mike

Dear MOD_mike and sewoji4568weirbycom yes, we figured out that setting 0x29 to 0x0f is probably enabling AAD A because microphone enabled that way was not responding to AAD D2 configuration at all. And yes, that was me who contacted you.

MOD_mike I tried your configuration with no luck :(. Using it. My resulting plot is attached on the first screenshot. Next, when I modify the last call so it sets 0x29 to 0x0F (this was what Zohir experimented with) or 0x08 (I know it's for AAD A) then the plot looks like on the second attachment. I'm adding it to show that our protocol "kinda" works, namely the microphone "hears" us and accepts at lest some of our commands. As I stated before, and in accordance with what sewoji4568weirbycom said AAD A works well, and we are able to configure its threshold.

I have tried suggested updated sequence with no luck.
Doing exact configuration as suggested makes no difference and AAD D2 mode still doesn't work. I haven't tried it yet with AAD D1, but it is D2 mode I am more interested in after all.

Hi,

Thanks for your response. As you mentioned, it does appear that the device is acknowledging some of the writes being issues as you can see the acknowledgement pulse coming from the AAD system.

If possible, it would be helpful if you could post either a file of the capture from your logic analyzer or screenshots of the sequence of writes that are zoomed in enough to be able to look carefully at the timing of these signals.

Regards,
Mike

Hello,

As I mentioned above. It would be great if you could post a file containing the sequence of writes captured using a logic analyzer or some screenshots of the writes with the appropriate time scale to review the timing of each write.

Thanks,
Mike

from my code logs, so sequence can be seen:
[00:00:00.390,625] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x5c, data: 0x0
[00:00:00.401,733] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x3e, data: 0x0
[00:00:00.413,055] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x6f, data: 0x0
[00:00:00.424,133] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x3b, data: 0x0
[00:00:00.434,753] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x4c, data: 0x0
[00:00:00.445,373] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x29, data: 0x0
[00:00:00.455,993] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x2a, data: 0x0
[00:00:00.467,529] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x2b, data: 0x16
[00:00:00.478,851] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x2c, data: 0x32
[00:00:00.489,715] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x2e, data: 0x0
[00:00:00.500,793] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x2f, data: 0x0
[00:00:00.511,169] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x30, data: 0x0
[00:00:00.522,491] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x31, data: 0x13
[00:00:00.533,355] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x32, data: 0x1
[00:00:00.544,677] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x33, data: 0x24
[00:00:00.555,511] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x29, data: 0x2

note that I have one extra write to 0x29 with 0x00 since my current setup doesn't support toggling power to microphone, but I had no luck with removing said write either. This write is here so I still get verification pulse on wake pin after the sequence.

attached you will find CSV export from logic analyzer since screenshoting does not give nice representation of full sequence being written.

Another reply with zip file, since forum apparently doesn't allow CSV to be uploaded.

Hey good point, here are the captures:
* MOD_mikes-config.sal - the register set from MOD_mike above.
* our-config.sal - again AAD D2 attempt, but with everything set to minimum (more sensitive).
* AAD-A-for-reference.sal - AAD A

400Hz sine signal from a speaker 10cm from the mic.

There is another issue I found. Datasheet states that unlock sequence can be written once and is valid as long as there is power applied to the microphone.

My testing proved otherwise.
unlock sequence is valid as long as there is AAD mode enabled. If I enable AAD mode, and later disable it via writing to registers, sequence has to be repeated when re-enabling AAD mode.

Please update the write to register 0x32 in your sequence as follows:

[00:00:00.533,355] <dbg> t5838: prv_multi_reg_write: t5838 reg write addr: 0x32, data: 0x21

Please try adding an additional write of data 0x00 to address 0x29, immediately following writing 0x00 to address 0x4C. Please see the sequence posted by @sewoji4568weirbycom below as an example. As they mention, this write is not shown in the documentation, but my code does include this write and it appears that it may be necessary in some cases. Otherwise, your register writes appear to be correct, including the correct value of 0x21 being written to address 0x32.

The only other thing that I noticed was that there is some variation in the period of your clock signal. If all your signals are synchronized to your clock signal, then I would not expect slight variations to be a problem but if adding the write above does not solve the problem then I would recommend trying to ensure the clock frequency is stable.

To the moderator:

My apologies just dropping in with a comment but it would be really helpful if there was a published and tested c library for this mic. I, like probably many others, have to develop one from scratch. This is a really odd and limited protocol and the lack of any ability to read registers and only be able to check for a pulse ack makes this time consuming and difficult to test so it is not surprising that there is a support thread like this.

Regards,
Rob

Hi,

Thank you for this comment. I think you are correct here with some caveats.

There is a reset mechanism that we are adding to the datasheet that is triggered by disabling AAD and then subsequently placing the microphone in sleep mode with the clock disabled (f_clk < 1 kHz). When this sequence occurs, the AAD register are reset, and I suspect this is why you are observing the need to write the unlock sequence again after disabling AAD. This does assume that you are turning off your clock or setting its frequency below 1 kHz after disabling AAD; is that a fair assumption?

As I mentioned, this sequence is not currently in the datasheet but we are in the process of adding it.

Regards,
Mike

I have updated the code to write 0x21 to address 0x32 with no luck. I had this configured prior but I guess I accidentally removed it during further testing. Unfortunately, with same result.

Dear MOD_mike,

I'm also experiencing difficulties in activating AAD2. I have attempted the new sequence that you recently provided, but it hasn't been successful. At the end of the sequence, It set the WAKE pin to HIGH for approximately 12 microseconds, but afterward, it remains low and doesn't seem to respond to any acoustic events. Could you please provide more insights into how this should work or share the sequence that has been effective for you?

Thank you.

Hey everyone. This actually worked for us (in order to enable AAD D2). We are starting to test it but at least WAKE reacts to noises:

The register 0x32 bit7~5, mask_duration, needed to set with value >=2.

mask_duration = 2; //2~7
absoluteThreshold()
{
writeReg(0x31, lsb);
writeReg(0x32, (mask_duration<<5) | msb);
}

Hi,
Anyone can please share the working c code, so I can test this feature at my end.

Hi,
I am also looking for a working C code.
Is there any update from Invensense site?

Thank you @lukasziiomicous for providing the capture, I have been strugling to get AAD-A working for months. I have now figured out clock signal has to be turned on for about 500us before starting the ThSel signal. I only had the clock turned on for about 200us before starting and it did not work. Could the datasheet please be updated to warn that clock signal has to be active for some time before writing to ThSel pin.

Hello,

I have been struggling to get the T5838 to respond to AAD-A setup. I see above that others have succeeded and I have reviewed their Saleae logic analyzer outputs. I first attempted to implement a bit-banged signal (see bit-banged AAD-A.sal). I did not receive a 12uS wake pulse from the T5838. I checked my waveform against other working examples and cannot find any issues with mine other than some jitter. To reduce the jitter I then used the SPI CLK and MOSI outputs to generate a signal that emulates the T5838 protocol. This was done by mapping the T5838 signal to an array of SPI bytes (see SPI generated AAD-A.sal below). I did not see the T5838 respond with this either. With the SPI generated signals the SPI and Thsel edges line up as shown below (SPI generated CLK and THSEL edge alignment.jpg). Perhaps this is an issue?

I have a custom circuit that includes a 1.8V regulator and a 1.8V to 3.3V level converter chip. I have checked that the CLK and THSEL signals are getting level shifted correctly and that the 1.8V regulator is working. I cannot easily test the WAKE level conversion because there is no signal but it is part of the same chip and the direction is correct. I see no 1.8V WAKE signal from the T5838 so I do not think that there is a level conversion issue. I measured the T5838, level and voltage regulator circuit current consumption with no CLK and it is about 10uA including the regulator and level conversion chip. When I clock the T5938 circuit the current consumption jumps to a few hundred uA for the duration of the CLK. I have tried different boards in case the board has a bad chip.

My next step is to see if I can get PDM data from the T5838 just to confirm there is not a chip or board issue.

Any feedback on my signals and issue would be appreciated. I am happy to post my code to a shared repository if anyone has a serious interest in getting it working. The code is Arduino based but could be converted to c. I am using an ARM M4 microcontroller.

Thanks,
Rob

Just a follow up.

I tested the PDM functionality and I am able to read PDM data from the microphone using my test setup. This confirms that the microphone is powered correctly and the PDMCLK and PDMDATA signals are being level converted and are connected correctly. It seems that the microphone is functional so there must be something wrong with my THSEL message. Any help is appreciated.

Thanks

I finally managed to get D2 mode into operation. I would like to also express my great disappointment with how this issue was handled so far!

After our driver implementation was sitting with no luck of getting D1 and D2 modes to works, I finally resolved the issue today. Solution was to use sequence as described in T5848 datasheet - different part number. At the time of our driver development this datasheet was not yet available.

Main issue was with register 0x32 and value that is written into reserved bits. T5838 datasheet claims you should write 0 to reserved bits, updated sequence in this forum thread claims you should bitwise or the value 0x20 (aka. setting 0x01 to reserved bits) while it should actually be bitwise or with 0x40 - as per t5848 datasheet.

Also note that all the support information in regards to this issue that was found in this thread is behind log-in wall and while at it - really bugged one where logging into these forums seem to break for me if trying to access original link that throws me on login page.

Both datasheets still claim reference to application note that users were asking about in this thread - this application note still doesn't exist, despite claims made back in April 2023 that application note should be available in "following weeks" - it has literally been more than 100 weeks at that point.

Also there are registers explained which make sense to configure for T5848 algo selection that also seem to work for T5838 and are not documented at all for T5838.

We feel very displeased with how all this was handled! There have been multiple users having same issues and all we got was support claims that this operates fine and solutions that didn't actually work. There is no official reference driver/implementation to confirm operation, the whole "one wire" that isn't really one wire protocol is just terrible. There was absolute no viable way to resolve this problem with wrong information in datasheet and wrong information provided by support.

We spent significant amounts of effort trying to make this functionality work at the time, wasting weeks to months of time and money only because your documentation and support was not providing correct information.

And even years after the issue, information in datasheet is still wrong for active production part! there was absolutely no resolution from support and the only way to resolve this now was a wild guess that different more recent part from your line is using same configuration.

Hello, I'm trying to get AAD to work as well but I simply don't see anything on the WAKE pin.
I think I must've missed something. I'll include the code I've written for my STM32U375 and the output of the logic analyser.

In the logic analyser output you'll see the clock start with a frequency of 100KHz just like in the example on page 18.
Then I send the sequence described by the data sheet on page 21 to turn on AAD A.
I should have gotten a response by now on the WAKE pin but I didn't as you can see in the logic analyser output.

After that, I turn the clock off. wait for a bit and switch to a higher frequency of 500KHz, then the audio data starts coming out of the mic, this works fine.
That leaves the question: what am I doing wrong?

Thanks for the clarification. That makes sense regarding the Analog mode and its low-power operation. I’ll look into using AAD Digital 1 when an output signal is required. Appreciate the update on the App Note as well—please do keep us posted once it’s released.

saaas

sadasd

sdfsdfssdf

cxvcxzvzzxcxz zzcxxzxc zxc

Hi all,

I'm using an nRF52832 module and a T5838 mic. I'm using the PDM clock at 65kHz (within the range specified in the data sheet) and then bit-banging the THSEL pin with a usec timer. I don't get the 12uS pulse on the WAKE pin, it just goes high once the clock is stopped and stays high.
I've tried tweaking the number of clock cycles in the range 10-15 with no change. If I disable all interrupts I get a nice clean signal with very little jitter. I've looked at lukasziiomicous' AAD-A-for-reference capture and it matches up very well with my traces. The chip works in non-AAD mode.

Has anyone that was having trouble getting the AAD-A mode working and resolved their issues got any tips?

Thanks,
Julian