nRF5 action!

NeverDie

What's going to be the best way to reduce the sleep current and Tx current on the nRF52? Since I'm feeding off a supercap for power, it's noticeably worse (by an order of magnitude) on the same task than the atmega328p+rfm69 combo. I've already increased the datarate to 2mbps, and it's inherently lower Tx current should give it a natural advantage.

I guess I'll try reducing Tx power and see if that makes much of a dent....

I suppose reducing 3 separate packets to one single packet, and maybe turning off ACK requests might also help. Then, maybe all of the LONG_WAIT's can be eliminated. Is the radio still awake even if the CPU is sleeping during a "wait" period? If so, that might be a large chunk of the wasted power.

I wonder if the mysensors mesh networking (which I don't intend to use) might be getting in the way, and possibly keeping it awake longer than it otherwise would be? Can I disable the mysensors meshnetworking just to be sure?

Sorry for the shotgun blast of questions, but I'm trying to get a sense of what will yield the highest payoff.

NeverDie

Since I'll be reducing Tx power in an attempt to reduce current consumption, I'll be using a scanner program to try to find empty channels. The only one I know of is: https://github.com/nRF24/RF24/tree/master/examples/scanner
for the nRF24L01, but it seems to work well enough if you let it run awhile. Anyone else using one that they like?

NeverDie

@NeverDie said in nRF5 Bluetooth action!:

Since I'll be reducing Tx power in an attempt to reduce current consumption, I'll be using a scanner program to try to find empty channels. The only one I know of is: https://github.com/nRF24/RF24/tree/master/examples/scanner
for the nRF24L01, but it seems to work well enough if you let it run awhile. Anyone else using one that they like?

Nevermind. I see now that there's an entire entry on it:
https://forum.mysensors.org/topic/2454/node-cant-see-gateway-less-than-10m-away/11

Nca78

@gohan said in nRF5 Bluetooth action!:

I don't know if it is actually related, but I'll post the link to this programmer :)
adafruit.com/product/3571

Not sure it's even legal to use this if you ever plan to sell PCBs on openhardware.io ...

You may use the J-Link EDU for non profit educational purposes only! Non-profit educational purposes means that you >may not use the J-Link EDU and its J-Link software.

direct or indirect in or for a profit organization or business purposes or other undertaking intended for profit

direct or indirect in any other commercial environment (e.g. office)

to develop, debug, program or manufacturer a commercial product (or parts thereof)

to use it to either earn money or reasonably anticipate the receipt of monetary gain from it.

gohan

@Nca78 Educational versions of many things can not be used for commercial purposes, maybe they got an agreement as it will be sold primarily to hobbyists.

NeverDie

In my testing, NRF5_PA_LOW did offer some modest reduction in overall current consumption, but it's no silver bullet.

The range with NRF5_PA_MIN is just a few feet, so I don't consider it practical for the vast majority of use cases.

So, further reductions in current consumption will have to come from somewhere (?) else.

I suppose the next step is to turn-off auto ACK's and any listening for ACK's by the mote. Hopefully (?) there's a switch in myconfig which does that.

d00616

I have checked the current with my nRF52 board with integrated shunt. I have measured 6.5µA while sleeping until timeout or sleeping until interrupt. It doesn't matter if RX/TX are connected but after flashing the firmware a reset by removing the voltage is required.

There was an bug, with any type of sleep(0) which is fixed by this PR https://github.com/mysensors/MySensors/pull/909

NeverDie

Unless I'm doing it unwittingly, I'm not doing any sleep(0)'s at present.

NeverDie

I'm finding that having a very simple adapter board, such as that in the photo here, is quite convenient both for programming and for powering the nRF52832, and for wiring-up prototypes. I made my breakout board for breadboards, but those connections are always just too flakey. Maybe I need to use better breadboards? Anyhow, this meets the requirement for reliable, solid connections.

NeverDie

I removed this useless block of code from the main loop, which, with its long waits, may have been what was draining the power:

	Serial.println("");
	Serial.println("");
	Serial.println("");
	Serial.println("#########################");
	randNumber=random(0,101);

	Serial.print("RandomNumber:");
	Serial.println(randNumber);
	// Send fake battery level
	Serial.println("Send Battery Level");
	sendBatteryLevel(randNumber);
	wait(LONG_WAIT);

	// Request time
	Serial.println("Request Time");
	requestTime();
	wait(LONG_WAIT);

rmtucker

@NeverDie
When you are comparing the atmega 328 and the nrf52 what sketch are you using to come to your conclusions?.

NeverDie

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie
When you are comparing the atmega 328 and the nrf52 what sketch are you using to come to your conclusions?.

A solar mote which reports the voltage on the supercap and the unloaded voltage on the solar panel.

The goal is to get the mote to be a solar powered remote, where it will wake up and listen for a packet once every 100ms and then go back to sleep if it doesn't receive one inside a very narrow window of time. That window can be a lot narrower on the nRF52302, because it supports 2Mbps, whereas the RFM69 can support at most 300kbps. I got the atmega328p+rfm69 to do that (although it required a larger than 10F supercap to get through the night), and it worked. At the present moment, though, I don't think the nrf52 can do it, unless I were to use an even bigger supercap and more than one mini solar panel. The potential to do it is there though. I just need to drive it better.

I think a high priority is to get the DCDC working on the nRF52.
That should cut the higher currents (such as during Tx and Rx) by about half, as discussed earlier in this thread.

BTW, removing the above block of code did help appreciably.

d00616

@NeverDie said in nRF5 Bluetooth action!:

I think a high priority is to get the DCDC working on the nRF52.

You can try to do this:
#include <nrf.h>

...in before()

NRF_POWER->DCDCEN = 1;

NeverDie

I haven't yet touched DCDC, but having stripped the example code down a bit, my 10F capacitor is now losing only about 18mv per hour, which is much better than when I began. Some of that is even self-discharge. Whew! Another bullet dodged. Of course, it needs to go lower still, but at least this is meaningful progress for minimal effort.

NeverDie

Removing ACK's is the next easy step, and I found the entry in myconfig.h that will do it:

/**
 * @def MY_PASSIVE_NODE
 * @brief If enabled, the node operates fully autonomously, i.e. messages are sent without ACKing.
 *
 * @note All transport-related checks and safety-mechanisms are disabled.
 * @note Requires that @ref MY_NODE_ID is set, @ref MY_PARENT_NODE_ID and
 *       @ref MY_PARENT_NODE_IS_STATIC are optional.
 * @note Singing, registration, and OTA FW update are disabled.
 */
//#define MY_PASSIVE_NODE

scalz

@NeverDie
in case.. it's better to make the config changes inside your sketch instead of the MyConfig file, especially if you want to use MySensors for others nodes (else each time you'll have to struggle with MyConfig)

NeverDie

@NeverDie said in nRF5 Bluetooth action!:

#define MY_PASSIVE_NODE

Not sure, but I may have run into a bug. I've defined MY_PASSIVE_NODE, and in the main loop I send two different packets once every 5 minutes. The first one never arrives. The second one always arrives. Prior to defining MY_PASSIVE_NODE, both would always arrive. This is on an nRF52832.

NeverDie

@NeverDie said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

#define MY_PASSIVE_NODE

Not sure, but I may have run into a bug. I've defined MY_PASSIVE_NODE, and in the main loop I send two different packets once every 5 minutes. The first one never arrives. The second one always arrives. Prior to defining MY_PASSIVE_NODE, both would always arrive. This is on an nRF52832.

Of course, within a minute of posting the above, the first one suddenly decided to arrive. Maybe it's not a bug after all.

NeverDie

On the other hand, it really does seem to receive the second packet (solar panel voltage) far more often than the first (supercap voltage):

2017-08-14 12:17:45.613 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:22:45.866 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:22:45.887 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:27:46.121 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:27:46.152 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:32:46.399 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:32:46.431 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:37:46.661 (nRF52 DK Gateway) General/Barometer (SuperCap Voltage)
2017-08-14 12:37:46.708 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:42:46.928 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:42:46.975 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:47:47.207 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:47:47.254 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:52:47.474 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:52:47.493 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 12:57:47.736 (nRF52 DK Gateway) General/Barometer (SuperCap Voltage)
2017-08-14 12:57:47.767 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:02:48.006 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:02:48.051 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:07:48.279 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:07:48.310 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:12:48.556 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:12:48.587 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:17:48.843 (nRF52 DK Gateway) General/Barometer (SuperCap Voltage)
2017-08-14 13:17:48.882 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:22:49.085 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:22:49.116 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:27:49.371 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:27:49.402 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:32:49.624 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:32:49.655 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:37:49.896 (nRF52 DK Gateway) General/Barometer (SuperCap Voltage)
2017-08-14 13:37:49.942 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:42:50.169 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:42:50.215 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:47:50.450 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)
2017-08-14 13:47:50.481 (nRF52 DK Gateway) General/Barometer (Solar Panel Voltage)

Also, I hadn't realized until now that it was sending them multiple times. I had wanted each packet to be sent only once.

NeverDie

It looks as though it's a bug in Domoticz. If I open up the serial monitor to the gateway, I can see that it is receiving both packets. However, Domoticz isn't displaying them or even logging them. However, if I don't turn on MY_PASSIVE_NODE, then it does correctly display them. So, Bye-bye Domoticz. I hopee the other controllers don't have the same problem.

nRF5 action!

1

11.7k

11.2k

113.0k