Logging Current Meter

RC Logging Current Meter

A 150 A / 60 V inline power meter and datalogger for RC ESC test benches, a WM150-class meter with live logging, a graphing touchscreen, and thermistor plus ESC-signal channels.

Status: Rev A built, assembled and brought up (2026-08-25). Display, capacitive touch, all four analog channels, backlight and the ESC output all work. Voltage and thermistor are calibrated. Two known Rev A faults: the buttons are dead (footprint pad mapping) and JP1 ships open. See "Known open items". Bring-up firmware is in firmware/.

What it does

Read the accuracy budget in DESIGN.md §5 before trusting a number. Short version: honest between roughly 30 A and 150 A, and increasingly meaningless below ~20 A, because a ±1%-of-full-scale nonlinearity term is a fixed ±1.5 A regardless of reading. That is inherent to putting a 150 A Hall sensor on a small current. For comparative testing, same board, same session, ESC A vs ESC B, the systematic terms cancel and repeatability is far better than the absolute figures.

Two ideas worth sharing

The ratiometric trick (§4.2). The sensor's output scales with its own supply, which here is raw USB VBUS, sagging with cable resistance and modulated by the display backlight PWM. Rather than fight that with a regulator, a second divider measures the 5 V rail, and the current is recovered from the ratio. Both V_CC and V_REF cancel algebraically, so accuracy depends only on two resistor ratios and the sensor's own spec.

The current path crosses the short dimension. The ACS770's terminals sit side by side, so rotating it 90° and stacking the connectors above and below gives a ~28 mm connector-to- connector path. The ground return, not the sensor, turns out to dominate the loss budget. See §8.

Repository layout

Logging_Current_Meter.kicad_sch    schematic
Logging_Current_Meter.kicad_pcb    board, 95 × 62 mm, 4 layer
LCM.kicad_sym / LCM.pretty         all project symbols and footprints, self-contained
production/                        gerbers, BOM, positions and IPC netlist as sent to fab
DESIGN.md                          the real documentation, reasoning, maths, decisions
BOM.md / BOM.csv                   bill of materials, generated from the schematic
generator/                         the Python that builds and checks all of the above
firmware/                          bring-up diagnostic and the touchscreen UI, one folder per sketch
tools/capture_stream.py            records the meter's USB CSV stream on a PC
tools/log_analyzer.py              GUI: graphs, summary CSV and run comparisons from SD logs
libraries/JCR_TouchScreen/         reusable ST7796 + FT6336U display and touch library
COMMIT_TIMELINE.md                 full detail behind every commit, newest first

DESIGN.md is the substantive document; this README is only an index. It records why each choice was made, including the ones that turned out wrong and were reversed.

The generator / verifier toolchain

The schematic and board are hand-edited in KiCad, but every mechanical change is applied by script and checked by an independent verifier. The rule throughout: the checker re-reads the finished file from disk and re-derives everything, so it can disagree with the tool that wrote it.

Requires KiCad 10 or newer. The schematic and board are now in KiCad 10 format (20260306 and 20260206), written by KiCad itself. KiCad refuses to open files stamped newer than the running version, so an older install will not open this project at all.

cd generator

# check, read-only, safe at any time
python3 verify.py     ../Logging_Current_Meter.kicad_sch ../LCM.kicad_sym
python3 verify_pcb.py ../Logging_Current_Meter.kicad_pcb ../Logging_Current_Meter.kicad_sch

# regenerate derived artefacts
python3 gen_bom.py                                    # BOM.md + BOM.csv from the schematic
python3 copper_budget.py ../Logging_Current_Meter.kicad_pcb   # 150 A loss budget
python3 region_map.py    ../Logging_Current_Meter.kicad_pcb   # the §14 layout map
python3 render_pcb.py    ../Logging_Current_Meter.kicad_pcb ../placement.svg

gen_sch.py is a historical build script, not a live tool. generator/kicad8.py hardcodes SCH_VERSION = 20231120, so re-running it would overwrite the KiCad 10 schematic with a KiCad 8 one and discard every edit made in KiCad since. gen_pcb.py was updated for KiCad 10; gen_sch.py was not.

verify.py rebuilds the netlist geometrically, so pins, wire endpoints and label anchors sharing a coordinate are one node, then compares it against an independently written expectation of all nets and pin connections. verify_pcb.py runs nine checks over the board: s-expression syntax, footprint inventory against the schematic, net coverage, board extent, courtyard overlaps, stale net names, pour and stitching integrity, components inside soldermask openings, and pad-to-pad clearance against the resolved netclass rules.

Both currently pass clean.

gen_pcb.py will refuse to run its place or pour stages once the board has routed tracks, because both would destroy hand routing. Override with --force only after re-syncing the placement table from the board.

Every check in verify_pcb.py exists because something actually went wrong: a quoted s-expression tag that made KiCad reject the file, a net rename that left a dead name on a live pad, a resistor placed inside a soldermask aperture, a netclass clearance that made a 0.5 mm-pitch connector unroutable. The commentary in the source explains each one.

Known open items

Rev A hardware faults

• JP1 ships open — bridge it or the display is dead. It is the display's only supply. Bridge pad 2 (DISP_VCC) to pad 1 (+5V). No backlight, no SPI and no I²C until you do, which makes it look like a much bigger problem than it is. DESIGN.md §9.
• J7 needs a TYPE A (same-side) FFC cable. The one in the display's box is Type B and reverses the pin order, putting 5 V on the module's SD_CS while VCC sits unpowered. 14 pin, 0.5 mm pitch, Type A, ≤100 mm. DESIGN.md §9.
• SW1/SW2 are dead — footprint pad mapping is wrong. SW_TS-1187A was remapped assuming internal pairs 1–3/2–4; they are 1–2/3–4, so both buttons short BTN1 to GND permanently. Rev B fix, plus a lift-two-legs bodge for Rev A. Calibration runs from serial commands instead. DESIGN.md §9.
• RV1 footprint. Corrected in the library to the real 3362P triangle but not yet applied to the board. Update Footprints from Library moves all three pads 1.27 mm and needs T_NODE and T_POT_TOP re-routed. DESIGN.md §4.4.
• D1 / U1 courtyards overlap by 3.49 × 0.45 mm. Courtyard margin only — no pad, body or silk inside it. KiCad will keep flagging it. Not a bug.

Firmware

• Bring-up diagnostic is complete and lives in firmware/display_bringup/. It exercises all 20 GPIO, reports pass/fail per subsystem with net names, and runs the calibration routines.
• Current gain is the last uncalibrated channel. Voltage, thermistor and the current zero are done and baked in.
• The touchscreen UI is built and running, in firmware/logging_current_meter_FABLE/ (v3.6): live V/I/T/W, energy accumulation, an autoscaled 5 s graph, Test Mode (ESC signal on GP1 for uni- or bidirectional ESCs — manual buttons or slider with a dead-man option, ramped auto-cycle, and a counted Log Test that records itself), SD logging (manual, Test-cycle or current-threshold start, 1–15 min duration) with a USB CSV stream, a Settings screen with flash persistence and a settable wall clock that stamps every log with the date and time it was recorded, dark and navy themes, a tunable weighted filter on the V and I readings, and a touch diagnostic screen with a serial telemetry harness. Its display and touch stack is factored out into libraries/JCR_TouchScreen/. Architecture and the measured sampling constraints are in DESIGN.md §11.
• Touch responsiveness fading with use is under investigation. v3.1b's register watchdog found the FT6336U's mode register losing its value on its own (47 times in 39 minutes) and now rewrites it within 500 ms; the per-register breakdown in v3.1c will say whether the part is resetting or one register is flaky.
• v3.2a is bench-verified (ESC timing, SD logging, USB stream, log analyzer). v3.3 (the Test Mode rework), v3.4 (the wall clock), v3.5 (ESC arming, pre-roll and stop escalation) and v3.6 (cycle mode: STOP→SPIN / SPIN→SPIN in place of the old mirrored DIRECTION) are compile-checked and host-tested; each bench run has fed the next, and v3.6 is not yet on the bench.
• microSD MISO tri-state risk. Inconclusive so far, and not a blocker — the panel is driven write-only and works. With no card in the slot nothing drives MISO on these modules, so 0xFF is the expected reading. The §11 question only has meaning with a card inserted.

Sourcing note

Three cost figures get confused, so to be explicit. BOM.md's $10.75 is the theoretical SMT parts cost at LCSC unit prices, and it is the only one the generator computes. The $15 above is what a delivered assembled board actually cost at qty 10, and the real PCBA line came in at $11.06/board against that $10.75 estimate, which is close enough to validate the generated BOM. $44 is a complete working meter, and the display alone is $18.99 of it. All three are at qty 10; setup and shipping amortise, so a one-off build costs considerably more per board.

The ACS770 is marked not for new designs but remains in stock. ACS772KCB-150U-PFF-T is a drop-in replacement requiring no board changes at all, same package, same 26.66 mV/A, same quiescent output, same ratiometric behaviour, same load limits. DESIGN.md §4.1.1 has the full comparison, including which of the commonly-quoted differences are wrong.

Licence

• Hardware (schematic, PCB, footprints, symbols, BOM, documentation): CC BY-NC-SA 4.0, plus the additional permissions below.
• Software (the Python in generator/): PolyForm Noncommercial 1.0.0, plus the same additional permissions.

What you can do

Build one. Build several. Modify the design. Use it at work, in a business, in a makerspace, in a classroom, or in a paid repair shop. Put it in a monetised YouTube video, a paid course, or a magazine article. Publish your modified version, as long as you credit this project and licence your version the same way.

What you cannot do

Sell the design files. Sell hardware built from them, whether assembled boards, bare PCBs, or kits. Bundle either into a product you sell. Selling kits is how this project funds itself, so that part is reserved.

Want to sell something based on this? Ask. Contact team@justcuzrobotics.com.

Why it is written this way

CC BY-NC-SA's "NonCommercial" clause is broader than the intent above; read strictly it would also block using one at work or in a monetised video. The additional permissions in the LICENSE files grant those uses explicitly, so the only real restriction is on selling the design or hardware.

Because commercial sale is restricted, this is source-available rather than open source in the OSI or OSHWA sense.

Copyright © 2026 Seth Schaffer / Just 'Cuz Robotics