Archive

Posts Tagged ‘cloud’

Texas Instruments CC3200 WiFi SensorTag is Now Available for $40

March 15th, 2017 No comments

Texas Instruments launched SensorTag in 2013, and at the time there was just a Bluetooth 4.0 LE version with 6 different sensors. I bought one for $25 at the time, and tried it with a Raspberry Pi board and a BLE USB dongle. Since then, the company has launched a new multi standard model (CC2650STK) supporting Buetooth low energy, 6LoWPAN, and ZigBee, and has just started to take orders for CC3200 WiFi SensorTag for $39.99, which seems expensive in a world of $2 ESP8266 modules.

But let’s see what the kit has to offer:

  • Wireless MCU – Texas Instruments CC3200 SimpleLink ARM Cortex-M4 MCU @ up to 80 MHz, with up to 256KB RAM, Hardware Crypto Engine, DMA engine
  • Storage – 1 MB serial flash memory
  • Connectivity – 802.11 b/g/n WiFi with on-board inverted-F antenna with RF connector for conducted testing
  • Sensors – Gyroscope, accelerometer, compass, light sensor (OPT3001), humidity sensor (HDC1000), IR temperature sensor (TMP007), and pressure sensor (BMP280)
  • Expansion – 20-pin DevPack SKIN connector
  • Debugging – Debug and JTAG interface for flash programing
  • Misc – 2x buttons, 2x LEDs, reed relay MK24, digital microphone, and a buzzer for user interaction
  • Power – 2x AAA batteries good for up to 3 months (with 1 minute update interval)

So it has plenty of sensors to play with, and rather long battery life for a WiFi evaluation platform. The kit ships with one CC3200 WiFi SensorTag, two AAA batteries, and a getting started guide.

WiFi SensorTag Mobile App – Click to Enlarge

Resources includes hardware design files (schematics, PCB layout, BoM, etc..), iOS and Android apps and source code, IoT Device Monitor for Windows, Code Composer Studio, and cloud-based development tools. Note that there’s no embedded software for the Wi-Fi SensorTag, it is only a a demo platform, while you can modify cloud-based applications, you can’t modify the firmware. If you want an embedded development platform, you’d have to go with CC3200 LaunchPad board. You can still have some fun SensorTag using Android or iOS app, or connecting it to IBM Watson IoT Platform.

Visit SensorTag page for further information.

Socionext SC2A11 Low Power Server Processor Comes with 24 Cortex-A53 Cores, Scales up to 1536 Cores via PCIe

March 15th, 2017 7 comments

Socionext SC2A11 is an 24-core (tetracosa) ARM Cortex-A53 processor designed for low-power server system suitable for edge computing, web server & indexing, cloud computing, and any applications that do not require high single thread peak performance. The company also designed SC2A20 switch SoC that allows up to 64 SC2A11 processors (1536 cores) to communicate over PCI Express using Socionext DDT (Direct Data Transaction).

SC2A11 SoC specifications:

  • Processor – 24x ARM Cortex-A53 MPCore cores @ up to 1GHz, with 32KB/32KB I/D L1 cache, 256 KB L2 cache, and 4MB L3 cache
  • Memory I/F – DDR4-2133Mbps 64-bit + ECC
  • Flash I/F – HSSPI, eMMC
  • PCIe – PCI Express Gen2, Root/Endpoint select, 4 lanes (2 systems/ for SoC IF)
  • LAN – 2x 1Gbps with IPSec Network Offload Engine (wire-speed)
  • Serial I/F – UART, I2C, GPIO

The company did not provide any info about software, but it’s safe to assume it’s running Linux. There’s some code on the Linux mailing list for other Socionext processor,  but nothing for SC2A11. Another interesting use case is to connect several processor element card (PEC) based on SC2A11 using SC2A20 switch SoC, and a few Socionext MB86M30 ASSP via PCIe to encoding raw videos to 4K HEVC / H.265 videos @ 60 fps.

Media Transcoder Server

Socionext was at Linaro Connect Budapest 2017 demonstrating some of those PECs, and Charbax checked them out at the demo event, where they showcase the boards, and explained a little about them, and their relation with Linaro (as a member).

You won’t find than many details on Socionext SC2A11 product page, but at least you can inquire the company if you need more information.

Secure IoT Connectivity with NodeMCU ESP8266 Board, ATECC508A Crypto Chip, Mongoose OS, and AWS IoT

March 7th, 2017 16 comments

There are many examples of Internet of Things projects, but more often than not the implementation is not secure, either because the device is exposed to the Internet with minimum or no security (worst case), or a gateway (hopefully) provides secure connection to the Internet, but the communication between sensor nodes and the gateway in the local network is not secure, due to memory limitation of the nodes, for example it might be challenging to implement security on ESP8266. Mongoose OS is an open source operating system for the Internet of Things developed by Cesanta working on ESP32, ESP8266, STM32, and TI CC3200, and the developers have demonstrated a secure solution with Mongoose OS running on ESP8266 connecting over a TLS connection to AWS IoT (Amazon Web Service IoT) and using TLS credentials stored in Microchip ATECC508A CryptoAuthentication Device.

NodeMCU with ATCRYPTOAUTH-XPRO (Left) or barebone ATECC508A (Right)

The addition of ATECC508 chip either using “XplainedPro extension board for crypto products” (ATCRYPTOAUTH-XPRO) or ATECC508A chip itself, is to avoid storing private TLS credentials in NodeMCU’s flash memory, as anybody with physical access to the device could steal private keys and get access to the cloud. ATECC508A is connected via the I2C interface of the target board.

So I guess the crypto chip truly makes sense if you have sensor nodes on the field with information important enough that third parties may be interested in getting access to your sensor to try read your private key from ESP8266’s flash. It costs less than $1, so you may consider it anyway, although you can still get a secure TLS connection between NodeMCU and AWS IoT without it, but it adds another level of security.

Once you are done with the hardware connections, you’ll need to install Mongoose OS on the board, and follow the MQTT + AWS IoT tutorial to get started. Nothing complicated need to be done to leverage the crypto chip, as the command mgos aws-iot-setup should automatically detect ATECC508A chip and use it.

Netgem SoundBox is a Speaker with Built-in Set-Top Box Features

February 25th, 2017 1 comment

Netgem, a company specializing in Connected TV & Home, has sent a press release about profit growth, and two new “innovations int its smart home roadmap” with voice control with Amazon, and SoundBox, a connected speaker which embeds set-top box technology.


Netgem does not sell directly to consumers, but instead sell its products and solutions to service providers, and they have not provided a great deal of technical details. But we still know the company has improved Netgem Home Platform, a cloud service allowing the deployment and management of multi-screen features, content discoverability, with support for multi-room, multi-source music service through technology from Voxtok.

SoundBox will then offer both video and audio service, and be controlled by voice using Amazon Alexa. The SoundBox will be customized for each Telco to adapt to the needs of local markets.

A few more details may eventually surfaced on Netgem’s SoundBox product’s page. They’ll also demonstrate their solutions at Mobile World Congress 2017.

Amazon EC2 F1 Instances Put Xilinx Virtex Ultrascale+ FPGA Boards into the Cloud

February 22nd, 2017 4 comments

We’ve covered several board and modules based on Xilinx Zynq Ultrascale+ MPSoC such as the AXIOM Board and Trenz TE0808 SoM, both featuring ZU9EG MPSoC, with systems selling for several thousands dollars. But I’ve been informed you may not need to purchase a board to use Virtex UltraScale+ FPGAs, which are different from Zynq UltraScale+ since they lack the ARM CPU & GPU and normally feature a more capable FPGA, as last November, Amazon launched a developer preview of F1 instances giving access to this type of hardware from their cloud.

That’s the FPGA hardware you’ll be able to access from one F1 instance:

  • Xilinx UltraScale+ VU9P manufactured using a 16 nm process.
  • 64 GB of ECC-protected memory on a 288-bit wide bus (four DDR4 channels).
  • Dedicated PCIe x16 interface to the CPU.
  • Approximately 2.5 million logic elements.
  • Approximately 6,800 Digital Signal Processing (DSP) engines.
  • Virtual JTAG interface for debugging.

I understand those FPGA boards are PCIe card plugged into servers with an Intel Broadwell E5 2686 v4 processor, up to 976 GB of memory, and up to 4 TB of NVMe SSD storage. This is obviously only usable if the FPGA do not need extra hardware connected to the board.

You can choose from two instance types as described in the table below.

Instance Type FPGA Cards vCPUs Instance Memory (GiB) SSD Storage (GB) Enhanced Networking EBS Optimized
f1.2xlarge 1 8 122 480 Yes Yes
f1.16xlarge 8 64 976 4 x 960 Yes Yes

Amazon provides an hardware development kit or FPGA Developer AMI (Amazon Instance), where developers write and debug FPGA code on their own hardware/instance, before creating an “Amazon FPGA image” (AFI), and attaching it to an F1 instance as describe in the first diagram of this post. If you’re a customer who needs a specific “acceleration routine”, you don’t even need the FPGA development kit, as you can purchase the AFI on the market place, and deploy it on F1 instances.

If you are interested in Amazon solution and want to know more and get started, Amazon organized a one hour webinar last December.

Hardware-accelerated computing leveraging FPGAs is especially used for genomics research, financial analytics, real time video processing, big data search and analytics, and security applications.

AFAIK, Amazon has still not officially launched F1 instances commercially, at which point you’ll be able to pay by the hour for the use of the instance, but you can still sign up for the F1 preview.

Thanks to Jon for the tip.

SigFox Launches Spot’it Low Cost GPS-Free IoT Geolocation Service

February 17th, 2017 2 comments

Asset tracking was traditionally done using a combination of cellular and GPS technology, and LPWAN standards like LoRa & Sigfox promised to lower the cost of communication and hardware while still relying on GPS technology, but Sigfox has just announced Spot’it geolocation service, which will get rid of GPS all together, and instead use radio signal strength analysis and deep learning techniques in order to provide location information both outdoors and indoors.

Key benefits listed by the company include:

  • Lowest-cost IoT location service – Spot’it does not require any additional hardware or software upgrades, and the device does not have to transmit more messages, meaning there is no impact on the solution operating cost for customers.
  • Low energy – Spot’it does not rely on energy intensive GPS technology, nor require additional processing or any more energy than what Sigfox-enabled devices already consume.
  • Enabled through a planetary network – Spot’it is embedded in Sigfox’s global network footprint and represents the first global IoT geolocation offer. This allows the simplification of global supply chain management: once a device is registered into the Sigfox Cloud, the geolocation service is available in all territories where the network is present.
  • Unlike traditional GPS-tracking, Sigfox Spot’it works both indoors and outdoors.

For this to work, you’ll need to be covered by Sigfox’s network in one of the 31 countries currently covered, so coverage is not exactly “global” yet. The service does not need any new hardware, and you can use existing Sigfox modules, which you can get for as low as $2 (in quantities), and track them at low cost. Sigfox has not provided that much details on how they are doing it, but they still explained Spot’it was the first big data based Sigfox server, which relies on their Cloud service analyzing signal strength to determine the location.

So there are still unanswered questions, such as accuracy of the system, and how much the company charges for the geolocation service on top of the network access fee.

Categories: Uncategorized Tags: cloud, gps, IoT, lpwan, sigfox

Android Things OS for the Internet of Things Supports Raspberry Pi 3, Intel Edison, and NXP Pico Boards

December 14th, 2016 6 comments

Google introduced Project Brillo a little over a year ago, an operating system based on Android, but with a smaller footprint optimized for Internet of Things applications. Brillo has now just become Android Things OS, with Google releasing a developer preview of Android Things working on Raspberry Pi 3, Intel Edison, and NXP Pico boards.

android-things-architecture

Android Things Software Architecture

The company has also updated the Weave platform to simplify connection of all types of devices to the cloud, and interaction with services like the Google Assistant. The Weave Device SDK currently supports schemas for light bulbs, smart plugs, switches, and thermostats, with more type of device supported in the future, as well as a mobile app API for both Android and iOS.

Using an Android based OS instead of a pure Linux OS should make it easier for Android app developers to create smart devices thanks to the use of familiar Android APIs and Google Services. The workflow is pretty similar to creating mobile apps, with development being done within Android Studio and you’d connect to the target board through adb. One difference is the the Things Support library that provides a peripheral I/O API for interfaces such as GPIOs, PWM, I2C, SPI and UART as well as a user driver API  used to allow apps to inject hardware events in to the Android framework.

nxp-pico-board

NXP Pico Board with TechNexion PICO-i.MX6UL SoM

If you’d like to get started, get one of the three supported boards, and get the Android Things developer preview. You may also been interested in Weave and Google Cloud platform sites to respectively control capable device such as Philips Hue and Samsung SmartThings, and get your data into the cloud. Some sample code is also available on AndroidThings’ github account, and you may want to subscribe to  Google’s IoT Developers Community on Google+ for support and discussions. NXP also has a higher end Android IoT platform equipped with more I/Os and ports called VVDN Technologies Argon i.MX6UL development board.

How to Use Sonoff POW ESP8266 WiFi Power Switch with MQTT and ThingSpeak

December 11th, 2016 11 comments

ITEAD Studio’s Sonoff is a family of cheap home automation products based on ESP8266 WiSoC, and I’ve already tested Sonoff TH16 wireless switch with a humidity and temperature sensor using the stock firmware and eWelink app for Android or iOS. It works, but up to recently it required a registration to a cloud service (the company will now allow use from the local network), and the source code is closed. So for the second device under review, namely Sonoff POW wireless switch with a power consumption monitor, I decided to install ESPurna firmware working on ESP8266 Sonoff devices and NodeMCU, as it’s open source, supports Sonoff POW natively, includes a web interface to control the device from the LAN, and includes an MQTT client.

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol used to control IoT sensors and devices, and it’s a popular method to gather data from client to a MQTT broker to push the data to the cloud or a local database.

iot-sensors-mqtt-cloud

So typically, you’d have a bunch of sensor nodes (like Sonoff devices) communicating over MQTT to an MQTT Broker in your local network, which could be an OpenWrt router or a Linux development board like a Raspberry Pi, which in turns gets the data the the cloud to services like AWS IoT, Xively, or ThingSpeak. It’s also possible to use Cloud services to control MQTT devices remotely through the MQTT broker.

I eventually plan to use NanoPi NEO board to run both MQTT and ThingSpeak locally (not connected to the cloud) in order to monitor the power consumption of my small office, but since I’m all new to this, I’ve started experimenting by connecting a 30W light to Sonoff POW, and use a desktop computer running Ubuntu 16.04 for MQTT and ThingSpeak.

sonoff-pow-connection

Click to Enlarge

Click to Enlarge

Since I’ve already installed ESPurna firmware to the device, I disconnected the USB to serial board (important since Sonoff POW board has a hot ground), and connected it to the mains (220V in my location). That means we already have an MQTT client which first I had to configure.

Click to Enlarge

Click to Enlarge

Since it was the first time I connected a load to the device, I went to ESPurna’s status menu to check power usage was reported, and my 30 Watts light bulb was drawing 27 Watts. Close enough. I changed the hostname to sonoff-office, and setup two SSID in order to connect Sonoff POW to my local network in client mode, instead of using it in Access Point mode by default. You’ll need to tap on Update each time you modify the settings. Since the SSID must be entered manually, please note that SSID are case sensitive, e.g. CNX-SOFTWARE is different from cnx-software.

Click to Enlarge

Click to Enlarge

I wanted to calibrate the power using the 30W light bulb, so I entered 30W in AC RMS Active Power field, and tapped on Update, but the web interface reported “no changes”. I’m not sure how to use that part. Finally the most important part for this tutorial is to set the MQTT settings with MQTT IP address, and leaving other fields unchanged. However, you can change MQTT Topic field for example replacing /test/switch/{identifier} by /myiotstuff/{identifier}.

Now that our MQTT client is configured, I need to install mosquitto MQTT broker in Ubuntu:

mosquitto-clients is not really needed, but I’ll use it to test the MQTT broker a little later. Once you installed it, the MQTT Broker should already run automatically.

The last line of the log above shows a client connection from Sonoff POW. Now, we need to check the topic, and since ESPurna documentation is still work in progress, you could either check out the source code, or IMHO more fun, capture MQTT packet with tcpdump or Wireshark as I’ve done below.

Wireshark MQTT Capture - Click to Enlarge

Wireshark MQTT Capture – Click to Enlarge

Here we can see that Sonoff POW will send a Publich Message with the power level using the topic “/test/switch/sonoff-office/power29”.  “/test/switch” is the string we’ve defined in the web interface, “sonoff-office” the hostname we’ve given to Sonoff Pow, and “power29” indicates 29 Watts of power is currently used.

We can also start a client in Ubuntu 16.04 terminal window to check more MQTT topics with # wildcard for sonoff-office host:

We can use MQTT to get the IP address, firmware and file system version, hearbeat message, power use, and relay status (on or off).

It’s all good, but now we need to do something to draw the data, and possibly analyze it. I selected ThingSpeak for this purpose since it can be installed in the local network, or through their service in the cloud. By the end of my testing, I’ve noticed ThingSpeak has a new MQTT API, meaning it should be possible to connect your MQTT broker directly to it, but for this guide I use mqspeak instead as a bridge between MQTT and ThingSpeak. It may still be useful, as the open source version of ThingSpeak is not updated anymore, and lacks the MQTT API.

You’ll need Python 3 and pip3 to install mqspeak:

Once it’s done, we’ll need to create a config files as explained on mqspeak’s github repo, and I created /etc/mqspeak.conf with the following content:

Brokers are used to configure MQTT broker IP address and port, as well as the topic(s) to subscribe to, while Channels take care of ThingSpeak configuration with the channel’s Id and write API key, update rate in seconds (15s minimum), update type (see github for details), and fields defined in your ThingSpeak’s channel(s), which will create later on. I wrote one broker for the power consumption topic, and other for the relay status. However, I eventually ignored the relay status, as it’s not updated often enough and cause ThingSpeak’s channel to only be updated when the relay changes status, even if there are power updates in the meantime. A workaround is to use two different channels for ThingSpeak.

mqspeak connects directly to api.thingspeak.com, so if you are using ThingSpeak cloud services, the next step is to register an account and setup one or more channels.

Extra Instructions for a local installation of ThingSpeak

However, if you’ve installed ThingSpeak in Ubuntu 16.04 or other Linux operating systems locally or on your own server, you’ll need to change the server in the source code, and reinstall mqspeak.

  1. Get the source code:
  2. Modify mqspeak/sending.py to replace api.thingspeak.com using HTTPS with localhost (or other IP address/URL where you’ve installed ThingSpeak) with HTTP:
  3. Install mqspeak

An improvement would be to install a signed SSL certificate, like the one offered by LetsEncrypt and configure the rails server to use https instead. I have not setup ThingSpeak server to start automatically yet, so I have to start it manually for now:

End of instructions specific to local installation.

The instructions specific for the local installation of ThingSpeak are now done, and all instructions below are valid for both the local installation and cloud service. Now open a web browser, go ThingSpeak (cloud or local), and click on “Get Started Now” in order to register an account.

Click to Enlarge

Click to Enlarge

Once it is done, login and click on “New Channel”.

Click to Enlarge

Click to Enlarge

Give it a name, a description, create fields as needed, for example power-consumption and power-status, and click on Save Channel.  Update /etc/mqspeak.conf accordingly with the fields’ name, and channel Id.

thingspeak-api-keyNow select API Keys tab to copy and paste the write API key into mqspeak.conf.

Now we can start mqspeak:

ESPurna firmware will send a power update every 60 seconds (this can be changed in code/src/pow.ino), so you’ll see a new message pop-up every 60 seconds with your channels Id and write API key. I’ve let it run for about one hour, and got the follow chart in ThingSpeak after turning on and off the lights from time to time.
thingspeak-power-consumptionThat’s pretty cool, so it only shows the current power in watt, and we’d probably want to get power consumption in kW/h per day, week and month at some time, and I have yet to study how to do that, Exporting the data to excel would be a workaround if this can not be handled in ThingSpeak. ThingSpeak.com (but not the open source version) offers some Matlab processing of the data, so that’d be another options.

The next steps would be to install MQTT and ThingSpeak in NanoPi NEO board, enable HTTPS in ThingSpeak, autostart rails server and mqspeak at boot time, make ESPurna firmware publish the “Power” topic more often than every 6 second, and find some way to generate useful kW/h consumption charts from the data stored in ThingSpeak within ThingSpeak, or but exporting the data.