Summary of the AR2 Sketch
by Claude 4.5
AR2 is an Arduino Uno R4 WiFi sketch that acts as the dedicated sensor aggregator for the ARMAC system. Its sole function is to read all physical sensors, compute derived values, and broadcast the results at 10 Hz over UDP to any listening receiver on the local WiFi network — primarily AR3 and TAR3. AR2 has no relay outputs and issues no control commands. It also hosts a scenario engine that can inject scripted simulated sensor values into the outgoing UDP stream for system testing without affecting the real sensor hardware.
Hardware and Pin Assignments
AR2 reads seven distinct sensor inputs. Three DS18B20 digital temperature sensors share a common OneWire bus on D6, mapped by hardware address to external temperature (EXT_TEMP), internal/shed temperature (INT_TEMP), and a second external temperature (EXT2_TEMP). Two flow meters connect to interrupt-capable pins D3 and D2: a DN15 in-feed meter measuring mains water filling the tank (450 pulses per litre) and a DN50 pump-line meter measuring outflow to the sprinklers (calibration constant noted as a placeholder requiring field measurement). An ember/flame detector on D12 is read as an active-LOW digital input. Tank water level is read from an analogue voltage on A0, converted to depth in metres via a linear voltage-to-depth mapping. Oil pressure from the pump engine is read as a digital signal on D10 via a PC817 optocoupler, where a LOW output indicates oil pressure present (engine running). Water pressure at the SFS pump control node is read as a raw 0–5 V analogue voltage on A1, where approximately 0 V indicates the pump is running under load. Battery voltage is read on A2 through a calibrated resistor divider, with the conversion factor trimmed to match a measured reference point of 12.0 V producing 2.53 V at the ADC input, with a further system-level correction factor applied.
Network Architecture
AR2 operates as a WiFi access point (SSID Arduino2_AP) rather than joining an existing network. This means it has a fixed, predictable IP address regardless of external infrastructure, and AR3/TAR3 can connect directly to it. All sensor data is transmitted as UDP broadcast packets to 255.255.255.255 on port 5000, so any client on the AR2 AP subnet receives the data without AR2 needing to know client addresses. The same UDP port receives incoming scenario control commands, allowing TAR3 to start, stop, and configure test scenarios on AR2 without a separate channel.
Sensor Reading and Processing
Temperature readings are requested from all three DS18B20 sensors in a single blocking call via the DallasTemperature library. Each reading is validated against a sanity window (-55°C to 125°C); failed sensors fall back to defined defaults (31°C, 30°C, 32°C respectively) so downstream consumers receive a reasonable value rather than a sentinel. If all three sensors return invalid readings on the same pass, a consecutive-failure counter increments. After five consecutive all-bad reads, the OneWire bus is reinitialised (reset + dallas.begin()) to recover from bus faults. Any single valid reading clears the failure streak.
Flow measurement uses hardware interrupts on both flow meter pins with an 8 ms debounce guard to prevent contact bounce producing false pulses. Each loop iteration at 10 Hz atomically snapshots and clears both pulse counters (with interrupts disabled during the read), converts the 100 ms pulse count to a frequency in Hz, and divides by the calibration constant to obtain flow in litres per minute. Readings below 0.05 L/min are clamped to zero to suppress noise when no flow is present.
Battery voltage is passed through an exponential moving average filter with a time constant of approximately 45 seconds. The filter initialises to the first real reading rather than zero, avoiding a large initial transient. This smooths ADC noise and load-induced voltage dips without masking genuine slow trends in battery state.
UDP Payload Format
Every 100 ms AR2 assembles and broadcasts a single pipe-delimited key:value string containing all sensor values: EXT_TEMP, INT_TEMP, EXT2_TEMP, FLOW_IN, FLOW_OUT, a legacy FLOW field (equal to FLOW_OUT for backward compatibility), EMBER, WATER_LEVEL, BAT, OIL_OK, and WATER_PV. All floating-point values are formatted to two decimal places. The format matches what AR3 and TAR3 expect to parse, and the inclusion of both FLOW and FLOW_OUT ensures older firmware versions that reference only the legacy field continue to function correctly.
A 1 Hz console debug print echoes the current sensor values to the Serial port, with a separate flag (DEBUG_TEMPS) that gates the temperature and flow portions of this output.
Scenario Engine
AR2 includes a sensor-only scenario engine ported from the AR3 AutoTest facility. When active, the scenario overrides the values in the outgoing UDP payload with scripted simulated values; real sensor hardware continues to read normally and is unaffected. This allows end-to-end system testing of AR3's autonomous control logic — including its temperature thresholds, mode transitions, and shutdown conditions — while the physical system remains in a known safe state.
Scenario control arrives via UDP on the same port 5000, using SIMCTRL: prefixed commands from TAR3: SIMCTRL:START:<id> begins a named scenario; SIMCTRL:SPEED:<x> adjusts the time-scaling factor (a speed of 1.0 runs at real time, lower values compress time); SIMCTRL:STOP terminates immediately.
Two scenarios are implemented. Scenario 1 is a 19-step table-driven sequence that exercises a full fire approach and departure cycle: it starts with flow running and good battery, advances through rising external and internal temperatures crossing various AR3 mode thresholds (thermostat, intermittent, continuous), reaches a peak external temperature of 95°C, then steps through a cooldown phase with a battery voltage drop event, followed by tank water level declining through the gel injection threshold to near-empty shutdown. Each step holds its values for a configurable duration (default 30 seconds, scaled by FS_speed). The sentinel value -9999 on any field means "no change from previous step", allowing sparse step definitions that only modify the values relevant to that phase of the test.
Scenario 5 is a shorter procedural scenario focused on flow meter and water level fallback behaviour, using a mix of fast (100 ms) and slow (30 s) step intervals depending on the step index.
When a scenario is active, battery voltage is also taken from the scenario state, allowing battery voltage drops to be injected as part of a test sequence alongside the temperature and water level changes.
Simulation Flags
Independent of the scenario engine, compile-time flags (SIMULATION_MODE, SIMULATE_TANK_WATER_LEVEL, SIMULATE_FLOW, SIMULATE_BATTERY) can substitute fixed hardcoded values for individual sensor channels. These are distinct from the scenario engine: simulation flags provide static values for bench testing a single sensor channel, while the scenario engine drives dynamic multi-variable sequences for testing control logic. In normal deployment all simulation flags are set to 0.
<< AR1 Arduino Sketch - Structure and Function | | AR3 Arduino Sketch - Structure and Function >> |Table of Contents>