Warping Time

During my measurements, I read off the battery discharge values at irregular intervals that do not coincide for the two memory chips. To juxtapose the two discharge curves for a direct comparison, the data-normalize script (Listing 1) pushes the times onto a common time axis. Both sets of measurements then start at a virtual hour 0.

Starting with absolute points in time, the script calculates relative times by subtracting the virtual starting time.

For example, if the first set includes measurements at 8:00 and 9:00 and the second set has values for 11:00 and 11:30, the shared virtual time axis would start at 0:00 and include a second data point for set 2 at 0:30 and for set 1 at 1:00.

To do so, the data-normalize script uses the $data structure, which contains a reference to a hash with keys "2gb" and "0.5gb", each referencing an array containing points with pairs of time and battery capacity.

Normalize Between 2 and 98

The goal of this approach is to start the two graphs at a common point and normalize both the time values on the X axis and the measured battery capacity values on the Y axis within an integer range of 0 through 100, as the Chart service expects of the data.

The script uses the CPAN DateTime module for these calculations and sets the time of the first, randomly selected, series of measurements as the starting point of the common time axis as $day_start. It stores the time of the current measurement as $time_current, whereas the day on which the last measurement was performed is stored as $day_current.

If the script finds out that a day has passed between two measurements (for example if a measurement at 23:00 is followed by a measurement at 8:00), lines 65 and 67 add a day to the counters. Lines 74 to 77 ascertain the number of minutes since the last measurement and stores the value in the variable $x (for X axis values), where it is picked up in line 80 and dumped into the @results array, along with the name of the set of measurements and the current battery value.

Lines 85 and 91 keep the highest X and Y values and stores them in the $max->{x} and $max->{y} hash entries, respectively. They are used later in the for loop in lines 98ff. to normalize all the X/Y values within a range of 0 to 100. Additionally, the $margin variable creates a margin with a width of 2 on the right and left before data-normalize finally normalizes the X/Y values within a range of 2 and 98. The reason for this becomes apparent in the chart later on; it just looks better if the graphs don't touch the horizontal and vertical axes. The print statement in line 101 sends the results to STDOUT (Figure 5).

Type XY

While looking for a suitable chart format, I found the "lxy" type [3], which expects a set of X and Y coordinates for any drawn line. This makes it fundamentally different from other formats, which assume that the measured values are on the same X coordinates for any records they visualize. Line 26 in graph-discharge thus defines 'XY' for the type option in the constructor call for a new Google::Chart type object.

Listing 2 first reads the output from the data-normalize script (line 10) and sorts the X and Y values into the $data structure. At the end of the while loop in line 21, $data->{"0.5gb"}->{x} contains all the normalized time stamps for the 512MB configuration, and $data->{"0.5gb"}->{y} is an array of the corresponding battery states. This makes it easy to pass a pointer to an array of X/Y records to the Google::Chart object's data parameter in line 28, just as the XY chart type expects.

The size parameter (line 35) sets the dimensions of the chart: 750 by 400 is about the maximum; if you try for larger dimensions, Google objects and returns a "Bad Request" message.

The chart title, which is displayed at the top of the chart, is set by the title option in line 39.