How customers
connect their systems.

Grouped by how the screen gets its data. Every one started as a protocol or requirement we had not seen before. Yours can be next →

Filter by integration path

12 cases

Your existing protocolCUSTOMER CASE

Flight signs in a baggage hall

An international airport in Southeast Asia · baggage handling system

Challenge
The baggage system already drove its signs in its own serial format. New controllers had to accept it as it was.
Approach
Custom controller firmware reads the existing frames on the RS-485 bus. A custom character file matches the lettering.
Result
New controllers on the existing bus. The airport kept its software, gateways and wiring.
  • C-Power 10B
  • RS-485
  • Custom firmware
Read the case →
Your existing protocolCUSTOMER CASE

Smart bus-stop signs

City bus networks in East Asia

Challenge
Each stop sign had to show arriving buses from the city's bus platform, in two languages, over a mobile link.
Approach
Custom firmware speaks the platform protocol over 4G. Routes are configured per stop. Single-row, three-row and double-sided layouts; voice announcements on later versions.
Result
Signs register with the platform and show each route's arrival time, "arriving soon", the clock and notices.
  • 3 & 5 Series
  • 4G
  • Voice
Read the case →
Your existing protocolCUSTOMER CASE

Expressway variable message signs

Expressway operators in China

Challenge
Traffic platforms drive their signs with an industry protocol: playlists, brightness modes and fault reports.
Approach
Custom firmware answers the platform over TCP: upload and play preset playlists, auto, manual or scheduled brightness, read back current content, report faults.
Result
Signs behave like native platform equipment. The bad-pixel check feeds the fault report and flags a module when faults pass a threshold.
  • 5 & 7 Series
  • TCP
  • Bad-pixel check
Read the case →
Your existing protocolCUSTOMER CASE

Toll-lane fee displays

Expressway toll plazas in China

Challenge
Lane systems send vehicle class, weight and fee, and also switch lane lights and voice prompts.
Approach
The controller reads the lane protocol on serial or network. IO pins drive the lane and warning lights; a voice board reads out the fee.
Result
One controller per lane handles text, lights and voice.
  • 10B · 30A · 50A
  • RS-232 / 485
  • IO + voice
Field devices & sensorsCUSTOMER CASE

Radar speed feedback signs

Road-safety integrators

Challenge
Show each vehicle's speed from a radar: green under the limit, red over it, the limit when the road is empty.
Approach
The radar connects straight to a controller serial port. Firmware filters readings and shows speed, limit icon and warning text. One version logs speed and traffic volume to CSV files on the controller.
Result
No roadside PC. The sign reacts on its own.
  • 5 Series · 10B
  • Radar on serial
  • CSV log
Field devices & sensorsCUSTOMER CASE

Crane load display

Industrial lifting equipment · East Asia

Challenge
Show the loads on two hoists, read from the weighing controller.
Approach
The controller polls the weighing unit over Modbus RTU and shows both values in tonnes with two decimals.
Result
Operators read the load from a distance, with no PC in the loop.
  • C-Power 20A
  • Modbus RTU
Field devices & sensorsCUSTOMER CASE

Wind and weather displays

Weather and environmental monitoring

Challenge
Show wind speed, wind direction and weather readings next to the sensors.
Approach
The controller reads the sensor over serial at a set interval and shows speed and an eight-point wind direction. Settings live in a small file on the controller.
Result
A self-contained readout: sensor, controller, screen.
  • Serial sensor
  • Variables
Field devices & sensorsCUSTOMER CASE

Vessel speed display

Marine equipment supplier

Challenge
Show the ship's speed from its GPS receiver.
Approach
The controller parses the standard NMEA 0183 speed sentence and shows speed in knots to one decimal.
Result
Speed on the screen straight from the GPS feed.
  • C-Power 10B
  • NMEA 0183
Remote platformCUSTOMER CASE

NTCIP road signs

Road agency in South America

Challenge
Signs had to follow the NTCIP traffic-sign standard used by the agency's central system.
Approach
NTCIP traffic reaches the controllers through the remote management server. Field inputs select messages, and a radar mode shows speed messages.
Result
Signs managed from the central system with the standard it already uses.
  • 7 Series
  • NTCIP
  • Remote server
Remote platformCUSTOMER CASE

City parking guidance

Parking operator platform

Challenge
Space counts from the operator's platform had to reach guidance signs across the city.
Approach
A server reads the platform's data file every second and pushes counts to each sign. Each sign can be limited to its own car parks; urgent notices go out the same way.
Result
Signs follow the platform automatically, with a default message if data stops.
  • Server
  • Platform data
SDK & librariesCUSTOMER CASE

Displays inside third-party terminals

Terminal equipment maker

Challenge
The maker's own software had to drive the built-in LED display.
Approach
We supplied a Windows DLL and a Linux shared library with logging. Content sent through the interface plays at once and can be selected later.
Result
The maker ships the display as part of its own product.
  • C-Power 1200
  • Linux .so
  • Windows DLL
Our open protocolLAB REFERENCE

Parking space counter

Reference build · tested on a live controller in our lab

Challenge
Show a fixed title and a free-space number that changes as cars come and go.
Approach
Two windows. The title is set once and saved. Only the number window is updated, over TCP port 5200.
Result
Every update acknowledged. Title and layout come back after a power cycle.
  • Any controller
  • TCP 5200
  • 2 windows

Every case, same five parts

Written so an engineer can judge fit in two minutes.

Customer and site names are left out unless the customer agrees. Facts that are not confirmed are not published.

  1. Challenge

    What the customer's system needed the screen to do.

  2. Constraints

    What could not change: software, wiring, protocol, layout.

  3. Approach

    Which path we used and what we built or configured.

  4. Result

    What runs today, in plain terms. No invented figures.

  5. Specification

    Controller, interface, display, firmware.

Your system is not listed? Send us its protocol or API.