NovaStar MRV366: maintaining and replacing a receiving card on an installed fleet
Diagnose a failing MRV366 card on an installed LED fleet: status LEDs, configuration readback, NovaLCT firmware updates, spare stock and migration.
NovaStar receiving cards — installed fleet
The MRV366 still runs on many LED walls in the field. This guide covers its maintenance: LED-based diagnosis, cabinet configuration backup and restore, firmware updates, and the repair-versus-migration decision.
The MRV366 is a general-purpose receiving card widely deployed across LED fleets installed several years ago. It supports scan rates up to 1/64, loads up to 512 × 256 pixels at 8-bit (or 256 × 256 at 10/12-bit), and communicates over standard HUB75 connectors. Many walls still running today rely on this card, which makes it a common maintenance item rather than a choice for new commissioning.
This tutorial does not cover commissioning a new wall. It targets maintenance teams who need to identify a failing card within an existing fleet, recover and replay a cabinet's configuration file without recalibrating from scratch, update firmware through NovaLCT, manage a coherent spare-parts stock, and decide between a like-for-like repair and a migration to a newer card.
All technical values referenced here come from the official MRV366 specifications sheet, revision V1.2.0 dated October 31, 2019, which documents firmware V4.6.1.0, the addition of 1/64 scan support and individual RGB Gamma adjustment.
1. The MRV366 on an installed fleet today
A receiving card is almost never replaced preventively: it stays in service until a visible symptom or a network alert flags it. On a fleet where the MRV366 was originally deployed, the technical team therefore has to work with a heterogeneous install base, sometimes spanning several firmware revisions depending on when each cabinet was installed.
The card handles up to 32 parallel RGB data sets over HUB75 and can drive scan rates up to 1/64, covering most high pixel-density panels installed at the time of its release. Understanding these limits remains essential before any replacement: a spare card incompatible with the cabinet's scan rate will produce incorrect display output even if it communicates correctly on the network.
- Supported scan: up to 1/64.
- Maximum load: 512 × 256 pixels at 8-bit, 256 × 256 pixels at 10/12-bit.
- Connectivity: standard HUB75, up to 32 parallel RGB data sets.
- Documented firmware: V4.6.1.0 (specifications V1.2.0, 10/31/2019).
Before working on an older fleet, note the exact cabinet revision and its scan density: two visually identical cabinets can require differently configured cards.
2. Official technical specifications
The table below lists the specifications published in the MRV366 V1.2.0 sheet. Use them as a reference to validate spare-card compatibility and to size a spare-parts stock consistent with the fleet in operation.
| Characteristic | Value |
|---|---|
| Supported scan | Up to 1/64 |
| Maximum load (8-bit) | 512 × 256 pixels |
| Maximum load (10/12-bit) | 256 × 256 pixels |
| Connectivity | HUB75, up to 32 parallel RGB data sets |
| Input voltage | DC 3.3 V–5.0 V |
| Rated current | 0.5 A |
| Rated power consumption | 2.5 W |
| Operating temperature | -20°C to +70°C |
| Operating humidity | 10% to 90% RH, non-condensing |
| Storage temperature | -25°C to +125°C |
| Dimensions | 145.6 × 91.5 × 17.2 mm |
| Net weight | 100.1 g |
| Certifications | RoHS, EMC Class A |
| Reference firmware | V4.6.1.0 |
The 3.3–5.0 V input voltage is set by the cabinet, not by the card: never substitute a power supply outside this range in an attempt to harmonize a mixed fleet.
3. Diagnosing a failing card from the status LEDs
The MRV366 has two front-panel indicators: a green status LED and a red power LED. Their behavior, as documented in the official sheet, allows for a first-level diagnosis without tools or a computer, which considerably speeds up an on-site visit when several cabinets need checking.
A red LED that is off indicates a power supply issue upstream of the card, and should be checked before suspecting the card itself. A green LED that blinks irregularly or stays fixed points to a problem specific to the card or its network link, to be confirmed afterwards in NovaLCT.
- Check the red LED first: if it is off, verify power and HUB75 wiring before replacing the card.
- A green flash every 0.2s signals a failed program load: the card automatically falls back to its backup copy.
- A flash every 3s points to a cable fault rather than the card itself.
- Log the observed LED behavior before intervening, it directly guides the next diagnostic step in NovaLCT.
| LED | Behavior | Meaning |
|---|---|---|
| Green (status) | Flashing every 1s | Normal operation, Ethernet cable OK, video source present |
| Green (status) | Flashing every 3s | Normal operation, but Ethernet cable abnormal |
| Green (status) | 3 flashes every 1s | Normal operation, cable OK, but no video source |
| Green (status) | Flashing every 0.2s | Program loading failed, falling back to backup program |
| Green (status) | 8 flashes every 1s | Sending card's backup Ethernet port active, card functional |
| Red (power) | Always on | Power supplied |
Record a short video of the blinking LED before powering down: the exact rhythm is hard to recall accurately once the card is unplugged.
4. Understanding dual program backup and loop backup
The MRV366 stores two copies of its application program from the factory, a mechanism designed to prevent an interrupted update from bricking the card. This explains the 0.2-second green flash mentioned above: the card detected a load failure and automatically switched to its backup copy, without losing control of the cabinet.
In a chain of cards, the card also manages loop backup on the main and backup cascading lines: if one of the two chaining links fails, the other takes over to keep the display running without interruption. This detail matters during diagnosis, since a card that fails physically upstream in a chain can cut the display of several downstream cabinets, even though those cabinets are not themselves faulty.
- Two copies of the application program stored at the factory on every card.
- Automatic fallback to the backup copy on a failed update.
- Loop backup on main and backup cascading lines.
- A fault at the head of a chain can mask the real state of downstream cards.
Before replacing a card suspected at the head of a chain, test it in isolation: an upstream chaining fault produces the same visual symptoms as several failing downstream cards.
5. Recovering and replaying the cabinet configuration file
Before pulling a suspect card, NovaLCT (V5.2.0 or later) lets you read back and save locally the receiving card's configuration parameters, as well as its firmware program. This readback is the first step that should never be skipped: it preserves the exact current settings, including brightness and chroma calibration applied through NovaLCT and NovaCLB.
Once the replacement card is installed, the recovered configuration file is replayed through NovaLCT to restore the cabinet's settings without a full recalibration. This approach is particularly relevant for fleet maintenance, where recalibrating a single cabinet from scratch would break visual consistency with its neighbors.
- Read back the suspect card's configuration before any removal, via NovaLCT.
- Also back up the current firmware program if a firmware rollback is being considered.
- Install the replacement card and check its firmware revision before replaying the configuration.
- Replay the saved configuration file to restore cabinet calibration and settings.
Name your backup files with the cabinet ID and the readback date: on a fleet of several hundred cards, a poorly named file is as useless as no backup at all.
6. Updating firmware through NovaLCT
The MRV366 sheet documents firmware V4.6.1.0, which introduced 1/64 scan support and individual RGB Gamma adjustment. On an older fleet, it is not uncommon to find cards on earlier firmware, incompatible with certain functions enabled on the sending-card side or in a recent NovaLCT release, particularly network error-rate monitoring, which requires NovaLCT V5.2.0 or later.
Updates are carried out from NovaLCT, either card by card or in batches depending on network topology. Thanks to the card's built-in dual program backup, an interruption during transfer does not brick the card: it falls back to its previous program and signals the failure through the characteristic 0.2-second flash.
- Check the current firmware version before any update, card by card on a heterogeneous fleet.
- Use NovaLCT V5.2.0 or later to benefit from network error-rate monitoring and firmware readback.
- Never cut power manually during an ongoing firmware transfer.
- Check the green LED after an update to confirm the new program loaded correctly.
A bulk update across a large number of cards at once can temporarily saturate the fleet's network bandwidth: prefer smaller batches outside the wall's operating hours.
7. Sizing a spare-parts stock
A coherent spare-parts stock for a MRV366-equipped fleet rests on three elements: physically identical or functionally compatible cards, a reserve of HUB75 cables and connectors, and up-to-date copies of each cabinet's configuration files, organized and quickly accessible during an intervention.
The original packaging, with an antistatic bag and anti-collision foam, remains the reference for long-term spare-card storage. Respect the -25°C to +125°C storage range and 0% to 95% RH humidity without condensation, notably wider than the operating range, which leaves a comfortable margin for stock kept in an unconditioned technical room.
- Plan a spare-card ratio proportional to the number of cabinets in operation, not to the total card count.
- Keep configuration files per cabinet in a structured folder, accessible offline during interventions.
- Store cards in their original antistatic packaging until use.
- Periodically check the firmware revision of spare cards in stock, to avoid installing a card older than the active fleet.
Update spare cards' firmware at the same pace as the active fleet: an outdated spare card complicates configuration replay at the exact moment of an emergency.
8. Repairing like-for-like or migrating to a newer card
Replacing a failing MRV366 with an identical card remains the fastest and lowest-risk option on a homogeneous fleet: mechanical and functional compatibility is guaranteed, and the backed-up configuration replays directly. This option fits when MRV366 sourcing remains possible and the fleet has no short-term upgrade plan.
Migrating to a newer receiving card makes sense when MRV366 cards become hard to source, when the fleet needs more advanced network diagnostic functions, or when a wall extension requires a higher-capacity card. This option, however, requires a full revalidation of the cabinet's settings, since an old card's configuration does not automatically transfer to a different model.
| Criterion | Like-for-like repair | Migration to a newer card |
|---|---|---|
| Intervention time | Fast, direct configuration replay | Longer, requires settings revalidation |
| Parts availability | Depends on remaining MRV366 stock | Recent cards widely available |
| Diagnostic functions | Limited to the V1.2.0 sheet's scope | Extended network and monitoring functions |
| Fleet consistency | Preserved if the rest of the fleet is MRV366 | Should be batched to avoid a long-term mixed fleet |
Avoid mixing MRV366 and newer cards long-term on the same cabinet or chain: prefer batch replacement per full cabinet to limit visible calibration mismatches.
9. Troubleshooting common issues
The table below lists the most frequent issues encountered while maintaining a MRV366 fleet, with the likely cause and the priority action before any card replacement.
| Symptom | Likely cause | Action |
|---|---|---|
| Cabinet off, red LED off | No power upstream | Check power supply and wiring before suspecting the card |
| Green LED flashing every 0.2s | Program load failure | Check firmware, restart a clean update from NovaLCT |
| Several downstream cabinets off | Chaining fault at the head of the line | Isolate and test the head-of-chain card first |
| Cabinet settings lost after replacement | Configuration not backed up before removal | Read back configuration from the failing card if it still responds |
| Network error-rate monitoring unavailable | NovaLCT version earlier than V5.2.0 | Update NovaLCT on the monitoring side |
Procedure
Identify the suspect card
Observe the green and red status LEDs on the front panel to locate the failing card without prior disassembly.
Back up the configuration
Read back and save locally the cabinet's configuration and, if needed, its firmware program through NovaLCT before any removal.
Check the spare stock
Verify the firmware revision and condition of the available spare card before installing it on the cabinet.
Replace the card
Remove the failing card, install the spare card and restore the HUB75 wiring and power supply.
Replay the configuration
Replay the saved configuration file through NovaLCT to restore the cabinet's settings and calibration.
Update firmware if needed
Align the spare card with the fleet's firmware revision through NovaLCT.
Check the result
Verify the green LED's behavior and the visual consistency of the replaced cabinet against its neighbors.
Frequently asked questions
What is the maximum scan supported by the MRV366?
Up to 1/64, according to the official specifications sheet V1.2.0 dated October 31, 2019.
How can I tell if an MRV366 is failing without a computer?
By observing the green and red front-panel LEDs: their blinking pattern, documented in the official sheet, indicates a power fault, a cable issue, a missing video source, or a failed program load.
Can a card's configuration be recovered before replacing it?
Yes, if the card still responds: NovaLCT (V5.2.0 or later) can read back and save locally the receiving card's configuration and firmware program.
Does a cabinet need recalibration after a card replacement?
No, if the saved configuration file is replayed through NovaLCT: brightness and chroma calibration are restored without a new full calibration pass.
When should you migrate to a newer receiving card instead of repairing like-for-like?
When MRV366 sourcing becomes difficult, when advanced network diagnostic functions are needed, or when a wall extension requires more than 512 × 256 pixels at 8-bit.
Which NovaLCT version is required for network error-rate monitoring?
NovaLCT V5.2.0 or later, according to the MRV366's official specifications sheet.
Downloads
Related tutorials
Need a spare card or maintenance support?
PIXELIGHT supports technical teams in maintaining installed LED fleets, from diagnosis to sourcing compatible parts.