The calculator estimates total update duration by summing each step, then adding expected retry time and a contingency buffer. Network throughput is adjusted for overhead, utilization, and contention.
| Component | Formula |
|---|---|
| Effective throughput | eff_Mbps = rate_Mbps × (1 − overhead%) × utilization% × (1 − contention%) |
| Download time | download_sec = (size_MB × 8) ÷ eff_Mbps |
| Write time | write_sec = size_MB ÷ write_speed_MBps |
| Base per-device | base_sec = pre + download + write + verify + reboot + post |
| Expected retries | expected_multiplier = 1 + retry_prob% × retry_penalty% |
| Per-device total | per_device = base_sec × expected_multiplier × (1 + buffer%) |
| Batch total | batch = waves × per_device + (waves − 1) × transition_sec |
Tip: If you want a conservative plan, increase contention, retry probability, or contingency buffer.
- Enter firmware size and the realistic site link rate.
- Set overhead, utilization, and contention to match your network.
- Enter device write speed and check/reboot timings from test runs.
- Choose device count and how many can update in parallel.
- Add retry probability and a buffer to match field conditions.
- Submit to see per-device and batch time with step breakdown.
- Use CSV/PDF export for reports and schedule approvals.
Sample planning scenarios for construction site controllers, sensors, and gateways.
| Firmware size | Link rate | Overhead | Write speed | Devices | Parallel | Estimated batch time |
|---|---|---|---|---|---|---|
| 180 MB | 20 Mbps | 12% | 8 MB/s | 12 | 3 | ~01:02:00 |
| 350 MB | 50 Mbps | 10% | 12 MB/s | 24 | 6 | ~01:05:00 |
| 0.9 GB | 75 Mbps | 15% | 10 MB/s | 40 | 8 | ~02:10:00 |
| 1.6 GB | 100 Mbps | 18% | 18 MB/s | 60 | 10 | ~03:20:00 |
| 500 MB | 12 MB/s | 10% | 9 MB/s | 30 | 5 | ~01:55:00 |
These values are illustrative. Always validate with a small pilot group.
Update Window Planning for Active Sites
Firmware work on active construction sites must respect safety briefings, access control, and shift changes. Use the batch total to reserve a protected window, then add a documented hold point for rollback. For night work, reduce utilization because shared backhaul can spike after hours. Record start time, wave count, and expected finish so supervisors align inspections, permits, and temporary closures. Notify stakeholders and lock affected zones.
Interpreting Effective Throughput
Link rate alone overstates delivery speed. The calculator reduces bandwidth using protocol overhead, realistic utilization, and site contention. Example: 50 Mbps with 10% overhead, 85% utilization, and 10% contention gives about 34.4 Mbps effective throughput. That value drives download time and often becomes the critical path when firmware is large and write speeds are strong. Capture packet loss and latency during each transfer window carefully.
Device Write and Verification Constraints
Gateways and controllers may write flash slower than they download. Enter a measured write speed from bench tests, not vendor peak numbers. Verification should include checksum validation, configuration preservation, and functional pings. If verification is 60 seconds and reboot is 120 seconds, small firmware files can still take minutes, so step timing matters for accurate manpower planning. Also budget time for device cooling and power checks.
Parallel Waves and Crew Productivity
Parallel updates limit how many devices can be handled at once without saturating the link or overloading operators. Waves equal devices divided by parallel capacity, rounded up. Add wave transition time for staging, labeling, and spot checks between groups. When increasing parallel updates, confirm switches, wireless, and VPN concentrators can sustain sessions without drops or rate limiting. Stagger start times to prevent shared link bursts today.
Risk Allowances and Change Control
Field conditions create retries from weak signal, power dips, or device lockups. The expected retry multiplier models this using a probability and a penalty percentage. Keep a contingency buffer for unexpected delays, then export the PDF for change records. After a pilot wave, update assumptions with measured throughput and real reboot times before scaling to full site deployment. Document pass/fail criteria before crews begin updates.
What inputs matter most for accurate update time?
Effective throughput and device write speed usually drive the estimate. Measure real link performance, then use observed write, verify, and reboot timings from a pilot run to avoid optimistic schedules.
How should I set protocol overhead and contention?
Use overhead for headers and control traffic, then set contention to reflect other site usage. If the link is shared with cameras, telemetry, or office Wi‑Fi, start with 10–20% contention and refine after testing.
Why is my batch time much larger than per-device time?
Batch time includes waves. If you can only update a limited number of devices in parallel, the calculator repeats the per-device total for each wave and adds wave transition time between waves.
How do retries affect the result?
Retry probability increases expected duration by applying a multiplier, and the retry penalty represents how much extra time a failed attempt adds. Use field history to set these, then keep a separate operational rollback plan.
When should I increase the contingency buffer?
Increase it for remote sites, unstable power, wireless links, or unknown device health. A larger buffer also helps when approvals require conservative scheduling, especially during night work or short shutdown windows.
Can I use this for mixed device types?
Yes. Run separate scenarios for each device class using its firmware size and timings, then add the batch totals. If updates are interdependent, schedule the slowest class first to protect the overall window.