Two bytes every ten minutes on the tea estate
A weather station on a tea estate records two values every ten minutes and stores them in a 64 KB EEPROM chip: air temperature in whole degrees Celsius, which ranges from -20 degrees Celsius to +45 degrees Celsius and is held as an 8-bit two's complement integer, and relative humidity from 0 to 100 per cent, held as an 8-bit unsigned integer. A laptop downloads the whole chip once every 30 days, after which the chip is erased. A technician proposes storing temperature instead as an unsigned value equal to the temperature plus 50, arguing that unsigned bytes are simpler to handle. Last week a badly repaired humidity sensor reported 130 per cent, and at the same moment the estate manager saw a large negative number where the temperature should have been. She wants to know whether the chip is large enough for a full month and whether the technician's change should be approved.
1. Show, with working, whether the 64 KB EEPROM can hold 30 days of readings. State your assumptions and comment on whether capacity is the real constraint.
Read the worked answer
Every ten minutes means six readings per hour, so 6 x 24 = 144 readings per day. Each reading is two bytes (one for temperature, one for humidity), giving 288 bytes per day. Over 30 days that is 288 x 30 = 8 640 bytes.
Taking 1 KB as 1 024 bytes, 64 KB is 65 536 bytes, so the logger would use 8 640 / 65 536, about 13 per cent of the chip. Even if the supplier means 64 000 bytes, the conclusion is unchanged. Capacity is therefore not the constraint, and the technician's argument cannot be justified on storage grounds.
The real risk is the 30-day download interval: if the chip fails, or the laptop visit is missed, a month of records is lost with no second copy. A better judgement call is to keep the byte layout and shorten the interval, or to add a second store, rather than to compress two bytes into one.
2. Compare the two temperature encodings. Give the stored byte for -20 degrees Celsius and for +45 degrees Celsius under each scheme, and state one situation in which the technician's scheme misbehaves.
Read the worked answer
In 8-bit two's complement, +45 is 0010 1101 (2D in hexadecimal). For -20, take +20 = 0001 0100, invert to 1110 1011, add 1 to get 1110 1100 (EC). Both values sit comfortably inside the -128 to +127 range, so the full stated range from -20 to +45 is representable, and negation, addition and comparison work directly in the processor.
In the technician's biased scheme, add 50 and store unsigned: -20 becomes 30 = 0001 1110 (1E) and +45 becomes 95 = 0101 1111 (5F). It also fits the stated range, so the scheme is not wrong on today's data; it is wrong at the edges. The byte can hold 0 to 255, so it represents only -50 to +205. A sensor taken below -50, for example into a cold store, wraps to a large positive value, and the same happens above +205. It also means every calculation in software has to subtract 50 first, and a programmer who forgets produces silent errors.
Recommendation: keep two's complement. Neither scheme gives 0.1 degree resolution, which would need 16 bits for this range.
3. Explain how a humidity reading of 130 per cent produced a large negative number, and recommend how the software should handle out-of-range readings.
Read the worked answer
130 in binary is 1000 0010. Read as an unsigned value it is 130; read as an 8-bit two's complement value the leading 1 means negative, and the value is 130 - 256 = -126. The bits were stored correctly, but the laptop program printed that byte using the signed routine it was already using for temperature. That explains a large negative number appearing at exactly the moment the humidity sensor misbehaved: the fault was in the sensor, and the misdisplay was a separate data-type error in the software.
The handling should be defensive. First, validate on read: humidity outside 0 to 100 is impossible, so the value should be flagged as an error and logged rather than plotted. Second, keep the error flag in the record, for example the top bit as a validity marker, since humidity needs only seven bits for 0 to 100 and the eighth bit is spare. Third, tell the operator, because a sensor reading 130 per cent is a maintenance problem, not a data-entry problem. Silently clamping to 100 would hide a broken sensor and corrupt the estate's records.