Cold-Soak Battery Characterization Rig

The battery bay on the quadcopter frame gets the full treatment: Kapton heater pads bonded flat against the bay walls with polyimide tape, a logic-level N-MOSFET switching the pads on the low side, and foam insulation wrapped around the whole bay. The insulation is not there to keep the pack warm for free, it is there to make the heat budget measurable, so watts in maps predictably to degrees gained instead of leaking into the freezer.

Safety and failure behaviour are designed in, not added on: a fuse within centimetres of the pack lead, and a gate pull-down so the heater is physically off until software says otherwise. If the Pi crashes mid-run, the rig defaults to a cold, passive pack, never to a runaway heater in an insulated box.

HEATER DRIVER WIRING, LOGIC-LEVEL N-MOSFET

N-MOSFET with Rds(on) specified at Vgs = 2.5 V (3.3 V GPIO drive)
  Gate   -> GPIO17 (Pi pin 11) via 100 ohm series resistor
  Gate   -> 10 kohm pull-down to GND   (fails OFF at boot)
  Drain  -> Kapton pads (-)
  Source -> GND (common with Pi ground)
Kapton pads (+) -> 4S pack (+) via 5 A fuse
Heater feed measured by INA228 #2 on the high side

Why not the classic IRLZ44N: its Vgs(th) of 1-2 V is only the onset of conduction, not proof of low-resistance enhancement at 3.3 V GPIO; its datasheet Rds(on) is specified at 4 V and 10 V gate drive. This rig needs a MOSFET whose datasheet table explicitly lists Rds(on) at 2.5 V Vgs, or a proper gate driver, otherwise the heater current runs through a half-on MOSFET.

What can go wrong: bonding pads before testing them is the classic mistake, I bench-ran each pad through the MOSFET first and checked for even heating by hand (and against the Fluke's thermocouple) before anything got taped down permanently.

Six DS18B20 sensors go where the physics actually happens: taped to the cell surface, on the bay wall, directly on the heater pad, in ambient air inside the freezer, plus two spares for cross-checking. All six share one 1-Wire bus on GPIO4 with a single 4.7 kΩ pull-up, in powered 3-wire mode, parasite power over long freezer leads is asking for dropouts.

The Pi reads them through the kernel's w1-therm driver, which exposes each probe as a file under /sys/bus/w1/devices/. Reading a sensor is literally cat-ing a file, no libraries, no daemons, and nothing to debug at -30 °C. Know the accuracy bands from the datasheet: the DS18B20's ±0.5 °C figure applies only from -10 to +85 °C; from -30 to +100 °C it is ±1 °C, and across the full -55 to +125 °C range it is ±2 °C. The ±0.5 °C soak-stability band at -20 or -30 °C is therefore a repeatability and stability requirement, not uncalibrated absolute accuracy, and cold-setpoint runs need calibration against a reference at the soak temperature.

ENABLE 1-WIRE, /boot/firmware/config.txt

dtoverlay=w1-gpio,gpiopin=4

VERIFY ALL SIX PROBES ENUMERATE AND READ

$ sudo modprobe w1-gpio && sudo modprobe w1-therm
$ ls /sys/bus/w1/devices/
28-00000a4f11c3  28-00000a51e907  28-00000b02d44a
28-00000b7c31e8  28-00000c19f0b2  28-00000c52aa61
w1_bus_master1
$ cat /sys/bus/w1/devices/28-00000a4f11c3/temperature
21375

How I verified: each sensor got a warm finger while watching its file, that maps serial number to physical position, and the mapping is written into the logger config. A sensor stuck at exactly 85.000 °C is the DS18B20's power-on default and means the last conversion failed, i.e. a wiring problem, not a coincidence.

Two INA228 power monitors do the electrical accounting. One sits in series between the pack and the discharge load and logs bus voltage, shunt current, and accumulated charge; the second sits in the heater feed, so the energy spent on heating is costed separately from the energy delivered to the load. That separation is what makes the heater-strategy comparison in step 09 honest instead of hand-wavy.

Both chips share the Pi's I2C1 bus, so the second one needs its address moved off the 0x40 default by tying A0 to VS+ (0x41), which matches the INA228 datasheet's address-strapping table (A0 at VS+ with A1 at ground selects 0x41). The INA228 monitors bus voltage through 85 V with a 20-bit delta-sigma ADC, specified at ±1 µV maximum offset and ±0.05% maximum gain error; those figures only hold with a real shunt calibration, so the shunt value and maximum expected current are written to the calibration register, not left at defaults.

CONFIRM BOTH CHIPS ON THE BUS

$ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
40: 40 41 -- -- -- -- -- -- -- -- -- -- -- -- -- --

INA228 INIT + CALIBRATION (PYTHON / smbus2)

from smbus2 import SMBus

ADDR    = 0x40        # discharge monitor; heater monitor is 0x41
R_SHUNT = 0.002       # 2 mOhm shunt on the breakout board
I_MAX   = 25.0        # worst-case expected current, A
CURRENT_LSB = I_MAX / 2**19

bus = SMBus(1)

def wr16(reg, val):
    bus.write_i2c_block_data(ADDR, reg, [(val >> 8) & 0xFF, val & 0xFF])

# ADC_CONFIG (0x01): continuous shunt+bus, 4.12 ms conversions, 16x averaging
wr16(0x01, (0xF << 12) | (0x7 << 9) | (0x7 << 6) | (0x7 << 3) | 0x2)
# SHUNT_CAL (0x02) = 13107.2e6 * CURRENT_LSB * R_SHUNT   (ADCRANGE = 0)
wr16(0x02, int(13107.2e6 * CURRENT_LSB * R_SHUNT) & 0x7FFF)

How I verified: the Fluke went in series with the load for a full discharge at room temperature; the INA228's current track had to agree before any cold data counted. What can go wrong: a swapped shunt sense lead gives perfectly smooth negative current readings, plausible-looking garbage, which is worse than no data.

The logger is a small Python service on the Pi: each sensor sweep reads all six w1-therm files and both INA228s, integrates current into accumulated mAh, and appends one timestamped row to the run's CSV on the Pi's NVMe drive. One flat CSV per run, one schema for the whole dataset, no database, because a dataset people can open in anything is a dataset people actually check. A full sweep lands about once every few seconds: the DS18B20 needs up to 750 ms per conversion at 12-bit resolution, so six sequential reads through the kernel driver cannot sustain a true 1 Hz cadence, and the logger does not pretend otherwise.

It runs under systemd with Restart=always, because freezer sessions are long and unattended: if the process dies at hour two of a soak, it comes back and keeps appending to the same run file instead of silently losing the night.

CSV SCHEMA, ONE ROW PER SENSOR SWEEP, ONE FILE PER RUN

timestamp,setpoint_c,strategy,v_pack,a_discharge,mah_discharge,v_heater,a_heater,mah_heater,t_cell,t_bay,t_pad,t_ambient,run_id
2026-09-14T21:03:12-04:00,-20,thermostat,16.71,4.02,3.4,16.68,1.21,0.9,-19.8,-18.2,-12.5,-20.1,run-014

/etc/systemd/system/coldsoak-logger.service

[Unit]
Description=Cold-soak battery logger
After=network.target

[Service]
ExecStart=/usr/bin/python3 /home/taki/coldsoak/logger.py --out /data/coldsoak
WorkingDirectory=/home/taki/coldsoak
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

$ sudo systemctl enable --now coldsoak-logger
$ journalctl -u coldsoak-logger -f

How I verified: I killed the process mid-run on purpose (sudo kill -9) and confirmed the service restarted and resumed appending without corrupting the header or duplicating rows. One edge remains: a kill landing mid-write can leave a torn final row, so downstream parsing must reject any row that does not parse to the full schema. What can go wrong: logging to the SD card instead of NVMe fills or wears the card during multi-hour runs, the dataset lives on the NVMe from day one.

The thermostat strategy is a hysteresis (bang-bang) controller: heat on when the pad sensor falls below the band, off when it rises above it. Hysteresis instead of a single threshold keeps the MOSFET from chattering at the boundary, which both wears nothing mechanical but does pollute the current trace with switching noise the INA228 then has to average out.

Two independent protections sit outside the strategy logic: a hard cutoff that forces the heater off if the cell sensor ever exceeds a safe limit, and a watchdog that cuts heat if sensor reads go stale, a crashed loop must equal a cold heater, matching the hardware fails-off from step 01.

HYSTERESIS THERMOSTAT LOOP (gpiozero)

from gpiozero import OutputDevice
import time

heater = OutputDevice(17, active_high=True, initial_value=False)
SETPOINT, HYST = 15.0, 1.5     # pad temperature band, deg C
CELL_HARD_LIMIT = 45.0         # cell surface hard cutoff, deg C
SENSOR_MIN, SENSOR_MAX = -55.0, 125.0   # DS18B20 valid range
MAX_STALE_S = 10.0             # a sensor that stops updating is a failed sensor

def reading_ok(t, ts):
    if t is None or ts is None:
        return False
    if time.time() - ts > MAX_STALE_S:
        return False           # stale: the sensor is not updating
    if abs(t - 85.0) < 0.001:
        return False           # DS18B20 power-on default: the last conversion failed
    return SENSOR_MIN <= t <= SENSOR_MAX

def control(t_pad, ts_pad, t_cell, ts_cell):
    if not reading_ok(t_cell, ts_cell) or t_cell > CELL_HARD_LIMIT:
        heater.off()           # stale, invalid, or hot: always off
    elif not reading_ok(t_pad, ts_pad):
        heater.off()           # no valid pad reading: always off
    elif t_pad < SETPOINT - HYST:
        heater.on()
    elif t_pad > SETPOINT + HYST:
        heater.off()

How I verified: the loop was exercised with the pad sensor in ice water and then under a hair dryer, watching the GPIO state flip at both band edges, no battery involved. What can go wrong: the pad sensor responds faster than the cell surface, so a naive setpoint on the pad overshoots the cell temperature; that is exactly why the hard limit reads the cell, not the pad.

Every comparison in the dataset is only meaningful if the load is identical across runs, so the pack discharges through a fixed resistive bank sized for roughly three-quarter-C draw on the 5200 mAh drone packs (~4 A), close to a cruise-level pull rather than a full-throttle burst. The bank is series-wired chassis-mount power resistors bolted to a heatsink, and it lives outside the insulated bay: a 60-watt heater inside the bay would be the single best way to destroy the dataset's credibility.

LOAD SIZING (4S PACK, ~4 A NOMINAL, NOT CONSTANT CURRENT)

Target draw: ~0.77C on the 4S 5200 mAh packs (three-quarter C) -> ~4 A nominal
R = V / I = 16.0 V / 4.0 A = 4 ohm
P = V * I = 16.0 V * 4.0 A = 64 W
Build: 4x 1 ohm 25 W chassis-mount resistors in series (100 W total rating)
       bolted to a finned heatsink, mounted outside the bay
Reality: a resistor is not a constant-current load; current falls with pack
       voltage, about 4.2 A at 16.8 V down to 3.2 A at the 12.8 V cutoff.
       Watt-hours is therefore the comparison metric across runs, not amps.
Cutoff: logger flags pack <= 12.8 V (3.2 V/cell), and an independent
       hardware undervoltage disconnect on the load backs the flag, a
       software flag alone is not a cutoff

How I verified: before trusting the INA228 at all, the actual draw went through the Fluke in series at room temperature, measured current has to match the design math within tolerance or the resistor bank gets re-checked. What can go wrong: resistor values drift when hot; the bank is rated 100 W against 64 W dissipated, but power-resistor ratings assume a proper heatsink, so the bank is bolted to one and gets a warm-up settle before logging starts, so early-run current matches late-run current.

Each run soaks a fully charged pack in the freezer at a fixed setpoint, 0, -10, -20, -30 °C, and waits until the cell-surface sensor (not the freezer's air, not the freezer's own display) has held within half a degree of the target for fifteen consecutive minutes. That half-degree band is a stability and repeatability criterion, not a claim of uncalibrated absolute accuracy at -30 °C (see the DS18B20 accuracy bands in step 02); it is enforced with cold-reference calibration, not assumed from the datasheet. The core temperature is what the chemistry feels; air temperature in a frost-free freezer swings several degrees with the defrost cycle, which is precisely why the freezer's thermostat is never part of the criterion.

Only then does the load connect, and the logger captures the full discharge: initial voltage sag under load, any recovery as the discharge self-heats the cell, runtime to the 12.8 V cutoff, and how the cutoff behaves, a graceful knee or a hard cliff.

SOAK CRITERION CHECK (runs on the Pi, watches the cell sensor)

#!/usr/bin/env bash
# Soak = cell sensor within +/-0.5 C of setpoint for 15 straight minutes
CELL=/sys/bus/w1/devices/28-00000a4f11c3/temperature
TARGET=-20; TOL=0.5; HOLD=900; STABLE=0
while :; do
  T=$(awk '{print $1/1000}' "$CELL")
  OK=$(awk -v t="$T" -v g="$TARGET" -v e="$TOL" \
       'BEGIN{print (t > g-e && t < g+e) ? 1 : 0}')
  [ "$OK" = 1 ] && STABLE=$((STABLE+10)) || STABLE=0
  [ "$STABLE" -ge "$HOLD" ] && { echo "soaked at $T C - connect load"; break; }
  sleep 10
done

What can go wrong: trusting the freezer's front-panel display, mine reads several degrees off the air sensor at the cold end, and the defrost cycle can break a "stable" soak mid-hold. The script above resets the stability timer on any excursion, so a marginal soak simply takes longer instead of quietly passing.

The freezer is a controlled stand-in, not the real thing. The same protocol repeats outdoors through a Toronto winter, porch and balcony runs at whatever the weather delivers, to validate the freezer data against reality and to catch what a chest freezer physically cannot: wind stripping heat from the insulation, humidity and snow on the connectors, and the slow radiative chill of a clear night.

Every outdoor run gets tagged with observed weather at run start, pulled from Open-Meteo (no API key needed) and stored next to the CSV, so a windier -15 °C night is never averaged blindly against a calm one.

TAG EACH OUTDOOR RUN WITH REAL WEATHER (OPEN-METEO, NORTH YORK)

$ curl -s "https://api.open-meteo.com/v1/forecast?latitude=43.77&longitude=-79.41&current=temperature_2m,relative_humidity_2m,wind_speed_10m,wind_gusts_10m" \
    | tee /data/coldsoak/run-021.weather.json

How I will verify: each outdoor run is matched against its nearest freezer setpoint curve, agreement within the run-to-run spread validates the freezer as a proxy; systematic divergence (for example, only on windy nights) becomes its own finding in the dataset. What can go wrong: melted snow wicking into sensor joints, outdoor harness joints get heat shrink and dielectric grease before the first snow run.

Three strategies run at every setpoint, three repeats each: unheated (the baseline), thermostat-controlled (the step-05 loop holds the bay through the soak and discharge), and pre-heat-and-fly (heat on the ground, disconnect the heater, then discharge on stored warmth, the way a real drone actually launches). The matrix lives in a config file so the runs are driven by data, not by memory.

The point is honest energy accounting: the heater-branch INA228 measures exactly how many mAh heating consumed, so each strategy is scored on net recovered capacity, capacity gained back from the cold minus capacity spent on heat. A heater that recovers 20% capacity but costs 25% is a worse battery, and the dataset should be allowed to say so.

RUN MATRIX, matrix.yaml

setpoints_c: [0, -10, -20, -30]
strategies: [unheated, thermostat, preheat]
repeats: 3
cutoff_v: 12.8          # 3.2 V/cell on the 4S packs
load_a: 4.0             # fixed resistive bank from step 06
thermostat:
  setpoint_c: 15.0
  hysteresis_c: 1.5
preheat:
  ground_minutes: 20
  disconnect_before_discharge: true

How I verify the accounting: after every run the pack is recharged on the balance charger, and the charger's returned mAh is cross-checked against the INA228's discharged mAh, the two should bracket the same number, and a growing gap between them flags a sick pack before it contaminates the matrix.

The end product is the dataset itself: per-run CSVs, the weather tags, the run matrix, the plotting code, and the written protocol, setpoints, soak criterion, load sizing, sensor placement, and safety rules, so anyone with a freezer and fifty dollars of sensors can reproduce or extend it. Every published figure regenerates from the raw CSVs with one script; there are no hand-edited plots, because a reviewer should be able to recompute every line on every graph.

PLOT ONE RUN (pandas + matplotlib)

import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv("run-014.csv", parse_dates=["timestamp"])

fig, ax1 = plt.subplots()
ax1.plot(df["timestamp"], df["v_pack"], label="pack V")
ax1.set_ylabel("pack voltage (V)")

ax2 = ax1.twinx()
ax2.plot(df["timestamp"], df["t_cell"], color="orange", label="cell C")
ax2.set_ylabel("cell temperature (deg C)")

fig.tight_layout()
fig.savefig("run-014.png")

How I will verify before publishing: a clean-checkout test, clone the dataset repo into a fresh directory, run the plot script, and diff the regenerated figures against the published ones. If the numbers in the write-up do not fall out of the CSVs untouched, the write-up gets fixed, not the data.