element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Achievement Levels
    • Benefits of Membership
    • Feedback and Support
    • Members Area
    • Personal Blogs
    • What's New on element14
  • Learn
    Learn
    • eBooks
    • Learning Center
    • Learning Groups
    • STEM Academy
    • Webinars, Training and Events
  • Technologies
    Technologies
    • 3D Printing
    • Experts & Guidance
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Arduino Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Project Groups
    • Raspberry Pi Projects
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Or choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
RoadTests & Reviews
  • Products
  • More
RoadTests & Reviews
Blog SimpleLink™︎ Sub-1 GHz Wireless Microcontroller - Side Note : Measure Power Use of Sensor Controller Engine
  • Blog
  • RoadTest Forum
  • Documents
  • RoadTests
  • Reviews
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
RoadTests & Reviews requires membership for participation - click to join
  • Subscribe by email
  • More
  • Cancel
  • Share
  • Subscribe by email
  • More
  • Cancel
  • Author Author: Jan Cumps
  • Date Created: 14 Nov 2016 12:52 PM Date Created
  • Views 1459 views
  • Likes 1 like
  • Comments 8 comments
Related
Recommended
  • ds1052e
  • bm235
  • cc1310
  • microcurrent
  • brymen
  • texas_instruments
  • µcurrent
  • simplelink
  • sub_1ghz
  • ti_rt
  • eevblog
  • rigol

SimpleLink™︎ Sub-1 GHz Wireless Microcontroller - Side Note : Measure Power Use of Sensor Controller Engine

Jan Cumps
Jan Cumps
14 Nov 2016

Complexity: medium

What do you need:

  • a CC1310 LaunchPad
  • Code Composer Studio Wirelsess Sensor Network  Node example loaded
  • An instrument to log low currents

 

This blog digs into the sub-module that manages communication with sensors. A dedicated part of the IC that takes care that Radio and CPU can sleep until something meaningful happens in sensor land.

 

 

image

 

 

This side note checks the current when only the Service Controller Engine is running vs. Full On.

 

I'm still looking at the Sensor Controller Engine (SCE) of the CC1310 Sub-1 GHz controller.

I'm measuring the power in a scenario where we let the SCE run the show and leave the rest of the system sleep as much as possible.

In our exercise, the SCE is the only active element most of the times. It polls an analog input in a very low power mode, while the CC1310 ARM core and Radio are powered down.

Under certain conditions (large change of the voltage on that analog input and/or after a given time) it wakes up the core and asks it to communicate the analog value to a receiver.

The core wakes up the Radio, the Radio sends the info, and we're returning back to the low power mode.

 

Sensor Controller Engine: Adapt the WSN Node example

The Wireless Sensor Network Node example has been our guideline in the last three posts.

Take care that you check out those previous blogs. Start at first SCE related post, because I made some changes to the example.

We'll make some more changes to get  a good trigger signal to base our measurements on, and also to remove unnecessary energy consumers (the activity status LED).

 

In the TI-RTOS example, an LED toggles each time the SCE activates the main ARM Core and Radio (just before radio activation actually)

    while(1) {
        /* Wait for event */
        uint32_t events = Event_pend(nodeEventHandle, 0, NODE_EVENT_ALL, BIOS_WAIT_FOREVER);

        /* If new ADC value, send this data */
        if (events & NODE_EVENT_NEW_ADC_VALUE) {
            /* Toggle activity LED */
            PIN_setOutputValue(ledPinHandle, NODE_ACTIVITY_LED,!PIN_getOutputValue(NODE_ACTIVITY_LED));


            /* Send ADC value to concentrator */
            NodeRadioTask_sendAdcData(latestAdcValue);
        }
    }

 

We'll replace this by a mechanism that pulls a free GPIO output high before radio activation, and low again after the radio stops.

    while(1) {
        /* Wait for event */
        uint32_t events = Event_pend(nodeEventHandle, 0, NODE_EVENT_ALL, BIOS_WAIT_FOREVER);

        /* If new ADC value, send this data */
        if (events & NODE_EVENT_NEW_ADC_VALUE) {
            /* bump activity PIN */
            PIN_setOutputValue(pinPinHandle, NODE_ACTIVITY_PIN, 1);

            /* Send ADC value to concentrator */
            NodeRadioTask_sendAdcData(latestAdcValue);

            /* unbump activity PIN */
            PIN_setOutputValue(pinPinHandle, NODE_ACTIVITY_PIN, 0);
        }
    }

 

Even though the SCE has already woken up the ARM Core by then, it's a good indicator to tell us that we've only just woken up.

We can base our measurement trigger point on that - if we take care that we also capture a part of the data before that trigger point.

 

image

On the image above you can see that the 'trigger' pin goes high when the ARM is already active.

But it's close enough to the start point of the active phase to capture a part of data before that trigger.

I selected DIO22. Any of the free GPIO pins can be selected.

 

image

i replaced the LED assignments in the code to that DIO22. Apart from the change I showed at the start of this blog, here are the other things to do.

In NodeRadioTask.h:

From

#define NODE_ACTIVITY_LED Board_LED0

To

#define NODE_ACTIVITY_PIN IOID_22

 

In NodeTask.c:

From

static PIN_Handle ledPinHandle;

To

static PIN_Handle pinPinHandle;

 

From

PIN_Config pinTable[] = {
    NODE_ACTIVITY_LED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,
    PIN_TERMINATE
};

To

PIN_Config pinTable[] = {
    NODE_ACTIVITY_PIN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,
    PIN_TERMINATE
};

 

From

    ledPinHandle = PIN_open(&ledPinState, pinTable);
    if (!ledPinHandle)
    {
        System_abort("Error initializing board 3.3V domain pins\n");
    }

To

    pinPinHandle = PIN_open(&pinPinState, pinTable);
    if (!pinPinHandle)
    {
        System_abort("Error initializing board 3.3V domain pins\n");
    }

 

Compile and load the example to your LaunchPad. Then close CCS. The controller won't go into sleep mode if you are executing the code from the debugger.

You can also unplug your LaunchPad now. We're going to wire in our measure instruments.

 

Test Setup

We'll need to measure low currents. And because the 'active' mode is so short, it's best to have a logging mechanism too.

I'm using an EEVblog µCurrent to capture the current and a digital oscilloscope to log the output for later measurements.

 

µCurrent and voltmeter

The easiest way to get at the CC1310 current only is at the bridge between debugger and CC1310 part of the LaunchPad.

 

image

Remove the 3rd-closest-to-the-side jumper on connector P4, It's labeled 3V3.

We have now cut the power supply to the controller.

Replace the jumper with your µcurrent input.

Place the meter in the µA range.

On the output side of the µCurrent, attach a voltmeter. Put it in the DC mV range if it has that, else in the DC Volt range

Don't attach an oscilloscope yet. If done wrong you'll short your USB power supply.

 

image

The µCurrent will output a mV per µA.

 

Burden voltage:

There's a shunt resistor of 10R in our circuit now, so we'll also loose a bit of our 3.3V. Let's see how much.

I'm jumping ahead a little now - the calculations are based on measurements that are documented later in the blog.

Calculate the drop caused by the Burden voltage by multiplying the measured current * 10.

Our maximum current, as we'll see later, is 0.0012A.

Our maximum voltage drop over the µCurrent is 0.0012A * 10R = 0.012V.

That means that we end up with 3.300V* - 0.012V = 3.288V at the CC1310. That'll work.

 

*theoretical value. I haven't measured the voltage of the 3V3 rail.

 

Oscilloscope Measurement Signals

imageread this before connecting your scope

The µCurrent isn't an isolated device. You can't just plug your scope probe in the output.

We're going to use a differential measure technique. That allows us to measure the voltage over a component (µCurrent) when both sides of that component aren't at ground level.

Put the hot side of your channel 1 probe on one of the µCurrent outputs, channel 2 probe's hot side on the other µCurrent output.

We'll make sure there's a ground connection between LaunchPad and oscilloscope in the next step, when we're probing the trigger signal.

Set both 1 and B vertical sensitivity to 1V/DIV.

Enable the Math function, and define it as A-B. The Math function will give the output voltage of our µCurrent.

Set the Math scale to 200 mV/DIV

Each mV on the oscilloscope's Math signal represents a µA consumed by the CC1310.

 

Oscilloscope Trigger Signal

We'll trigger the oscilloscope on the rising edge of the signal that we're generating on pin DIO22 especially for that purpose.

If you have a 4 channel scope, it's straightforward. Just connect the ground of channel 3 to a LaunchPad ground, and the tip to pin DIO22.

Set the trigger source to channel 3.

If you have a 2 channel scope, then use the Ext Trigger channel.

Connect its ground to a LaunchPad ground, and the tip to pin DIO22.

Set the trigger source to Ext.

 

Trigger on the rising edge. The signal goes up to 3.3V, so any trigger level a little above the ground noise is ok.

Set trigger mode to Normal, so that the screen only refreshes if we pulse DIO22 high.

Time base of 2mS/DIV is a good one to capture a full power up to power down cycle on a single screen.

 

You can now turn on the µCurrent and multimeter. Then plug in the LaunchPad.

You can power it from a computer, power bank or a wall wart. Just take care that you don't activate the CCS debugger if you use a PC.

 

Results

My voltmeter consistently shows close to 270 mV. That indicates that that in low power mode our consumption is close to 270µA.

 

image

 

I can't measure the Active Mode current with the multimeter because the on-time is too short (14-16ms).

That's when the log from our scope is useful.

image

before 1: Stand-by, 270µA

1 - the ARM core wakes up, 1100µA

T - our trigger line goes high.

2 - the Radio transmits, 1200µA

3 - I don't know the reason why power goes wild at that point. Either the whole device goes into low power mode a few times during transmission, or this is antenna noise.

4 - the Radio listens for the Acknowledgement from the Concentrator, 1150µA

5 - Radio off, ARM Core does bookkeeping and prepares to sleep, 1100µA

6 - Idle, 270µA (and this until the next instance of the wake-up cycle).

 

For power consumption calculation, multiply with 3.3V and the time taken for each chunk.

If we wake up every minute; and the up-time is roughly 15ms

59.85s      we consume 3.3V * 0.00027A = 0.000891W

0.15s        we consume 3.3V * 0.0012A = 0.00396W

per minute: 0.004851W -> 0.0000809 WH

 

Let's compare with the spec.

ModeMeasuredSpecified
Standby270µA1.7µA + 130µA (Timers) (+ maybe UART or µDMA?)
ARM core on1100µA1200µA + frequency and load dependent addition
Radio Transmit1200µA1200µA + approx 20µA + frequency and load dependent addition
Radio Receive1150µA1200µA + 5.5µA + frequency and load dependent addition

 

With my low-tech measurements, I'm not that far off of the theoretical values.

I am known for being extremely bad with figures. It's worth checking my measurements and calculations and to correct me if needed.

 

 

 

SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Check  Received Signal Strength
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Use SmartRF to Try Radio Configs
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Debug 2 LaunchPads at the Same Time
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Side Note: Recognise your PuTTY Sessions
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Side Note: Recognise your Code Composer Studio Sessions
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Debug a Sender to Receiver Conversation
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Side Note: Start a Fresh Project
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Create a Transmitter with SmartRF Studio Part 1
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Create a Transmitter with SmartRF Studio Part 2
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Sensor Controller Engine Part 1: Dry Run
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Sensor Controller Engine Part 2: RTOS Integration
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Sensor Controller Engine Part 3: Wake Up Options
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - Side Note : Measure Power Use of Sensor Controller Engine
SimpleLinkTm Sub-1 GHz Wireless Microcontroller - ToolKit for Range Testing

on TI E2E community: How to connect a CC1310 LaunchPad to the SIGFOX network

  • Sign in to reply

Top Comments

  • DAB
    DAB over 7 years ago +3
    Great update Jan, I can agree with the caution about attaching the oscilloscope. I once shorted out a laser power supply with the scope ground. I had never seen a wire vaporize before. Scared the hell…
  • Fred27
    Fred27 over 7 years ago +1
    I just ordered some CC1310 LaunchPads and I'd assumed that the CC13xx supported EnergyTrace as the MSP432 (and MSP430) does. A quick check and it seems that it doesn't. That's a shame as it makes this…
  • Fred27
    Fred27 over 7 years ago in reply to Jan Cumps +1
    Nothing EnergyTrace-related on the launchpads that arrived today (CC1310 v1.4 and CC1350 v 1.1)
  • Jan Cumps
    Jan Cumps over 7 years ago in reply to Fred27

    A while ago, I compared the measurements of the µCurrent that I'm using here with those of EnergyTrace on an MSP432 and the results were very close: MSP432 Power Modes: real time current measurement - µCurrent vs. EnergyTrace

     

    image

    We'll have to resort to devices like this for the time being image

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Fred27
    Fred27 over 7 years ago in reply to Jan Cumps

    Nothing EnergyTrace-related on the launchpads that arrived today (CC1310 v1.4 and CC1350 v 1.1)

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps over 7 years ago in reply to Fred27

    I just re-listened to the relevant part of the webinar:

    "We are looking at adding a on-board power profiling tool [...] equivalent to what is on the MSP432 today. We will be porting this to our wireless MCU devices in the future"

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Fred27
    Fred27 over 7 years ago in reply to Jan Cumps

    I saw something similar mentioned on e2e.ti.com too. I've also ordered a CC1350 but won't be expecting it to have EnergyTrace.

     

    I find it odd that the "standard" EnergyTrace isn't included on the XDS110 as that is independent of the target device:

    http://www.ti.com/tool/energytrace

    In debuggers that support EnergyTraceTm technology, a software-controlled DC-DC converter generates the target power supply. The time density of the DC-DC converter charge pulses equals the energy consumption of the target microcontroller. A built-in calibration circuit in the debug tool defines the energy equivalent for a single charge pulse. Since the width of each charge pulse remains constant, the debugger can just count every charge pulse and then sum them over time to calculate an average current – which leads to very accurate measurements.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Jan Cumps
    Jan Cumps over 7 years ago in reply to Fred27

    I heard on a recent webinar that the next release (not the current one !) of the CC1350 LaunchPad will have EnergyTrace on board.

    I haven't heard any plans on the CC1310...

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2023 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube