# Accurate Energy Consumption Modeling of IEEE 802.15.4e TSCH Using Dual-Band OpenMote Hardware
## 4 Measurements
### Time Slot State Durations  
We measured the duration of each state in every time slot where the CPU is active. The durations in which the CPU is sleeping can then be trivially calculated, using the active durations and the timing constants found in OpenWSN firmware. The total length of a time slot was set to 15 ms. The state durations for all time slots are shown in Tables 8-14. States do not always have the exact same duration for a variety of reasons. There can be multiple code branches (i.e., different execution paths); the packet size can vary and have an influence; or the duration of an operation can simply be variable (e.g., waking up the CC1200 chip). Therefore, multiple measurements were executed to find a single duration that could be associated with the state. Changing the mode of the CC1200 radio from Sleep to Idle takes between 246 us and 343 us, which causes every state where the radio wakes up to have a variable duration. It only required a few measurements to find that the median for waking up is 268 us. However, we decided to use the average value instead of the median because it resulted in a slightly more accurate energy consumption prediction. To avoid being susceptible to outliers, the wakeup time was measured over ten thousand times, and an average duration of 273 us was observed. Figure 5: Energy consumption measurement setups: for the 2.4 GHz measurements, only the OpenMote-CC2538 was used, while for the 868 GHz measurements, the power analyzer was connected to the OpenUSB to which the OpenMote-CC2538 was attached. (**a**) 2.4 GHz measurement setup; (**b**) 868 MHz measurement setup. For states with multiple code branches, the median value of multiple measurements was chosen. For example, in state TxDataOffsetStart, an Enhanced Beacon (EB) might be sent if and only if there are no data to send. Another example is state TxProc in which the execution path is different when a data packet has no retries left. However, these small variations of the duration only have a limited impact on the total slot consumption. The durations of states where packets are loaded to and read from the radio were measured before and after the radio was accessed. Afterwards, the communication with the radio for different packet sizes (from 0 bytes-125 bytes with steps of 25 bytes) was measured. Linear interpolation was applied on the measured durations to come up with a formula that fits well to all packet sizes. The difference in durations in states where data are transferred between the radio and CPU (e.g., TxDataPrepare and TxProc) is caused by the way these bytes are transferred: the CC2538 radio is combined with the CPU in one chip, so data can just be copied in/out of memory while the CC1200 needs to use the slower Serial Peripheral Interface (SPI) to transfer data to and from the CPU in the CC2538 chip, resulting in longer durations. The duration of transmitting and receiving also depends on the packet size. Since the radio has a baud rate of 250 kbps, the time it takes to transmit one bit is 4 us, which makes the time to transmit a byte 32 us. To calculate the duration, the amount of transmitted bytes had to be multiplied with 32 us. The PHY header byte and two-byte Cyclic Redundancy Check (CRC) also have to be included as they are sent with the packet. To verify that this calculation is valid, the time between the start-of-frame interrupt and the end-of-frame interrupt was measured: the average error was only 0.13%. To model the guard time, we assumed that the clocks are synchronized. Our model thus assumes that the packet always arrives exactly in the center of the guard interval.