Event customers often want live rankings, timing, athlete information and advertising on an LED display. A stable solution is not simply “connect the race software to the screen.” The event-data layer, page renderer, output windows, video processor and LED sending path have different responsibilities. RACE RESULT 14, Presenter, RaceResultExchange and the LED control system should be designed as separate but connected layers.
RACE RESULT 14 manages event data such as timing, rankings and race administration. Presenter can organise information into a display page for a large screen or browser window; see the official RACE RESULT software information and Presenter documentation. RaceResultExchange acts as an exchange layer for making timing data available to display boards, LED walls or other rendering software. These tools provide data, pages, windows or rendered content; they do not automatically replace the LED processor, sending device or receiving cards.
A practical signal chain is: timing system/database → Presenter or Exchange/rendering software → playback computer or media server → HDMI/DisplayPort/network output → video processor/sending device → receiving card → LED cabinet. Define the input, output, IP address, port, window size and fallback method for every layer. If the customer requires local network operation without a cloud service, confirm that the timing computer, rendering computer and devices can communicate on the same approved network and test the system when the internet is unavailable.
Screen-zone planning comes before page design. Three independent screens may show a main ranking in the centre and group information or advertising on the sides. They may also use one large canvas cut into different areas. The processor needs enough windows and output capability, the playback computer needs enough rendering resources, and the LED system needs independent coordinates for each zone. A browser-window size is not the same thing as LED pixel resolution.
Test data and display separately. Use simulated data to verify layout, fonts, refresh behaviour and error messages before connecting live timing data. Preview the page on a normal monitor before sending it through the processor to the LED screen. Test network loss, application restart, input switching, screen power recovery, paused data and a high update rate. Prepare a static fallback slide so a temporary data problem does not leave the entire wall empty.
The configuration record should include software versions, Presenter/Exchange settings, computer IPs, window coordinates, processor scenes, zone resolutions and support contacts. RaceResultExchange configuration and script fields must follow the current official documentation and project licence. Do not promise a field, API or real-time performance that has not been tested in the customer’s actual environment.
The data owner and the display owner should agree on a status vocabulary. Decide what appears when there is no timing result, a race is paused, an athlete is disqualified, the network is unavailable or a result is still provisional. A display page that is technically connected but shows stale data can be more confusing than a deliberate fallback slide. Add a timestamp or status label where the customer’s workflow requires it, and confirm who is allowed to approve a result layout.
For a local network design, document static or reserved IP addresses, firewall rules, service ports, computer names and the recovery order. Do not expose an event-data computer directly to the public internet merely because a screen is online. If a reseller or venue IT team manages the network, provide the minimum required traffic and identify which addresses belong to the timing system, renderer, processor and management computer. Test the system on the actual VLAN or isolated event network before race day.
The rehearsal should include realistic update rates and the largest expected amount of text. Long names, multiple categories and unusual characters often reveal layout problems that a small test dataset does not. Keep a local export or static result file for demonstration and emergency use, but label it clearly so an old result is never mistaken for a live one.
Frequently Asked Questions
Q1: Can RACE RESULT 14 directly control an LED display?
It normally needs Presenter or another rendering layer, a playback computer and the LED control chain. The event software is not the LED processor.
Q2: Does RaceResultExchange require a cloud service?
A project can use local network configuration, but verify the current documentation, licence and network design rather than assuming from the product name.
Q3: Who is responsible for delay in live rankings?
Measure data update, page rendering, computer output, processor handling and LED display separately. Do not assign every delay to the screen.
Q4: What is the most important event backup?
Prepare a static fallback slide, a second input or computer path, configuration backups and a clear manual switching procedure.
