Does a 30-Second Report Survive a Ten-Year Deployment?
Does a 30-Second Report Survive a Ten-Year Deployment?
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
Does a 30-Second Report Survive a Ten-Year Deployment?
A magnetic parking sensor reports occupancy every 30 seconds over LoRaWAN and is sized for “a typical 10-year deployment,” yet the chapter’s own budget — 2,880 uplinks a day at 40 mA for a second each — drains its 8,000 mAh pack in about 249 days. Those two facts are not at peace. This audit lines the achieved life up against the ten-year goal and asks what reporting interval the target really demands, and whether a bigger battery alone can ever close the gap.
Companion to the chapter Smart Cities — every number here comes from that chapter.
Use the displayed 30 s reporting interval, 40 mA for 1 s per uplink, and 8000 mAh battery as a fixed audit case; press Calculate.
Check yields 2880 uplinks daily and about 249 days of life, far short of the 10-year target.
Radio charge accumulates once per report, so meeting 10 years requires roughly 15x fewer scheduled transmissions, event-driven reporting, or harvested energy.
See the relationship before changing it
The figure reads from left to right. The blue input is report interval. The middle card names the page’s rule. The green output is ideal battery life. The arrow matters: change the input, apply the rule once, then read the result with its unit.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 30 s.
- 2
Name the relationship. life = 8000 mAh / ((86400/interval) x 40/3600 mAh + 0.12 mAh/day)
- 3
Substitute with units. 8000 / ((86400/30) x 40/3600 + 0.12) = 249 days
- 4
Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.
Predict, then change report interval
Try Predict how ideal battery life responds when report interval moves. Calculate report interval; compare ideal battery life with that prediction.
Observe Return to 30 s. Recheck ideal battery life with report interval at its chapter value.
Explain Longer gaps mean fewer radio bursts and more battery life.
Check yourself
What should you do before trusting a moved-slider result?
What does this small model leave out?
Technical boundaries
For the parking node, excluded from this fixed arithmetic are battery self-discharge, temperature, retransmissions, network outages, maintenance visits, or reporting-rate changes.
Ada: This section sizes a parking sensor for “a typical 10-year deployment,” then finds an 8,000 mAh pack lasts about 249 days. Those two facts are not at peace. Let me line the achieved life up against the stated goal and read off what the reporting interval would really have to be.
Start from the chapter’s own budget. Each uplink is 40 mA for 1 second, so 40 x 1 / 3600 = 0.0111 mAh, and 2,880 uplinks a day cost 2,880 x 0.0111 = 32.0 mAh. Sleep adds 0.005 x 24 = 0.12 mAh, for 32.0 + 0.12 = 32.12 mAh/day. That gives 8000 / 32.12 = 249 days — the section’s figure, confirmed.
Now invert it for the goal. Ten years is 10 x 365 = 3650 days, so the daily budget is 8000 / 3650 = 2.19 mAh. Take out the fixed 0.12 mAh of sleep and only 2.19 - 0.12 = 2.07 mAh is left for radio, which buys 2.07 / 0.0111 = 186 uplinks a day — an interval of 86400 / 186 = 465 seconds, about one report every 7.7 minutes. Against the design’s 30 seconds that is 2880 / 186 = 15.5x fewer transmissions.
Design meaning: the 30-second interval and the ten-year life are apart by more than an order of magnitude, so no larger battery closes the gap on its own — this node has to report roughly 15x less often, move to event-driven sends, or add energy harvesting, and the arithmetic names which lever and how far.
Every number above is taken from the chapter’s own material and re-derived step by step.