I suppose the comment out is just for testing purpose (enable/disable the problem)
I also suppose the problem in the delay(300) which makes the processor to doing nothing for 300ms and might stop the audio playing. I am sure it is the better way to delay the LED by using a timestamp inside the loop.

For me it works fine when click on the "Floppy". It saves a file with the name given in the project name (even if it is called "main") and use .m5f extension. You will find the file in the browsers downloads directory. It is possible to load this file later oder view the content in any text editor.

For my Celestron Nextstar SE I simply added a cheap Bluetooth module into the Hand held controller.
There are many different versions of the controller board so there are many different instructions available. One is here: https://www.instructables.com/Bluetooth-enabled-Nexstar-handcontroller/
In my device it was a version where no instructions were availlable but it was easy to identify the RX and TX line between the USB chip and the microcontroller (which is the bigest chip inside). It was also easy to find a line that offers 3.3V for the HC06 bluetooth module. Adding a small switch into the data line allows the choice of USB (for SW updates) or Bluetooth (for normal use).
It works fine with Stellarium software on my laptop and WiFi is still available for internet connection.

try the following:

1. set the stick to power OFF
2. plug in USB (it will automatically power ON)
3. look in M5Burner (or in your computers device manager) if the serial port appears. If not there is a driver issue on your computer or your USB cable might have broken wires (once happened to me)
4. if the port appears burn the factory test or UiFlow

I suppose there no need to put the stick in any special mode to burn the firmware. the internal USB chip will do that for you while the programm downloads. Once the UiFlow Firmware is running you have to set the mode for wifi or usb if not already done while burning firmware.

Your information is very insufficient. I suppose you have the UIFlow firmware on the Stick. Did you try to upload a new program by UIFlow? Is it possible to re-flash the UIFlow firmware or the factory test program?

UHF-RFID use a different frequency so a standard smart tag will not work.
RFID RC522 (most common for smart tags): 13.56MHz
UHF RFID (long range): 860 to 960 MHz

There are even more RFID frequencies like 125kHz, 134kHz... depending on the application and the country where it will be used.

Hi,
You wrote: Once the M5Stack is powered off, only the CAN information can no longer be read. So the solution is easy: Power ON the M5 device!
Or do you mean OTHER devices on the same CAN are not able to read data WHILE M5 is OFF? In this case it might be possible that the CAN transceiver in the Commu is still powered (check that!) but miss the input signal. According to the datasheet of the CAN driver chip the bus output is dominant while TXD and S pins are LOW. This blocks the communication of other devices. It may help to solder the pin 8 of the transceiver to +3.3V instead of GND to enable silent mode (switch it to Rx only) or make sure the commu is not powered. The bus driver is then going to float (Off Mode) and should not block the communication anymore.

Method 1: As far as I know the pulse goes from 1ms to 2ms (1.5ms is middle position). It should be possible to "analogify" or mathematically say "integrate" the PWM signal using a R-C combination on the input pin and read the voltage from this. But the voltage level will be low due the duty cycle which goes from approx. 1:20 (1ms/20ms) to 1:10 (2ms/20ms). From 5V full scale you read 0.25V to 0.5V. You may add an analog OPAMP amplify it to 5V. This method will slow down the reaction time a little bit

Method 2: Before doing the Method 1 it may be less effort to write it in Arduino and use either a PWM read library or use a interrupt to measure the pulse width. You can also read the low time to determine if the input signal is valid or not eg. to detect signal loss.

Method 3: This is the simple but ugly workaround! Add a small Servo to your signal and drive a potentiometer which ist then read by the M5 analog input.

If you compile the example WiFiAccessPoint then it means the Atom turns into a WiFiAccessPoint. If you entering the same SSID and PW as your home Wifi then it means you are creating an additional access point on the Atom with the same name as the existing one. This may be confusing. The IP Address of 192.168.4.1 is the local address of the Atom now. Change the SSID on the Atom to something else to avoid the confusing.
To connect your Atom to the existing wifi you need a WifiClient sketch or any firmware like UIFlow that has one included. After connection to your home Wifi the Atom gets an IP Adress from your home DHCP Server which is running on the Wifi Router in most cases. This should be one in the 10.0.0.xxx range if this is your home network.

Ok, I see you want to poll the data instead of push.

Blockly, which is great for simple projects or quick test of a sensor, seems to lack of many functions. It is also not very comfortable for extensive projects and you are required to use a cloud service to edit your code or you have to use a very old desktop version with even less functions. My oppinion about that.

I prefer the Arduino environment. There are many libraries and examples including web servers.
It means a bit more of text coding and less drag&drop but copy&paste from examples work for me well.