Datasheets list numbers like
240×280, 60Hz, and 16-bit color — but what do they actually mean for your project? This guide decodes the three most important touch screen specifications, with plain-language explanations and real-world examples from small IPS LCD modules.
Resolution 240×280 Width × height in pixels. More pixels = sharper image.
Refresh rate 60 Hz Screen redraws per second. Higher = smoother motion.
Color depth 65K 16-bit = 65,536 distinct colors. Enough for most UIs.
01 / resolution What 240×280 actually means
Resolution describes how many individual pixels fit across and down the screen. 240×280 means 240 columns of pixels and 280 rows — giving a total of 67,200 pixels on the panel. Each pixel is a tiny square that can display one colour at a time. The more pixels you pack into the same physical area, the sharper text and graphics appear.
For a 1.69-inch display, 240×280 is a practical sweet spot. It's enough to render readable text at 12–14pt, clean icons, simple graphs, and status dashboards — all the typical use cases in embedded and IoT devices. You could push a higher resolution onto a screen this size, but the gain in perceived sharpness becomes negligible once you pass a certain pixel density threshold (more on that next).
Width first, then height
Display resolutions are always written as width × height. So 240×280 is 240 pixels wide and 280 pixels tall — a portrait-oriented panel. Some panels can be rotated 90° in firmware, giving you 280×240 landscape orientation without changing the hardware.
Portrait vs landscape — same pixels, different layout
Because the panel is 240 wide and 280 tall, it naturally suits a portrait layout — think a small watch face, a sensor readout, or a menu screen. If your UI calls for landscape, your display driver (such as the ST7789) can rotate the frame buffer in firmware. No extra hardware cost, but your code needs to account for the swapped axes.
02 / pixel density Pixel density (PPI): why physical size matters
Two screens can share the same 240×280 resolution but look completely different in sharpness if they are different physical sizes. Pixel density — measured in pixels per inch (PPI) — captures this relationship.
The formula is: PPI = diagonal pixel count ÷ diagonal screen size in inches. For a 240×280 panel at 1.69 inches, the diagonal pixel count is √(240² + 280²) ≈ 369 pixels, giving roughly 218 PPI. That's sharp enough that individual pixels are invisible to the naked eye at normal viewing distances of 15–30 cm.
PPI comparison — same 240×280 resolution, different screen sizes
Above ~200 PPI, individual pixels become invisible at normal viewing distance.
Rule of thumb
For small embedded displays viewed at 20–30 cm, anything above 180–200 PPI will look sharp. Below 150 PPI you may start to see pixelation on diagonal lines and small text. The 1.69-inch panel at 218 PPI is comfortably above that threshold.
03 / refresh rate Refresh rate: do you really need 60 Hz?
Refresh rate tells you how many times per second the display redraws its image, measured in Hertz (Hz). A 60 Hz screen redraws 60 times per second; a 30 Hz screen, 30 times. Higher rates mean smoother animation and faster response to touch input changes.
For most embedded and IoT applications, the refresh rate question is less important than it is for smartphones or gaming monitors. Here's why:
| Use case | Typical content | Refresh rate needed |
|---|---|---|
| Sensor dashboard | Static values, occasional updates | 10–30 Hz is fine |
| Menu navigation | Tap to switch screens | 30 Hz feels smooth |
| Animated UI / transitions | Scrolling lists, progress bars | 60 Hz recommended |
| Video playback | Moving images at 24–30 fps | 60 Hz recommended |
| Gaming / fast motion | Sprites, rapid frame changes | 60 Hz+ ideal |
A small IPS module running over SPI at typical clock speeds will comfortably sustain 30–60 Hz for the display content common in embedded projects. If you're only updating a temperature reading every second, even 10 Hz feels instantaneous to a human observer.
SPI bandwidth is the real constraint
For SPI-connected displays, the actual achievable frame rate depends on your SPI clock speed and the number of pixels to push. At 240×280 with 16-bit colour, each full frame requires sending 134,400 bytes. At a 40 MHz SPI clock, that theoretical ceiling is around 37 full-screen refreshes per second — more than enough for smooth embedded UIs when you use partial-screen updates.
Partial updates: the practical solution
Most embedded display drivers support writing only a rectangular region of the screen (a "window" command). Instead of redrawing all 67,200 pixels every frame, you update only the region that changed — for example, the number in a temperature readout. This dramatically reduces SPI traffic and makes even modest MCU speeds feel responsive.
04 / color depth Color depth: 16-bit vs 18-bit vs 24-bit
Color depth tells you how many distinct colors each pixel can display. It's determined by how many bits of data describe each pixel's color value.
16
16-bit color
65,536 colors — the most common for small SPI displays
16-bit color uses the RGB565 format: 5 bits for red, 6 bits for green, 5 bits for blue. Green gets the extra bit because human eyes are more sensitive to it. The result is 65,536 distinct colors — more than enough for icons, status bars, graphs, and dashboard UIs. Banding can occasionally appear in smooth photographic gradients, but for typical embedded UI content it's invisible.
18
18-bit color
262,144 colors — smoother gradients, wider palette
18-bit color (RGB666) gives 6 bits per channel, yielding 262,144 colors. The improvement over 16-bit is visible mainly in smooth gradient areas — think colour wheels, sunrise backgrounds, or photographic images. For most text-and-icons embedded UIs, the difference vs 16-bit is subtle. Note that 18-bit data over SPI requires 3 bytes per pixel vs 2, which increases the bandwidth cost by 50% per frame.
24
24-bit color
16.7 million colors — true color, rarely needed at this size
24-bit (RGB888) is "true color" — 8 bits per channel, 16.7 million colors. At 1.69 inches and 218 PPI, the actual visible improvement over 18-bit is negligible. The bandwidth cost, however, is significant: 3 bytes per pixel, the same as 18-bit for SPI but requiring more MCU processing. Small SPI modules rarely operate at full 24-bit; they typically accept 24-bit input and dither or truncate it internally.
Practical recommendation
For most small embedded displays, 16-bit (RGB565) is the right choice. It halves SPI traffic compared to 18/24-bit, is natively supported by virtually every MCU graphics library, and looks excellent for UI content on a 1.69-inch IPS panel. Only consider 18-bit if your design relies heavily on smooth photographic gradients.
05 / putting it together Reading specs together: a worked example
Let's apply all three parameters to a real module: the Polcd 1.69-inch 240×280 IPS capacitive touch screen.
| Spec | Value | What it means for your project |
|---|---|---|
| Resolution | 240×280 |
Enough for readable text, icons, and simple dashboards at 1.69" |
| Pixel density | ~218 PPI |
Sharp at normal viewing distance — pixels invisible to the naked eye |
| Refresh rate | Up to 60 Hz |
Smooth for animated UIs; use partial updates to stay within SPI bandwidth |
| Color depth | 16-bit / 65K |
Ideal for embedded UIs — efficient SPI transfer, vibrant color, library support |
| Panel type | IPS |
Wide viewing angle, consistent color — no washout at oblique angles |
| Interface | 4-Line SPI |
Minimal GPIO pins; bandwidth ceiling applies — use partial updates for fast UIs |
Reading specs this way — understanding what each number costs and buys — lets you evaluate any display datasheet confidently, compare options side by side, and avoid over-specifying (and overpaying) for capabilities your project doesn't need.
See these specs in a real module
The Polcd 1.69-inch 240×280 IPS display ships with a 4-line SPI interface, 16-bit color, and MOQ of just 1 piece.
View product details Request a sample
Hinterlassen Sie einen Kommentar