nRF5 action!
-
Motivated by the above, I just now did some current tests on the nRF52832 and found that:
- Going directly to an RTC sleep after powerup consumes 2.2ua.
- Enabling DCDC doesn't increase that.
- Nor does blinking an LED and then putting that pin into a disconnected state (D0) before sleep.
HOWEVER,
4. Activating Serial using Serial.begin(..) before sleep causes the current drain during sleep to rise to around 10.8ua. That was surprising to me, because this code in hwSleep(..) seems geared toward turning OFF serial prior to sleep:// Idle serial device NRF_UART0->TASKS_STOPRX = 1; NRF_UART0->TASKS_STOPTX = 1; NRF_UART0->TASKS_SUSPEND = 1;So, I guess more is needed there?
-
-
OK, I found that adding:
NRF_UART0->ENABLE=0; //disable UART0brings the current consumption back down to 2.2ua during sleep. :)
-
OK, I found that adding:
NRF_UART0->ENABLE=0; //disable UART0brings the current consumption back down to 2.2ua during sleep. :)
-
@Toyman said in nRF5 Bluetooth action!:
@NeverDie should it be placed just before hwSleep()?
It's just a possible preliminary piece of the solution, because you'll need to renable UART0 after waking up from sleep. I haven't tested to see whether Serial.print(..) still works after re-enabling, or whether it needs to be re-initialized. Those are details yet to be sorted.
Or, maybe there's some other way of doing it. At this point, I'm just reporting my finding and tossing it out there as a tantalizing possibility.
-
@d00616 thx. How do I use the macro? Just put in ISR?
Regarding the bug: if read the docs correctly, all nrf51 have the bug :-(@Toyman said in nRF5 Bluetooth action!:
@d00616 thx. How do I use the macro? Just put in ISR?
Yes. Give the event register as parameter.
Regarding the bug: if read the docs correctly, all nrf51 have the bug
This bug is listed as PAN#39 and fixed at the end of 2014.
-
OK, I found that adding:
NRF_UART0->ENABLE=0; //disable UART0brings the current consumption back down to 2.2ua during sleep. :)
@NeverDie said in nRF5 Bluetooth action!:
OK, I found that adding:
NRF_UART0->ENABLE=0; //disable UART0brings the current consumption back down to 2.2ua during sleep.
Great work. Are you able to build an Pull Request fixing this? This Pull request should also be tested in the condition with a disabled serial port.
If you need help, please ask. I do the reviews.
-
@Toyman said in nRF5 Bluetooth action!:
@d00616 thx. How do I use the macro? Just put in ISR?
Yes. Give the event register as parameter.
Regarding the bug: if read the docs correctly, all nrf51 have the bug
This bug is listed as PAN#39 and fixed at the end of 2014.
-
@NeverDie said in nRF5 Bluetooth action!:
OK, I found that adding:
NRF_UART0->ENABLE=0; //disable UART0brings the current consumption back down to 2.2ua during sleep.
Great work. Are you able to build an Pull Request fixing this? This Pull request should also be tested in the condition with a disabled serial port.
If you need help, please ask. I do the reviews.
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
-
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
Just re-enabling the UART isn't enough. Nor are the existing UART related instructions after a wake-up, if UART0 was disabled. It seems to require a re-initialization. Another Serial.begin(BAUDRATE) after wake-up does work. However, I should point out that doing that isn't free, as it adds to wake-up time. So, you may wish to add another "level" of sleep, one which saves more energy while sleeping but at the cost of a longer wake-up. Moreover, the energy consumed during the longer wakeup isn't free either, so if the sleeps are very short, you could lose more energy for using it than not. One may, therefore, also want to calculate the breakeven point to provide guidance on when to use which level of sleep.
In short, this is more than a simple fix, and the software architect probably needs to consider the bigger picture in order to craft the best solution.
-
@Toyman said in nRF5 Bluetooth action!:
Guys,
Have you seen this?
Note, that our beloved ebyte is not there, but PTR9618PA is
It's useful. But just knowing the module exists is one thing. Finding a source for it is another.
-
@Toyman said in nRF5 Bluetooth action!:
Guys,
Have you seen this?
Note, that our beloved ebyte is not there, but PTR9618PA is
It's useful. But just knowing the module exists is one thing. Finding a source for it is another.
-
@d00616 said in nRF5 Bluetooth action!:
Yes. Give the event register as parameter.
so, if I have an intterupt atached to pin 1, what shall i put into ISR?
NRF_RESET_EVENT....;
Sorry for dumb questions, this is completely new to me.@Toyman said in nRF5 Bluetooth action!:
@d00616 said in nRF5 Bluetooth action!:
Yes. Give the event register as parameter.
so, if I have an intterupt atached to pin 1, what shall i put into ISR?
With arduino-nrf5, you can't put nothing into the pin interrupt ISR because the ISR is already defined.
Sorry for dumb questions, this is completely new to me.
There are no dumb questions, there are bad answers.
-
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
@NeverDie said in nRF5 Bluetooth action!:
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
There is and document describing the procedure: https://www.mysensors.org/download/contributing
I think this is a good document to start with. If you have trouble, please ask.
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
There is and document describing the procedure: https://www.mysensors.org/download/contributing
I think this is a good document to start with. If you have trouble, please ask.
@d00616
The solution I'm going with, which serves my present needs, is just to put all serial communications code within "DEBUG" compiler directives. So, if I'm not debugging, the issue just goes away, and there's no added overhead. :) -
@d00616
The solution I'm going with, which serves my present needs, is just to put all serial communications code within "DEBUG" compiler directives. So, if I'm not debugging, the issue just goes away, and there's no added overhead. :)@NeverDie said in nRF5 Bluetooth action!:
@d00616
The solution I'm going with, which serves my present needs, is just to put all serial communications code within "DEBUG" compiler directives. So, if I'm not debugging, the issue just goes away, and there's no added overhead. :)Found a shortcut. Instead of doing all that, which is extra work and looks ugly too, I just disabled the UART0 on the first sleep, and then never re-enabled it. It works.Now my sleep current is just 2.1ua, except for the brief pulses every 100ms where the PPI listens for an incoming packet addressed to it. :) -
Nonetheless, I just now measured the sleep current on the cheap nRF51822 that @NCA78 referenced:
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html?aff_platform=aaf&cpt=1507850033284&sk=e2Vzr3v&aff_trace_key=fa8ec197f200446fbd58fc8679ffb3bd-1507850033284-07709-e2Vzr3v&terminal_id=29bfb7ff18284b7f96acb3c3884390ce
It measures at 5ua, which is higher than the 2.1ua of the nRF52832, but still not bad in absolute terms. I was afraid after the discussion of how some nrf51's had a 1ma bug in the hardware that they would be counted among them. Fortunately, it seems not. :) -
Nonetheless, I just now measured the sleep current on the cheap nRF51822 that @NCA78 referenced:
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html?aff_platform=aaf&cpt=1507850033284&sk=e2Vzr3v&aff_trace_key=fa8ec197f200446fbd58fc8679ffb3bd-1507850033284-07709-e2Vzr3v&terminal_id=29bfb7ff18284b7f96acb3c3884390ce
It measures at 5ua, which is higher than the 2.1ua of the nRF52832, but still not bad in absolute terms. I was afraid after the discussion of how some nrf51's had a 1ma bug in the hardware that they would be counted among them. Fortunately, it seems not. :)@NeverDie The nRF51 is done on a different process then then the nRF52. The nRF52 is on average 50% lower power then the nRF51. The picture of the module shows a nRF51822QFAA Hx part which is a 256k flash, 16k Ram part REV 3. You can see all the revision number here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf51/dita/nrf51/compatibility_matrix/nRF51822_ic_revision_overview.html?cp=3_0_1
