Battery Service reading adc value from other GPIO

[Zachary16]

Hi everyone,

I have connected a potentiometer to a GPIO pin (AIN2) and would like to show the varying values in the battery service.

I was wondering if there's any way for me to amend the battery service so that the service can read other ADC/voltage value from other GPIO pins.

Tools:

• nRF52832
• nRF52DK
• nRF5_SDK_17.1.0
• 132 softdevice

Thanks,

Zachary

[Jared]

Hi,

A good start would be to merge the SAADC example into the battery service example. You should also take a look at our ble_app_uart__saadc_timer_driven__scan_mode example on GitHub which shows how you can use the SAADC with the Softdevice,

regards

Jared 

[Zachary16]

Hi Jared,

thanks for the reply. I have actually tried to merge the saadc and battery service together. 

What I’ve encountered during connection, was that the battery level from the battery service will always be 100%. I’ve also tried powering up the DK with the USB or external power supply (2.6V), but it also still 100%. 

I have also seen some old post regarding this however, the author did not further explain his solution.( https://devzone.nordicsemi.com/f/nordic-q-a/2377/battery-level-service-on-custom-profile)

My concerns are:

1. Why the battery level is always at 100%

2. Is there a way for me to input the adc reading from a GPIO pins into the battery service. 

Regards,

Zachary

[Jared]

Hi,

Zachary16 said:

Why the battery level is always at 100%

Not sure I understand your question correctly. The pin that is sampled in the code that you shared is VDD, and you're wondering why the supply is at constant 100% while you supply it via USB?

I would expect the sampled value to be constant if you supply the board via the USB, which would result in the return value from battery_level_in_percent() to be constant. For example if you're supplying the board via a computer.  

Maybe I misunderstood you? In that case, please elaborate. 

Can you set a breakpoint in saadc_callback_handler() and see what p_event->data.done.p_buffer[i] is? Is it constant?

regards

Jared 

[Zachary16]

Hi Jared,

thank you so much for your kind reply and patience with me. I apologise for my broken english and I'm rather new to Nordic.

What I meant was when I supplied the board via the external supply or USB (which was powering less than 3V), the battery level should be less than 100% due to the "app_util.h" file, as it states that any voltage level that is less than 3V should not be 100%. (correct me if I'm wrong).

Hence, I was puzzled when I supplied a 2.5V to the board via the external supply, the battery level in the application remains 100% or 0% after a couple of refreshes. Whereas, I've tried the "ble_app_proximity" example, the battery level reading were quite accurate. (E.g. 2.4V = 18%, 2.1V = 1%). The difference between the example and my code was the way we sample our adc reading. Will this affect how the battery service reads the voltage? 

Jared said:

Can you set a breakpoint in saadc_callback_handler() and see what p_event->data.done.p_buffer[i] is? Is it constant?

I've attached a screenshot the debug and breakpoint in saadc_callback_handler and I've realised that in the debugging terminal, no log was activated and there where no actions or errors while debugging. 

I'm not sure if I've done it correctly, please advice me. 

Once again, thank you for your kind reply and patience. I truly appreciate your time and effort. 

Regards,

Zachary

[Jared]

Zachary16 said:

thank you so much for your kind reply and patience with me. I apologise for my broken english and I'm rather new to Nordic.

What I meant was when I supplied the board via the external supply or USB (which was powering less than 3V), the battery level should be less than 100% due to the "app_util.h" file, as it states that any voltage level that is less than 3V should not be 100%. (correct me if I'm wrong).

Hence, I was puzzled when I supplied a 2.5V to the board via the external supply, the battery level in the application remains 100% or 0% after a couple of refreshes. Whereas, I've tried the "ble_app_proximity" example, the battery level reading were quite accurate. (E.g. 2.4V = 18%, 2.1V = 1%). The difference between the example and my code was the way we sample our adc reading. Will this affect how the battery service reads the voltage? 

I understand. When you supply 2V5 to the board externally, is the 5V USB still connected?

Zachary16 said:

I've attached a screenshot the debug and breakpoint in saadc_callback_handler and I've realised that in the debugging terminal, no log was activated and there where no actions or errors while debugging. 

I'm not sure if I've done it correctly, please advice me. 

Could you set the breakpoint at line 120, and check the value of p_event->data.done.p_buffer[i]? You can check it by adding it to watch:

Note, that Softdevice applications requires you to restart the application after it has been paused. It will assert if you try to resume it. See this and this for more.

regards

Jared 

[Zachary16]

Hi Jared,

Thank you for your reply.

Jared said:

I understand. When you supply 2V5 to the board externally, is the 5V USB still connected?

no, the USB was disconnect from the board.

I've realised that the problem in my code was that the SAMPLE_BUFFER_LENS was at 5 hence causing the battery level to display only 0%.

I have used the link that you provided earlier on and change the way I sample the adc. I changed SAMPLE_BUFFER_LENS to 1 and used oversampling and burst to give me a more accurate reading.

Jared said:

Could you set the breakpoint at line 120, and check the value of p_event->data.done.p_buffer[i]? You can check it by adding it to watch:

I have tried to do this however, it seems like the debugger did not stop at the breakpoint and the callback function is still running. I have attached a screenshot for reference.

Could you kindly explain to me how debugging actually work? Does debugging only stops when there is an error in the code? and what information I can get from doing a debugging?

regards,

Zachary

[Jared]

Zachary16 said:

I've realised that the problem in my code was that the SAMPLE_BUFFER_LENS was at 5 hence causing the battery level to display only 0%.

Ok, so the problem is solved? What does the battery level show now?

Zachary16 said:

I have tried to do this however, it seems like the debugger did not stop at the breakpoint and the callback function is still running. I have attached a screenshot for reference.

Could you kindly explain to me how debugging actually work? Does debugging only stops when there is an error in the code? and what information I can get from doing a debugging?

Where is the breakpoint in the screenshot that you've shared? I was interested to see the value of p_event->data.done.p_buffer[i] when the callback handler is returned:

Jared said:

Could you set the breakpoint at line 120, and check the value of p_event->data.done.p_buffer[i]? You can check it by adding it to watch:

See this for an explanation on debugging.

regards

Jared

[Zachary16]

Hi Jared, 

Jared said:

Ok, so the problem is solved? What does the battery level show now?

Yes, the problem have been partially solved. The problem i faced now is that every time I established a connection between the DK and nRF Connect App, the initial battery level (100%) will appear and only change the value after 20 secs (below 100% depending on the voltage input/adc reading). Is there a way that I can omit the 100% and allow the DK to show the accurate value immediately after connection. 

Jared said:

Where is the breakpoint in the screenshot that you've shared? I was interested to see the value of p_event->data.done.p_buffer[i] when the callback handler is returned:

Apologies for uploading the wrong image. I have attached a photo with the proper breakpoint.

Jared said:

See this for an explanation on debugging.

Thank you for sharing this link. I've watched this video hence, I've assume that the debugger will only stops if there's an error in the code. Whereas, during my trial of debug of my own code, the callstack will keep running and do not stop at the breakpoint. 

Regards,

Zachary

[Jared]

Hi,

Zachary16 said:

Is there a way that I can omit the 100% and allow the DK to show the accurate value immediately after connection. 

The sampling in your application is started by the saadc timer, you can do a sample right after a connection by calling nrf_sample() in the BLE_GAP_EVT_CONNECTED event in the ble event handler. 

Zachary16 said:

Thank you for sharing this link. I've watched this video hence, I've assume that the debugger will only stops if there's an error in the code. Whereas, during my trial of debug of my own code, the callstack will keep running and do not stop at the breakpoint. 

The debugger should stop at the breakpoint. Are you sure the program reach the breakpoint? Try to output a log in the handler and see if it's printed out in the terminal. 

regards

Jared 

[Zachary16]

Hi Jared,

Jared said:

The sampling in your application is started by the saadc timer, you can do a sample right after a connection by calling nrf_sample() in the BLE_GAP_EVT_CONNECTED event in the ble event handler. 

Thank you for this advice. I no longer see 100% in the nRF Connect App.

Jared said:

The debugger should stop at the breakpoint. Are you sure the program reach the breakpoint?

Sorry if this may sound silly, but how do I tell if the program reach the breakpoint. In other program that I've run, the debugger will reach the breakpoint within seconds. Was I supposed to let it run for a couple of mins or hours?

Regards,

Zachary

[Jared]

Hi,

If the program never stops at the set breakpoint within reasonable time, you can assume that the program never reaches that breakpoint. How long depends on your application, and when you start sampling. You can try to pause the program and see where it's currently at. In the code that you shared I see that you have commented out the line which starts the SAADC timer, have you remembered to include this line when you test?

regards

Jared