Why does my CRT screen roll every time new aircraft data comes in?

Yeah, that rolling is classic Wi-Fi interference with the video timing. Composite video on the ESP32 has to be generated line by line with really tight timing, and every time the radio fires up to handle packets the CPU gets yanked away for a few milliseconds. The sync pulses wobble and the monitor loses vertical hold for a beat, then relocks. Moving the fetch to a second task doesn't help much on its own because by default both tasks can still end up fighting over the same core, which is why it sometimes got worse for you. Pin the video work to core 1 with xTaskCreatePinnedToCore and leave core 0 to the network stack. Also turn off Wi-Fi modem sleep with WiFi.setSleep(false), that alone calmed the bursts right down on my setup, it stops the radio doing that stop-start doze cycle between packets. You'll use a bit more power but who cares on a plugged-in build. Your buffering instinct is right too, that's the correct fix long term. Do the ugly stuff, JSON parsing and all that, in the network task, and only copy finished numbers into the structure the drawing code reads. Swap it right after a frame ends so a mid-frame update never happens. It fits fine on the chip, people run way heavier stuff than a plane map. The waviness along the top is a seperate thing in my experiance. First thing I'd check is the ground lead between the ESP32 and the monitor, keep the video lead short and make sure you've got a solid common ground, not just through some random breadboard row. Second thing is power. If the monitor and the ESP32 share a supply, the radio's transmit bursts can sag the rail enough to bend the top of the picture. I had exactly that symptom feeding two things off one cheap adapter, and splitting them onto separate supplies cleaned it up completley. Old CRTs are also just fussy about sync levels, so if the waviness survives the power split, don't sweat it too much, it's probaly the monitor being 40 years old rather than anything you did wrong.

Nice, I did something similar with a little CRT and a weather map last year. One thing that helped me was dropping the resolution a bit. Fewer pixels per line means looser timing, so the odd Wi-Fi hiccup doesn't wreck the picture as badly. Depends which library you're using for the composite out, some make that easy, others not so much. Also curious how you're driving the Apple monitor. Mine only had a composite input so it was plug and play, but I've heard some of those old ones expect a diferent signal level. Does yours show a proper picture apart from the rolling, or did you have to fiddle with the input at all?

On the waviness, a chunky capacitor right across the ESP32's power pins did more for me than anything else. I had a similar bendy-top problem with a small TV and it cleaned up about 90 percent after I soldered a big electrolytic between 5V and ground at the board itself. Also, where are you pulling the plane data from? I've been meaning to do one of these for my dad who lives under a flight path and never got round to figuring out the data side of it.

Total beginner question probably, but how often are you pulling new data? Mine is a much simpler thing, an old portable TV showing a clock and a few numbers from the web, and I just made it fetch once a minute. The picture still blips for a split second when it does, but it's so rare nobody notices anymore. Might be a lazy fix for a plane map though if you want it feeling live. Also mine took a good ten minutes to warm up before the picture stopped drifting on its own, so if you just powered that Apple monitor on after years in a garage, maybe let it run a while before chasing the wavy thing.

Update: sorted it. Did the big electrolytic across the power pins like the third reply suggested and the wavy top basically vanished, so that was the monitor all along, not my wiring. For the rolling I ended up stashing the plane data in a buffer and only drawing it during the blanking gap, and it's been rock solid since. Wish I'd asked sooner.