While working at SetNet, I explored a practical production question: could a small network-connected device provide a clear visual signal when a camera was live?
A tally light normally gives performers and crew an immediate answer without requiring another conversation. My goal was to test whether that signal could be controlled remotely over Ethernet while keeping the device small enough to fit into a production environment.
What I wanted to learn
The first version did not need to be polished hardware. It needed to answer three questions: could an Arduino-compatible board listen for a command over a local network, could that command switch an LED reliably, and could the basic electronics remain compact?
That kept the experiment focused. Instead of building an enclosure or a larger control system first, I began with the network behavior and the light itself.
Building the bench prototype
I configured the board as a small TCP server and assigned the network settings it needed to listen on a designated port. A client could then send a simple state: 1 turned the LED on, and 0 turned it off.
The code was intentionally narrow. Setup initialized the network connection and LED output; the main loop waited for a client and changed the light when a valid command arrived. Keeping the command set this small made it easier to isolate wiring, networking, and control problems during testing.
The photographs document several breadboard and board-level revisions. They are not fifteen different accomplishments, so this edited article uses only the views that explain the progression.
What the experiment established
The bench prototype demonstrated the core idea: a camera-status indicator could respond to a simple command sent across the local network. It also gave me a physical platform for thinking through size, wiring, and how the control logic might fit into a broader production workflow.
It was still a prototype, not finished production hardware. The exposed boards and temporary wiring would need an enclosure, secure connectors, a repeatable power arrangement, startup and reconnection behavior, and field testing before the system could be treated as deployable equipment.
That distinction is the useful part of the project. A focused prototype can answer the riskiest question before time is spent polishing the wrong solution. Here, the network-control concept worked on the bench; the next phase would have been about durability, recovery, integration, and real operating conditions.
