[Bug/Enhancement]: Default fall_thresh (500) causing excessive false positives in high-traffic environments

[austinjs471]

During testing of a 3-node TDM mesh setup (Node IDs 0, 1, 2) on ESP32-S3 CSI Nodes, the default fall_thresh value of 500 (and in some cases the internal default of 50) triggers constant "Fall Detected" alerts during normal human walking/movement.

Logs
19:31:19.037 -> W (423803) edge_proc: Fall detected! accel=5.0683 > thresh=2.0000
19:31:19.071 -> W (423823) edge_proc: Fall detected! accel=2.4746 > thresh=2.0000

Note: Even when provisioned at 500, the logs show the comparator hitting a much lower threshold (2.0), suggesting the NVS value might not be applying correctly or the default is too low for ADR-039 Edge Intelligence.

[ruvnet]

Analysis: fall_thresh NVS scaling bug

You're right — there's a mismatch between the provisioned value and what the firmware uses internally. Looking at the code:

In provision.py, --fall-thresh is stored as a raw u16:

writer.writerow(["fall_thresh", "data", "u16", str(args.fall_thresh)])

In nvs_config.c, it's loaded and divided by 1000:

uint16_t fall_thresh_val;
if (nvs_get_u16(handle, "fall_thresh", &fall_thresh_val) == ESP_OK) {
    cfg->fall_thresh = (float)fall_thresh_val / 1000.0f;
}

So --fall-thresh 500 → NVS stores 500 → firmware reads 500 / 1000.0 = 0.5 rad/s².

The Kconfig default (CONFIG_EDGE_FALL_THRESH) is also divided by 1000, but the compiled default when no Kconfig is set is 2.0f:

cfg->fall_thresh = 2.0f;

Your logs show thresh=2.0000 which means the NVS override isn't being applied — the firmware is using the compiled default of 2.0. This happens when:

1. The NVS partition wasn't flashed (provisioning didn't complete)
2. The NVS namespace csi_cfg doesn't exist yet

Fix: Re-provision with the latest v0.4.2-esp32 firmware and set a higher threshold:

# Threshold 500 → 0.5 rad/s², too low for walking
# Try 5000 → 5.0 rad/s² (only triggers on actual falls)
python provision.py --port COMX --fall-thresh 5000

For the default: We should increase the compiled default from 2.0 to 5.0 rad/s² to reduce false positives in standard deployments. I'll add this to the next firmware release.

Recommendation for your 3-node TDM setup:

python provision.py --port COMX --fall-thresh 8000 --pres-thresh 100 \
  --node-id 0 --tdm-slot 0 --tdm-total 3

The 8000 → 8.0 rad/s² threshold should eliminate false positives during normal walking while still catching genuine falls.

[ksullivan86]

During testing of a 3-node TDM mesh setup (Node IDs 0, 1, 2) on ESP32-S3 CSI Nodes, the default fall_thresh value of 500 (and in some cases the internal default of 50) triggers constant "Fall Detected" alerts during normal human walking/movement.

Logs
19:31:19.037 -> W (423803) edge_proc: Fall detected! accel=5.0683 > thresh=2.0000
19:31:19.071 -> W (423823) edge_proc: Fall detected! accel=2.4746 > thresh=2.0000

Note: Even when provisioned at 500, the logs show the comparator hitting a much lower threshold (2.0), suggesting the NVS value might not be applying correctly or the default is too low for ADR-039 Edge Intelligence.

How is your mesh setup working? Do you think this is just AI slop os will this eventually work as they claim?