Packing Locker Telemetry for a Low-Data SIM Plan
A bike-share cooperative operates 2,400 lockers across three towns. Each locker reports every 5 minutes: a 12-bit locker ID (1–2400), battery voltage 0.0–5.0 V in 0.1 V steps, temperature −20 to +60 °C in 1 °C steps, a locked/unlocked flag and a 3-bit error code. The current uplink sends an ASCII CSV record such as ID=1234,V=4.2,T=23,L=1,E=0 followed by a newline, averaging 30 bytes. The mobile provider charges £0.90 per MB, and the cooperative’s newest SIM bundle is 500 MB per month across the whole fleet. Last month the bill was £612. The operations manager proposes dropping the temperature field to save data. A developer suggests packing every field into a fixed-length binary frame instead, keeping all readings and adding a 16-bit checksum. The lockers must run for 18 months on two AA cells, and the radio transmitter consumes 22 mA for 40 ms per message. Analyse whether binary packing is enough, and what representation choices should be made for temperature and voltage.
1. Calculate the payload size of the proposed binary frame and the monthly data volume for 2,400 lockers reporting every 5 minutes. State any padding assumptions, and compare the result with the current ASCII traffic and the 500 MB bundle.
Read the worked answer
Field sizes
- Locker ID: 12 bits because 2,400 is below 2^12 = 4,096.
- Voltage: 0.0 to 5.0 in 0.1 steps gives 51 possible values. 5 bits holds only 32 values, so 6 bits are needed (64 values). Store the voltage as an integer number of tenths, 0–50.
- Temperature: −20 to +60 in 1 °C steps gives 81 possible values. 6 bits holds 64, so 7 bits are needed. Use an offset of +20 and store 0–80, or use 7-bit two’s complement.
- Locked flag: 1 bit.
- Error code: 3 bits.
Data total = 12 + 6 + 7 + 1 + 3 = 29 bits. Adding the 16-bit checksum gives 45 bits. If the radio sends whole bytes, pad to 48 bits, so the frame is 6 bytes. If the designer byte-aligns each field first, the data still occupies 4 bytes and the checksum adds 2, so the result is also 6 bytes.
Monthly volume
Messages per locker per month = 12 per hour × 24 hours × 30 days = 8,640. Across 2,400 lockers = 20,736,000 messages.
Binary traffic = 20,736,000 × 6 = 124,416,000 bytes ≈ 124.4 MB per 30-day month. Current ASCII traffic = 20,736,000 × 30 = 622,080,000 bytes ≈ 622.1 MB.
At £0.90 per MB the simple ASCII payload would cost about £560, so the £612 bill implies roughly 680 MB including retransmissions or protocol overhead. Binary packing would be about 136 MB even with similar overhead, comfortably inside 500 MB. The proposal is therefore sufficient on capacity grounds.
2. The operations manager wants to remove the temperature field. Evaluate this proposal, including its effect on frame size, monthly cost and the lockers’ 18-month battery target.
Read the worked answer
Removing temperature reduces the data fields from 29 bits to 22 bits. With the 16-bit checksum the frame is 38 bits, padded to 40 bits, so it becomes 5 bytes instead of 6. The saving is 1 byte per message, or 20,736,000 bytes ≈ 20.7 MB per month. At £0.90 per MB that is about £18.70 per month if every megabyte is chargeable. That is a modest saving compared with the 124 MB binary frame, and if the fleet is already inside the 500 MB bundle the cash saving could be zero.
The battery argument is also weak. Each transmission uses 22 mA × 40 ms = 0.88 mA·s = 0.000244 mAh. Across 20,736,000 messages that is about 5,067 mAh per month for the fleet, or 2.11 mAh per locker per month. Over 18 months one locker uses about 38 mAh for radio transmissions. Even if a one-byte shorter frame reduced transmit energy by one sixth, the saving would be only about 6 mAh over 18 months, tiny against two AA cells. The fixed preamble and wake-up time probably dominate anyway.
Removing temperature loses useful diagnostics: overheating, charging faults and seasonal battery behaviour may be detected from temperature. A better judgement is to keep temperature, rely on binary packing for the large saving, and reduce cost further by exception reporting or less frequent reporting for stable lockers if necessary.
3. Explain why a fixed-length frame plus checksum is suitable for this radio link, and identify one failure mode of using offset binary for temperature that the developers must guard against.
Read the worked answer
A fixed-length frame lets the receiver read fields at known bit offsets without searching for commas or newlines. That is useful on a lossy radio link: a truncated ASCII record can swallow the next record, while a 6-byte binary frame can be rejected if it is short or if the checksum fails. Fixed length also makes buffer allocation and airtime predictable, which matters for battery life.
The checksum detects corrupted bits caused by interference. A 16-bit checksum is reasonable for accidental errors, although a CRC-16 is stronger than a simple sum. It does not provide security: an attacker could alter the frame and recompute the checksum. If command frames are ever accepted, message authentication is needed.
Offset binary creates a specific risk: if the sensor reports below −20 °C, the offset value becomes negative. If the code stores it in an unsigned 7-bit field without checking, −25 °C becomes −5 + 20, which may wrap to a large positive value. A receiver could then display a dangerous high temperature instead of an out-of-range low reading. The firmware must range-check, clamp or send a sentinel value, and the protocol document must state the offset unambiguously.