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.
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.
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.
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.
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.
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
 | read 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.
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.
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.
| Mode | Measured | Specified |
|---|---|---|
| Standby | 270µA | 1.7µA + 130µA (Timers) (+ maybe UART or µDMA?) |
| ARM core on | 1100µA | 1200µA + frequency and load dependent addition |
| Radio Transmit | 1200µA | 1200µA + approx 20µA + frequency and load dependent addition |
| Radio Receive | 1150µA | 1200µ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.
Top Comments
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 out…
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…
Nothing EnergyTrace-related on the launchpads that arrived today (CC1310 v1.4 and CC1350 v 1.1)