Flow rate input is provide for in code, but the original flow rate meter in the main 50DN line is not operating correctly and will require attention. (It turns out that real-time on-line flow rate monitoring is not as important as originally supposed . The current manual flow meter confirms that flow rates are pretty stable, and thus predicable and the tank water-level sensor provides the crucial information of how much water remains. However, the code provides for the flow pulse counters are read and cleared by briefly disabling interrupts, preventing race conditions where a pulse might arrive during the counter read. The accumulated pulse counts convert to liters per minute as described earlier. If resulting flow rates are below 0.05 liters per minute, they are forced to exactly zero to eliminate noise from false pulses.
All sensor values are then assembled into a UDP packet formatted as a single line of pipe-delimited key-value pairs: EXT_TEMP:35.20|INT_TEMP:30.15 |EXT2_TEMP:35.20|FLOW_IN:0.00|FLOW_OUT:165.30| FLOW:165.30|EMBER:0|WATER_LEVEL:2.85| BAT:13.20|OIL_OK:1|WATER_PV:0.15.
This packet is broadcast to IP address 255.255.255.255 on port 5000, reaching all devices on the local WiFi network.
AR3, connected to AR2's WiFi access point as a client, listens on port 5000 for incoming UDP packets. When a packet arrives, AR3 parses it by searching for each expected key string followed by a colon, extracting the substring up to the next pipe character, and converting it to the appropriate data type. These parsed values are stored in volatile global variables where they can be accessed by the autonomous control algorithms. The entire sensor acquisition, broadcast, reception, and parsing cycle completes in well under 100 milliseconds, providing effectively real-time environmental data to the decision-making code.
For more detail on coding see the Coding Technical Appendix
<< Coding | | Autonomous Fire Defence Algorithms >> |Table of Contents>