nRF5 action!

[NeverDie]

Well, setting the pinmode to OUTPUT and then digitalwriting it to LOW seems to help considerably--at least when it's not connected to anything.

[Edit: Setting it to HIGH also helps similarly.]

[NeverDie]

Anyhow, I'm relieved that the radio isn't the source of these power drain problems. This pinmode stuff is a bummer, but it looks like I can at least partially work around it.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Well, setting the pinmode to OUTPUT and then digitalwriting it to LOW seems to help considerably--at least when it's not connected to anything.
[Edit: Setting it to HIGH also helps similarly.]

Thank's. I check this after I fixed the Radio.

Actually, I have this board running. I measure a voltage of 0.13mV=6,6µA at the shunt with a simple sleep sketch. When I switch two pins into INPUT_PULLUP, then I measure 0.15mV==7,5µA.

When I switch on the LED then I measure 12.75mV == 0,6375mA, One pin in OUTPUT_H1H0 mode. With LED off I measure 0.15mV==7,5µA.

My MCU is nRF52832 QFAAB0 1615AX

P.S.: I have no documentation about the board. When I measure the boards current, then I have an shunt factor of 22,5. I think calculating with 20 is ok.

[NeverDie]

@d00616
Thanks! I just now ordered one of your boards so that in the future we can share a common platform for comparing numbers. :)
https://www.aliexpress.com/item/NRF52832-Mini-Development-Board-Gold-Core-board-Wireless-Bluetooth-Transceiver-Module/32798618219.html?spm=2114.search0204.3.1.GUmybP&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10130_5490020_10068_5430020_5410020_10307_10137_10060_10155_10154_10333_10334_10056_5370011_10335_10055_10336_10054_10059_10332_100031_10099_5400020_10103_10102_10052_10053_10107_10050_10142_10051_10324_10325_5380020_10326_5390020_10084_10083_10080_10082_10081_10178_10110_10111_10112_10113_10114_10312_10313_10314_10316_10078_10079_10073_5420011-10332_10333,searchweb201603_5,ppcSwitch_4_ppcChannel&btsid=78a27a2f-4aa5-49a0-a538-502a2c86d8f2&algo_expid=598ae4bb-6401-4529-89ad-6e8d8a90af12-0&algo_pvid=598ae4bb-6401-4529-89ad-6e8d8a90af12&transAbTest=ae803_3

[By the way, I did my measurements on an Ebyte nRF52832 module]

[scalz]

in that case, you need to set it as a floating input i think, like it's generally at reset.
In datasheet, section 20 (p111), is explained how works the GPIO. You have a Bit for disconnecting it. See the PIN_CNF[n] registers. For instance, p.140, you can see how it looks for the P0.10, and the Bit 1.
This should do the job..

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Thanks! I just now ordered one of your boards so that in the future we can share a common platform for comparing numbers.

Ok. I have measured my Ebyte with the same sketch and in the µA range of my VC165 multimeter. Sleep current is 9.9µA with two ports in INPUT_PULLUP and one Port in OUTPUT_H0H1 mode. (b.t.w. this module costs actually 3,82€)

@scalz said in nRF5 Bluetooth action!:

in that case, you need to set it as a floating input i think, like it's generally at reset.
In datasheet, section 20 (p111), is explained how works the GPIO. You have a Bit for disconnecting it. See the PIN_CNF[n] registers. For instance, p.140, you can see how it looks for the P0.10, and the Bit 1.
This should do the job..

Should I add a DISCONNECTED mode to hwPinMode()?

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

Sleep current is 9.9µA with two ports in INPUT_PULLUP and one Port in OUTPUT_H0H1 mode....

Ah, maybe that's part of the difference. I was doing just:

pinMode(ALPHA_PIN, INPUT)
pinMode(BETA_PIN, OUTPUT)

because that's how I would have done it on an Arduino. Should we instead always use INPUT_PULLUP and OUTPUT_H0H1 instead?

[rmtucker]

@NeverDie
Should be

hwPinMode(DIGITAL_INPUT_SENSOR, INPUT_PULLUP);

According to NRF5 platform

[NeverDie]

Thanks! Somehow didn't remember that.

So, as suggested by @scalz what is some example code that can be used to "disconnect" the pin later?

[rmtucker]

@NeverDie
He has not added that facility yet,i think he asked you if you wanted it adding to the code?

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

if you wanted it adding to the code?

Definitely!

[scalz]

for unused pins, it should be floating, not pullup. set the pin register you need to 0x02.
Something like that
NRF_GPIO->PIN_CNF[ulPin] = 0x02;
that will put pin in same state like it's on reset. Everything disabled/default, floating, with disconnect bit set.
(see datasheet gpio).

@d00616 said in nRF5 Bluetooth action!:

Should I add a DISCONNECTED mode to hwPinMode()?

make sense to have it for input too.. i agree :simple_smile:

[NeverDie]

Maybe add:
OUTPUT_D0D1 -> Disconnected 0, Disconnected 1
or similar to your list as another easy way to effectuate the disconnect?

[NeverDie]

It finally makes sense now as to why there were all those "disconnected" choices among the various OUTPUT options. In my case, for controlling whether the solar panel is connected or disconnected, choosing OUTPUT_S0D1 works perfectly. :)

So, I suppose another way to disconnect an input pin would be to redefine it as an OUTPUT pin with a disconnect state, and then immediately put it into the disconnected state.

[rmtucker]

@d00616 said in nRF5 Bluetooth action!:

@rmtucker said in nRF5 Bluetooth action!:

Yes being able to change the prescaler dynamically would help a great deal as 125ms / 582.542 hours is not really useful for most applications with a 250ms overrun.

The sleep() function is now more precise for sleeping <512s:

https://github.com/mysensors/MySensors/pull/909

The PR is waiting for merge.

Hmm just tried the latest commit and it is giving me 306ms for sleep(10000).
Something not quite right.

[NeverDie]

@rmtucker
How are you measuring how long it's sleeping?

[rmtucker]

@NeverDie said in nRF5 Bluetooth action!:

@rmtucker
How are you measuring how long it's sleeping?

Just using hwMillis() before and after sleep and subtracting one from the other.
It was just reading + 250ms until @d00616 commited some changes a few hours ago.

[rmtucker]

something wrong in here:-

// Calculate sleep time and prescaler
		if (ms<512000) {
			// prescaler 0, 30.517 μs resolution -> max 512 s sleep
			MY_HW_RTC->PRESCALER =  0;
			// Set compare register to 1/30.517 µs to garantee event triggering
			// A minimum of 2 ticks must be guaranteed
			// (1000/32768)<<12 == 125
			MY_HW_RTC->CC[0] = max((ms<<12 / 125), 2);
		} else {
			// 8 Hz -> max 582.542 hours sleep.
			MY_HW_RTC->PRESCALER = 4095;
			// Set compare register to 1/125ms
			// A minimum of 2 ticks must be guaranteed
			MY_HW_RTC->CC[0] = max((ms / 125), 2);
		}

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

@rmtucker
How are you measuring how long it's sleeping?

Just using hwMillis() before and after sleep and subtracting one from the other.
It was just reading + 250ms until @d00616 commited some changes a few hours ago.

I thought so. The point being: doesn't millis stop when you're deep sleeping? Well, at least on an Arduino it does. Not sure what it does on the nRF5.

[rmtucker]

@NeverDie
No the nrf5 has a rtc.(Real time Counter)
It can even keep time while sleeping.(just found this out myself!).
That is a great leap forward on the arduino.