-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Detection sensor sleep & interrupt #8766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Relocates the conditional setting of nRFSenseSleep for NRF52 architecture from runOnce() to the header section, ensuring it is set earlier in the module lifecycle. This change means that the sleep lib is only imported on supported platforms, reducing binary size on other platforms
Eliminated the explicit setting of BACKGROUND priority for non-sensor devices in sendCurrentStateMessage. This would otherwise affect all nodes using the DetectionSensor module in roles other than Sensor.
Minor tweaks to make the code play nice on other platforms
…ity assignment for non-sensor devices
…uration configurable by setting "super duper sleep duration", but not less than 1h
…working with the current sleep.c
|
Some additional testing has revealed an issue where the nRF52 does not wake up. My feeling is to close the PR as sleeping forever ignores the SDS_Secs and will confuse inexperienced users, making them think their nodes are dead. |
|
Yeah, trash the pull request, Colombo. I am about to finish what works in both cases.
|
|
replaced by #8778, please drop PR. |
Presented by @rbomze and myself, this PR updates the DetectionSensor module to use an interrupt-driven approach when the following conditions are met:
• The device is nRF52840-based
• The node role is Sensor
• Power saving mode is enabled
When these criteria are satisfied, the module uses GPIO interrupts instead of polling, allowing the device to reliably enter deep sleep for ultra-low power operation.
These changes are contained within an
#ifdef ARCH_NRF52to prevent build failures on other platforms, ensuring that they only affect nRF52 devices. Devices that do not meet all of the above conditions, including nRF52-based devices, continue using the existing polling behaviour to maintain compatibility.All existing configuration values (
sds_secsandmin_wake_secs) continue to be respected, preserving expected module behaviour.🤝 Attestations