Related
Recommended

SimpleLink™︎ Sub-1 GHz Wireless Microcontroller - Sensor Controller Engine Part 1: Dry Run

Jan Cumps

Complexity: medium

What do you need:

  • two CC1310 LaunchPads Out of Box
  • Code Composer Studio
  • TI RTOS
  • Sensor Controller Studio
  • ur brain

 

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.

 

 

 

You'll learn how to run the system low power and let the Sensor Controller module wake up the rest of the CC1310 only when needed.

In part 1, we'll test the engine in isolation, without the CC1310 radio or ARM controller.

 

Sensor Controller Engine

I'm going to quote the documentation a few times in this blog post.

I prefer to not do that when possible, but in this case the quoted sections were a better explanation than what I tried to write.

I will put these quotes in a grey box to highlight that they are copied.

Here's the first one: a summary of the Sensor Controller's purpose.

 

Sensors [...] handled in a very low-power manner by a dedicated autonomous ultra-low-power MCU that can be configured to handle analog and digital sensors; thus the main MCU (Cortex-M3) can maximize sleep time.

 

The engine is a state machine. You can program it to sample sensors at a given interval, and react on thresholds.

When something noteworthy happens, the engine can wake up the controller. And when the event needs to be transmitted, the controller can wake up the radio.

This schema allows for a conservative power use, unless there's something that needs communication.

Programming the engine is done with the Sensor Controller Studio.

Just like with the SmartRF Studio we used before, the result is a set of .c and .h sources.

 

Wireless Sensor Network (WSN) Node and Concentrator example

 

I've chosen this TI-RTOS example because it uses the Sensor Controller Engine on the Node (also because it's a first non-peer 2 peer example).

Some snippets from the example's documentation:

 

The Wireless Sensor Network (WSN) Node and Concentrator examples illustrate how to create a very basic sensor network consisting of one or many Node device(s) and a Concentrator device. The example shows how to form a one-to-many network where the Nodes send messages to the Concentrator.

 

The Concentrator is always waiting for incoming packet.

 

The Node use the Sensor Controller Engine to periodically read the value of the light sensor.

Whenever the sensor value change, the main controller wakes up and sends a packet with the value to the Concentrator.

 

For this blog, where we focus on the Node, we'll just load that example in Code Composer Studio.

Use the Resource Explorer of CCS to load the CC1310 TI-RTOS Driver Examples -> RF Examples -> RF Wireless Sensor Network Node.

This will load project and sources into your IDE, including the Sensor Controller Studio project that we'll use in the next step.

 

Test the Engine in Isolation from Sensor Controller Studio

Once you retrieved the project with Resource Explorer, you are ready to run the first test.We'll measure the analog value on analog input DIO26.

The screen capture below shows the studio when our project is loaded (by opening sce/adc_sample.scp).

 

 

A warning though. In the example program, the initialisation code ignores the I/O mapping, and passes the fixed value 2 to adcSelectGpioInput().
This is very confusing, because value 2 is pin DIO28 - it took me a while to understand why the example was sampling a different pin as selcted in the I/O.

You fix this by changing the code to adcSelectGpioInput(AUXIO_A_AD_INPUT).

 

 

 

Once that's done, you can start measuring.

I have used a potentiometer. Both ends are connected between GND and +3V3. The middle pin goes to the selected IO, DIO26.

 

 

I set the test mode to simplified so that I didn't have to worry about the Init / Termination cycle and started the sampling.

 

This is te result:

 

 

In the next part of this series, I'll include this in a real firmware project - to wake up our ARM Cortex and radio once we have something to send....

 

 

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

Anonymous
Parents

  • I should have added the missing link between project and ADC settings: the task.

    That's the umbrella for an IO management activity in the engine.

    The names of variables and the nature of the activity are defined and managed there.

     

    In the example, we have one task, AD_INPUT, that manages one analog input. Additionally to that, it's also the location where you define (part of) the constant name AUXIO_A_AD_INPUT that we used.

Comment

  • I should have added the missing link between project and ADC settings: the task.

    That's the umbrella for an IO management activity in the engine.

    The names of variables and the nature of the activity are defined and managed there.

     

    In the example, we have one task, AD_INPUT, that manages one analog input. Additionally to that, it's also the location where you define (part of) the constant name AUXIO_A_AD_INPUT that we used.

Children
No Data