nRF5 action!

NeverDie

Anyone have a good sketch for measuring the battery supplied voltage on an nRF52? Some of the concepts from the old atmega328p may apply, but the specifics are going to be different, I'm sure.

Mike_Lemo

Check on adafruits feather reference they use two resistors as a voltage divider for that simple and effective.

NeverDie

@Mike_Lemo said in nRF5 Bluetooth action!:

Check on adafruits feather reference they use two resistors as a voltage divider for that simple and effective.

I'm not finding it. Do you have a link?

Mike_Lemo

@NeverDie https://learn.adafruit.com/assets/39913

Top right corner of the schematic.

Mike_Lemo

@NeverDie but a much better but more expensive solution would be a lipo fuel guage from spark fun they use a Max chip for that.

Nca78

If supplied with less than 3.6V you can do it with ADC, 1.2V voltage reference and 1/3 prescaling.
But I've only looked at the theory yet.

Rules are Vdd+0.3V max at the pin, and max 2.4V as input of ADC (after prescaling)

NeverDie

Well, as you all know, on the atmega328p you can read the 1.1v gap voltage using the battery voltage as the reference voltage, by doing analogRead(A0), and from just that one measurement then calculate the battery voltage by doing a little bit of math. So, I'm just wondering what the code is to do the equivalent of that (using 1.2v instead of 1.1v) on the nRF52832.

d00616

@Nca78 said in nRF5 Bluetooth action!:

If supplied with less than 3.6V you can do it with ADC, 1.2V voltage reference and 1/3 prescaling.
But I've only looked at the theory yet.

For this, you can use the implemented hwCPUVoltage() function. Reading the voltage costs nRF51: 260µA/20µs | nRF52: 700µA/3µs

NeverDie

@d00616 said in nRF5 Bluetooth action!:

hwCPUVoltage()

I'm finally installing Visual Micro, because I hope it will help me quickly find where all these functions are defined. With all these new layers, the Arduino IDE is just no longer cutting it.

NeverDie

LOL. Well, Visual Micro found it alright, but just in the wrong place. It found it in MyHwAVR.cpp

scalz

@NeverDie said in nRF5 Bluetooth action!:

@d00616 said in nRF5 Bluetooth action!:

hwCPUVoltage()

I'm finally installing Visual Micro, because I hope it will help me quickly find where all these functions are defined. With all these new layers, the Arduino IDE is just no longer cutting it.

good choice :+1:
for nrf5, the function is located in MyHwNRF5.cpp

NeverDie

@d00616 said in nRF5 Bluetooth action!:

For this, you can use the implemented hwCPUVoltage() function.

I tried this function call on an nRF52 DK, and it seems to work. I then tried it on an Ebyte module, treated as an nRF52 DK "board", and it reported zero voltage. So, probably I just need to do a pin mapping so that it reads the voltage on the proper pin. But which pin/mapping would it be? I thought that Vcc wouldn't really be mappable to anything but Vcc. I guess whichever analog pin (if that's what it is?) is connected to Vcc on the nRF52 DK is the pin I need to find and re-map to its equivalent pin on the Ebyte module. Hmmm.... I'll have to look into which one that would be.

NeverDie

Actually, something different may be going on. Here's the function definition:

uint16_t hwCPUVoltage()
{
	// VDD is prescaled 1/3 and compared with the internal 1.2V reference
	Serial.println("Inside hwCPUVoltage function.");
#if defined(NRF_ADC)
    Serial.println("This is an NRF_ADC.");
	// NRF51:
	// Sampling is done with lowest resolution to minimize the time
	// 20uS@260uA

	// Concurrent ressource: disable
	uint32_t lpcomp_enabled = NRF_LPCOMP->ENABLE;
	NRF_LPCOMP->ENABLE = 0;

	// Enable and configure ADC
	NRF_ADC->ENABLE = 1;
	NRF_ADC->CONFIG = (ADC_CONFIG_EXTREFSEL_None << ADC_CONFIG_EXTREFSEL_Pos) |
	                  (ADC_CONFIG_PSEL_Disabled << ADC_CONFIG_PSEL_Pos) |
	                  (ADC_CONFIG_REFSEL_VBG << ADC_CONFIG_REFSEL_Pos) |
	                  (ADC_CONFIG_INPSEL_SupplyOneThirdPrescaling << ADC_CONFIG_INPSEL_Pos) |
	                  (ADC_CONFIG_RES_8bit << ADC_CONFIG_RES_Pos);
	NRF_ADC->EVENTS_END = 0;
	NRF_ADC->TASKS_START = 1;
	while(!NRF_ADC->EVENTS_END);
	NRF_ADC->EVENTS_END = 0;
	int32_t sample = (int32_t)NRF_ADC->RESULT;
	NRF_ADC->TASKS_STOP = 1;
	NRF_ADC->ENABLE = 0;

	// Restore LPCOMP state
	NRF_LPCOMP->ENABLE = lpcomp_enabled;

	return (sample*3600)/255;

#elif defined(NRF_SAADC)
	// NRF52:
	// Sampling time 3uS@700uA
	Serial.println("This is an NRF_SAADC.");
	int32_t sample;
	NRF_SAADC->ENABLE = SAADC_ENABLE_ENABLE_Enabled << SAADC_ENABLE_ENABLE_Pos;
	NRF_SAADC->RESOLUTION = SAADC_RESOLUTION_VAL_8bit << SAADC_RESOLUTION_VAL_Pos;
	NRF_SAADC->CH[0].PSELP = SAADC_CH_PSELP_PSELP_VDD << SAADC_CH_PSELP_PSELP_Pos;
	NRF_SAADC->CH[0].CONFIG = (SAADC_CH_CONFIG_BURST_Disabled << SAADC_CH_CONFIG_BURST_Pos) |
	                          (SAADC_CH_CONFIG_MODE_SE << SAADC_CH_CONFIG_MODE_Pos) |
	                          (SAADC_CH_CONFIG_TACQ_3us << SAADC_CH_CONFIG_TACQ_Pos) |
	                          (SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos) |
	                          (SAADC_CH_CONFIG_GAIN_Gain1_6 << SAADC_CH_CONFIG_GAIN_Pos) |
	                          (SAADC_CH_CONFIG_RESN_Bypass << SAADC_CH_CONFIG_RESN_Pos) |
	                          (SAADC_CH_CONFIG_RESP_Bypass << SAADC_CH_CONFIG_RESP_Pos);
	NRF_SAADC->OVERSAMPLE = SAADC_OVERSAMPLE_OVERSAMPLE_Bypass << SAADC_OVERSAMPLE_OVERSAMPLE_Pos;
	NRF_SAADC->SAMPLERATE = SAADC_SAMPLERATE_MODE_Task << SAADC_SAMPLERATE_MODE_Pos;
	NRF_SAADC->RESULT.MAXCNT = 1;
	NRF_SAADC->RESULT.PTR = (uint32_t)&sample;

	NRF_SAADC->EVENTS_STARTED = 0;
	NRF_SAADC->TASKS_START = 1;
	while (!NRF_SAADC->EVENTS_STARTED);
	NRF_SAADC->EVENTS_STARTED = 0;

	NRF_SAADC->EVENTS_END = 0;
	NRF_SAADC->TASKS_SAMPLE = 1;
	while (!NRF_SAADC->EVENTS_END);
	NRF_SAADC->EVENTS_END = 0;

	NRF_SAADC->EVENTS_STOPPED = 0;
	NRF_SAADC->TASKS_STOP = 1;
	while (!NRF_SAADC->EVENTS_STOPPED);
	NRF_SAADC->EVENTS_STOPPED = 1;

	NRF_SAADC->ENABLE = (SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos);

	return (sample*3600)/255;
#else
	Serial.println("Unknown MCU!!");
	// unknown MCU
	return 0;
#endif
}

One, perhaps likely, theory would be that it doesn't recognize the MCU, which would explain why it returns the value of zero. Well, to debug that, I added the Serial.println(...) statements into the library code (see above) in an attempt to see which of the if-else branches is being taken, but none of the Serial.println(...)'s were printed! Here's a sample of the output from the Ebyte Module:

332641 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
332968 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
332973 TSF:MSG:FPAR OK,ID=0,D=1
334649 TSM:FPAR:OK
334650 TSM:ID
334651 TSM:ID:REQ
334654 TSF:MSG:SEND,255-255-0-0,s=59,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
336662 TSM:ID
336663 TSM:ID:REQ
336665 TSF:MSG:SEND,255-255-0-0,s=23,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
338673 TSM:ID
338674 TSM:ID:REQ
338676 TSF:MSG:SEND,255-255-0-0,s=242,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
340684 TSM:ID
340685 TSM:ID:REQ
340687 TSF:MSG:SEND,255-255-0-0,s=205,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
342695 !TSM:ID:FAIL
342696 TSM:FAIL:CNT=7
342698 TSM:FAIL:DIS
342700 TSF:TDI:TSL
402703 TSM:FAIL:RE-INIT
402705 TSM:INIT
402706 TSM:INIT:TSP OK
402708 TSM:FPAR
402711 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
403472 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
403478 TSF:MSG:FPAR OK,ID=0,D=1
404719 TSM:FPAR:OK
404720 TSM:ID
404721 TSM:ID:REQ
404724 TSF:MSG:SEND,255-255-0-0,s=241,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
406732 TSM:ID
406733 TSM:ID:REQ
406735 TSF:MSG:SEND,255-255-0-0,s=205,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
408743 TSM:ID
408744 TSM:ID:REQ
408747 TSF:MSG:SEND,255-255-0-0,s=168,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
410754 TSM:ID
410755 TSM:ID:REQ
410757 TSF:MSG:SEND,255-255-0-0,s=131,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
412765 !TSM:ID:FAIL
412766 TSM:FAIL:CNT=7
412768 TSM:FAIL:DIS
412770 TSF:TDI:TSL
472773 TSM:FAIL:RE-INIT
472775 TSM:INIT
472776 TSM:INIT:TSP OK
472778 TSM:FPAR
472781 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
472955 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
472960 TSF:MSG:FPAR OK,ID=0,D=1
474789 TSM:FPAR:OK
474790 TSM:ID
474791 TSM:ID:REQ
474794 TSF:MSG:SEND,255-255-0-0,s=167,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
476802 TSM:ID
476803 TSM:ID:REQ
476805 TSF:MSG:SEND,255-255-0-0,s=131,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
478813 TSM:ID
478814 TSM:ID:REQ
478816 TSF:MSG:SEND,255-255-0-0,s=94,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
480824 TSM:ID
480825 TSM:ID:REQ
480827 TSF:MSG:SEND,255-255-0-0,s=57,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
482835 !TSM:ID:FAIL
482836 TSM:FAIL:CNT=7
482838 TSM:FAIL:DIS
482840 TSF:TDI:TSL

I'm not quite sure how to interpret that, but pretty clearly it doesn't contain the println's that I was expecting.

Any theories as to what's going on?

NeverDie

Bracketing that and setting it aside, I do now notice this line in the BatteryPoweredSensor demo sketch:

int BATTERY_SENSE_PIN = A0;  // select the input pin for the battery sense point

So, if I map that A0 in the sketch to the A0 of the Ebyte Module, then maybe (hopefully) the voltage measurement will work on the Ebyte Module. I'll give it a try.

NeverDie

Unfortunately, after I add:

#include <mySensors.h>

the locus of control goes somewhere else (I guess the gateway or something?). Anyhow, it makes this very hard to debug.

For instance, the pin of interest is PIN_AIN0. I can't find where it's defined, and I can't print out its value either, because of this locus of control issue.

Anyhow, I think I may wait for others to get up and running with their modules, and start facing the same issues. Maybe then we can help each other figure this stuff out.

d00616

@NeverDie I don't know why the println() doesn't work. There is an "DEBUG_OUTPUT(x, ##VA_ARGS)" macro, you can use when debug is enabled.

NRF_ADC is the nRF51 ADC and NRF_SAADC is the ADC of the nRF52. They are defined when "nrf.h" is included.

What board type have use used for your tests?

NeverDie

@d00616 said in nRF5 Bluetooth action!:

What board type have use used for your tests?

The nRF52832 Ebyte Module.

Terrence

@NeverDie VS Code with the Arduino Extension is your friend.

NeverDie

@d00616 said in nRF5 Bluetooth action!:

What board type have use used for your tests?

I just re-read your question and realized you were asking something else than the question that I answered above.

Answer: nRF52 DK is the board type, because I wired directly to P0.06 as its Tx pin on the Ebyte nRF52832 Module.

NeverDie

@Terrence said in nRF5 Bluetooth action!:

VS Code with the Arduino Extension is your friend.

I'll try that. Maybe it will be a little less of a learning curve than Visual Micro yet still do what I need.

nRF5 action!

9

11.7k

11.2k

113.0k