Why does my ESP32 stats display freeze after a few minutes?

The screen staying on and the graph still drawing rules out the battery almost completely. A sagging li-po on these boards causes brownouts, and brownouts mean reboots or flickering, not a radio quietly going deaf while everything else runs fine. So you can drop that theory. What you're describing sounds a lot like the Bluetooth link actually dying while your code never notices. On the ESP32 side the serial input just stops arriving, but if your loop is written as 'read a packet, draw it' with no check on whether anyone is still connected, it'll happily keep redrawing stale values forever. The PC app can also be lying to you here. Windows will happily report the device as paired and connected in its settings while the actual link has gone stale. I've had that exact situation where the sender script thought everything was fine. Try watching the board over the USB serial port while it runs. If you print connection state and free heap every few seconds, you'll usually see one of two things: the state flips to disconnected around the five minute mark, or the heap number steadily shrinking until things stop working.

The shrinking heap is your other suspect, and your instinct about not clearing things isn't quite the right place to look. Drawing over old lines on the display buffer is fine, that memory is fixed. The problem shows up if you're creating strings or buffers on every loop iteration to build the readings or the graph data. That fragments memory over minutes and eventually the Bluetooth stack can't get what it needs. Reusing the same variables instead of making new ones each pass fixes it.

Two quick experiments. First, run it with the USB cable plugged in but battery disconnected, so you're on stable power for hours. If it still dies at five minutes, it's not power. Second, add a check for the connection state in your loop and print it. If it flips false while the PC claims it's still sending, you'll want logic on the ESP32 to attempt a reconnect, and probably a heartbeat byte from the PC app every couple seconds so the board can tell a dead link from a quiet one.

I totally agree with the point that the issue is likely the radio link dropping without any obvious error. It's annoying when the PC side keeps thinking everthing is fine while the ESP board is just silently waiting for data. I ran into this exact mess once with data logging and it was a pain. The hardware would just stop responding entirely, so I ended up adding a simple timeout check on the PC that forced the ESP to restart the connection process if the data didn't arrive within a specific window.

I ran into a similar wall when I was integrating real-time data logging on a similar project. It wasn't the memory, but how the radio stack handles buffering under load. If your PC is trying to push packets as fast as possable, the internal FIFO queues on the ESP32 can get backed up and start dropping data silently, even if the Bluetooth link stays nominally active. I fixed it by forcing a delay after every data block; specifically, doubling the transmission interval to two seconds resolved the drop issue entirely for my application. That subtle throttling made a big difference in stability.

The focus on the heap and the link dropping is spot on, but sometimes it’s just a matter of the ESP32 choking on its own tasks. Even if your code is clean, if the display drawing routine is taking too long, the CPU might not be able to process the incoming radio packets quickly enough. I had a similar headache once when monitoring server stats. The only thing that relly saved it was adding a specific scheduler tool to govern how often the display acutally refreshed. That made sure the system always had a small slice of time free to manage communication. It’s definatly worth double-checking the timing of your GUI update function against your data reception logic.

I was reading about how the Bluetooth link could just die without the code knowing. It made me think about the signal quality itself. If the device is sitting too far away from the computer, even if everything else is running fine, maybe the signal just gets too weak to hold a connection steady? Does anyone else have issues if the little board is placed even a few feet away from the PC?