## 4 Improvements to Reduce Power Consumption
The line-based 2D-DWT transform performs a 5-level dyadic decomposition by means of a convolution with an integer-based bi-orthogonal 5/3 filter bank. As explained in [15], the line-based 2D-DWT transform would require the storage of no more than \(2\cdot(2N+1)\cdot w\) 16 bit integers, where N is fixed by the filter length (Bi5/3 \(\xrightarrow{}\) N = 2) and \(w\) is the image line width. So, with the largest image size (\(640\times 480\)\(\xrightarrow{}\) w = 640), the required memory for line-based 2D-DWT would be 12,800 bytes (In [9], we propose a lifting line-based 2D-DWT algorithm, which would require near the half of memory than the convolution version. However, for coding simplicity we decide to use convolution version as enough memory is available). Both quantization and run-length encoding also demand some buffer storage to perform their duties. In particular, at each decomposition level we will require 4 rows of each subband (HL, LH, HH) to conform the encoder buffer, and this will sum up no more than \(2\cdot(4\cdot 3)\cdot w/2\)) integers (15,236 bytes for \(640\times 480\) image size). However, although the extra memory needed is affordable, the computational power required by this encoder (one of the lowest computational demanding wavelet encoders) surpasses by large the capacity of our CC1110F32 SoC system. To prove that, we implemented in our image sensor node the 1D-DWT transform (convolution approach) to get timing measures that allow us to estimate the time required to perform the full 5-level 2D-DWT wavelet decomposition. As it can be seen in Figure 9(b), the time required to perform the 2D-DWT transform is not shorter than 6 s for the lowest image resolution, being up to more than 500 s for the highest image size. Although the code may be optimized, the 2D-DWT complexity is unaffordable for CC1110F32 architecture. So, at the moment, the only improvement we may apply to our design is the faster SPI communication interface between sensor node and camera. For that purpose, the operating software was modified at the running mode stage (see Figure 4) in order to include SPI master-slave interface driver (simpler than the one we have coded for the asynchronous USART management) running with master clock rate set at 3 MHz. The basic operations of running mode will be the same with the exception of \"Get_Slice\", that now will be a faster operation due to SPI interface, and \"CAM_Connect\" that would not require the camera synchronization process being simpler and faster than the older one. Respect to the timing profile performed in Section 3.1, we would assume that basic operations will have the same timings with the exception of the ones that were modified: CAM_Connect and Get_Slice. The first one would be significantly shorter since synchronization is avoided thanks to the SPI synchronous interface. In particular, the sensor node requires an average of 25 SYNC command exchange through the USART interface to receive the ACK command that declares synchronized the connection, so we may estimate the timing of the new CAM_Connect operation by simply deducing the time wasted in synchronization (an average of 190 ms) from the timing obtained in Section 3.1 (218.2 ms, in average). The last modified operation, Get_Slice, is much faster than the one defined with the initial image sensor design, as downloading one slice of 240 bytes trough SPI connection interface will considerably reduce the overall transfer time, specially at the largest image sizes. In Figure 10(a), we show the new timing profile of the running mode stage, where basic operations CAM_Connect and T_Get_Slice are the only affected by the SPI camera improvements. As explained before, the rest of basic operations have the same timings than the ones obtained in Section 3.1. So, as  
Figure 9: DWT complexity using Bi9/7 and Bi5/3 filter banks: (**a**) 1D-DWT computing time, and (**b**) estimation of the 2D-DWT execution time (logscale).