Why does my radar sweep animation stutter instead of scrolling smoothly?

The chunky stepping is almost never a refresh problem on its own, it's the math. If you're computing sine and cosine for every pixel of the sweep every loop, that alone can eat most of your frame time on a breadboard micro. First thing I'd do is time it: drop a counter in your loop that prints how many loops run per second. That tells you right away wheather you're getting 5 frames or 50, and it's a two line change to your copy pasted mess. And yes, there's a trick for the sweep, and it makes everything easier. Don't redraw the arc every frame. Keep a copy of the screen in memory as a small grid of brightness values. Each pass, you only draw the new leading edge position, then you run through that grid and knock down every pixel's brightness by one step. Anything below zero goes fully dark. That gives you the fading tail for free and your drawing workload drops to a handful of pixels per frame instead of the whole arc. The other classic bottleneck is the connection to the screen itself. If your display is running on I2C, that's slow for full screen updates. SPI is much faster if your display supports it, and you can often crank the SPI clock well past the default in the library settings. I nearly doubled my frame rate on a project just by raising that number.

One more cheap win: precompute your sweep table. Since the sweep always visits the same angles, work out the x and y offsets for each angle once at startup, stick them in an array, and just look them up at runtime. No trig in the main loop at all.

Do those in order, time it first, then the fade buffer, then the screen speed. Once the sweep is smooth the detection side you alredy have working will slot right in, since it only needs to plot a blip when the sweep angle passes the target's bearing.

Tried something like this with a little black and white screen I had lying around and hit a wall. The pixels on mine are either lit up or not, there's no in between, so when I tried the dimming thing every dot just stayed fully bright untill it switched off all at once. Looked like a comet with a hard edge instead of a nice fade. Is there a way to fake the fading on a screen like that, like turning off every other dot or something?

One thing that bit me on a similar project: tie the sweep speed to actual time, not loop count. If you just advance the angle every pass thru the loop, it'll move at whatever speed the code happens to run at, and it'll stutter worse when other stuff (like your sensor reading) slows things down. Use a timer or a millis check so the angle only moves when enough real time has passed. Fixed my jittery sweep instantly and it's like three lines of code. Also lets you slow the sweep down to a nice menacing crawl, very satisfying.

Gotta push back on the first reply a bit. Saying the math is the bottleneck 'almost never' a refresh problem doesn't match what I've seen. On my setup the trig took microseconds, but pushing the whole screen buffer over the wire took longer than everything else combined. The loop only ever moved as fast as that transfer, no matter how I optimized the code. So before rewriting anything, swap in a dummy draw call that skips the screen entirely and see how the sweep speed changes. If it suddenly flies, the math was never your problem and all the lookup tables in the world won't fix it.

This takes me back to when we faked radar displays on those old character LCD modules by just cycling through a pre-drawn set of frames stored in memory. Crude, but it swept smooth enough to fool anyone at a school demo. The point is you don't need fancy math if you get clever with what you store. One thing I'd ask: what's driving your display, and how much memory does that chip have free? If you're tight on RAM, the full screen buffer idea gets expensive fast, and you'd be better off drawing a short tail of fixed length behind the leading edge instead of a fading trail across the whole sweep. Worked fine for me back then.