A solar panel for a cellular IoT device should be selected from measured device behaviour, including communication activity. A brief data transmission can involve network attachment, listening, retries and other work beyond sending the payload. The energy result depends on the device, firmware, network and deployment.
We recommend separating the communication requirement from the solar requirement before joining them into a complete design. This prevents a panel chosen from a modem’s headline low-power figure from becoming the limiting part of a field product.
Write the reporting requirement as a use case
Define what data must arrive, how often it is needed and how much delay is acceptable. Distinguish routine reporting from alarms, commissioning, firmware updates and diagnostic sessions. An alarm policy that repeatedly retries during poor coverage may create a different energy demand from normal operation.
Describe behaviour when the server is unavailable or a connection cannot be established. Decide whether data is buffered, retried or discarded, and who approves that choice. These are product requirements rather than details that should be left until battery life is tested.
Measure a complete operating cycle
Capture sleep, sensing, processing, network activity and return to the intended idle state. Include the charging electronics and other always-on components. Check both the energy consumed over time and the ability of the supply to support short demand peaks.
A modem evaluation board can support early research, but its measured behaviour may differ from the final device. Test the chosen module, firmware and network configuration. The GSMA guidance on Mobile IoT energy efficiency identifies network parameters and measurement scenarios as relevant to LTE-M and NB-IoT outcomes.
Include coverage and connection failures
Define representative and difficult coverage conditions for the planned market. Test where the product will operate, including the final enclosure and antenna placement. A strong signal on an open bench does not characterize a remote installation.
Record the energy consequences of the retry policy, loss of service and reconnection. Do not promise a fixed reporting interval and fixed autonomy without defining the conditions under which both are expected to be maintained.
Select storage for energy and power delivery
The storage system has two related jobs: supporting operation between useful-light periods and supplying the device’s instantaneous demand within its permitted voltage range. A capacity value alone does not confirm both.
Review chemistry, temperature, charging limits, protection, ageing assumptions and the supply path with the electronics designer. Avoid treating a larger battery as a universal solution; the panel and charging system must also be able to recover the required reserve.
Turn the installation into a solar input scenario
Describe the available panel area, mounting direction, season, nearby shade and enclosure obstructions. Decide what happens during the longest expected period with little useful solar input. The system may need to defer nonessential work while preserving its required core function.
Use our IoT panel-sizing workflow to connect the measured load with realistic energy input. Keep each assumption visible rather than hiding every uncertainty inside a single design-margin percentage.
Test recovery as well as normal operation
A prototype should demonstrate that it can resume an approved operating mode after low energy and restore reserve when useful light returns. Test the interaction among charger startup, storage voltage, modem activity and firmware restart behaviour.
Watch for repeated startup attempts that consume energy without completing a connection. The appropriate response depends on the device; changes to retry timing or operating modes should be assessed against data-delivery requirements.
A field-trial record worth keeping
- Device, modem and firmware revisions.
- Network and deployment location characteristics.
- Reporting, retry and diagnostic activity.
- Panel position and useful-light conditions.
- Device energy and storage-voltage trends.
- Missed reports, resets and recovery events.
- Changes made during the trial and their effect on the required service.
Review energy performance alongside communication success. A device that preserves its battery by failing to deliver required information has not met the product brief.
Explore our custom modules for compact electronics. Share the enclosure area, measured operating cycle and deployment assumptions so we can review the solar module interface with your product team.
