Skip to content
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

How to reduce power consumption in receiving mode #30

Open
shekmun opened this issue Aug 25, 2023 · 3 comments
Open

How to reduce power consumption in receiving mode #30

shekmun opened this issue Aug 25, 2023 · 3 comments

Comments

@shekmun
Copy link

shekmun commented Aug 25, 2023

I've test the power consumption both in receiving and sending mode on the nrf52832 minimum system board.
In receiving mode, the average current is about 13mA. But after switched to sending mode, the average current reduced to 1mA.
Which means that the "receiving" (something like scan) costs about 12mA. So is it possible to reduce power consumption in "receiving" mode?

@nordic-auko
Copy link
Owner

The system is not optimized with regards to power consumption. That is, the transmitter is somewhat optimized in the sense that it only uses the radio when it actively transmits. The receiver on the other hand, keeps the radio in receive mode for as long as possible. To improve this the receiver needs to know when to expect packets to arrive, and only keep the radio on accordingly.

@shekmun
Copy link
Author

shekmun commented Jan 2, 2024

Thanks for your advising. But can I know which parameters can I change in the code to make it receive in shorter time (I can accept if the sync speed is slower and maybe not as long as possible), or only receive the packet at the exact moment with very short period (maybe this needs being synced). I've tried something like "m_timeslot_req_earliest" and "m_timeslot_req_normal", but no success.

@rdebrum-cdi
Copy link

Any further updates on this? I too see more than double the current draw in receiving mode and for my customer's sake will need to bring this down.
Do you mean the firmware should not try to extend the MPSL? If the transmit frequency is known, how do you think it is possible that we could optimize the receiver to only be in receive mode for the expected window of time (on the general tick of the freewheel)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants