v3.3 is the firmware we recommend as the official EPS firmware. It replaces the network layer of v2.2 with one written for the job (v3.0), brings it in line with the network standards an enterprise network expects (v3.1), widens the chip self-check to the faults that reproduce the field dropout (v3.2), and closes the four gaps a full code analysis found in that self-check (v3.3). Where v2.2 needed a power cycle after the network failures we reproduced, v3.3 recovers by itself, measures its own supply, and records what happened when something goes wrong. It was tested overnight against every earlier version on the same box; it has not yet run in the field. The case for making v3.3 official → · All versions compared →
Field problem: EPS units on v2.2 randomly drop off the network (no ping, no web page, no control) until their power is cycled.
What we found: v2.2 has several defects that lead to exactly that state. The clearest one: in DHCP mode, a single DHCP renewal that goes unanswered makes v2.2 restart itself, and if the DHCP server is away at that moment, the unit stays off the network until someone power-cycles it. Others: the network chip losing its settings (v2.2 never notices), and connections that block the control port. For units set to a static address, the field trigger is still open.
What the code analysis added (2026-10-12): v2.2 cannot silence a static unit by its own logic; something outside the firmware has to upset the network chip. But every such upset is permanent on v2.2, and the most likely trigger is the supply: the board's brown-out level is 2.7 V (the box reports it), well below what the CPU and the network chip need.
v3.3: recovers by itself from every one of these in our tests, typically within seconds, keeps the outputs on while it does, and keeps a log (now with the supply voltage at every chip fault) that will tell us what happened if a unit does drop off in the field. In the single-register fault matrix it recovers from all 17 faults, including two new ones: a PHY held in reset, on which v3.2 is dead, and a link that only the new link-down recovery can bring back. On the pre-registered suite of 56 network-standard requirements it passes 48 (v3.1/v3.2: 46, v2.2: 26); of its six failures, two are limits of the network chip and four are kept on purpose. We are confident v3.3 is the most robust firmware we have. Whether it ends the field dropouts will be shown by a pilot and a supply-sag test, not by the bench.
Outputs, timing, inputs, LEDs, the TCP control protocol (Companion, eXcontrol, Crestron, Q-SYS) and all stored settings work as before. The network layer below was rewritten in v3.0, brought to standard in v3.1, had its self-check widened in v3.2, and had the gaps in that self-check closed in v3.3.
| Area | v2.2 | v3.3 | Why it matters |
|---|---|---|---|
| Network driver | Arduino Ethernet library, 4 connections shared by everything | Own W5500 driver, all 8 hardware sockets, fixed per service | No service can starve another |
| Idle and half-open connections | Never closed; two idle browser connections block the control port | Web closed after 5 s idle; control connections kept, oldest evicted when full; a stalled receiver is dropped after 2 s | Controllers and browsers can't lock the unit out |
| DHCP | Blocks for up to 60 s; an unanswered renewal restarts the unit; after one failed start it never asks again; asks once a second | Never blocks; RFC 2131 timing (random start delay, back-off 4–64 s, renew, rebind); checks the leased address and declines it if in use; falls back to static and keeps asking | Survives DHCP server outages without a power cycle, and doesn't flood the server |
| Address conflicts | None: takes an address already in use | Checks every address before use (RFC 5227: 3 probes, 2 announcements); doesn't take one in use; defends its own | A mistyped IP doesn't knock another device off the network |
| Network chip health | Never checked | Checked every 5 s; re-initialised within seconds if settings are lost. v3.2 widened the check to the mode, retry and PHY registers (ping block, retry count, forced slow link, PHY power-down); v3.3 adds the PHY reset bit, so a PHY held in reset is caught too | Recovers from a supply dip, interference or a PHY fault (the field symptom) |
| Link and PHY | Never reset | Fresh negotiation at every start; re-applied if the PHY register is wrong; v3.3: PHY reset after 30 s without link (backing off to ~32 min); receiver check once a minute that also works without a gateway and ignores a gateway that has simply gone; optional fixed 10 Mbps | Recovers from a stuck, powered-down or deaf link |
| MAC address | Set in the sketch for each unit before flashing | Written once per unit from Expromo's IEEE block and stored in the unit; later updates and factory reset keep it | A generic update can't give a unit the wrong MAC |
| Web page and HTTP | 3,598 packets, ~0.9 s, blocks control meanwhile; every method treated as GET | 3 packets, ~45 ms; 400/405 for bad or other requests; HEAD never switches anything | Control stays responsive; HEAD and other methods never switch power |
| TCP retries | Library writes the wrong chip registers: gives up after 18 s | Gives up after 102 s (RFC 1122: at least 100 s) | Connections survive short network hiccups |
| Power control during network waits | Stops while the network code blocks | Inputs, power sequence and LED keep running | A slow client can't delay switching |
| Diagnostics | None | NET_STATUS, a 96-event log that survives power cuts, and optional syslog: restarts with reason, link drops, chip re-inits, PHY resets, DHCP, address conflicts, every power command with its source. v3.3: 5 V supply now and lowest (VCC, VCC_MIN), logged with every chip re-init, and the brown-out fuse (BOD) | A dropout in the field leaves evidence, including whether the supply sagged |
The side-by-side comparison ran on v3.0, which has the same network layer. Every test that doesn't need a long run was then repeated on v3.1's final build, all passed.
| Test | v2.2 | v3.0 / v3.1 |
|---|---|---|
| Normal controller load: availability (6 runs, 2 boards) | 84.2–86.6 % | 99.91–100 % v3.0 |
| Control reply, 99th percentile | 1,031–1,532 ms | 31–47 ms v3.0 |
| Longest control-port outage per 5-min run | 79–121 s | 0 s v3.0 |
| Idle connections held open (up to 5 per port) | control port dead from 1–2 | 800 of 800 answered v3.1 |
| Network chip loses its settings | dead until reset (4/4) | recovered in 2.1–6.9 s, outputs kept (10/10) v3.1 |
| DHCP renewals (M4250 server, 10 min) | restarted itself every 3–4 min | kept its lease, no restarts v3.0 |
| DHCP server off 5 min, then back | stranded until power cycle | lease back 6 s after the server returned v3.0; v3.1 keeps asking at most 64 s apart |
| Silent start-up after a reset (same board) | 4 in 536 | 0 in 300 (suggestive, not proven) v3.0 |
| 5 h side by side, ping and control every second | no failures; worst reply 625 ms | no failures; worst reply 16 ms v3.0 |
| Main-loop hang | watchdog restart | watchdog restart, answering ~25 s later (3/3) v3.1 |
| Single chip-register faults (17 faults, real box) | dead or stuck on most | v3.1 dies on 4 (incl. PHY power-down); v3.2 recovers from the original 14 but is dead on a PHY held in reset; v3.3 recovers from all 17 (51 trials, 3–10 s, outputs never moved) v3.1–v3.3 |
| Gateway disappears (router reboot), 12 min watched | keepalive keeps using the cached address; no reaction | v3.2: no ARP after it vanished, so its check keeps "succeeding" on a cached address (and can't see a deaf receiver); v3.3: one ARP request per check, no false PHY reset v3.2 / v3.3 |
| Start-up after a USB reset (real box, ×200) | 200/200, 0 deaf | 200/200, 0 deaf v3.1 |
Fifty-six requirements from ten standards, each with a pass criterion written down before either firmware was tested, run with the same tool on the same box. A standard passes only if every one of its requirements passes, so one failed item is enough to fail it. The suite was run on v3.1 (2026-10-10) and again on v3.3 (2026-10-12). v3.2 scores as v3.1: its only change is the health check, which nothing in the suite measures.
| Standard | v2.2 | v3.3 |
|---|---|---|
| IEEE 802.3 Ethernet | Pass | Pass |
| IEEE 802 MAC addressing | Pass | Pass |
| RFC 826 ARP | Pass | Pass |
| IEEE 802.1D/Q end station | Pass | Pass |
| RFC 5227 address conflict detection | Fail: 6 items | Pass |
| RFC 5424/5426 syslog | Not available | Pass |
| RFC 2131/2132 DHCP client | Fail: 7 items | Fail: 1 item |
| HTTP (RFC 9110/9112) | Fail: 7 items | Fail: 2 items |
| TCP (RFC 9293/1122) | Fail: 2 items | Fail: 1 item |
| RFC 1122 host requirements | Fail: 3 items | Fail: 2 items (chip limits) |
| Requirements passed, of 56 | 26 | 48 |
Host header is missing, because control systems send hand-written HTTP strings that often omit it.Host check above): the web page and control systems switch power with simple GET links; a stalled receiver is dropped after 2 s so it can't hold up power control; while waiting for a DHCP server the unit asks from its fallback address, so it stays reachable.| Area | v3.3 behaviour | Confidence |
|---|---|---|
| DHCP client (RFC 2131) | Random start delay and back-off; renews by unicast at T1, rebinds at T2, falls back when the lease expires; declines an address in use; sends a hostname (EPS-xxxxxx). Tested with three different servers (v3.0) and the new timing with a bench server (v3.1). One deviation: while it has no lease it asks from its fallback address, not 0.0.0.0. | Verified |
| Static addressing | Default mode; the address is checked before use and not taken if another device has it. | Verified |
| Address conflicts (RFC 5227) | Probes and announces at start-up, after a link outage and for every new lease; logs later conflicts and defends its address (defence code-reviewed only: testing it needs forged traffic). | Verified |
| ARP | Answers in hardware; one ARP request a minute to the gateway (or, without one, to the last controller), never more than one a second, even when the gateway is absent. | Verified |
| Unique, registered MAC | One address per unit from Expromo's IEEE MA-S block (8C:1F:64:C3:9x:xx). | Verified |
| Link | 10/100 Mbps auto-negotiation; works with a partner forced to 10 or 100 Mbps half duplex; optional fixed 10 Mbps. The W5500 chip has no Energy-Efficient Ethernet. | Verified |
| Spanning tree | Plain end station, sends no BPDUs; works on edge / auto-edge ports (≈ 3 s forwarding delay on the M4250). | Verified |
| Long-lived controller connections | Crestron / Q-SYS-style persistent connections kept; a new client always gets in. TCP keep-alive available, off by default. | Verified |
| Syslog (RFC 5424) | Optional: every logged event to a server set on the web page or by DHCP. | Verified |
| DHCP snooping, dynamic ARP inspection | Standard renewals and probes should pass; not tested in such an environment. | Not yet verified |
| Other switch brands (e.g. Cisco), multi-day operation, real loads | Not tested yet; planned in the pilot. | Not yet verified |
| 802.1X, VLAN tagging, IPv6, SNMP, NTP | Not available. Use MAC-based port authorisation and an untagged access port in the AV VLAN. | Not supported |
| Authentication and encryption | None on the control port or web page (same as v2.2). Keep EPS units on a dedicated AV VLAN or restrict access with ACLs. | Not supported |
NET_LOG after it is back.