This article is about the constraint the coverage question leaves out. Working out how many gateways it takes to reach every label is a geometry problem, and we built a coverage calculator for it. Working out how many labels one gateway can actually serve is a timing problem, and it has a different answer.
Why “one gateway supports N labels” misleads
Because capacity is not a property of the gateway. It is the result of dividing your update window by the time each label consumes. Change the window or change the label, and the same hardware supports a different number.
Think of it like asking how many people fit in a lift. The plate on the wall says fifteen. But if everyone is going from the ground floor to the thirtieth and back, the lift moves far fewer people per hour than if they are all going up one floor. The capacity figure is real; it just answers a different question from the one you have.
This is why published figures disagree so badly. Industry sources commonly cite anywhere from about 2,000 to 15,000 labels per access point. Both ends are probably honest under their own assumptions. Neither states them.
The two limits, and which one binds
Every deployment has to satisfy two independent constraints, and your gateway count is whichever demands more.
| Limit | The question | What decides it | When it binds |
|---|---|---|---|
| Coverage | Can a gateway reach this label at all? | Floor area, radio range, mounting height, obstruction | Large, tall or awkwardly shaped spaces — high-bay warehouses, multi-floor stores |
| Capacity | Can every label finish updating in time? | Update window, label count, per-label time, retries | Dense stores with tight windows — supermarkets with high SKU counts, promo-heavy operations, colour labels |
A small, dense convenience store can be fully covered by one gateway and still need two, because one cannot get through the label list fast enough. A large open warehouse can be the reverse: plenty of time, but the geometry demands more units. Sizing on one constraint and ignoring the other is the most common planning error we see, and it usually surfaces after installation.
The real question: what is your update window?
This is the input nobody writes down, and it decides everything downstream. Two operating patterns dominate, and they differ by an order of magnitude in what they demand.
| Pattern | Typical window | Scope | What it implies |
|---|---|---|---|
| Overnight batch | Hours | Every label in the store | Generous. Even slow colour labels usually fit. Capacity rarely binds |
| Intraday rolling | Minutes | A subset — a category, an aisle, a promotion | Tight. This is where capacity planning actually matters |
| Emergency correction | Immediate | A handful of labels | Rarely a capacity problem, but tests whether the queue can be pre-empted |
Write your requirement as a sentence with a number in it. “All 8,000 labels updated before the doors open at 07:00” is a very different system from “any 200 labels updated within 10 minutes, at any point during trading.” The first is a throughput requirement; the second is a latency requirement, and a system can pass one while failing the other.
The intraday case is the one worth stress-testing, because it is where the business value sits. An afternoon markdown on fresh produce only helps if the shelf price changes before staff start pulling stock. If the update takes forty minutes to propagate, you have bought the hardware without buying the outcome.
How to estimate capacity
The arithmetic is simple; the inputs are what you have to extract from your supplier. At concept level:
W = update window, in seconds
P = parallel streams the gateway sustains (often 1 — confirm this)
A = radio airtime to deliver one label’s image
R = time the display itself takes to redraw
r = retry and acknowledgement allowance
Two things about this formula matter more than the formula itself.
First: whether A and R add or overlap is a protocol design decision, and it changes the answer by a large factor. If the gateway transmits to one label, waits for it to redraw, waits for confirmation, and only then moves on, the two costs serialise and capacity collapses. If it pipelines — streaming to the next label while the previous one redraws — the display time largely disappears behind the radio time. This is a specific, answerable question. Ask it.
Second: R is a hard physical floor that no amount of network engineering removes. A tri-colour label cannot redraw faster than its panel allows, no matter how good the gateway is. Which brings us to the factor that dominates everything else.
A worked example, and why it lands where it does
Take a supermarket with 8,000 monochrome labels, already covered geometrically by a single gateway. Assume 5 seconds consumed per label — a plausible figure once a 2–5 second redraw is combined with transmission and a modest retry allowance.
| Requirement | Window | Fully serialised | With 4× pipelining |
|---|---|---|---|
| All labels before opening | 6 hours (21,600 s) | 4,320 labels — fails | 17,280 labels — comfortable |
| 200 labels mid-trading | 10 minutes (600 s) | 120 labels — fails | 480 labels — passes |
Illustrative arithmetic on stated assumptions, not a measurement of any product. The point is the gap between the two right-hand columns, not the absolute figures.
Notice what this shows. On a fully serialised design, one gateway cannot even finish an overnight run on a mid-size supermarket — a result most people find surprising, because the label count sits comfortably inside every published capacity figure. Add pipelining and the same hardware clears both requirements. The single architectural detail moves the answer by roughly four times, and it appears on no datasheet. That is why question two in the checklist below matters more than any capacity number a supplier quotes.
What actually consumes capacity
Ranked roughly by impact, and the first one is a purchasing decision, not a network one.
| Factor | Effect on capacity | What to do about it |
|---|---|---|
| Colour vs monochrome | Largest single factor. A monochrome panel redraws in roughly 2–5 seconds; tri-colour in roughly 15–25 seconds — about 4×. Spectra 6 references commonly put six-colour full refresh at 10–30 seconds | Use colour where it earns its place — promotions, end-caps, fresh — not estate-wide by default |
| Refresh mode | Monochrome supports fast full refresh (1–2 s) and partial refresh (0.3–1 s). Multi-colour panels generally support neither and must always full-refresh | Ask whether price-only changes can use partial refresh on your labels |
| Panel size and image complexity | Larger panels carry more data and take longer to redraw | Match label size to the shelf rather than standardising large |
| Retries | Stock, metal shelving, freezer doors and shoppers all block signal. Failed updates are re-sent, consuming the window twice | Plan a retry allowance rather than assuming first-time success |
| Temperature | E-paper redraws more slowly when cold. Full-colour panels are typically rated for 0–50 °C operation | Size chilled and freezer zones separately — they are slower than the ambient aisle |
| Label wake interval | Labels sleep to save power. A longer sleep means better battery life and a slower response to any given update | This is the same trade-off described in ESL battery life, seen from the other side. You cannot maximise both |
Redraw figures are published component-level specifications from e-paper module suppliers, not measurements from any particular ESL system. Actual per-update time in a deployed store also includes radio airtime, protocol overhead and retries, and will be longer. Treat these as the floor, not the expectation.
The colour row deserves emphasis because of how the decision is usually made. Colour labels are chosen in a showroom, on how they look. The capacity consequence shows up months later as a gateway count, and by then it reads as a network problem rather than what it is — the downstream cost of a display choice. If you are moving from monochrome to colour on an existing estate, re-run the capacity sizing before assuming the current gateways carry over.
Does the radio protocol change the answer?
Yes, and it is the one place where a supplier’s choice of wireless stack has a direct, physical consequence for your gateway count.
ESL systems run on several different radio families — sub-GHz bands around 433 and 868/915 MHz, and 2.4 GHz including Bluetooth-based approaches. The trade-off between them is not a matter of vendor preference; it is basic radio physics. Lower frequencies propagate further and penetrate obstacles better for the same power, but carry less data per second. Higher frequencies carry more data but are absorbed more readily by stock, metal shelving, refrigeration glass and people.
For capacity planning, that trade-off inverts the two limits against each other:
- A long-range, low-data-rate link improves coverage — fewer gateways to reach the floor — but spends longer transmitting each label’s image, which reduces capacity. You may cover the store with one gateway and still need three to hit your window.
- A shorter-range, higher-data-rate link moves images faster, so each gateway serves more labels per hour, but you need more of them to cover the same area in the first place.
Neither is better in the abstract. What matters is which constraint binds in your building. A high-bay warehouse with sparse labelling is coverage-bound and rewards range. A dense supermarket with a tight intraday window is capacity-bound and rewards throughput. Sizing the second kind of site with hardware chosen for the first is a common and expensive mismatch.
One practical note on standards. Most ESL systems have historically run proprietary protocols, and a standardised Bluetooth profile for electronic shelf labels now also exists. We are not going to tell you which to buy — but the capacity question is worth asking in the same conversation as the openness question, because both are decided by the same choice of stack and both are expensive to reverse later.
Headroom and what happens when a gateway fails
A design that exactly fits its window has no headroom, and stores do not operate at average conditions.
Three things break a tight design. Peak days: the promotional changeover before a holiday weekend is not a typical night. Growth: SKU counts rise, and every added facing is added airtime. Failure: if one gateway stops, its labels are not slowly served by neighbours — depending on the design, that zone may simply stop updating, and a zone that stops updating is a zone whose shelf prices are now drifting away from the register.
That last point connects capacity planning to something with a measurable cost. Shelf-versus-register mismatches are the failure mode US regulators inspect for, and roughly one store in four fails that standard — the data is in our piece on ESL and pricing accuracy. A capacity design with no headroom quietly reintroduces the problem the system was bought to remove.
We are not going to publish a headroom percentage, because the honest answer depends on your failure tolerance and your peak-to-average ratio. What we will say is that sizing against your peak update day rather than a typical one, and asking your supplier what happens to a zone when its gateway drops, are both free.
Sizing for your own store: what to ask
You cannot answer this from a datasheet, but you can make the supplier answer it. Six questions, in the order that matters:
- “What is your measured time to update 100% of labels in a reference store of my size and label mix?” This is the only question that matters. Everything else is a way of sanity-checking the answer. Ask for the store profile it was measured in.
- “Does transmission pipeline with display refresh, or serialise?” Determines whether the redraw times above add to your window or hide behind it.
- “What is the redraw time for the exact panels I am buying, at my lowest operating temperature?” The ambient-temperature figure is not the freezer-aisle figure.
- “What retry rate do you see in a store like mine, and is it included in that timing?” A first-time-success number is not a plan.
- “What happens to a zone when its gateway fails?” Ask for the behaviour, not the reassurance.
- “Will you write the update window into the acceptance criteria?” If the answer is yes, most of the preceding questions stop mattering — you have transferred the risk to the party who actually controls it.
That last item is the highest-leverage line in any ESL contract. A clause reading “100% of labels in each store shall complete a full content update within X minutes, verified on site at handover” does more for you than any capacity specification, because it is testable and it makes the gateway count the supplier’s problem rather than yours. Set X from your intraday requirement, not your overnight one.
Once you have a window and a label mix, the coverage side is the easier half — our coverage planner gives you the geometric minimum, and your capacity answer tells you whether to go above it. The gateway count that goes into your budget is the larger of the two, and it feeds directly into the per-store cost model, where gateways are the line item most often left out.
The short version
Stop asking how many labels a gateway supports. Ask how long it takes to update all of yours, at peak, in the coldest aisle, with the labels you actually intend to buy. The first question has a marketing answer. The second has a testable one.
If you take one thing from this: the largest capacity lever is not the network at all. It is whether you specified colour panels estate-wide because they looked better in a demo. Monochrome redraws in seconds, colour in tens of seconds, and that ratio propagates straight through to how much infrastructure you buy. Decide it deliberately — and if the update path from your pricing system is still being designed, our guide on connecting ESL to POS, ERP and databases covers what has to be in place before any of this timing applies.
Sources
- Understanding the Refresh Times of Monochrome and Tri-Color EPD — Dalian Good Display, e-paper module manufacturer. Monochrome ~4 s, tri-colour ~16 s typical redraw.
- Common refresh methods of e-paper display — Dalian Good Display. Full, fast-full and partial refresh ranges, and which panel types support each.
- E-Ink Spectra 6 — LCD-Mikroelektronik. Spectra 6 full-refresh guidance of 10–30 seconds by temperature and panel size.
- E Ink Spectra 6 — E Ink Corporation. Published characteristics of the six-colour e-paper platform used in retail signage and premium labels.
- Per-gateway capacity figures of roughly 2,000–15,000 labels are cited by multiple ESL suppliers in public material. We deliberately do not link or attribute these: none of the sources we found states the update window, label type or retry assumptions behind the figure, which is the argument of this article.