Most LED projects are sold as hardware. A screen, a controller, a cabinet, a price per square meter. Then the screens go up on light poles across a district, and the buyer discovers the real product: the operating routine. Someone has to change the poster on 40 poles before Monday, and nobody wants to send a truck.
That is where the datasheet ends and the deployment begins. Here is what actually decides whether a pole-screen network is manageable, written from the procurement side of the conversation rather than the spec sheet.
The truck test
A simple way to evaluate any pole-screen proposal: ask how a single content change is executed across the whole network.
If the answer involves a technician, a ladder, a USB stick, and a maintenance window, the network is not a network - it is 40 independent screens that happen to share a logo. The cost of that model is not visible on the invoice. It shows up later, in the number of site visits per month and in how long a wrong poster stays up.
If the answer involves a browser tab, a schedule, and a publish button, you are buying a system. Ask for a live demo on the actual player, not a marketing video.
Four things a cluster platform must do
1. Address individual screens, not just all of them
City deployments are never uniform. A pole outside a school needs different content at 07:30 than the same pole at 22:00. A screen facing a construction site may be legally required to show a permit notice. Group-level publishing is table stakes; per-screen override is what makes the system usable in year two.
2. Survive the network
Pole screens sit on 4G routers with data caps and patchy coverage. The player must keep playing from local storage when the link drops, and it must resync without duplicating or skipping playlists when the link returns. Ask what happens to a 200 MB video scheduled for 18:00 if the SIM is throttled at 17:55.
3. Report state, not just success
The useful question every morning is not whether the publish succeeded, but which of my 40 screens is dark, which is playing the wrong playlist, and which has a failing power supply. A platform that only confirms uploads is a file transfer tool. Look for per-screen heartbeat, playback log, signal strength, and cabinet temperature.
4. Be honest about the subscription
Cloud platforms usually carry a per-device service fee, sometimes bundled with a data plan. Buyers should ask for it in writing, per screen per year, plus what happens to the screens if the subscription lapses. A player that stops working when a cloud contract ends is a hostage situation, not a product.
GPS and the map problem
Pole screens are physical assets scattered across a city, and asset registers rot fast. GPS positioning in the player solves a boring but expensive problem: when the map and reality disagree, the platform tells you which screen is where, and the maintenance crew stops hunting.
Worth asking: does the map come from the player's own GPS fix, or from whatever address someone typed during installation? The first survives staff turnover. The second becomes fiction within a year.
Power and network are the same conversation
On a pole, the screen shares a circuit with the luminaire, and often with a small 4G router in the base cabinet. Two design details matter more than they look:
- Wide-input power supply. Street lighting circuits vary, and a supply rated only for a narrow band will fail on the poles where voltage sags worst. Specify the input range, then ask for the test report.
- Independent protection. If the router's power supply fails, the screen should keep playing cached content rather than going dark. Separate protection on the two branches costs very little at build time.
What to put in the RFQ
If you are writing the tender or the purchase order, these lines do more work than any brightness figure:
- Number of screens, and whether group publishing and per-screen override are both required.
- Playback continuity during network loss, with the retention window for cached content.
- Per-screen status reporting: online state, current playlist, playback log export format.
- Remote control method - browser, mobile, or both - and whether scheduling supports day-of-week rules.
- Service fee per device per year, stated separately from hardware.
- Exit clause: what the screens can still do if the platform contract ends.
None of these are exotic. They are simply the questions that decide whether the deployment is still running smoothly eighteen months after handover, when the launch photos are forgotten and the screens are just street furniture that has to work.
A double-sided pole screen like the DGB5 in a 640x1920 mm portrait format is a common building block for this kind of network - narrow enough for a pavement, tall enough for a full-length creative. More detail on the cabinet and mounting options: https://www.mlxled.com/product/dgb5-double-iron/
MuenLED
I work with MuenLED, a Shenzhen LED display manufacturer. This post is about how to evaluate these systems, not a recommendation of any single model.
Top comments (0)