This TI Design demonstrates how to connect sensors to the cloud over a long-range Sub-1 GHz wireless network, which is suitable for industrial settings, such as building control and asset tracking. The design is powered through a TI Sitara™ AM335x processor and
SimpleLink™ ultra-low-power (ULP) Sub-1 GHz
CC1310 and CC1350 devices. The reference design pre-integrates the TI 15.4-Stack part of the SimpleLink
CC13x0 software development kit (SDK), which is a part of TI’s SimpleLink MCU platform, providing a unified software experience across TI’s low power wired and wireless MCUs. This reference design also includes the TI Linux
®
Processor SDK. The TI Design
Network partners with stackArmor to support the cloud application services for cloud connectivity and visualization of the sensor node data.
TIDEP0084
CC1310
CC1350
AM335x
Design Folder
Product Folder
Product Folder
Product Overview
•
•
•
•
•
•
Large Network-to-Cloud Connectivity Enabling
Long Range, Up to 1 km (Line of Sight)
IEEE 802.15.4e/g Standards-Based Sub-1 GHz
Solution With TI 15.4-Stack
Based on Proven Hardware Designs Enabling
Quick Time to Market With Out-of-the-Box, Readyto-Use Demonstration Software
TI Linux Processor SDK Provides Scalability
Across Multiple Sitara Processors, Such as
AM437x and AM57x
Supports Star Networks
Ultra-Low-Power Sensor Nodes
•
•
•
•
Building Security Gateway
Door and Window Sensor Networks
HVAC Gateway
Asset Management and Tracking
ASK Our E2E Experts
JTAG
Ethernet
PHY
USB
USB clk
BeagleBone Black
AM335x
ARM®
Cortex® -A8 application processor
Graphics
Display
PRU-ICSS
System
DMA, timers, WDT,
PWM ADC, RTC, power management
Connectivity
USB with PHY,
Ethernet, SPI,
UART, I
2
C, McASP,
CAN
DDR
DDR3L
(512 MB) eMMC eMMC
(2 GB)
MMC/SD uSD
Card
I
2
C Power
Power
Management
UART
/DXQFK3DGŒ
CC1310/50
ARM®
Cortex® -A3 microcontroller
Peripherals
I
2
C, UART, I2S,
GPIO, AES, uDMA, Timers,
EDT, SSI, RTC, temp mon
RF Core
Flash/SRAM
DC-DC
Sensor controller
ADC, analog
CMP, SPI/I
2
C dig, TDC, CCS
RF
RF
Circuitry clk
JTAG
Power
Power
Management
Copyright © 2016, Texas Instruments Incorporated
CC1350 Sensor tags
Sub-1 GHz
Network
Industrial IoT Gateway
(BeagleBone Black,
CC1350 /DXQFK3DGΠ)
Sub-1 GHz Sensor-to-Cloud Industrial IoT Gateway Demo
Ethernet switch
Internet port
Internet
Cloud application
* 7KHUH¶V D logical link to each node
Laptop showing
Cloud application
Logical connectivity with AWS
Physical connectivity via
Ethernet cables
RF connectivity (Sub-1 GHz)
An IMPORTANT NOTICE at the end of this TI reference design addresses authorized use, intellectual property matters and other important disclaimers and information.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
1
System Overview
www.ti.com
This TI Design provides a reference for creating an industrial IoT gateway that is capable of connecting a network of wireless sensors to an enterprise cloud provider. In this TI Design, a long-range, low-power wireless network, made up of Sub-1 GHz CC1310 or CC1350 devices (both are supported) that run the TI
15.4-Stack-based application, is connected to the AWS IoT cloud. An online dashboard is provided that allows the user to visualize the real-time sensor data as well as send actuation commands from anywhere in the world using an Internet-connected device with a web browser.
This reference design provides a list of required hardware, schematics, and foundational software to quickly begin your Internet of things (IoT) product development. Amazon Web Services (AWS) IoT service, which is brokered by stackArmor, was chosen as the cloud service provider for the demonstration. The software design, however, is architected to be flexible to enable other cloud service providers.
This TI Design enables IoT in numerous applications, such as building security gateways, door and window sensor networks, asset management and tracking, and other IoT-enabled home and industrial automation applications.
The connection between the wireless sensor network and the cloud is made possible by TI’s Sitara
AM335x device on the BeagleBone Black development platform. On one side, the AM335x is connected to a Sub-1 GHz device acting as the central node in the wireless network, and on the other side, the device is connected to the AWS IoT cloud using Ethernet. These two connections allow the AM335x device to act as a gateway to get the sensor messages from the wireless network to the cloud and, also, to get the actuation requests from the cloud dashboard sent back to the wireless network.
Due to the long-range and low-power capabilities of the Sub-1 GHz sensors, this TI Design is useful for any type of application that would benefit from distributed sensing. This reference design provides a blueprint that gives the ability to visualize or actuate tens or hundreds of sensors while only needing one gateway device, TI’s Sitara AM335x, to be connected to the Internet.
BeagleBone Black
AM335x
JTAG
Ethernet
PHY
USB
USB clk
ARM®
Cortex® -A8 application processor
Graphics
Display
PRU-ICSS
System
DMA, timers, WDT,
PWM ADC, RTC, power management
Connectivity
USB with PHY,
Ethernet, SPI,
UART, I
2
C, McASP,
CAN
DDR
DDR3L
(512 MB) eMMC eMMC
(2 GB)
MMC/SD uSD
Card
I
2
C Power
Power
Management
UART
/DXQFK3DGŒ
CC1310/50
ARM®
Cortex® -A3 microcontroller
Peripherals
I
2
C, UART, I2S,
GPIO, AES, uDMA, Timers,
EDT, SSI, RTC, temp mon
RF Core
Flash/SRAM
DC-DC
Sensor controller
ADC, analog
CMP, SPI/I
2
C dig, TDC, CCS
RF clk
JTAG
RF
Circuitry
Power
Power
Management
Copyright © 2016, Texas Instruments Incorporated
2
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
Cloud Service
IOT Cloud Application
User Interface
Application
Internet
Connection cloudAdapter appClient
IOT Gateway Application (NodeJS)
Socket Interface
TI 15.4-Stack appServer
TI 15.4-Stack
Collector Example
Application
Serial Device Level Interface
CC1310LP
Sensor End
Node
CC13xx
Sensor Tag
Sensor End
Node
Linux Kernel
BBB + Processor SDK
UART Interface
MAC Coprocessor Application
CC1310LP
Copyright © 2016, Texas Instruments Incorporated
System Overview
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
3
System Overview
www.ti.com
•
•
•
•
•
•
•
The following is a high-level description of each module in the software block diagram:
: This application presents the network information, device information, and provides ability to control network behavior to the end user.
: This application runs on the AWS cloud, which communicates with the IoT gateway application. The interface of the IoT cloud application with the cloud server is described in
and
.
: This application runs on the BeagleBone Black board. The application interfaces on one side with the cloud service to enable cloud connectivity and on the other side to the
Linux collector application to interface with the TI 15.4-Stack based network. The interface between the
IoT gateway and the cloud service is described in
–
: This application provides the cloud service provider specific functionality and is described in
Section 6 . Users can take the current interface, which is designed as an extensible
framework, and quickly modify the interface to add their own functionality for their end product development.
–
: This application implements an example application that starts the network, allows new devices to join the network, configures the joining devices on how often to report the sensor data, configures how often to poll for buffered messages in case of non-beacon and frequency-hopping mode of network operation for sleepy network devices, and tracks connected devices to determine if they are active or inactive on the network. This determination is achieved by the collector periodically sending tracking request messages and awaiting corresponding tracking response messages.
–
: This application interfaces with the Linux collector application over the socket interface to enable connection with the TI-15.4 Stack network. The interface is described in
.
: The collector application also opens up a socket server to talk to the
iotgateway
application. The communication over the socket is implemented through a serialization protocol known as Protocol Buffers or ProtoBuf. Protocol Buffers are a language-independent and platform-neutral way of serializing structured data for efficient data communication. The proto files are defined in the /example/collector/ directory for the collector application. For the iot-gateway application, the protocol file is at /example/iot-gateway/appClient/protofiles. The definitions in these proto files should match for successful communication. For details on protocol buffers, see Protocol
Buffers . The interface between the collector application and the iot-gateway application is described in
: The MAC coprocessor application runs on the CC1310 or CC1350
LaunchPad™, which provides a UART-based interface from TI 15.4-Stack sensor to cloud IoT gateway
SDK.
: The sensor example application from TI 15.4-Stack and runs on the CC1310 LaunchPad.
: The CC13xx SensorTag runs the sensor example application ported from the TI
15.4-Stack out-of-box sensor example applications, which enable support of the CC1350 SensorTag platform and integrate support for various sensors on the SensorTag platform.
4
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
System Overview
This section highlights key hardware devices and software components used in the TI Design.
The AM335x processors, based on the ARM
®
Cortex
®
-A8 core, are enhanced with image, graphics processing, peripherals, and industrial interface options, such as EtherCAT
® and PROFIBUS
®
.
These devices support high-level operating systems (HLOS) such as Linux, which is available free of charge from TI. The AM335x processors contain the subsystems shown in
unit (MPU) subsystem is based on the ARM Cortex-A8 core and the PowerVR SGX™ graphics accelerator subsystem provides 3D graphics acceleration to support display and gaming effects.
The PRU-ICSS is separate from the ARM core, which allows independent operation and clocking for greater efficiency and flexibility. The programmable real-time unit subsystem and industrial communication subsystem (PRU-ICSS) enables additional peripheral interfaces and real-time protocols such as
EtherCAT, PROFINET
®
, EtherNet/IP, PROFIBUS, Ethernet Powerlink, Sercos, and others.
ARM®
Cortex A8
Up to 1 GHz*
Graphics
AccelerationPac
SGX530 t
45nm
PRU- ICSS
Industrial
Communication
Subsystem
EtherCAT
®
,
PROFINET
®
,
EtherNET/IP
Π,
and more
32K/32K L1
256K L2 w/ECC
64K RAM
64KB L3 Shared RAM
LPDDR1/DDR2/DDR3/
DDR3L
EDMA JTAG/ETB
EMAC
2- port w/
Switch
10/100/1
G w/1588
LCD
Controller
24bit LCD Cont.
Touch Screen
Controller
(1)
Security
AccelerationPac
Crypto
USB2
OTG
+PHY x2
System Services
Timers x8 WDT RTC
Connectivity and IOs
CAN x2
PWM x3 eCAP / eQEP x3
SPI x2
I2C x3
McASPx2
GPIO
UART x6
12- bit ADC
(1)
NAND/NOR
(16bit ECC)
MMC/
SD/SDIO x3
Additionally, the programmable nature of the PRU-ICSS, along with its access to pins, events, and all system-on-chip (SoC) resources, provides flexibility in implementing fast, real-time responses, specialized data handling operations, custom peripheral interfaces, and in offloading tasks from the other processor cores of the SoC.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
5
System Overview
www.ti.com
The CC1350 is a member of the CC26xx and CC13xx family of cost-effective, ultra-low-power, 2.4-GHz and Sub-1 GHz RF devices. Very-low active RF and microcontroller (MCU) current consumption, in addition to flexible low-power modes, provide excellent battery lifetime and allow long-range operation on small coin-cell batteries and in energy-harvesting applications.
The CC1350 is the first device in the CC13xx and CC26xx family of cost-effective, ultra-low-power wireless MCUs capable of handling both Sub-1 GHz and 2.4 GHz RF frequencies. The CC1350 device combines a flexible, very-low-power RF transceiver with a powerful 48-MHz Cortex-M3 MCU in a platform supporting multiple physical layers and RF standards. A dedicated radio controller (Cortex-M0) handles low-level RF protocol commands that are stored in ROM or RAM, thus, ensuring ultra-low power and flexibility to handle both Sub-1 GHz protocols and 2.4-GHz protocols [for example Bluetooth
® low energy
(BLE)]. This enables the combination of a Sub-1 GHz communication solution that offers the best possible
RF range together with a BLE smartphone connection that enables great user experience through a phone application. The Sub-1 GHz-only device in this family is the CC1310.
The CC1350 device is a highly-integrated, true single-chip solution, which incorporates a complete RF system and an on-chip DC-DC converter.
SimpleLink
TM
CC26xx wireless MCU cJTAG
Main CPU
ROM
ARM
®
Cortex
®
-M3
128KB
Flash
8KB cache
20KB
SRAM
RF core
Digital PLL
DSP modem
ADC
ADC
ARM
®
Cortex
®
-M0
4KB
SRAM
ROM
G eneral peripherals / modules
I 2 C 4× 32-bit Timers
S ensor controller
Sensor controller
engine
UART
2× SSI (SPI, µW, TI)
I2S
10 / 15 / 31 GPIOs
Watchdog timer
TRNG
12-bit ADC, 200 ks/s
2x comparator
SPI-I 2 C digital sensor IF
AES Temp. / batt. monitor
Constant current source
32 ch. µ DMA
RTC
Time-to-digital converter
2KB SRAM
DC-DC converter
Copyright © 2017, Texas Instruments Incorporated
6
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
System Overview
Sensors can be 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.
TI 15.4-Stack is an IEEE802.15.4e/g-based software stack part of the SimpleLink CC13x0 SDK supporting a Star network topology for Sub-1 GHz applications. TI 15.4-Stack software runs on TI’s SimpleLink Sub-1
GHz CC1310 or CC1350 wireless MCU. TI 15-4 Stack offers several key benefits such as longer range in
FCC band and better protection against in-band interference by implementing frequency hopping. The
SDK also provides customers an accelerated time to market with a complete end-to-end, node-to-gateway solution. TI 15.4-Stack is supported on the industry’s lowest-power SimpleLink Sub-1 GHz wireless MCU platform.
This release is available royalty-free to customers using TI’s CC1310 or CC1350 wireless MCU and also runs on TI’s SimpleLink Sub-1 GHz CC1310 or CC1350 wireless MCU LaunchPad development kit. This release is available royalty-free to customers using TI’s CC1310 or CC1350 wireless MCU and also runs on TI’s SimpleLink Sub-1 GHz CC1310 or CC1350 wireless MCU LaunchPad development kit.
•
•
•
•
•
•
•
•
•
•
•
•
•
Features:
IEEE 802.15.4e/g standards-based solution
Frequency hopping
Medium access with CSMA/CA
Built in acknowledgment and retries
Network and device management (joining, commissioning, service discovery)
Security feature through AES -128 encryption and integrity check
Supported on SimpleLink Sub-1 GHz CC1310 wireless MCU
Star topology: Point-to-point, one-to-many, and data concentrator
Synchronous (beacon) and asynchronous (non-beacon) modes
Designed for 915-MHz FCC and 863-MHz ETSI
Sensor-to-web example application
Easy application development guided through sample applications showcasing the stack configuration and APIs
Coprocessor mode for adding connectivity to any MCU or MPU, with Linux host middleware and console application
For more details and to get the TI 15.4-Stack software, download the includes the TI 15.4-Stack.
, which
®
The TI processor SDK is a unified software platform for TI embedded processors, which provides easy setup and fast out-of-the-box access to benchmarks and demonstrations. All releases of the processor
SDK are consistent across TI’s broad portfolio, which allows developers to seamlessly reuse and migrate software across devices. Developing scalable platform solutions has never been easier with the processor
SDK and TI’s embedded processor solutions.
•
•
•
•
TI processor Linux SDK highlights:
Long-term stable (LTS) mainline Linux kernel support
U-Boot bootloader support
Linaro GNU compiler collection (GCC) tool chains
Yocto Project™ OE Core compatible file systems
For more details and to get the processor SDK, see
AM335x Processor SDK
.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
7
Getting Started Hardware and Software
www.ti.com
This section provides details on required hardware and software to be able to run the out-of-box TI 15.4-
Stack sensor-to-cloud TI Design software application. Developers can then quickly use the out-of-box application as a framework to develop end products.
•
•
•
•
•
•
•
•
•
•
•
The following hardware is required to get the out-of-box application running and to develop applications.
A CC1310 or CC1350 LaunchPad to run the MAC coprocessor application
One or more CC1310 or CC1350 LaunchPads or CC1350 SensorTags application to create one or more Sub-1 GHz network devices to run the TI 15.4-Stack sensor
An AM335x-based BeagleBone Black board
An 8-GB microSD card (the TI processor SDK image requires at least 8 GB of space)
A 5-V power supply for the BeagleBone Black
An Ethernet cable to connect the BeagleBone Black to the Internet
An LCD BoosterPack device)
(optional if using the CC1310 or CC1350 LaunchPad as the Sub-1 GHz network
A means to configure and set up the BeagleBone Black microSD card (Windows
® or Linux machine)
A PC to host and run the web browser used to view the web application
A standard Ethernet router required for internet connectivity to the BeagleBone Black and the host computer or tablet to view the web-application to monitor and control the sensor nodes in the network
A USB cable to connect the BeagleBone Black with the CC1310 or CC1350 LaunchPad
NOTE:
The out-of-box application is demonstrated using a USB cable to connect the AM335x-based
BeagleBone Black with the CC1310 or CC1350 LaunchPad. The TI Design includes design files for a hardware adapter board that connects the BeagleBone Black with the CC1310 or
CC1350 LaunchPad the way an end product should. The adapter board is not available for purchase but customers can either build their own using the design files provided, or they can jump straight to their own form factor design using the adapter board design files as a reference for how to connect the AM335x and CC1310 or CC1350 devices for an end product. When designing an end product, customers must also keep in mind that certificates need to be stored in secure memory; therefore, a trusted platform module (TPM) or other means of having secure storage must be included in the end-product design.
8
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
shows the hardware setup to run the demonstration.
CC1350 SensorTag
Ethernet cable for internet connectivity
Getting Started Hardware and Software
BeagleBone Black
Micro-SD card programmed with Processor
SDK Linux for AM335x
USB cable connects
BBB and CC1310/50LP
CC1310LP running MAC coprocessor application
CC1310LP with optional LCD
BoosterPack
With the required hardware, perform the following steps to replicate the software portion of the demonstration:
1. Boot the Linux kernel and file system from the Linux Processor SDK on the BeagleBone Black.
2. Copy the provided Sub-1 GHz IoT gateway demonstration reference design software to the
BeagleBone Black.
3. Program a CC1310 or CC1350 LaunchPad with the provided MAC coprocessor application.
4. Program the remaining CC1310 or CC1350 LaunchPad and CC1350 SensorTags with the provided sensor application.
The following sections in this chapter detail the above steps. For the purposes of this design guide, it is assumed that a Windows host machine is being used.
Program the SD card with the Linux processor SDK image using the following steps:
1. Download the prebuilt TI Linux processor SDK SD card image am335x-evm-linux-xx.xx.xx.xx.img.zip from http://software-dl.ti.com/processor-sdk-linux/esd/AM335X/latest/index_FDS.html
(where xx.xx.xx.xx is the version number of the latest Linux Processor SDK).
2. To program the microSD memory card, see the instructions at
.
Processor SDK Linux Creating an SD
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
9
Getting Started Hardware and Software
www.ti.com
Boot the BeagleBone Black from the microSD card using the following steps:
1. Disconnect power and unplug the USB cable from the BeagleBone Black board.
2. Insert the microSD card into the BeagleBone Black (see
3. Press and hold the boot switch (S2).
• Important: The boot switch is detected only at initial power on.
4. Provide power to the BeagleBone Black (1.5 A, 5 V).
5. Wait a few seconds then release the boot switch. In about 5 to 15 seconds, the LEDs begin to blink.
NOTE:
The first boot from a freshly-formatted SD card takes about one to two minutes longer.
During this extended time, the BeagleBone Black Linux distribution performs some one-timeonly steps.
•
In order to transfer files to the BeagleBone Black using its network interface, it is necessary to find its network address (IP address). There are two methods to determine the IP address of the BeagleBone
Black:
Method 1: Use the FTDI cable to connect through the serial header on the BeagleBone Black, and use the ifconfig command to determine the IP address allocated to the BeagleBone Black.
10
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
Getting Started Hardware and Software
• Method 2: Most routers include a built-in web server to configure the device (see
).
–
–
–
Connect the BeagleBone Black to the router.
Boot the BeagleBone Black.
Find the DHCP client page to determine the IP address of the BeagleBone Black. Some examples follow. The generic name for this feature is the DHCP client table.
NOTE:
Troubleshooting – the DHCP IP address is often determined by the order in which the devices boot. If the user's laptop booted first, it may receive address: xx.xx.xx.100. The
BeagleBone Black boots second and receives the address: xx.xx.xx.101; however, on the next use or if another device is attached (for example, a cell phone or tablet), the resulting boot order may change, and therefore, the IP address might change.
BRAND
LINKSYS™
NETGEAR
®
BELKIN™
EXAMPLE LINK
http://www.linksys.com/us/support-article?articleNum=139502 http://documentation.netgear.com/fvs336g/enu/202-10257-01/FVS336G_RM-11-
07.html
http://www.belkin.com/pyramid/AdvancedInfo/F5D8235-4/Advance/reserveIP.htm
•
The Sub-1 GHz sensor to cloud Industrial IoT gateway reference design demonstration software is located on a Git repository found at https://git.ti.com/apps/tidep0084 . Clone the repository to the host machine and copy it over to the BeagleBone Black using secure copy (SCP).
On your Windows host machine:
– cd C:\path\to\desired\clone\directory\
–
– git clone git://git.ti.com/apps/tidep0084.git tidep0084
Use WinSCP, Teraterm, or FileZilla to copy the the network address found earlier.
tidep0084
directory to the BeagleBone Black using
Putty or TeraTerm can be used (along with the IP address found in
BeagleBone Black using SSH. The user name is
root
, and there is no password. Once connected, the root user will be logged into the board and the Linux console prompt will appear.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
11
Getting Started Hardware and Software
www.ti.com
To run the example application users must first program one CC1310 or CC1350 LaunchPad with the
MAC CoP hex file and the other LaunchPads with the sensor example application hex file. In this design guide, the Flash Programmer 2 tool running on a Windows machine is used. Developers can also use the
Serial Flash Programmer tool, described in the
CC13x0 SimpleLink TI 15.4-Stack 2.x.x Linux Developer’s
to program the desired hex image onto the CC1310 or CC1350 LaunchPad.
NOTE:
It is easy to confuse the sensor and CoP devices. Be sure to label the devices as they are programmed.
To program the LaunchPad or SensorTag, follow these steps:
1. Download and install the SmartRF Flash Programmer 2 . .
2. Program CC1310 or CC1350 LaunchPad 1 – this device runs the CoP example application.
(a) Label this device collector. The LCD BoosterPack is not supported in the CoP application.
(b) If using the CC1310LP as MAC coprocessor: From a Windows PC, use the SmartRF Flash
Programmer 2 to program a CC1310 LaunchPad MAC CoP with the coprocessor_cc1310_lp.hex
file located here:
{demo software clone directory}/firmware/CC1310_LAUNCHXL/coprocessor_cc1310_lp.hex
(c) If using the CC1350LP as MAC coprocessor: From a Windows PC, use the SmartRF Flash
Programmer 2 to program a CC1350 LaunchPad MAC CoP with the coprocessor_cc1350_lp.hex
file located here:
{demo software clone directory}/firmware/CC1350_LAUNCHXL/coprocessor_cc1350_lp.hex
3. Program CC1310 or CC1350 LaunchPad 2 or SensorTag – this device runs the sensor example application.
(a) Label this device sensor. Optional: connect the LCD BoosterPack to this LaunchPad.
(b) To program CC1310 LaunchPad: From a Windows PC, use the SmartRF Flash Programmer 2 to program the hex file sensor_cc13x0lp.hex file located here:
{demo software clone directory}/firmware/ CC1310_LAUNCHXL/sensor_cc13x0lp.hex
(c) To program CC1350 LaunchPad: From a Windows PC, use the SmartRF Flash Programmer 2 to program the hex file sensor_cc13x0lp.hex file located here:
{demo software clone directory}/firmware/ CC1350_LAUNCHXL/sensor_cc13x0lp.hex
(d) To program CC1350 SensorTag: From a Windows PC, use the SmartRF Flash Programmer 2 to program the hex file sensor_cc13x0stk.hex file located here:
{demo software clone directory}/firmware/ CC1350_SensorTag/sensor_cc13x0stk.hex
NOTE:
Important – the default hex files are built for 915-MHz band operation. To rebuild the hex files for other bands (for example, 868 MHz ETSI band) see the
CC13x0 SimpleLink TI 15.4-
Stack 2.x.x Embedded Developer's Guide
Applications Quick Start Guide
. See the
or
TI 15.4-Stack CC13x0 SimpleLink Embedded
CC13x0 SimpleLink TI 15.4-Stack 2.x.x Linux
Developer’s Guide
[5] , specifically the Example Collector Application configuration section, to
change the Linux example application.
For porting the out-of-box TI 15.4-Stack sensor application, which is supported on the
LaunchPad platform to the CC1350 SensorTag platform, see the
TI 15.4-Stack Wiki
Troubleshooting – If the devices (sensor or CoP) get mixed up, use the Flash Programmer 2 tool to verify the flash content. Uncheck the ERASE option, uncheck the PROGRAM option, and enable the VERIFY option along with the read-back feature, to double-check or doubleverify the flash operation.
12
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
Getting Started Hardware and Software
•
•
•
•
•
With the required hardware and software together, the demonstration can be completed. At this point, the following assumptions are made:
The BeagleBone Black is booted from the SD card using the latest kernel and file system from the
Linux processor SDK.
The BeagleBone Black is powered up, and the user is logged in using SSH and can send commands on the Linux console.
The Git repository containing the demonstration software was copied to the file system of the
BeagleBone Black.
The coprocessor LaunchPad has been programmed with the coprocessor firmware.
The remaining LaunchPads and SensorTags have been programmed with the sensor example application.
If any of these assumptions are not true at this point, return to the previous corresponding sections in this chapter.
Plug the CC1310 or CC1350 LaunchPad running the coprocessor application into the BeagleBone Black using the USB cable. In
Figure 7 , the USB connection on the right side of the image is connected to the
CC1310 or CC1350 LaunchPad coprocessor.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
13
Getting Started Hardware and Software
www.ti.com
Once this connection is made, type
ls -l /dev/ttyACM*
at the BeagleBone Black console. There are two ttyACM devices that correspond to the serial ports from the CC1310 or CC1350 LaunchPad (similar to
Make sure/dev/ttyACM0 shows up in the list. This is the UART connection between the BeagleBone Black and the CC1310 or CC1350 LaunchPad device over which all of the sensor and network information is transferred. Open the {demo software directory}/prebuilt/bin/collector.cfg file and double check that the
[uart-cfg] section for the collector application is pointing to the correct device, as shown in
.
•
•
•
•
•
To connect the IoT Gateway to the AWS IoT service, the gateway needs authentication certificates provisioned by AWS. For these certificates, as well as a unique AWS URL, see the stackArmor web
page [8] . Return to this guide once obtaining the following:
certificate.pem.crt
private.pem.key
public.pem.key
root-CA.crt
a URL to the AWS host that should be used
Use SCP to copy the four files into the {demo software directory}/prebuilt/iot-gateway/cloudAdapter/certs/ directory on the BeagleBone Black’s file system.
•
•
•
•
Open the {demo software directory}/prebuilt/iot-gateway/cloudAdapter/awsConfig.json file and do the following:
- Make sure that the four files were copied.
certDir
parameter is set to the correct path to the certs directory where the
- Set the
host
parameter equal to the URL that was provided by stackArmor.
- Make sure that the something similar to
region us-east-1
.
parameter matches the region portion of the URL. It should be
- The
clientId
parameter must be changed to a unique string. Only one connection to the AWS cloud from a specific
clientId
is allowed. If the same
clientId
is used by more than one device connecting to the AWS cloud, connectivity issues can occur as the connection may timeout or be refused.
14
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
Getting Started Hardware and Software
The {demo software directory}/prebuilt/ directory has a simple shell script called following at the BeagleBone Black console to run the IoT Gateway application:
run_demo.sh
. Type the
cd {demo software directory}/prebuilt/ chmod +x bin/bbb_collector bash run_demo.sh
The shell script will start all of the necessary programs in order to get the full demonstration application up and running. The script will also print the URL to the IoT dashboard to the console. Navigate to the URL from the console output using the web browser on the host machine.
2.3.3.1
Common Issues
The following is a list of common issues that might be seen while starting or running the application:
•
•
•
•
•
This error occurs when the AppClient (which is started by the IoT Gateway) is not able to make a local socket connection with the AppServer (which is started by the bbb_collector). Make sure that the bbb_collector application is up and running before starting the IoT Gateway. The run_demo.sh script in the prebuilt directory gives an example on how to start the demonstration in the correct order. This script starts up the bbb_collector application and then starts the IoT Gateway.
This error can happen if the BeagleBone Black is behind a firewall and cannot connect to the servers at the AWS URL. This issue can be resolved by using a mobile hotspot to connect the BeagleBone
Black to the Internet or possibly by configuring the local network settings to allow the BeagleBone
Black to access outside servers.
This issue can occur if the date and time on the BeagleBone Black are set incorrectly to a time before the AWS certificates were generated by stackArmor. Setting the date of the BeagleBone Black to the current date and time should resolve this issue.
The current demonstration does not provide a method in the user interface to remove sensor nodes from the Sub-1 GHz wireless network. The bbb_collector application uses a file named
simulation.bin
(that can be found in the
prebuilt/bin/ nv-
directory) to save the information of the sensor nodes that have connected to the Sub-1 GHz wireless network. Delete the
nv-simulation.bin
file and restart the demonstration in order to remove sensor nodes. This process also means the remaining sensor nodes will need to reconnect to the Sub-1 GHz wireless network before they will show up in the user interface again.
Cloning the TIDEP0084 Git repository to a Windows machine and then copying it to the BeagleBone
Black might produce Node-JS errors when starting the demonstration. These errors appear to be caused by the line endings in the repository getting changed by Windows before being copied to the
BeagleBone Black. To correct this issue, the TIDEP0084 Git repository can be cloned directly to the
BeagleBone Black. To accomplish this, make sure your BeagleBone Black has an internet connection and then run the following command from the terminal:
.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
15
Getting Started Hardware and Software
www.ti.com
shows the IoT dashboard provided by stackArmor. Navigate to the dashboard by following the
URL provided by the console output in the previous step. Initially, the application starts with no devices present (not shown), the network is closed to new devices joining (not shown), and the network will not accept new devices.
16
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
Getting Started Hardware and Software
•
•
•
•
At start up, the collector example application initially has the network closed; therefore, sensor devices cannot join. To open the network, switch the
On/Off
button on the web browser to the
On
state. Within a few seconds (time depends on the polling interval and other configuration settings), the sensor joins the network. When the device joins the network, the red LED turns on. If the sensor LaunchPad has an LCD module, the device indicates the current state on the LCD. See
.
State 1 = Not joined
State 3 = Joined
State 4 = Restored
State 5 = Orphan condition
More details can be found in the
CC13x0 SimpleLink TI 15.4-Stack 2.x.x Embedded Developer's Guide
.
After the new device appears, initially only the short and extended addresses appear. The data fields will not show any data as none have been reported yet.
Sensor Data Reports:
After about one minute data appears on the screen (the exact interval is configured in the collector application using a #define value), see the
CC13x0 SimpleLink TI 15.4-Stack 2.x.x Embedded Developer's
or the Linux example collector source code for more details. After this time, the sensor nodes periodically report the sensor data.
Actuation:
Clicking on the toggle LED button sends a message to the sensor module to toggle the LED. There may be a slight delay (a few seconds) in toggle operation on the desired sensor LaunchPad. This delay is because the sensor nodes are in sleep mode and only wake up periodically to get the command buffered on the collector.
See
for an example of the IoT dashboard with multiple sensors and reported data.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
17
Testing and Results
www.ti.com
During the development process of this TI Design, the full hardware and software portions described in earlier sections were used for testing. Multiple CC1310 and CC1350 sensor nodes and a BeagleBone
Black (connected to a CC1310 coprocessor) were used to verify the IoT gateway functionality with the
AWS cloud enabled by stackArmor. The culmination of this TI Design can be visualized by the IoT dashboard described in
.
shows an example of the IoT Dashboard being displayed on the web interface. Observe that the current network information is shown, the network chart displays the number of connected devices, and that the sensor nodes section shows the device and current sensor information for all the devices in the network.
18
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
IoT-Gateway and Collector Application Interface API
The purpose of this section is to provide a description of the application programming interface between the TI 15.4-Stack Linux collector example application and the IoT gateway application. The collector example application implements an appsrv module, which opens up a server socket to which a client application can connect. The interface allows management and data interface to the client application, connecting to the socket server, to monitor and control the TI 15.4-Stack-based network. Management functionalities include the ability to open and close the network for new device joins, whereas the data interface allows sending and receiving data to and from the network devices. It is easy to add new APIs or modify the current implementation.
This API is defined at a specific interface level, which is a TCP socket pipe.
API commands and parameters are serialized over the socket interface using Google
® protocol buffers
(protobuf; for details, see Protocol Buffers ). The names of some parameters in this API section do not reflect the true name of the parameter, which is used by the application using that API, as those parameters are automatically generated by the protobuf engine.
For transport using a TCP socket, the protobuf-packed packets are preceded by a 4-byte header, containing the following fields (in this order):
1.
2.
– 16-bit number that specifies the actual length (in bytes) of the protobuf-packed packet
3.
– 1 byte: specifies the subsystem to or from which the packet is sent or received. The value '10' is reserved for TI 15.4-Stack application server interface.
– 1 byte: The command ID of the actual command being sent. This value is also available inside the packed packet. The actual command ID numbers are provided in the protobuf definition files that are part of the TI 15.4-Stack Linux SDK (collector example application and the gateway example application). When using command IDs in code, always use the defined names (never hardcode the command ID numbers), as the numbers may change between releases.
4.1.1.1
Description
Allows client application to enable or disable network for join for new devices.
4.1.1.2
Parameter List
PARAMETER
Duration
TYPE
INT32
DESCRIPTION
Duration for join permit to be turned on in milliseconds:
• 0 sets the join permit pff, and 0xFFFFFFFF sets the join permit on indefinitely.
• Any other non-zero value sets the join permit on for that duration.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
19
IoT-Gateway and Collector Application Interface API
www.ti.com
4.1.2.1
Description
The application server notifies the client of the result of processing of permit join request message.
4.1.2.2
Parameter List
PARAMETER
Status
TYPE
INT32
DESCRIPTION
0 if success
4.1.3.1
Description
The application server notifies the client of the network information when a network is formed using this
API.
4.1.3.2
Parameter List
PARAMETER
Fh channel panID shortAddress extAddress securityEnabled nwkMode state
TYPE
UINT32
UINT32
UINT32
UINT32
INT64
INT32
ENUM
ENUM
DESCRIPTION
True if network is frequency hopping
Channel number used, if non-frequency hopping network configuration
The 16-bit PAN identifier of the network
The 16-bit short address of the PAN coordinator
The 64-bit IEEE extended address of the PAN coordinator device
true
if security enabled,
false
otherwise
Network operation mode
BEACON_ENABLED = 1
NON_BEACON = 2
FREQUENCY_HOPPING = 3
PAN coordinator state values
STATE
Initialized waiting for user to start
VALUE
1
Starting coordinator
Restoring coordinator (from NV)
Started
Restored
2
3
4
5
Joining allowed for new devices
Joining not allowed for new devices
6
7
4.1.4.1
Description
The application server’s client can use this API to get the current network information
4.1.4.2
Parameter List
There is no parameter in the command message.
20
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
IoT-Gateway and Collector Application Interface API
4.1.5.1
Description
The application server sends the current network information as a response to the get network information request from the client using this API.
4.1.5.2
Parameter List
PARAMETER
Status
Fh channel panID shortAddress extAddress securityEnabled nwkMode state
TYPE
INT32
UINT32
UINT32
UINT32
UINT32
INT64
INT32
ENUM
ENUM
DESCRIPTION
0 if success
True if network is frequency hopping (optional)
Channel number used, if non-frequency hopping network configuration
(optional)
The 16-bit PAN identifier of the network (optional)
The 16-bit short address of the PAN coordinator (optional)
The 64-bit IEEE extended address of the PAN coordinator device
(optional)
true
if security enabled,
false
otherwise (optional)
Network operation mode (optional)
BEACON_ENABLED = 1
NON_BEACON = 2
FREQUENCY_HOPPING = 3
PAN coordinator state values (optional)
STATE VALUE
Initialized waiting for user to start
Starting coordinator
1
2
Restoring coordinator (from NV)
Started
Restored
Joining allowed for new devices
Joining not allowed for new devices
5
6
7
3
4
4.1.6.1
Description
The application client requests the current list of connected device using this API.
4.1.6.2
Parameter List
There is no parameter in the command message.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
21
IoT-Gateway and Collector Application Interface API
www.ti.com
4.1.7.1
Description
The application server sends the current list of connected device as a response to the get device array request message using this API.
4.1.7.2
Parameter List
PARAMETER
Status devInfo panID shortAddress extAddress panCoord ffd mainsPower rxOnWhenIdle security allocAddr
TYPE
INT32
Csf_deviceInformation
UINT32
UINT32
INT64
UINT32
UINT32
UINT32
UINT32
UINT32
UINT32
DESCRIPTION
0 if success
Multiple entries of this structure element. Number of entries is equal to the number of connected devices in the network.
The 16-bit PAN identifier of the network
The 16-bit short address of the network device
The 64-bit IEEE extended address of the network device
True if the device is PAN coordinator
True if the device is a full function device
True if the device is mains powered
True if the device's RX is on when the device is idle
True if the device is capable of sending and receiving secured frames
True if allocation of a short address in the associate procedure is needed.
4.1.8.1
Description
The application server informs the client of a new device join in the network using this API.
4.1.8.2
Parameter List
PARAMETER
panID shortAddress extAddress panCoord ffd mainsPower rxOnWhenIdle security allocAddr
TYPE
UINT32
UINT32
INT64
UINT32
UINT32
UINT32
UINT32
UINT32
UINT32
DESCRIPTION
The 16-bit PAN identifier of the network
The 16-bit short address of the network device
The 64-bit IEEE extended address of the network device
True if the device is PAN coordinator
True if the device is a full function device
True if the device is mains powered
True if the device's RX is on when the device is idle
True if the device is capable of sending and receiving secured frames
True if allocation of a short address in the associate procedure is needed.
22
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
IoT-Gateway and Collector Application Interface API
4.1.9.1
Description
The application server informs the client of an inactive device using this API.
4.1.9.2
Parameter List
PARAMETER
panID shortAddress extAddress timeout
TYPE
UINT32
UINT32
INT64
UINT32
DESCRIPTION
The 16-bit PAN identifier of the network
The 16-bit short address of the network device
The 64-bit IEEE extended address of the network device
True if not active because of tracking timeout.
meaning that the device didn't respond to the tracking request within the timeout period.
4.1.10.1
Description
The application server informs the client of change in the state of the collector application using this API.
4.1.10.2
Parameter List
PARAMETER
state
TYPE
ENUM
DESCRIPTION
STATE
Initialized waiting for user to start
Starting coordinator
Restoring coordinator (from NV)
Started
Restored
Joining allowed for new devices
Joining not allowed for new devices
VALUE
1
2
3
6
7
4
5
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
23
IoT-Gateway and Collector Application Interface API
www.ti.com
4.2.1.1
Description
The application server informs the client of receipt of sensor data from a network device using this API.
4.2.1.2
Parameter List
PARAMETER
srcAddr
Rssi sDataMsg sConfigMsg
TYPE
UINT32
SINT32
Smsgs_sensorMsg
Smsgs_configRspMsg
DESCRIPTION
The 16-bit PAN identifier of the network
RSSI of the message received
Received sensor message (optional)
Received config response message (optional)
PARAMETE
R
cmdId
TYPE
ENUM
Framecontro l
UINT32
DESCRIPTION
COMMAND ID
Smsgs_cmdIds_configReq
Smsgs_cmdIds_configRsp
Smsgs_cmdIds_trackingReq
Smsgs_cmdIds_trackingRsp
Smsgs_cmdIds_sensorData
Sensor message command ID
DESCRIPTION
Configuration message, sent from the collector to the sensor
Configuration response message, sent from the sensor to the collector
Tracking request message, sent from the collector to the sensor
Tracking response message, sent from the sensor to the collector
Sensor data message, sent from the sensor to the collector
VALUE
1
2
3
4
5
Smsgs_cmdIds_toggleLedReq
Toggle LED message, sent from the collector to the sensor
Smsgs_cmdIds_toggleLedRsp
6
Smsgs_cmdIds_toggleLedRsp 7
Frame control field states what data fields are included in reported sensor data, each value is a bit mask value so that they can be combined (OR'd together) in a control field. When sent over-the-air in a message this field is 2 bytes.
PARAMETER
Smsgs_dataFields_tempSensor
Smsgs_dataFields_lightSensor
Smsgs_dataFields_humiditySens or
Smsgs_dataFields_msgStats
Smsgs_dataFields_configSettings
DESCRIPTION
Bit mask for temperature sensor
Bit mask for light sensor
Bit mask for humidity sensor
Bit mask for stats message
Bit mask for configuration settings
VALUE
0x0001
0x0002
0x0004
0x0008
0x0010
Smsgs_dataFields_pressureSens or
Smsgs_dataFields_toggleSettings
Bit mask for pressure sensor
Bit mask for toggle settings
0x0020
0x0030
24
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Copyright © 2016–2017, Texas Instruments Incorporated
www.ti.com
PARAMETE
R
TYPE
tempSensor
Smsgs_tem pSensorFiel d lightSensor
Smsgs_light
SensorField humiditySen sor
Smsgs_hum iditySensorF ield configSettin gs
Smsgs_confi gSettingsFie ld pressureSen sor
Smsgs_pres sureSensorF ield
PARAMETER
cmdId
Status
Framecontrol treportingInterval pollingInterval
IoT-Gateway and Collector Application Interface API
DESCRIPTION
PARAMETER
Lists the reported temperature sensor data (optional)
Smsgs_tempSensorField:
TYPE
ambienceTemp UINT32
DESCRIPTION
Ambience chip temperature
- each value represents a
0.01° C, so a value of 2475 represents 24.75° C.
objectTemp UINT32
Object temperature - each value represents a 0.01° C, so a value of 2475 represents 24.75° C.
PARAMETER
rawData
PARAMETER
temp
Lists the reported light sensor data (optional)
Smsgs_lightSensorField:
TYPE
UINT32
DESCRIPTION
Raw sensor data read out of the OPT2001 light sensor
Lists the reported humidity sensor data (optional)
Smsgs_humiditySensorField:
TYPE
UINT32
DESCRIPTION
Raw temperature sensor data humidity
PARAMETER
reportingInterval
UINT32
Lists the reported configuration settings (optional)
Smsgs_configSettingsField:
Raw humidity sensor data
TYPE
UINT32
DESCRIPTION
Reporting interval - in milliseconds, how often to report sensor data to the pan-coordinator, 0 means reporting is off pollingInterval
PARAMETER
tempValue pressureValue
UINT32
Lists the reported pressure sensor data (optional)
Smsgs_pressureSensorField:
TYPE
UINT32
UINT32
Polling interval - in milliseconds (32 bits) - If the sensor device is a sleep device, this states how often the device polls its parent for data. This field is 0 if the device does not sleep.
DESCRIPTION
Temperature value
Pressure value
TYPE
Smsgs_cmdIds
Smsgs_statusValues
Smsgs_dataFields
UINT32
UINT32
DESCRIPTION
Sensor message command ID
Status of the processing of the request message
Bit mask of Smsgs_dataFields
Sensor data reporting interval
Polling interval if the device is a sleepy device
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
25
IoT-Gateway and Collector Application Interface API
www.ti.com
4.2.2.1
Description
The application client uses this to send data to a network device.
4.2.2.2
Parameter List
PARAMETE
R
TYPE
msgId panID shortAddres s extAddress
Smsgs_cmdI ds
UINT32
UINT32
INT64 configReqM sg
Smsgs_confi gReqMsg toggleLedRe q
Smsgs_toggl eLedReqMs g
DESCRIPTION
Sensor message command ID
The 16-bit PAN identifier of the network
The 16-bit short address of the network device
The 64-bit IEEE extended address of the network device
Configuration request message parameters (optional)
PARAMETER TYPE
cmdId Smsgs_cmdIds
DESCRIPTION
The value will be
Smsgs_cmdIds_configReq
( = 1).
frameControl reportingInterval pollingInterval
UINT32
UINT32
UINT32
Frame control field states what data fields are included in reported sensor data, each value is a bit mask value so that they can be combined (OR'd together) in a control field.
When sent over the air in a message this field is 2 bytes.
Sensor data reporting interval
Polling interval if the device is a sleepy device
Toggle led request message parameters (optional)
4.2.3.1
Description
Thepplication server informs the client of result of the transmit data request
4.2.3.2
Parameter List
PARAMETER
Status
TYPE
INT32
DESCRIPTION
0 if success
26
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
TI IoT Gateway to Cloud Interface
The purpose of this section is to provide a description of the message types and expected data flows that will be shared between the TI IoT gateway and an IoT cloud server. The interface is designed to be flexible to support multiple cloud vendors. For this purpose, the Sub-1 GHz wireless network and node information will be exchanged between the gateway and the cloud using the long-established JavaScript object notation (JSON) format. Additionally, IPSO alliance smart object definitions will be used to define sensors (and their data) that are connected to each node in the wireless networks.
To fully specify the Sub-1 GHz wireless network information, as well as the Sub-1 GHz sensors and their data, two distinct message types have been defined for the IoT gateway to update the cloud. In order to allow the cloud to send messages back to the TI IoT gateway, two additional message types are defined that allow the cloud to update the wireless network state and also send actuation messages to specific devices in the network.
•
•
•
•
•
•
•
•
•
This message type presents information about the wireless network, its current state, and a list of devices that are connected to the network. As shown later in this document, this will be the first message type sent after the network is initialized, and it contains all the information necessary to prepare for receiving sensor data from devices. This message type contains the following fields:
: begins as the short address of the network but allows for the cloud to provide a more specific name
: list of channels that the wireless network is operating on
: the 16-bit PAN identifier of the network
: the 16-bit short address of the pan-coordinator
: the 64-bit IEEE extended address of the pan-coordinator device
:
yes
if security enabled,
no
otherwise
–
: network operation mode (beacon, non-beacon, frequency hopping)
: PAN coordinator state values (waiting, starting, restoring, started, open, closed)
: list of wireless nodes in the network
: begins as the short address of the device but allows cloud to update
–
–
–
–
: the 16-bit short address of the pan-coordinator
: the 64-bit IEEE extended address of the PAN coordinator device
: the topic that the device will send its sensor data updates to
•
•
: list of IPSO alliance smart objects (sensors) attached to this device
: object ID which specifies the sensor type in the IPSO standard
: list of instance IDs for the current object (can be multiple same type sensors)
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
27
TI IoT Gateway to Cloud Interface
www.ti.com
•
•
•
•
This message type provides information about the wireless device as well as the latest data for all of the sensors connected to the device. This message type will be sent when a device reports sensor data or switches between an active or inactive state. The following fields are contained in this message type:
: whether or not the wireless node is active
: the 64-bit IEEE extended address of the PAN coordinator device
: received signal strength indicator of the last message received
: list of the IPSO alliance smart objects connected to this wireless device
–
: type of sensor (as defined in the IPSO standard); can be multiple types of sensors connected to each device
•
•
: the instance ID for the parent object type; can be multiple sensors of the same type
: sensor data name value pairs (for example,
sensorValue
: 32.5,
units
:
Celsius
, and so forth); these resources match what is specified for the given object ID in the IPSO standard
•
In the current implementation of the TI IoT gateway, this message type is intended to be able to open or close the wireless network to new devices joining. The cloud’s front end user interface can allow a user to click a button to open or close the network and then generate this message type and send it to the TI IoT gateway. The gateway will then notify the network on whether it needs to open or close to new device joins. This message type only includes the desired state of the network and should be sent to the same topic that the cloud is receiving the network information messages from. The following field is all that is required:
: should be set to either
open
or
closed
•
This message type is added to allow the cloud to send actuation messages to specific devices in the wireless network. The current implementation only supports toggling an LED on the wireless device’s board. The device actuation message should be sent to the topic of the device as given in the devices list of the network information message. The following field is the only requirement for this message:
: should be set to
true
This section of the document specifies the expected data flow when different events occur within the wireless network and also when the cloud must send configuration or commands to the TI IoT gateway.
•
•
•
The following items are the list of events that can occur on the TI IoT gateway that will cause a network information message type to be sent to the cloud. A description is given with each event, and the end of this section describes the expected behavior from the cloud upon receipt of this type of message.
This is the initial event in the TI IoT gateway. The TI IoT gateway will aggregate the information about the wireless network as well as the list of connected devices and their sensor types. The TI IoT gateway will then make a connection to the cloud and will send the aggregated data encapsulated in the network information message type.
This event can occur if any of the information about the wireless network changes. For example, if the network operation mode of the wireless network was changed, the TI IoT gateway would once again aggregate all the information needed (network information and device list) and send the network information message type to the cloud.
28
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
TI IoT Gateway to Cloud Interface
•
This event occurs if the state of the wireless network changes. For example, if the network state changes from open to closed, the TI IoT gateway will send a network information message type to the cloud.
When a new device joins the network, after the network is up and running, this event will occur. In this case, the TI IoT gateway will add the new device and its information to the devices list within the network information message type and then send the updated information to the cloud
It is expected that the cloud will be prepared for the network startup event and will be able to receive the network information message type (using a wildcard and then filtering or by having prior knowledge about the destination or topic of the message). Once the cloud receives the network information message, the wireless network information (PANID, security, mode, and so forth) can be displayed to users and the device list information (topic, object list, and so forth) can be used to prepare itself to receive and display device and sensor data.
•
•
The following is the list of events that will cause the TI IoT gateway to send a device information message type to the cloud. A description is given with each event and the end of this section describes the expected behavior from the cloud upon receipt of this type of message.
This event occurs when the TI IoT gateway detects that one of the devices in the connected devices list has stopped sending sensor data updates. The TI IoT gateway will update the a device information message type to the cloud for the inactive device.
active
field and send
Each time a sensor on a connected device reports sensor data this event occurs. The TI IoT gateway updates the IPSO alliance smart object list in the device for each sensor and then sends a device information message type to the cloud.
It is expected that the Cloud will be alert on each topic given in the connected devices list from the network information message. When one of the two events occur in this section, the TI IoT gateway will send the device information message to the topic (corresponding to the device being update) that the cloud should be listening on or subscribed to. When the device information message arrives at the cloud, the cloud should display the latest device information and sensor data to users.
This message is used to open or close the wireless network to new devices joining. This should be an option provided to users in the front end user interface that the cloud presents. When the user decides to update the network state, the cloud should send an update network state message type to the TI IoT gateway on the same topic that the network information messages are arriving on.
The TI IoT Gateway will receive the update network state message and will generate the correct command (either open or close) to the wireless network. This command should, in turn, cause a network state change event (from
) that will send a network information message back to the cloud, which can confirm the successful completion of the update network state command.
This method is used to toggle the LED on the board of the connected devices. This is meant to be a proofof-concept on the current device setup and will change for customer use-case specific actuations. A toggle
LED button for each device will be provided to users of the cloud’s front end interface. When the toggle
LED button is clicked, the cloud should send a device actuation message to the TI IoT gateway on the same topic that the device information messages are arriving on.
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
29
AWS IoT
www.ti.com
The TI IoT Gateway will generate a toggle LED command and send it to the device corresponding to the topic that the device actuation message was received on. This will cause the LED to toggle. Because the state of the LED is not captured in the device information message type, there will be no feedback to the cloud that the LED actually toggled.
of this document was generic to any cloud host or vendor. This section will give specific implementation details when using AWS IoT as the Cloud vendor. The numbering and header names of this section will be the same as
, but additional information specific to the AWS IoT implementation is added here.
The message types from
will remain the same for messages traveling in both directions.
However, the message payload sent to and from the AWS cloud will be wrapped with some additional information specific to the use of the Amazon thing shadow interface.
The network information message type will be sent to the AWS cloud using a thing name that includes the extended address of the wireless collector node that is attached to the TI IoT gateway. For example, the thing name could be
ti_iot_0x124b000a27dda1_network
$aws/things/ti_iot_0x124b000a27dda1_network/shadow
and would use the base thing shadow topic of where 0x124b000a27dda1 is the extended address of the collector node. Because all of the initial information needed to describe a network will be sent to this thing shadow, the thing name will either need to be known beforehand
or
the cloud front end will need to subscribe to an MQTT wildcard topic and then filter on the receive the initial message containing the network Information.
_network
keyword in order to
The message payload shown in
format and will be encapsulated in a
state
will remain the same, but the message will be in JSON
JSON object to comply with the Amazon thing shadow interface. Further, all messages sent from the TI IoT gateway toward the AWS cloud will be sent to the
state.reported
property of the thing shadow document. Sending data to the
state.reported
property is how the AWS cloud receives and stores the latest state of the thing.
The only other note that should be made on this message type is that the
topic
property given in each connected device will be the base topic for the thing device shadow in the following format:
"topic"
:
"$aws/things/ti_iot_0x124b000a27dda1_0x124b000a27d849/shadow"
where the thing name is
ti_iot_0x124b000a27dda1_0x124b000a27d849
. This name is comprised of first the wireless network’s extended address (0x124b000a27dda1) and second the extended address of the device connected to the wireless network (0x124b000a27d849). This naming convention guarantees a distinct thing name and also makes it easy to determine the wireless network that the device is connected to.
The device information message type messages will be sent to the thing shadows or MQTT topics that are provided in the devices list from the network information message type. It is recommended that things are registered (or MQTT topics are subscribed to) for each device once the network Information message is received. This registration will allow the cloud front end to receive all sensor and information updates from all devices.
Similar to the network information message type above, the device information message type will be sent in JSON format and will be wrapped in a
state
JSON object to comply with the Amazon thing shadow interface. Once again, when this message type is sent from the TI IoT Gateway to the AWS Cloud, the message will be sent to the
state.reported
property of the thing shadow document.
30
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
AWS IoT
The update network state message type messages will be sent to the same thing shadow or MQTT topic that the cloud receives network information messages on. This message type will also be sent in JSON format and will also be wrapped in a
state
JSON object to comply with the Amazon Thing Shadow API.
The major difference is that this message (
from
the Cloud
to
the TI IoT Gateway) will send its data to the
state.desired
property of the thing shadow. This is the method that the Amazon thing shadow provides to request a thing to make a state or property change. In this case, the only currently supported wireless network change that can be requested is to either open or close the network for new device joins. The following is an example of the message in JSON format that should be sent to the thing shadow:
{ “state” : { “desired” : { “state” : “open” } } }
The device actuation message type messages will be sent to the same thing shadow or MQTT topic that the Cloud receives device information messages on. This message type will also be sent in JSON format and will also be wrapped in a
state
JSON object to comply with the Amazon thing shadow API.
Similar to the update network state messages, this message type will also be sent to the
state.desired
property of the thing shadow. The only currently supported actuation message that can be sent is to request that the wireless device toggle an onboard LED. The following JSON object is the only currently supported device actuation message type that should be sent from the AWS cloud to the TI IoT gateway:
{ “state” : { “desired” : { “toggleLED” : “true” } } }
The data flows for the AWS cloud remain the same as in
above. The only AWS specific information is that the data is being sent to thing shadows and that the messages are wrapped in either
state.reported
or
state.desired
JSON objects as described in
This TI Design showcases the connectivity between AM335x and CC13x0 devices. The AM335x acts as a gateway processor and CC13x0 as communication node.
The AM335x-based BeagleBone Black is used as a platform for gateway processor, and the CC13x0based LaunchPad acts as communication node. The schematic for this TI Design shows how to map one
UART port and backdoor signals from BeagleBone Black to the LaunchPad.
For software flexibility, the schematic also maps various SPI, I²C, and GPIOs from BeagleBone Black to the LaunchPad; however, for this IoT gateway reference design only one UART port and backdoor signals are valid.
To download the schematics for each board, see the design files at TIDEP-0084 .
To download the bill of materials (BOM), see the design files at TIDEP-0084 .
To download the layout prints, see the design files at TIDEP-0084 .
To download the Altium project files, see the design files at TIDEP-0084 .
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
Copyright © 2016–2017, Texas Instruments Incorporated
31
Design Files
To download the Gerber files, see the design files at TIDEP-0084 .
To download the assembly drawings, see the design files at TIDEP-0084 .
www.ti.com
1. Texas Instruments,
TI-15.4 Stack: IEEE802.15.4e/g Standard Based Star Networking Software
Development Kit (SDK)
, TI 15.4-Stack Tool Folder
2. Texas Instruments,
Processor SDK for AM335x Sitara™ Processors - Linux and TI-RTOS support
,
PROCESSOR-SDK-AM335X Tool Folder
3. Texas Instruments,
TI 15.4-Stack Wiki
, TI 15.4-Stack Wiki
4. Texas Instruments,
Processor SDK Linux Creating an SD Card with Windows
, Wiki Page
5. Texas Instruments,
(SWRU490)
CC13x0 SimpleLink TI 15.4-Stack 2.x.x Linux Developer’s Guide
, User's Guide
6. Texas Instruments,
Guide (SWRU489)
CC13x0 SimpleLink TI 15.4-Stack 2.x.x Embedded Developer's Guide
, User's
7. Texas Instruments,
TI 15.4-Stack CC13x0 SimpleLink Embedded Applications Quick Start Guide
,
User's Guide (SWRU488)
8. stackArmor,
Industrial IoT Gateway Demonstration Request Form
Sitara, SimpleLink, LaunchPad are trademarks of Texas Instruments Incorporated.
ARM, Cortex are registered trademarks of ARM Limited.
LINKSYS, BELKIN are trademarks of Belkin International, Incorporated.
Bluetooth is a registered trademark of Bluetooth SIG, Incorporated.
EtherCAT is a registered trademark of EtherCAT Technology Group.
PowerVR SGX is a trademark of Imagination Technologies Limited.
Linux is a registered trademark of Linux Foundation.
NETGEAR is a registered trademark of NETGEAR, Incorporated.
PROFIBUS, PROFINET are registered trademarks of PROFIBUS and PROFINET International (PI).
Yocto Project is a trademark of The Linux Foundation.
All other trademarks are the property of their respective owners.
To download the software files for this reference design, please see the link at https://git.ti.com/apps/tidep0084 .
is an Applications Engineer at Texas Instruments, where he is responsible for supporting customers designing low power wireless systems. Suyash earned his Master of Science in Electrical
Engineering (MSEE) from Texas Tech University in Lubbock, TX.
is a Software Applications Engineer at Texas Instruments, where he is responsible for supporting customers using Linux on TI’s Sitara family of devices. Jason earned his Bachelor of Science in Computer Software Engineering and his Master of Science in Electrical Engineering at the University of
Florida in Gainesville, FL.
is a part of the Systems Team in Catalog Processors BU. He has been with TI for 13 years and has worked on multiple IP’s and SoC’s. He is the security architect for Keystone3 and security lead for Catalog BU. Amrit also is system lead for IoT EE initiative in BU.
32
Sub-1 GHz Sensor to Cloud Industrial Internet of Things (IoT) Gateway
Reference Design
TIDUCI9A – November 2016 – Revised April 2017
Copyright © 2016–2017, Texas Instruments Incorporated
Submit Documentation Feedback
www.ti.com
Revision A History
NOTE: Page numbers for previous revisions may differ from page numbers in the current version.
•
Changes from Original (November 2016) to A Revision
................................................................................................
Page
Added
Cannot find module
error to
Section 2.3.3.1 Common Issues
.
............................................................
TIDUCI9A – November 2016 – Revised April 2017
Submit Documentation Feedback
Copyright © 2016–2017, Texas Instruments Incorporated
Revision History
33
Texas Instruments Incorporated (‘TI”) technical, application or other design advice, services or information, including, but not limited to, reference designs and materials relating to evaluation modules, (collectively, “TI Resources”) are intended to assist designers who are developing applications that incorporate TI products; by downloading, accessing or using any particular TI Resource in any way, you
(individually or, if you are acting on behalf of a company, your company) agree to use it solely for this purpose and subject to the terms of this Notice.
TI’s provision of TI Resources does not expand or otherwise alter TI’s applicable published warranties or warranty disclaimers for TI products, and no additional obligations or liabilities arise from TI providing such TI Resources. TI reserves the right to make corrections, enhancements, improvements and other changes to its TI Resources.
You understand and agree that you remain responsible for using your independent analysis, evaluation and judgment in designing your applications and that you have full and exclusive responsibility to assure the safety of your applications and compliance of your applications
(and of all TI products used in or for your applications) with all applicable regulations, laws and other applicable requirements. You represent that, with respect to your applications, you have all the necessary expertise to create and implement safeguards that (1) anticipate dangerous consequences of failures, (2) monitor failures and their consequences, and (3) lessen the likelihood of failures that might cause harm and take appropriate actions. You agree that prior to using or distributing any applications that include TI products, you will thoroughly test such applications and the functionality of such TI products as used in such applications. TI has not conducted any testing other than that specifically described in the published documentation for a particular TI Resource.
You are authorized to use, copy and modify any individual TI Resource only in connection with the development of applications that include the TI product(s) identified in such TI Resource. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE TO
ANY OTHER TI INTELLECTUAL PROPERTY RIGHT, AND NO LICENSE TO ANY TECHNOLOGY OR INTELLECTUAL PROPERTY
RIGHT OF TI OR ANY THIRD PARTY IS GRANTED HEREIN, including but not limited to any patent right, copyright, mask work right, or other intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information regarding or referencing third-party products or services does not constitute a license to use such products or services, or a warranty or endorsement thereof. Use of TI Resources may require a license from a third party under the patents or other intellectual property of the third party, or a license from TI under the patents or other intellectual property of TI.
TI RESOURCES ARE PROVIDED “AS IS” AND WITH ALL FAULTS. TI DISCLAIMS ALL OTHER WARRANTIES OR
REPRESENTATIONS, EXPRESS OR IMPLIED, REGARDING TI RESOURCES OR USE THEREOF, INCLUDING BUT NOT LIMITED TO
ACCURACY OR COMPLETENESS, TITLE, ANY EPIDEMIC FAILURE WARRANTY AND ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL
PROPERTY RIGHTS.
TI SHALL NOT BE LIABLE FOR AND SHALL NOT DEFEND OR INDEMNIFY YOU AGAINST ANY CLAIM, INCLUDING BUT NOT
LIMITED TO ANY INFRINGEMENT CLAIM THAT RELATES TO OR IS BASED ON ANY COMBINATION OF PRODUCTS EVEN IF
DESCRIBED IN TI RESOURCES OR OTHERWISE. IN NO EVENT SHALL TI BE LIABLE FOR ANY ACTUAL, DIRECT, SPECIAL,
COLLATERAL, INDIRECT, PUNITIVE, INCIDENTAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES IN CONNECTION WITH OR
ARISING OUT OF TI RESOURCES OR USE THEREOF, AND REGARDLESS OF WHETHER TI HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
You agree to fully indemnify TI and its representatives against any damages, costs, losses, and/or liabilities arising out of your noncompliance with the terms and provisions of this Notice.
This Notice applies to TI Resources. Additional terms apply to the use and purchase of certain types of materials, TI products and services.
These include; without limitation, TI’s standard terms for semiconductor products http://www.ti.com/sc/docs/stdterms.htm
), evaluation modules , and samples ( http://www.ti.com/sc/docs/sampterms.htm
).
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright © 2017, Texas Instruments Incorporated
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
© 2021