Baldrick Troubleshooting: Find the Stage That Fails
Start by describing the failure precisely: which board, which output, which pixels and which source of data. A strand that passes a controller test but fails from FPP needs a different investigation from a strand that never responds at all.
Reviewed October 29, 2026. This guide covers Baldrick8/17 pixel output troubleshooting, including Mattos MD1500 builds. Keep the current layout and working settings before making changes.
Choose the test that separates the problem
Scroll sideways to see all columns.
| What you see | First useful check | What the result tells you |
|---|---|---|
| The board's page will not open | Check network reachability and find its actual address. | You have not yet established access to the controller. |
| Local test produces no light | Test one known compatible strand on the selected output. | Focus on test scope, output configuration and the physical path. |
| Local test works; xLights does not | Stop local test mode and inspect incoming data while xLights sends. | Separate the network/channel path from the already working hardware. |
| xLights works; FPP does not | Compare FPP destination and channel output with the saved xLights layout. | The player handoff is the first place to investigate. |
| It fails only with the installed extension | Repeat the same test using the short bench connection. | A changed cable route becomes a specific suspect. |
The page is missing or the board disappears
Use the network recovery guide for an unreachable address. Check the Ethernet link, setup computer's network and the correct router or show network before resetting anything.
If the controller remains accessible but the show freezes, note its uptime before and after the event. A changed uptime suggests a restart; unchanged uptime points you toward the incoming stream and output configuration. Record whether the failure occurs at a particular effect or brightness, and whether another controller is affected at the same moment.
Nothing lights, including the local controller test
Confirm the test is targeting the output actually connected. Begin with one short, compatible strand and a known modest test brightness. Verify the selected pixel protocol, voltage, connector and data-input end. The plug's shape alone does not verify its wiring.
With power disconnected, inspect the external connection and substitute one known working, electrically compatible item at a time. Replacing the cable, strand and output simultaneously may make the lights work without revealing which part failed.
If the same strand works on another appropriately configured output, preserve the result for support. Check the failed output's settings and protection under the controller's service instructions. Never bypass a fuse or increase its rating to keep a failing output running. For internal checks on an assembled unit, avoid exposed mains terminals and contact Mattos when access or the wiring is uncertain.
Only 50 pixels—or only part of a prop—light
First inspect the test's selected pixel count. A limited test and an incomplete configured model can look like a failed string. Compare the intended node count with the model assigned to that physical output, then repeat a test for the intended configured range.
If the configured count is correct, identify the exact node where the result changes. Does the cutoff stay at the same physical position with a known working source and short cable? Or does it move when the software count changes? Record that distinction before cutting or replacing any pixels.
Colors are wrong or a model changes halfway through
Request red, green and blue separately. A consistent swap across the entire prop suggests a color-order setting to review. Random colors, flicker or a change farther down a cable call for checks of the physical connection, protocol and load as well.
Compare color order in the xLights model's controller settings with the Baldrick's saved output configuration. A later xLights upload may replace a controller-only fix. Correct the maintained configuration, upload it and repeat the same three tests.
For several models chained on one port, Hodgical test mode assigns offset RGB cycles to successive models. If one physical prop is split between two expected colors, compare the boundary with the previous model's configured pixel count. This is a useful model-order check, not a substitute for checking the connectors and node count.
Local testing works, but the show does not
- Turn the board's local test mode off.
- Choose one sender for the test. Stop output from the other computer or player.
- Start a short known test and inspect Streaming State or the incoming-data view. Confirm the source address and protocol are the ones you intended.
- If no data arrives, compare the sender's destination IP and the network path. If data arrives, compare the configured channels, models and output assignments.
- If two senders appear, stop one and repeat. Do not try to solve conflicting streams by changing the pixel order.
For an FPP-only failure, also confirm that the current rendered sequence and current output configuration were transferred together. A new layout with an old rendered file can send valid data to the wrong positions.
The board restarts or colors fail when the effect gets brighter
Return to a previously passing test and record the difference. Review the actual supply, bank, output and cable load, including the longest route. A controller's advertised pixel total describes data capacity; it does not establish the available electrical power on every connected cable. Follow our power-planning guide for the load checks.
Do not assume every change after a firmware update is a wiring failure. Read the applicable release notes and compare the saved brightness, gamma and color settings. Make a single change, repeat the same test and record its effect.
Send a useful support record
Email Support@MattosDesigns.com with your order, board and firmware, software versions, affected output, pixel type/count, cable length and the first test that fails. Include a short video and clear connector/label photos.
If available, save Help → Debugging Info from the board for technical support. Treat that file as diagnostic information; it is not a promised one-click restore image. Include screenshots of the relevant controller and player settings, with passwords excluded.
Sources and next steps
- Baldrick support checklist
- Baldrick17 manual
- Hodgical model test
- Baldrick debugging file instructions
- xLights model connections
- xLights check and render tools
- Baldrick release notes
Explore the Mattos Baldrick Learning Center · All Mattos guides
