Recently, my team and I had the opportunity to develop a software to gamify a room filled with LED floor tiles. These tiles were equipped with sensors to detect if there is any contact with the tiles much like playing the floor is lava. During the initial phase of development before we got the hardware, we assumed that working with the tiles would be easy as pushing data out of the tiles sounded simple in concept. However, delving deeper into the topic we learnt that data transmitted to LED fixtures are through a network protocol known as Art-Net. This posed us with 2 major problems. First being this was our first time working with hardware related projects. And the second being this was our first project which involved networking.
During our research for development we started looking into ways where we could connect our program to the fixtures. Sourcing for controllers and experimentation was a long and arduous process as we were trying to find one that fit the requirements of the hardware we were dealing with. Our first task was to get a single tile to light up using Art-Net protocol. After weeks of extensive testing and research, we eventually stumbled upon Madrix. Not only did this allow us to light up the tile but also see the input of the sensor. Once we were able to accomplish this, we were able to light up a room filled with LED tiles. All that was left now was the communication between the tiles and our game software.

Understanding Art-Net
Art-Net is a network protocol developed in 1998 to allow for transfer of DMX-512 data over IP-based network. This allows us to transfer data to multiple DMX-512 universes over a single IP address. A single universe handles 512 channels, each channel ranging from 0 – 255. Splitting them into RGB channels gives us up to 170 devices controlled over a single universe.
Typical packet format for ART-NET would look like this:
| Byte Offset | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| 0 | ‘A’ | ‘r’ | ‘t’ | ‘-‘ |
| 4 | ‘N’ | ‘e’ | ‘t’ | 0 |
| 8 | Opcode ArtDMX(0x5000) | Protocol Version Hi (0) |
Protocol Version Lo (14) |
|
| 12 | Sequence | Physical | Universe | |
| 16 | Length Hi | Length Lo (2 to 512, even) | Data | |
| 20 | Data | |||
The key variables we should focus on are the universe, the length and the data as these control which controller the data is sent to and for controllers to be able to interpret the data within. The data typically contains bytes to be interpreted in a multitude of different formats like RGB, GRB, etc. These formats vary based on the hardware in question and have to be adapted accordingly.
Packets are sent via broadcast and are typically ignored by receivers unless the corresponding universes match with the one configured in the device/ recipient. It’s also important to note that ART-NET devices are typically configured to port 6454.
We can then construct this packet as a struct and send it via UDP using winsock in C++. To improve performance and reduce packet loss, the transmission rate should be configured to a value relative to the refresh rate of the controller.
Although this is a network operation, it is highly recommended to use ethernet over wireless transmission. Despite that for regular testing/prototyping, WIFI would work fine but in our case, we ran into issues when we started to move towards launch due to the heavy traffic load of our program.
Beginner Tips for Network Testing
When it comes to networking, WireShark is an essential tool to track packets. It gives you the ability to debug your packets directly. Being able to view your packets data, track the source and destination and even view the breakdown of the packet format based on the protocol the packet is sent in. This allowed me to become proficient with the ART-NET protocol quickly as I could directly view and diagnose the problems in question. I’m sure this would be useful for other well known protocol types as well.
Checking variables for network byte order is also important to ensure that data is being handled correctly. As a rule of thumb, anything longer than a single byte should be in network order apart from the actual data within the packet. Within winsock, functions such as ntohs and htons are used to convert between network and host ordered bytes. This is typically to avoid the data being misinterpreted due to device endianness.
Final Thoughts
This project gave me the opportunity to work on a real life experience with full control over how the project is written. I find this is rare for most game development or software engineering students and it was a great opportunity to be exposed to niche subjects such as LED management and the ART-NET protocol.
The shop in question is GriddyGrid and has launched in Singapore since May 2024. You can find them on their website or their Instagram(@GriddyGrid).
You can find the rest of my team members here:
Aloysius Tay
Xavier Lye
Lim Geng Yang

Leave a comment