DMX512 vs Art-Net: 4 Questions to Decide

DMX512 and Art-Net carry the same data; they differ in how far it travels and how much of it fits. DMX512 puts one 512-channel universe on one daisy-chained cable. Art-Net wraps that same DMX512 data — plus RDM — in UDP packets and sends thousands of universes down one Ethernet link. Pick DMX512 when one universe reaches everything you are controlling; pick Art-Net when any of these four answers comes back the other way: your pixel count does not fit one universe, you need more than a couple of output ports, the installation must run without a console, or you have Ethernet where the fixtures live. This is from PILEDS, a manufacturer that builds both DMX/SPI decoders and 16-port Art-Net controllers, so we have no reason to push you at either — here is the four-question test, the channel arithmetic behind it, and the failure modes that decide whether the rig actually works on site.

It is worth clearing one myth up front: neither protocol is faster in any way you will feel. A DMX512 line refreshes its 512 channels continuously, and Art-Net sends the same frames at a comparable rate over the network. Art-Net was never created to beat DMX512 — it was created to stop you running a separate cable for every universe. The official Art-Net site states the protocol is royalty-free, transports 32,768 universes per network, and is implemented by 500-plus manufacturers, which is why it has become the default answer for pixel-heavy work rather than a niche alternative.

The one number that matters commercially: implementing Art-Net costs nothing in licence fees — an OEM code is required, but there is no per-universe or per-device royalty.

DMX512 vs Art-Net: the short answer

The structure of DMX512-A itself is defined by ANSI E1.11, maintained by ESTA; its bi-directional companion RDM is ANSI E1.20, and the sACN streaming alternative is ANSI E1.31. Art-Net is not a standards-body document in the same way — it is published openly by its author as the Art-Net specification, which is the document to have on hand the day a manufacturer's feature list and the wire disagree. The two do not look alike either: a DMX512 line is RS-485 differential signalling on shielded twisted pair, conventionally terminated in a 5-pin XLR connector because it must never be confused with a microphone line, while Art-Net uses the same Cat5e or Cat6 cabling as the rest of a network. If you have ever been told your pixel wall "doesn't fit in one universe," that is the 512-channel limit being reached, and it is the single most common reason people arrive at this comparison at all. The broader map of how protocols sit on top of driver ICs is covered in our addressable LED driver IC and protocol guide.

The rule of thumb that survives contact with a real show: Ethernet for the backbone, DMX for the last three metres, and a copper island for the looks you cannot afford to lose.

Question 1: does your pixel count fit inside one DMX512 line?

Start with arithmetic, not with opinions. Every pixel is a group of channels: three for RGB, four for RGBW. A 512-channel universe therefore holds about 170 RGB pixels or 128 RGBW pixels. That is the whole budget — there is no partial universe you can borrow from.

Two caveats before you design to that number. It is a protocol addressing limit: it tells you how many channels one universe can carry, not how many pixels a particular box can drive and not how many universes a particular port can be mapped from. And it assumes one channel per colour component with nothing else on the line — a driver that adds a global dimmer, an amber channel or a dedicated white channel takes those channels out of the same 512, so check the fixture's channel table rather than the marketing pixel count.

Table note: protocol arithmetic only — 512 slots per universe, three channels per RGB pixel, four per RGBW, no dimmer or white channel and no spare slots reserved. Recompute for your own mix of fixture types before quoting; the divisions round up, so 1,200 channels is three universes, not 2.3.

Three different kinds of number get mixed up in these discussions, and keeping them apart is most of the job:

Note the last two rows of the first table against a spec sheet you may already have: a DMX→SPI decoder whose datasheet rates it for 1,024 pixels and a 16-port controller rated at 1,024 pixels per port are both products in our own range, and neither number is a universe count. Pixels per box and channels per universe are two different budgets; conflating them is how a rig ends up two universes short on load-in day. Both figures also belong to a specific model, output mode and firmware revision — confirm the number for the exact variant you are ordering in its datasheet, because capacity tends to move between revisions. The decoder also has to speak the right dialect at the pixel end — a DMX→SPI box is only useful if it matches the driver IC your strip carries, and the most common fork in the road there is compared in our WS2811 vs WS2812B driver IC comparison. Once the answer to question 1 is "more than one universe," Art-Net stops being a preference and becomes the plumbing — one network link carries all of those universes where copper would have needed one cable each.

A run like this is a channel-budget problem before it is an optics problem: every frame in the row is another block of three-channel pixels competing for the same 512-channel universe.

Question 2: how many outputs and zones do you actually need?

The second question is where the protocol decision turns into a product decision, because "universe" is a software concept and "port" is a physical one. The two are not the same budget, and the commonest sizing error in this whole comparison is to assume that one output port always equals one universe.

A physical output port is one connector and one output stage on the controller. A universe is 512 control channels — an addressing unit that lives in the console's patch and on the network. Whether a single port consumes one universe or several depends on what that port is configured to output:

• A DMX output port presents one 512-slot universe at the connector, because 512 slots is what a DMX512 link is.
• A pixel (SPI) output port is fed from the network and maps channel data onto pixels. Since 512 channels is only about 170 RGB pixels, a port driving a longer pixel run is fed the channel data of more than one universe — how many depends on that model's universe mapping and on the refresh rate you are asking it to hold.
• Per-port pixel capacity and per-port refresh both bound the answer, and neither is universal: they are properties of the model, of the output mode the port is set to, and of the firmware.

So do not size a rig as "eight ports, eight universes." Check the selected controller's universe mapping — how many universes each port can take and how pixel channels are assigned across them — together with its pixel capacity per port and the refresh rate it can sustain at that load. Those numbers, not the port count alone, tell you how many universes your console has to patch. What does not change is the physical side: if your rig has eight separate zones with eight separate cable runs, you need eight ports regardless of which protocol carries the data.

Two things follow. First, port count is the number every supplier quotes in, whichever brand you end up buying — it is what actually constrains the design, and asking for "an Art-Net controller" without it gets you a box that runs out of outputs at commissioning. The models in the table above are simply where ours sit on that ladder. Second, this is the point at which a networked control line repays its complexity, because port count and universe count stop tracking each other: on a 16-port unit the universes behind those ports are whatever the model's mapping assigns — one per port in straight DMX output mode, more than one per port once a port is in pixel mode and the run goes past a single universe's channel budget. "Sixteen ports" is therefore not a universe figure in either direction, and the number to design to is the mapping in the datasheet plus the universes your console will actually patch. In a DMX-only world every extra universe is another cable; in an Art-Net world one Ethernet link carries all of them to one box. Our own controller and decoder range runs from single-output decoders up to the 16-port Art-Net units for exactly this reason — the protocol, the port count and the universe mapping are chosen together or not at all.

The right way to read a controller catalogue: find the port count first, then check which protocols and offline modes that model supports.

Question 3: will a console be running, or must the show run itself?

This is the question most selection guides skip, and it is the one that reverses the answer. Art-Net and sACN are live network protocols: the data exists only while a console, media server, or mapping computer is generating it. If the console stops, the pixels hold their last state or go dark. DMX512 has the same property — it is a streaming signal — but the failure is easier to reason about because there is exactly one cable in the path.

So ask who is in the room. A touring or broadcast rig normally has a console and an operator: Art-Net is ideal, because the console can address every universe on the network and you can add a backup desk to the same fabric — provided the merge and takeover behaviour at the node is configured and tested, which is a device setting rather than anything the protocol arranges for you. A permanent installation — a facade, a club ceiling, a hotel lobby, a storefront that switches on at 18:00 every day — usually has nobody, and a network protocol with no controller running is a very expensive way to leave the lights off. That installation wants a controller that can hold and play a show without a console on the network.

Offline playback, scheduled playback and failover are controller features, not guarantees of a transport protocol. Art-Net says nothing about what a device does when nothing is transmitting, and two controllers that both list "Art-Net" can differ completely in whether either will start a show by itself after a power cut. Ask for the model, the firmware version and the documented behaviour: does it play from local storage with the network disconnected, which file format and schedule does it accept, what does it do at power-up, and what does it do when the network comes back mid-show? In our range that conversation starts with a unit like the PI-808SD, whose online/offline mode is the point of the product — confirm the current firmware's offline behaviour with us before you design a schedule around it, because that is a per-model and per-firmware answer, not a per-protocol one.

Permanently installed feature lighting is the case that decides question 3: nobody is holding a console when it powers up, so the controller has to hold the show.

Question 4: is there usable Ethernet where the fixtures live?

Art-Net needs a network — and a network is a piece of infrastructure somebody has to design, install, and label. That is the last question, and the one most often skipped at design stage and discovered at load-in.

A DMX512 line needs a cable and a terminator. An Art-Net link needs cable runs within the 100 m copper segment limit, a switch with enough ports, addresses and netmasks that match on every device, and a rule about how universes are addressed. The bandwidth itself is rarely the problem: one universe is a continuous stream of packets at roughly 40 to 44 per second, about 0.2 Mbit/s, so a modest 100 Mbit link carries dozens of universes with headroom and latency stays in the millisecond range. That is arithmetic on the packet stream at normal refresh — double the refresh rate and the figure doubles, and it is not a measurement of any particular switch's real throughput, so leave headroom for everything else on the link. What does bite is addressing, and three engineering constraints that rarely make it into the guides are worth designing in from the start:

• Match the network setting to the traffic mode. Unicast, broadcast and multicast fail differently, and the fix for one is not the fix for another. Establish which mode is actually on the wire before you change a switch setting, because "enable IGMP snooping" applied to a unicast stream does nothing at all.
• Broadcast. The easy default on a small network: every packet goes to every device, and each device discards what it does not need. Switch hardware cannot filter broadcast traffic, so at tens of universes every node spends real processor time discarding packets it never wanted. The fix sits at the source rather than the switch: confirm the control software is sending unicast (the Art-Net 4 specification directs controllers to unicast where possible, and most modern software now does so by default), then verify it by checking the per-universe destination address each node reports. Trigger: the rig behaves at low universe counts and starts to stutter as universes or nodes are added.
• Unicast. Each universe has a single destination, the switch forwards it to one port, and IGMP is not involved at all. If a confirmed unicast stream still stutters, IGMP snooping will not help — look at uplink utilisation, duplex mismatch, a saturated buffer in the node, or a wireless hop in the path instead. Trigger: unicast confirmed on the wire, instability remains.
• Multicast. This is the normal sACN case and an option in some Art-Net setups. A switch treats multicast like broadcast unless it is told otherwise: IGMP snooping, plus an IGMP querier on the VLAN, is what prunes each group to the ports that joined it. Both parts are needed — snooping with no querier is a classic way to break multicast that previously worked. Trigger: the stream is genuinely multicast and the universe or node count has grown. Verify with the switch's IGMP group table and by watching a mirrored port before and after the change.
• QoS is a separate question again, and only applies where control and bulk traffic share a physical link: if camera, signage or file-transfer traffic runs on the same uplink as control data, classify lighting packets and prioritise them on that uplink. On a dedicated lighting VLAN with nothing else on it there is nothing to prioritise. Trigger: control and bulk traffic share a link, and the stutter correlates with the other traffic.

The Art-Net discovery mechanism (a controller broadcasts an ArtPoll, each node answers with its address and universes, and the controller then unicasts each universe only where it belongs) is why broadcast can be avoided almost entirely on a well-configured network — ENTTEC's Art-Net reference documents the packet behaviour, the addressing fields, and the netmask traps in more detail than the guides usually bother with. Keeping lighting on its own VLAN is worth doing in every mode, because it removes the shared-link problem instead of tuning around it.

• Wi-Fi is for the last few metres, not the backbone. Wireless Art-Net works and is genuinely useful for a follow-spot data link or a temporary truss drop. It is a poor backbone choice: packets are dropped, a lost frame is overwritten by the next one within tens of milliseconds so you normally will not see it, but a contended access point produces exactly the intermittent flicker that operators remember for years. Keep the backbone wired; scope wireless to low-stakes hops.
• PoE will not drive your pixel run. Power over Ethernet is attractive because it collapses power and data into one cable, and it does work for small control devices. It does not work as a pixel power source: a dense 60 px/m RGBW strip draws on the order of 14–18 W per metre, and a PoE port budget is measured in tens of watts for an entire device. Pixel power stays on local 12/24/48 V supplies at the fixtures, and the network side only carries data. Size those supplies from the strip's actual wattage before you count ports — the method is the same one we describe in the power-supply budget walkthrough for pixel LED strip.

Where this gets big, the network pays for itself immediately: a project with 86,500 pixel points on a single observation wheel is a channel-budget exercise long before it is a lighting effect. At three channels per point that is 259,500 channels, or 507 universes before any spares — arithmetic on the point count, not a statement about what any one controller will carry — and no practical cable count covers that number.

The layer that decides question 4: one network link in, several universes out, sited near the fixtures rather than back at the control position.

What still goes wrong in either world

Two protocols do not make a reliable rig by themselves. These failures appear in both worlds, and the Art-Net-specific ones are almost always network configuration rather than lighting equipment. They are not folklore either — the Art-Net rows below are the cases ENTTEC's Art-Net reference documents, with the fix each one points to:

The DMX side has its own physics: 120 Ω shielded cable, correct termination, and roughly 32 loads per line before you split. A microphone cable plugged into a 3-pin DMX socket is still the most common cause of an intermittent fault in small rigs, and no amount of networking fixes it. RDM exists precisely because a plain DMX512 line cannot report any of this back — it is a one-way signal, which is why address setting and fault reporting needed a separate standard on top of it.

When DMX512 alone is the better answer

It would be easy, writing this from a company that sells network controllers, to pretend Art-Net always wins. It does not, and here is where a plain DMX512 line is the right engineering answer:

• One universe genuinely covers the job. A bar, a restaurant, a small retail unit, a handful of par fixtures and a couple of movers: a single DMX512 line with a terminator is cheaper, faster to commission, and has no addresses or netmasks to get wrong.
• The signal must survive on its own. When a line misbehaves you can walk it, unplug devices, and put a tester on the cable. That directness is why touring and broadcast rigs often keep a small DMX island for the critical looks, even inside otherwise fully networked shows — if the network is disturbed, the show does not go dark.
• The cable already exists. Plenty of venues were wired in DMX years ago and it still works perfectly. Adding a network where a working copper run already reaches everything buys complexity and nothing else.
• Somebody else's equipment is on the other end. If the pixel run feeds a fixture that only speaks DMX, the last hop is DMX regardless — and that is fine.

A 1,200 m DMX wall-washer installation, like the German plaza project in our case library, is a useful reminder that the protocol decision is about topology and control reach, not about how impressive the project sounds. Long linear runs answered to DMX512 routing decisions, and the result works.

Writing the four answers into a spec

Once you can answer the four questions, the specification writes itself in about eight lines. Put these on paper before you request a quote from anyone, and check controller capacity and the actual input/output configuration before that quotation rather than after: our DMX pixel controller capacity calculator does the channel arithmetic for a given pixel count and colour format, and the RFQ & BOM template builder turns the answers below into a request a supplier can quote against line by line.

1. Total pixel count, and the colour format (RGB or RGBW) — this fixes the channel budget and the universe count.
2. Universes required per control line, and how many of them the controller's mapping puts on each port.
3. Output ports and zones, zone by zone.
4. Control mode: live console or media server, or an offline show file with the network disconnected — naming the model and firmware that are expected to provide it.
5. Network plan, if any: switch ports, cable routes, segment lengths, VLAN, and whether the stream is unicast, broadcast or multicast.
6. Power plan per zone: strip wattage per metre × metres, and the supply for each run.
7. DMX island: any part of the rig that must keep working if the network is disturbed.
8. Spares and addressing: spare ports, spare universes, and who documents the patch.

Two honest limits on what the PILEDS range does and does not cover, since this is our own product list. Our controllers and decoders are specified per project — port count, protocol mix, offline mode, and voltage — rather than as a fixed catalogue of standard boxes, which means the exact configuration is confirmed at quotation rather than chosen from a stock list. And a controller is not a lighting design: if the four answers above are not settled, no controller will rescue the plan, which is why our usual first reply to a pixel enquiry is a question about pixel count and zones rather than a price.

One scope note, because it comes up on every pixel-heavy job: control software licences, show programming and on-site commissioning are separate items from the controller hardware. A licence, a programmed show file or a commissioning visit is quoted when it is asked for and agreed in the RFQ — none of them is included by default, and a page describing a packaged system such as our MADRIX LED ceiling system describes a control architecture, not a licence bundle. If you need any of it, put it in the request so it comes back as a line item. Bring the four answers, and send your spec or point count to our team — we will come back with a port layout, the supply sizing, and the universes your console actually needs to patch.

DMX512 vs Art-Net: FAQ

What is the actual difference between Art-Net and DMX512? DMX512 is a physical serial link: one 512-channel universe per cable, daisy-chained, roughly 300 m before repeaters. Art-Net carries the same DMX512 data over Ethernet as UDP packets, so one network link carries thousands of universes. Where the fixtures take DMX512, a node converts the network data back to a physical DMX512 output for the last few metres; where they take SPI or another protocol, a pixel controller outputs that directly and there is no DMX cable in that path at all.

Can Art-Net transmit DMX signals? Yes, that is precisely what it does. Art-Net transports DMX512 (and RDM) data over IP. What comes out at the far end depends on the receiving device and on what the fixture accepts: a DMX node or gateway turns those packets back into real DMX512 output on physical ports, while an Art-Net pixel controller maps the same channel data onto a pixel run and outputs SPI, or whatever protocol that strip or fixture is built for. Art-Net is the transport layer; the final connection is a property of the node or controller, not something you can infer from the fact that Art-Net is on the network.

What are the most common DMX512 problems? Cable and termination faults first: wrong cable type, missing or double terminators, too many loads on one line, and runs past the practical length limit. Then addressing: two fixtures on the same start address, or a patch that assumes a universe has room it does not have once you multiply pixels by three channels.

What software converts Art-Net to DMX? Strictly, the conversion is done by hardware — an Art-Net node or gateway, which turns those packets back into physical DMX512 output. In a pixel system the equivalent box may instead be an Art-Net DMX/SPI controller, which converts the stream onward to the pixel strip rather than back to a DMX cable. Software handles the other half: a console or a mapping application originates the Art-Net in the first place, normally straight out of the computer's own network port. A USB DMX interface is the separate, older path — it produces real DMX512 from the computer rather than Art-Net, and it is how you drive a rig with no node in it at all. Which application you use is a decision made on the software side and kept out of this comparison on purpose — but something upstream has to be generating the Art-Net, because a network with no controller on it carries nothing.

Do I need sACN instead? Not for most pixel projects. sACN (ANSI E1.31) is the other DMX-over-IP standard, and it uses multicast groups that managed switches can prune, which some large permanent installations prefer. Art-Net's simpler addressing and very wide hardware support make it the default in stage and touring work. If your project is hundreds of universes on shared IT infrastructure, compare the two properly before committing — the sACN vs Art-Net comparison works through that trade-off channel by channel.

Can a rig mix both? Yes, and most serious ones do: Ethernet as the backbone carrying Art-Net, with short DMX512 branches from nodes to fixtures at the edge — and a small pure-DMX island for the looks that must not fail. If your project is a stage or touring rig rather than a permanent installation, our stage and touring pixel LED guide covers the fixture side of the same decision.