use GROVE cables for the sensors one comes with every sensor. The MBus interface at the bottom of the core2 is not intended to connect by Dupont lines. If you want to tinker additional hardware to M-Bus then one of the PROTO module might be useful. It adapts the Bus to 2.54mm (0.1") spaced solder points. You are free to use Dupont from there.

in the section "Text" is a piece that calls "Reduce ... to ... decimal places"

Hi,
your question reads like "my car will not start, what shall I do?". The standard answer to that question is "buy a new car" even if the solution would be as easy as "turn the key" or "fill some gasoline".
From your description we know you want to have a world clock and you have a m5go. What is missing:

• The environment you use to code your clock
• Your code which seems to be the problem
• the exact error message or a picture of what you call "overloaded"

please read this post first: https://forum.m5stack.com/topic/535/forum-rules-read-this-first-before-posting

Just my comment about the missuse of the words "hologram" and "holography":
Displaying a stereoscopic or augmented reality image that seems to be floating in the room has nothing to do with holograms or holography. It is impressive YES, but it is NOT a hologram. Why do I know this? Look at my nickname! I have made my own REAL optical holograms for many years. They are made by interfering high-coherent wavefronts coming for a laser source and recording the resulting pattern in a 2D surface. There are different types of setup but all have in common the interference of a reference-beam with a object-beam. See https://en.wikipedia.org/wiki/Holography

However, mounting a real hologram on a robot arm and move it around is also possible. In case of a hologram that changes its displayed content by the angle of the light source it can be very impressive!

EZData is just one of the possible data storages. With M5 products it is very easy to use. It is also possibe to use other cloud services. Cloud means "some storage somewhere on the internet". It requires a connection to the internet anyway.

Some ideas:

• Use a separate non interupted connection such as LoRa or mobile internet for your battery measurement. Depends on what is possible at your location and what/how you need to communicate.
• log to a cloud like storage in the local network, powered by battery on mains loss. No access during power loss but all data saved
• Detect the internet connection loss and log to SD card until the connection is back, then upload all missing.

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.

I don't see your problem. Just send the data to the according address of your light.
Maybe you do not understand the addressing of DMX lights?
You need to configure an individual start channel (address) for every light with a spacing of at least the number of channels your light support. E.g. your RBGW light is set to 4-channel-mode and its start channel is set to 1, then it listen to the channel 1, 2, 3 and 4. The next light can have the start channel 5 and so on. Some more complex lights like moving heads can have more than 30 channels. It is possible to have up to 512 channels per physical bus (called DMX universe)
You may set several identical lights to the same address but then they all do the same.
Also very important: The last light in the bus should have a terminator plug/resistor. It may work without but often a missing terminator cause strange effects on the DMX bus.

Here you find the information about this module: https://docs.m5stack.com/en/unit/hall

According to the schematic it contains three A3144 Hall-sensors and a 74HC08 AND-Logic.
The datasheet of the A3144 tells me that it has an open-collector output and the schematic that they are pulled up to 3.3V by resistors.
So the function is: as long as all three sensors are not in a magnetic field that is higher than the level for switching (see datasheet), the AND gate output is HIGH. If one or more of the sensors are triggered by magnetic field, the output goes LOW.
There is nothing to configure or program inside the module. The decission if the module fits to your project is up to you. By the way, if you plan to use a Arduino compatible controller it might be an option to use one that is based on ESP32. The controller already contains a Hall-Sensor.

Just that you know: M5Stack does not make a mystery about the inside of their modules. You always find a schematic and all the datasheets that tells you everything about the hardware and its function. It is a big benefit if you learn to read and understand this informattion.

there are 2 variants:

A) the PWM signal can be captured by measuring the time ratio between 1 and 0:

• Put the PWM signal into one of the GPIO. Make sure the voltage is not too high, use a voltage divider and if possible a additional Z-diode for protection).
• Set the input to an interrupt source for both edges
• in the INT-routine put the current time stamp into a variable and wait for an oposite edge appears. If you do this in a clever way, the controller can do other things in the mean while (e.g.sending the value over ESPnow)
• once you have a high and a low time you can calculate the ratio.

B) integrate the PWM and measure the analog voltage

• use a R-C circuit to integrate the PWM into a analog voltage
• divide the voltage by a trimmer potentiometer so that 100% equals full scale of the analog input. If possible use a Z-diode to protect the input
• measure the analog value by M5Atom

Deine Frage hilft leider nur wenig bei der Fehlersuche.

• Gibt es Fehlermeldungen, Fehlfunktionen oder wie kommst du darauf, dass das Programm nicht mehr funktioniert?
• Hast du den Quellcode zur Verfügung oder ist der mit dem Programmierer zusammen verschollen?
• Welche Art Programm ist es? Ein UIFlow bzw. Python Script oder eine kompilierte Software in C (z.B. über die Arduino Umgebung)
  Ein Script könnte auch von der UIFlow Version abhängen, ältere Scrips laufen nicht immer mit der neuesten Firmware und umgekehrt.

Versuche herauszufinden was zwischen den Versionen der Hardware geändert wurde (z.B. Zuweisung von Ports, I2C Adressen von verwendeten Komponenten usw.). Damit kann man dann den Grund für das Verhalten erklären und nach möglichen Lösungen suchen.

When looking to the schematic on the back side of the unit then you will see the signal paths:

1. from MIDI IN to Groove TXD and the Switch
2. from Grove RXD to SAM2695 and the Switch
3. from the Switch to MIDI OUT

Connecting the MIDI IN direct to the SAM2695 is not prepared.

You have to go thru Groove port to do that. It may work if you just bridge the TXD and RXT on the port with a jumper wire (don't forget the 5V supply). Otherwise you have to go thru your processor and put everything what is coming in direct to the out.

@andrew-winton did you connect the sensor +5V to the +5V and GND to GND of the RPi? Are you sure not having crossed the clock/data pins? I speak from experience... spent more than one hour for a simple failure like this.
When powering on the 5V can you measure if the 3.3V inside the sensor is correct?

@marcelusvictor Did you put the Cardputer into Download Mode as described here? https://docs.m5stack.com/en/core/Cardputer
If Yes, check your device manager if the COM port appears without any error message. If it not apears then your USB cable may be broken or has power wires only (cross check with another one).

I guess this is a voltage level issue on the power supply for the sensor. M5 Groove Ports use 5V, RPi use 3.3V. Internally the AIN4-20mA use 3.3V (there is a voltage regulator between Groove port and the converter, see the schematic on https://docs.m5stack.com/en/unit/AIN4-20mA Unit) and 5V for the OP-Amp. You may supply the unit with 5V.

@mgrouch KMeter is just the thermocouple converter. The TC insulation itself can be made from plastic or silicon or it can be made from glass fabric. It can also be inside a stainless steel housing or whatever. It depends on the application.
I just did a quick search for exhaust thermosensors and there are many K-type thermocouple in different housing available. As long as they have a TC connector or open wires for mounting one by yourself you can use them with KMeter.

I strongly recommend you to read the basics about thermocouples and how they work. You may than understand, that this "plastic thing" can be and should be far away from the high temperature exhaust.

By the way: If you feel better with the MCP9600 then buy one from e.g. Adafruit and use it with its library in the Arduino environment. You controller can still be M5. As for the KMeter the MCP9600 breakout is not made to put in the exhaust as well.

@konacurrents You wrote "I'm not using RC-5 with my ESP32 M5 controllers" and in the next posting "eg. the IR doesn't turn the TV on"
So do you want to remote control a TV or another device? If you not using RC-5 what alternative protocol does your device use?

For the mentioned test by the mobile phone camera: Test if ANY working remote from TV or HiFi etc... is visible by your mobile phone camera. Point the transmitter to the camera and press a button. If you see a flashing light, then your camera is able to see the IR light.
Now do the same at the M5StickCPlus when one of the examples is running.

If there is no flashing IR then investigate on the port number of the IRLED on your device and change it in the code to the right one. If it flashes but your receiving device is not reacting to it, it may be a wrong protocol or command.

It may help if you post the code you are trying and a description of what exactly you want to control.

Most IR Remote use RC-5 coding. See https://en.wikipedia.org/wiki/RC-5
Often the IR LED is pulsed with high current on very low duty to increase the working distance (refer the datasheet of your IR LED for maximal pulse ratings). If you have a "normal" IR LED on a GPIO it might be less effective. In this case you have to try very close to the receiver.

Unfortunately you did not post your code so no one knows how you try to send the midi messages.
Check first: does the device apear as USB-MIDI-Class in your computers device manager?
Probably it is shown as a USB-Serial-Class device (which MIDI indeed is) but your MIDI application (seems to be a top secret application as you don't wrote which one) expect a MIDI-Class device.

Maybe this helps: https://github.com/esp32beans/ESP32USBMIDI

@erkel
This sounds like a poor solder joint at the internal voltage divider (the 11k and 680k resistors).

@tspycher
AFAIK: this are very simple transmitter/receiver modules. No protocol, no encryption, no guarantee for transmit/receive the correct data. You have to make your own protocol and data integrity functions.

Try to send something out from UART (not faster than 10kbps) and receive it on the other side. Be aware that disturbance could be possible as 433.92MHz is used in a wide range of applications like wireless thermometers, garage door opener, car keys, wireless doorbells, wireless power switches...

As you get the raw pulses out of the receiver it should be possible to receive and decode data from e.g. the thermometer oder switches. There are several protocol descriptions in the web.

If you want to send simple data from one to the other device, ESPnow could be the better option.