Use this when revising the main paper. IPSN papers are read by sensor-systems and information-processing reviewers, so they need a real sensing problem on the first page and evidence measured on real hardware against ground truth. The failure this skill prevents is a technically fine paper that reads like an offline ML result, or a hardware report with no measured trade-off.
| Section | Job it must do | Common failure |
|---|---|---|
| Intro | Sensing problem, inadequacy, contribution, real-hardware evidence preview, budget — first page | Leads with a model/technology trend, not a sensing problem |
| Background | The modality, the platform constraints, why this is hard physically | Motivation by assertion; no physical grounding |
| Method / System | The estimator/inference (IP) or the platform/tool (SPOTS), reproducibly | Method too thin to re-implement; platform under-specified |
| Evaluation | Each claim answered with measured, ground-truth evidence | Simulation or offline accuracy standing in for on-device/in-field results |
| Energy/latency budget | Joules, memory, timing as measured on the real platform | "Feasible on embedded devices" with no numbers |
| Limits / threats | Site-specificity, generalization, calibration drift, bounded | Generic paragraph untethered from this system |
| Related work | Delta-first against the sensing literature | Citation catalog with no contrast |
| Draft pattern | IPSN-safe rewrite |
|---|---|
| "Our method significantly improves accuracy." | "reduces localization error to X m (95% CI ...) vs |
| "It is energy-efficient." | "consumes X µJ per inference on <MCU> at |
| "We deploy it in the real world." | "deployed <N> nodes for |
| "Runs in real time on embedded devices." | "end-to-end latency X ms on <SoC>; fits <RAM/flash> footprint" |
| "The model detects the event well." | "detection rate D at F false alarms/hour on hand-labeled field audio, per site" |
[Energy] joules or µJ per operation, measured (rail/shunt/instrument named), not estimated
[Latency] end-to-end timing on the real SoC/MCU at a stated clock; number of runs
[Footprint] RAM/flash used vs available; where the model/pipeline had to shrink
[Ground truth] the reference (labels, co-located instrument, surveyed positions) and its own error
[Limits] site-specificity / calibration drift / generalization -> stated next to the result
A draft with a long system tour, six figures, and a thin evaluation: keep the system description at the level needed to reproduce, the two figures that carry the energy and yield story, a per-site false-alarm table, and a limits subsection; move the full protocol and secondary plots to the artifact with forward references. The test of a good cut: a reviewer should be able to answer "what was measured, on what hardware, against what ground truth, and how well did it hold up?" from the body alone.
[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped
[First-page fix] <new framing leading with the sensing problem and its budget>
[Claim audit] <claim -> measured evidence -> on real hardware / ground truth? yes/no>
[Budget check] <energy / latency / footprint reported? where>
[Anonymity edits] <tool/testbed names / board photos / self-citations / dataset links to fix>