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....
Top Comments