Subject: C1001 (SEN0623) — IO1/IO2 timing vs UART flags in fall detection mode
refael 2026-08-03 02:22:41 115 Views3 Replies Hi,
I'm using the C1001 in fall detection mode with an ESP32. The wiki lists two level-output pins:
IO2 — human presence level output (3.3V, fall mode active)
IO1 — fall state level output (3.3V, fall mode active)
I understand these are simple digital HIGH/LOW outputs. My questions are about timing, since I plan to use them as an independent backup channel alongside UART:
1. Fall timing: Does IO1 go HIGH at the same moment that getFallData(eFallState) returns 1 over UART? Or does one of them respond earlier? Specifically — is IO1 subject to the dmFallTime() confirmation delay, or does it reflect the raw fall decision immediately?
2. Presence timing: Does IO2 follow the same logic as smHumanData(eHumanPresence), including the dmUnmannedTime() delay before clearing? Several users have reported that presence stays asserted for a while after a person leaves the room — does IO2 behave the same way, or does it clear faster?
3. Electrical: Are these pins push-pull or open-drain? Do they need an external pull-down resistor, or is the internal pull-down of the MCU sufficient?
4. LED coupling: Are IO1/IO2 affected by configLEDLight(eFALLLed / eHPLed, ...)? In other words, if the LEDs are disabled in software, do the pins still output?
Context: I'm building a fall detection system for elderly care. I want a channel that keeps working even if UART parsing fails, and I'd like to know whether these pins can also give me a faster response than UART.
Thank you
Refael
THANK YOU JASON
i hvae another question about C1001 :
Sensor: DFRobot C1001 / SEN0623, running in eFallingMode on ESP32-S3 with the DFRobot_HumanDetection library.
Thanks for the detailed answers — the IO1/IO2 findings and the configLEDLight() clarification were exactly what I needed.
You mentioned the human data query in fall mode also covers seated horizontal distance, motion horizontal distance, trajectory switch, and a height cumulative time value. These weren't in the examples I've been working from, so I'd like to test them.
Could you share the exact method names / enum constants for these? Something like hu.smHumanData(hu.e...) — I want to make sure I call them correctly rather than guess.
Why this matters for my use case: I'm building a fall detector for an elderly person living alone. The core problem is that without a posture label, my logic can't distinguish "lying on the floor after a slow collapse" from "sitting still in an armchair watching TV" — both look like a present, static person. That means either false alarms every minute, or missing a real fall.
If seated horizontal distance and motion horizontal distance are separate measurements, comparing them might give me the distinction I need. And height cumulative time sounds directly relevant to a gradual descent, which never triggers the fall flag.
I'm happy to test these on hardware and report back what the values actually look like in each posture — I have a live dashboard logging all sensor outputs, so I can share real numbers if that's useful to others.
Thanks!
refael The library doesn't seem to expose a way to enable IO1/IO2, and one tester reported they stay low by default in fall mode — so they may not be the reliable backup you're looking for right now.
The Wiki calls them 3.3V level outputs but doesn't say whether dmFallTime() and dmUnmannedTime() apply to the pins or just the UART flags. They likely share the same state machine, but no timing diagrams in the docs.
Electrical specs just list "3.3V output" — no push-pull vs open-drain detail. Worth scoping before relying on it for a safety system.
configLEDLight() only drives the on-board LEDs. IO1/IO2 are independent lines.
For elderly care, aggressive UART polling + a watchdog is likely the safer backup until the level-pin behavior is better documented.
Jason.Miao 
