thank you - I appreciate you letting us know about the implication regarding power safe and usage of BLE and WiFi.

Thanks
Felix

Thank you very much. According my current research I cannot disable power safe function which includes wifi sleep. Reason behind is that I´am also using Bluetooth application and BLE + Wifi does not work in disabled power safe mode. According this discussion:
https://github.com/esphome/issues/issues/2141#issuecomment-865688582

Nevertheless, I activated adc power and longpress for user button for 2seconds. Since then I have not received any false signals and therefore I think I can deal with this and we have solution so far.

Big Thx and greetings!

Thx, I wasn´t aware that there are two models, Atom and Atom Lite so good to know.

I have Atom Lite in use / bought some days ago.

According your information I activated adc power for GPIO33 and will test if this will eleminate the pulses for GPIO39.

Because GPIO33 has no pullup I can only see unstable signal from 0.05V to 0.6V at the moment.

I cannot proof by oscilloscope so in case of several days without recognized pulses at GPIO39 I have to deal with this and assume that it will work in this case. More precise and professional measurement isn´t possible at my home.

Atom Lite is a simplified schematic and difficult to deal with.

M5Stack Atom PSRAM is fine.

There are two confirmations of unnecessary triggers.

1. Check the operation of Atom Lite.
2. You need to see the GPIO_39 waveform on your oscilloscope.
   2 is important.

... Google translate

Thx. I am testing at the moment with longpress trigger >=2 seconds and no unwanted actions have been triggered so far.

But if I understand your code right, you just included adc.h in general. Not directly specified and aligned for an GPIO e.g. GPIO39, right?

I think I can make use from this and align ADC Power to an unused GPIO (e.g. GPIO 19, 22 or 23) from my Atom lite. This will include adc.h for software compiling (automatically by ESPHome) and activate ADC Power in general. This should then also be beneficial for GPIO39 and avoid theses pulses.

wifi sleep I do not know if this can be disabled.

Web Radio of M5Stack
https://macsbug.wordpress.com/2021/01/08/web-radio-of-m5stack/

Web Radio with a built-in speaker in M5Stack
https://macsbug.wordpress.com/2021/04/16/web-radio-with-a-built-in-speaker-in-m5stack/

The button functions are as follows.
M5.BtnA.isPressedPressed(),
M5.BtnA.wasPressed(),
M5.BtnA.pressedFor(ms)
https://github.com/m5stack/m5-docs/blob/master/docs/ja/api/button.md

No matter which command I used, the A button was pressed without permission.
In M5.BtnA.pressedFor (ms), a problem occurred even with a value of 25 to 250 msec.

When I checked the signal of GPIO39, a pulse was generated.
The number of times a pulse is generated and the number of times a button is pressed do not always match.

This issue has been resolved below.
WiFi.setSleep(false);
Or
#include <driver/adc.h>
void setup(){
adc_power_acquire(); // ADC Power ON

Yes, I´m using Wifi in parallel and this sounds very similar to my identified behaviour. I´m not skilled in programming and using standard software solution ESPHome.
During compiling process the SDK version is shown:

Processing esp32 (board: m5stack-core-esp32; framework: arduino; platform: platformio/espressif32 @ 3.3.2)

This seems to be newer than reported in this github issue?

@macsbug as linked by you I have to check if can make use of the workaround by turning on the ADC power.

In general it is not clear mentioned if this problem only occur for millisecond or so? So in case of only a quick signal switch on/off I would prefer a woraround by making use of a "longpress-function". For usability longpress of e.g. 2 seconds is ok for me and in case the wifi/interrupt case will never switch longer 1 second this should work.....what do you thing about it?

I don't own ATOM Lite (ESP32-PICO-D4), so I haven't checked it.

1. Does the problem occur when using WiFi?
2. You need to check the signal of GPIO39.
   ：

In M5Stack (ESP32-D0WDQ6-V3), there is a case where GPIO39 works without permission when using WiFi.
M5.BtnA.wasPressed() conflicts with WiFi
https://forum.m5stack.com/topic/3262/m5-btna-waspressed-conflicts-with-wifi
：

Supplement：
Example of using GPIO39.
M5Stack Basic (ESP32-D0WDQ6-V3)：PULL UP with 100KΩ.
ATOM PSRAM (ESP32-V3-02)：PULL UP with 5.1KΩ.
M5Stamp Pico (ESP32-PICO-D4)：PULL UP with 5.1KΩ.

I haven't opened my M5Atom so I cannot say for sure whether there is an external pull-up resistor or not. But I must assume there is.

I think your issue might be that some GPIOs (like GPIO36 and GPIO39) can produce 'ghost' inputs when WiFi is active with sleep mode on. See here.

Thanks
Felix