task-13: elmyra_raw streams at 100Hz; force produces no deflection

docs/tasks/13-active-edge-squeeze.md

@@ -316,3 +316,67 @@ silence.
 So the remaining question is not "is the SUID served" (it is) but **who
 configures IRQ 125**. Downstream that is vendor DT/driver work. Start there,
 not at the client.
+
+## Update 2026-07-27 — the right sensor, streaming at 100 Hz, force does nothing
+
+### Corrections to the entry above
+
+`sns_touch_gesture` is **not** Active Edge. `PAF/touch.md:127` says it is the
+FTS double-tap nanoapp on the SLPI's i2c bus 5, and the registry agrees
+(slave 0x49, bus 5, irq 125 = the touch controller). The `irq_skip_pin_config`
+lead in the previous entry belongs to double-tap-to-wake, not to squeeze.
+
+**Active Edge is `elmyra_raw`** — the strain gauge array on the MAX11261.
+Resolves to SUID `15717249801838747009 / 6291402259395006624`.
+
+### Two libssc bugs, both patched (pkgs/libssc-souveraine)
+
+1. **Single-output sensors aborted the caller.** `sensor_open()` had
+   `g_assert_not_reached()` for any stream type other than continuous(0) or
+   on-change(1). Fixed: type 2 defined, opened like on-change, and the assert
+   replaced by a returned error — a library must not abort its caller over a
+   value it read off the device.
+2. **Sample rate was the first advertised, not the fastest.** libssc took
+   `v[0]` ("Only a single sample rate is supported for now"), giving **1 Hz**
+   on a sensor the factory capture shows running at ~115 Hz. A squeeze lasting
+   half a second was invisible. Now takes the maximum: **confirmed 100 Hz on
+   device.**
+
+Both belong upstream (codeberg.org/DylanVanAssche/libssc); neither is
+blueline-specific.
+
+### The producer works
+
+`pkgs/blueline-edge-sense` opens `elmyra_raw`, decodes six floats per sample,
+loads this unit's factory `touch_2_sensitivity` values
+(0.240 0.295 0.176 0.359 0.329 0.342), holds a rolling baseline and computes
+summed normalised deflection. Live baseline on device:
+`-79445 -104899 322598 236201 139847 53762` — six real gauges in the ±100k
+range the factory sweep shows.
+
+The threshold model comes from Google's own calibration sweep
+(`persist/sensors/edgesense_roller_cal/0_raw/sensor_data.csv`), which captures
+the gauges at a known 10 N and 20 N: the loaded bank moves 400–2000 counts per
+10 N step.
+
+### Where it stops
+
+**Squeezing produces no signal.** 399 samples across 35 s of deliberate hard
+squeezes: median deflection 49, p99 98, **max 127** — indistinguishable from
+the resting noise floor. The ADC is alive and the values move; they just do not
+move with applied force.
+
+So the gauges are being read but not *excited*. Things to look at next, in
+order:
+
+- `b1c1_max11261_no_pullup.json` carries `reset_gpio`, `haptic_gpio`,
+  `gpo_delay`, `mux_delay`, `gain`, `lp_mode`. Nothing configures these.
+- `sensor_def_qcomdev.conf` cfg 6 names SSC-side pins for this sensor:
+  `gpio1 = 0x108` (data ready), `gpio2 = 0x100` (reset). Neither is touched.
+- `results.csv` from the factory run records `afe_gain 2.0` — the analog front
+  end has a gain setting that presumably must be programmed.
+- PM8998 GPIO 2 is held high (`blueline-edge-sense-power`, verified active
+  after reboot). That is the rail the vendor script raises, so it is necessary
+  but evidently not sufficient.
+
+The remaining work is bridge excitation / AFE configuration, not the client.