A simulated relay board proves logic, not hardware. Keep every command bounded, decide the power-on state before anything else, and read the coil driver’s own datasheet before trusting a channel.
Four-channel relay control looks simple until you separate what the microcontroller decides from what the driver and the relay actually do. This reference treats it as a low-voltage test-plan exercise: bounded command handling, a defined startup state, and an honest account of what a simulation can and cannot show. For the wider control context, see the Arduino as a programmable logic controller guide.
Bounded command parsing
Serial is the Arduino API for communication with computers and other devices, and serial port mappings depend on the board; the classic UNO R3 table maps receive and transmit to pins 0 and 1. A control sketch should accept only the commands it defines, reject anything outside that set, and behave predictably when input is malformed. Bounds are a design requirement, not a nicety.
The startup state comes first
The digitalWrite reference states that a pin must be configured as OUTPUT to drive an output voltage, and that on an INPUT pin digitalWrite instead enables or disables the internal pull-up. Before any command is processed, the sketch should force every output to a known off state, so that a reset or a garbled command cannot leave a channel in an undefined position.
What the driver does and does not promise
| Evaluation point | Driver side (ULN2003A) | Coil / relay side |
|---|---|---|
| Documented capability | Seven NPN Darlington pairs with common-cathode clamp diodes for inductive switching | Coil requirements come from the relay’s own document |
| Current claim | 500 mA collector current is a single-output rating | Aggregate current across channels must be checked, not assumed |
| Inductive switching | Clamp diodes are provided for inductive loads | The flyback path still depends on how the load is wired |
| Isolation | Not established by the Darlington driver | Do not assume galvanic isolation from a driver alone |
The 500 mA figure is specifically a single-output rating, not a guarantee that every channel can run at full current simultaneously.
An ordered simulation and test process
- Define the allowed command set and reject everything outside it.
- Force a known off state at startup for all channels.
- Configure pins as OUTPUT before driving them.
- Validate each parsed command against bounds before acting on it.
- Simulate with indicators to confirm the logic responds as intended.
- Read the exact driver and relay documents for aggregate thermal and current limits.
- Keep the scope low-voltage and stop there; a simulation does not validate mains or appliance switching.
Reader questions
Does passing in simulation mean the hardware works?
No. A Proteus run exercises logic and indicators only; it does not validate a sketch’s completeness, its input-buffer bounds or the real relay specifications.
Is the board isolated just because it uses a Darlington driver?
No. A Darlington array does not itself create galvanic isolation, and full isolation needs separate evidence.
Can I run all four channels at 500 mA each?
The 500 mA collector-current figure is a single-output rating; it is not a guarantee of simultaneous full-current operation on every channel.
Why do the serial pins matter?
Serial mappings depend on the board, and the classic UNO R3 table assigns receive and transmit to pins 0 and 1, so pin choices should follow your board’s mapping.
Documentation
- Arduino Serial reference (official reference-en source)
- Arduino digitalWrite() reference (official reference-en source)
- Texas Instruments ULN200x/ULQ200x Darlington array datasheet, SLRS027T
Scope note: these links document the serial API, the digitalWrite API and one Darlington array datasheet. No hardware build or simulation run was performed, and the incomplete code, input-buffer bounds and exact relay specifications remain unverified; keep the work low-voltage, with no mains relay-contact wiring or appliance switching.
