Current consumption issue in the continuous ADC mode of data collection in CYBLE 416045-2

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
anikseng
Level 2
Level 2
25 sign-ins 10 replies posted 5 questions asked

Hello,

I have a program which is continuously sampling data until 240 bytes of data and then print the data and then the cycle continues. The board needs to be powered up at 3.3 V supply only.

 

The current I am measuring with this setup is around 4mA. I have several other methods from the cy_syspm.c to lower down the power but none of them seems to work. The project of mine is attached herewith.

 

Could anyone tell me some method to lower down the current?

 

Looking forward to hear from you.

 

Thanking you,

Anik Sengupta

0 Likes
11 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Anik,

Without looking at your code my first impression is that your 4mA in "continuously sampling data until 240 bytes of data and then print the data " mode is pretty good.  This is a lower current than many of my other projects where the CPU is awake all the time.

Beside it appears you are awake 100% of the time, you will consume more current than you will when you are asleep.

Additionally in low power mode, the ADC and the UART (I assume this is the "print" device mentioned.) are disabled.

If you re awake 100% of the time, the only practical way to lower the current is to lower the BUS_CLK frequency.

Here is the PSoC63 datasheet spec on Iddd current based on Core CPU frequency.

Len_CONSULTRON_0-1672813334031.png

If you are running on the CM4 core @ 30MHz with the CM0+ core asleep,  Iddd is about 2mA.

However, if you run your application on the CM0+ core @ 10MHz with the CM4 core asleep, Iddd is about 0.5mA.

 

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
anikseng
Level 2
Level 2
25 sign-ins 10 replies posted 5 questions asked

Hey @Len_CONSULTRON ,

 

Thank you for the advice. I am very new to this PSoC device. Could you tell me how to change the Bus_Clk frequency in PSoC creator.

 

also I am going to enable BLE to send this data over. The bus clk frequency won’t affect the BLE performance I suppose

 

looking forward to hearing from you

 

thanking you

anik Sengupta 

0 Likes

Anik,

The clock being used by the CM0+ core is Clk_Slow.

The clock being used by the CM4 core is Clk_Fast.

If you are trying to achieve the target current of 0.5mA then you need to set the CM0+ core clock to 10MHz.

To do so, you need to set the Clk_Slow Divider to 5.  Here is a screenshot of the items that need to be selected (in the RED boxes) to get to that setting.

Len_CONSULTRON_0-1672841399304.png

The CM4 core can be left to the standard setting since it will be sleeping. (ie. < 10uA).

Normally the CM0+ core is the core that handles BLE message processing.  Slowing down this clock will process the BLE messages slower.  I don't if this will be a problem for you.

Note:  You didn't mention that you were planning on BLE comm in the original post.

Question: When you measured the 4mA current was it using a digital multimeter (DMM)?

If so,  note that readings from the DMM tend to be averaged over a period of time.   If you had your BLE component configured, it will attempt a wakeup at the intervals you prescribed.  When the BLE wakes up, it will consume 10mA to 20mA in Tx mode or 15mA to 18mA in Rx mode for a very short time.  This will contribute to your overall cur

Len
"Engineering is an Art. The Art of Compromise."
anikseng
Level 2
Level 2
25 sign-ins 10 replies posted 5 questions asked

Hello @Len_CONSULTRON ,

 

Thank you for the elaborate advice. I changed the clk_slow to 10 MHz

Right now I am not using the BLE component for now. I am just focussing on the ADC data only. I observed that with slow frequency of 10 MHz I am getting about 3mA. 

And Yes I am measuring the current through DMM.Is there any thing I am doing wrong?

Looking forward to hear from you

 

 

Thanking you,

Anik Sengupta

0 Likes

 

Anik,

The graph above is the effect of the CPU frequency on the IDDD current ONLY.

Peripherals and other resources turned on ADD to the current consumption.

I had forgotten to mention the following spec for current consumption of the ADC.

Len_CONSULTRON_0-1672926580293.png

You can see that the SAR ADC adds at least 1mA to IDDD.

By lowering the CPU frequency, you've lowered the IDDD current from 4mA to 3mA.  That's a good thing.

In the long term to significantly lower the IDDD current, you need to put the CPU cores asleep. for a significant amount of time.

In your present project, you are continuously sampling ADC and pushing the data out a UART.   This does not lend itself to going to sleep often.

Allow me to make suggestions that may lower IDDD further.

Suggestion 1

If possible, minimize the sample conversion time AND reduce the ADC sampling rate.    Get it working WITHOUT putting the CMO+ to sleep.   

Set the ADC to a one-stop sampling.

Add a ADC soc timer interrupt to start the sampling.

Add an ADC eoc (End of Conversion) interrupt to retrieve the sampled data.

By minimizing the time to convert the sample, this shortens the time for the SAR ADC needs to be active.

Reducing the sampling frequency means the SAR ADC needs to be active less often.

The goal here is to minimize the ADC resource needing to be active.

Suggestion 2

Do not dump the ADC data accumulated UNTIL all 240 bytes are collected.  Get it working WITHOUT putting the CMO+ to sleep.    This counting can be done in the ADC eoc interrupt.

Using the ADC data count of 240 bytes becomes the "data dump event".   With the event, you can make causing the data dump resource to be efficiently used.

The goal here is only need the dumping resource when all the data is available.

Suggestion 3

Change the UART over to the USB_UART.  Get it working WITHOUT putting the CMO+ to sleep. 

The advantage of the USB_UART over the UART is that the UART resources must stay active/awake for the entire transfer of the data packet.  Therefore if your data rate is 115.2Kbps @ 8N1 and you transfer 240 bytes the UART needs to stay active for (240bytes * 10bits/byte /115200bits/sec 😃 20.8 ms.

With the USB_UART, it actually transfers the data at USB data rates which is usually better than 10Mbits/sec in 64 byte packets.   On the PC, this data is normally buffered internally to allow for the COM: data rate chosen by the user (ie. 115.2Kbps).  Therefore 240 bytes will be broken up into four 64 byte packets.  Approximate transfer time: 240us.

The goal here is minimize the total time needed for the USB_UART resource allowing the CMO+ core to sleep longer.

 

The next suggestion deal with forcing the CM0+ to sleep as often as possible and only needs the resources active for the minimum time needed.

Remember you will probably need to 'Save' and 'Restore' the configuration of the resource before and after sleep.

Suggestion 4

With Suggestions 1, 2 and 3 working, code the core sleep between samples.  

In this suggestion, the ADC soc timer interrupt should wake up the CM0+ core and start the ADC conversion.  The ADC remains active and on until the conversion is complete.  This would generate the eoc interrupt. 

Once the eoc interrupt is done,  Save the ADC state and check if the "data dump event" (dd_evt) flag.

If the dd_evt is active, start the 240 byte data dump event to the USB_UART.  Otherwise, put the CM0+ into sleep mode and wait for the next ADC soc timeout.

Test for the USB_UART to complete.  Once completed, Save the USB_UART state and put the CM0+ into sleep mode and wait for the next ADC soc timeout.

In theory let's look at the power savings available.  (Assumption: CM4 always asleep.)

  • CM0+ active IDDD with ALL needed resources active = 3mA
  • CM0+ sleep mode selected = 0.010mA
  • Average on time = 30ms per second.  This is a ON/TOTAL time ratio = 30/1000 = 3%

This means that your average IDDD = (3mA * 3% ) + (0.010mA * 97%) = 0.0997 mA

Your real data based on the ADC conversion rate, sampling rate and USB_UART data rate * bytes sent.

This study is BEFORE you need additional resources (such a BLE).  But by minimizing the resource ON time and going to sleep more often will help you meet your IDDD target goals.

I hope this helps.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Anik,

Sorry if I'm an annoyance.

I looked at your project's TopDesign schematic.  I have a few questions and some observations.

Here is a clip of the ADC of your schematic:

Len_CONSULTRON_0-1672933527550.png

Question:  Why are you using the pin as a Analog input AND digital output set to the default High (1)?

I don't see the logic here.   In fact, I'm amazed that the Application Build phase is not complaining.

Observation:  Your ADC is for each input is "Single-End (S/E)" and  "Vneg for S/E": configuration is:

Len_CONSULTRON_1-1672933749816.png

For the 'best' single-ended GND reference, I recommend setting  "Vneg for S/E" = Vssa.

Using "Vneg for S/E" = External is to applied a using a 'floating' or adjustable GND reference for the inputs.   Is this your intention?

If this is your intent, get rid of the Digital output in the configuration of your 'GND' pin 10[6].

 

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
anikseng
Level 2
Level 2
25 sign-ins 10 replies posted 5 questions asked

Hello @Len_CONSULTRON ,

 

First of all sorry for the late reply, I was busy with some coursework.

Thank you for the elaborate suggestion of the current issue on how to reduce it. I would work on that.

 

And yes the GND pin is actually an analog input with external connection. I do have one issue is that with scan rate of 10000 sps or 100000 sps we see that the waveform is not exactly what we can see in the input signal in the oscilloscope. Could you please help with this?

0 Likes

Anik,

I've looked at your presentation.

With sampling only ONE analog input, at 10,000 SPS, you are only sampling the 1KHz wave 10 times in one sine cycle.  At 100,000 SPS, you are sampling 100 times in one sine cycle.

This is one of the reasons why the 100,000 SPS waveform looks more like the input wave.

If you are evenly sampling across more than one analog input, you can take the number of sample per sine cycle and divide by the number of analog channels sampled.   Therefore it will be even less like the input wave.

My guess is that you are sampling two analog input channels.  I can see by the 10,000 SPS data output 5 samples per sine cycle.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
anikseng
Level 2
Level 2
25 sign-ins 10 replies posted 5 questions asked

Hello @Len_CONSULTRON ,

 

Yess I am showing the result from only one analog channel. But is there a way to get the analog sine signal the way it is being inputted. I know with 100000 sps i sample the 1KHz signal 100 times. But do you know any method I get the sine wave a lot more smoother?

 

Thanking you,

Anik Sengupta

0 Likes

Anik,

My question is are you sampling more than one channel?  In your schematic you show two inputs into the Scan_SAR. 

Len_CONSULTRON_0-1673539330531.png

 

In your pptx presentation you show 4 analog inputs.

Len_CONSULTRON_1-1673539383645.png

If you sample more than one input your Scan_SAR sampling rate of 100,000 gets divided by the number of channels being sampled.

Second Question:  Th project you supplied in the first thread. is this the project you are using to get the results where you're having issues?

 

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Anik,

You still haven't answer my previous two questions.

Here's a third question:   How are you acquiring the output waveforms shown in the pptx?

If you're dumping using the UART in the TopDesign to a serial data plotting program, I might have the reason the plot is not to smooth as you hope (ie 100 samples per cycle @ 100,000 ADC sps.)

First, your UART is set to 115.2Kbps 8N1.  This means the fastest the UART can send data is 11,520 bytes per send.  Therefore sending only one byte (8-bit) per byte the 100,000 sps becomes 11,520 sps at best.  Although the ADC can convert as fast as 100,000 sps only 11% of the actual data will be transferred through the UART.

I noticed your Scan_ADC is set to 12-bits resolution.  This means every sample is 2-bytes (16-bits).

In this case if you're sending 2-bytes through the UART, then you can only get half as many samples transferred at best (5720 sps).   With an input of 1KHz sine wave, you 5 to 6 samples per sine cycle.

 

The problem you are facing is what is termed a data "bottleneck".   

Solutions:

  • Speed up the UART data rate if you can.
  • Use the full-speed USB port to transfer data.   In most conditions you can get 1MByte/sec transfer.
  • Instead of sending continuous data, capture as much data as you can afford in a RAM buffer BEFORE sending it through your communication channel.  Once the transfer is fully complete, you can recapture the next set of buffered.
Len
"Engineering is an Art. The Art of Compromise."
0 Likes