Chinese
Spanish
Russian
Portuguese
French
German
Indonesian
Thai
Vietnamese
Arabic
Italian
Turkish
Polish
Japanese
Remote Tank Level Monitoring: A Power, Data and Alarm Design
Design rule. Remote tank level monitoring is not a radar with a radio attached. The project has three linked budgets: energy, communications and response time. Sampling every second does not require transmitting every second, and a dashboard updating every 15 minutes does not prove that a critical high-level alarm will arrive in time. Define those functions separately before choosing the sensor, battery or network.
Decide what must happen when the network is absent
A remote site should have a written loss-of-communications behavior. Which values are stored locally? How long can they be buffered? Does a local high-level switch still stop filling? Does the dashboard show the age of the last good value, or does it keep displaying it as if it were current?
A reading of 72% received six hours ago is not the same as a current 72%. Every value needs a timestamp and quality state. On reconnection, backfilled history should be identifiable so it is not mistaken for live data.
| Function | Local or cloud decision | Design question |
|---|---|---|
| Level sampling | Usually local | How fast can the tank physically change? |
| High-high protection | Local where immediate action is required | What stops flow if the radio is down? |
| Routine reporting | Edge gateway or platform | What interval supports inventory planning? |
| Exception reporting | Local event trigger with retry | Which changes must be sent immediately? |
| Historical storage | Local buffer plus server | How many days and what happens when full? |
| Configuration | Controlled local/remote process | Who can change scaling, alarms or firmware? |
Worked energy budget: do the arithmetic before selecting solar
Suppose an illustrative sensor and gateway together average 0.30 W while operating continuously. Daily energy demand is:
0.30 W × 24 h = 7.2 Wh/day
A nominal 12 V, 20 Ah battery contains 240 Wh, but not all of that is usable after allowable depth of discharge, temperature, aging and conversion losses. If the design permits only 50% usable nominal energy, the simple autonomy estimate is:
120 Wh ÷ 0.30 W = 400 h = 16.7 days
The 16.7-day result is an illustrative energy estimate, not a guaranteed autonomy. Define exactly which depth-of-discharge, temperature, ageing and conversion factors are already included in the assumed 50% usable energy, so they are not counted twice. Account for the measured duty cycle, radio peaks and required protection function. Evaluate solar using worst-season sun, orientation, shading and system efficiency.
Duty cycling can reduce demand, but only if the sensor startup time, warm-up, measurement validity and alarm response still meet the process requirement. “Sleep” is not a single number; ask what remains awake and how quickly a valid measurement is available.
Sampling, reporting and alarming should have different intervals
A tank that fills in two hours needs a different strategy from a tank whose inventory changes over two weeks. Use the fastest credible level change to set local sampling and protective functions. Use the business need to set routine reporting. Use exception rules to avoid waiting for the next scheduled packet when level crosses a threshold or changes unusually fast.
For example, a system might sample locally every minute, report a routine value every 30 minutes, transmit immediately on a high alarm, and store one-minute data after an event. This is an architecture pattern, not a universal recommendation; the actual intervals must follow the tank dynamics and energy budget.
Choose the network after checking the site, not the coverage map
Cellular, low-power wide-area and local radio options differ in coverage, power, payload, latency and operating model. Perform a site survey at the antenna location and consider a metal tank’s shielding. An antenna mounted inside a cabinet or below a steel roof may perform very differently from a handheld phone test nearby.
Design the data payload to carry tag, engineering unit, scaled value, timestamp, quality, battery state and diagnostic status. A bare floating-point level without units or quality creates problems when several tanks and gateways are integrated.
Define a stale-data rule for every consumer of the value. An inventory dashboard might mark data uncertain after two missed reporting intervals, while a dispatch calculation may stop using it immediately. Show “last received” and “measured at” separately when buffering is possible. On recovery, reconcile the local clock and reject impossible timestamps before the data enters trends or invoices.
Test loss of communications during commissioning. Remove or shield the link only through an approved test method, generate a local threshold event, restore the link and verify event time, quality, ordering and duplicate handling. A telemetry demonstration on a healthy office network does not test this behavior.
Remote does not mean maintenance-free
Plan antenna inspection, desiccant or enclosure checks where applicable, battery replacement, solar-panel cleaning, firmware and credential management, and periodic comparison against an independent level reference. Remote diagnostics reduce travel only when they distinguish product problems from sensor, power and communications problems.
Secure remote access with unique credentials, controlled roles, encrypted transport where supported, signed or trusted update processes and an auditable change log. Do not expose an instrument directly to the public internet merely to make commissioning easier.
Questions from distributed-tank projects
Q1. Can radar run directly from a small battery for years?
Only after a complete power and duty-cycle calculation. Sensor average power, startup, radio peaks, temperature and battery aging decide the result.
Q2. What happens to alarms when the server is offline?
The design must state this explicitly. Immediate protective action should not depend on a cloud dashboard unless the safety analysis has accepted that architecture.
Q3. How often should inventory data be sent?
As often as the operating decision requires and the energy/network budget supports. Separate that from local sampling and protection.
Q4. What belongs in the RFQ?
Tank map, product and measurement range, fill rates, alarm response, power availability, worst-season environment, network survey, reporting interval, buffer requirement and integration protocol.
