I see great potential in CC3200 for low power WiFi device. I mean battery powered and hibernating most of the time. TI promises years long operation this way. I wanted to test hibernation consumption on CC3200-LAUNCHXL eval board I played with before. Unfortunately LEDs and some other ICs stay powered on the board even if configured to be supplied with two AA batteries. TI did own low power tests without them. That meant unsoldering which I didn't want to do.
CC3200MOD seemed like a good alternative. I got one from eBay (even paid extra 2 bucks for faster shipping in hope that it will arrive sooner).
CC3200-LAUNCHXL
While waiting for CC3200MOD I wrote an application to read humidity and temperature data from DHT22 sensor wired to LAUNCHPAD with 3 wires.
It went smoothly. Results were instant. I decided to post data from sensor to dweet.io. dweet.io is a service to store small amounts of data (up to 2000 characters at the time of writing this) with http GET or POST requests. Data is then available (with up to 500 history entries at the time of writing this) to retrieve by other applications or just visualize on their page. JSON format is used for data.
CC3200MOD
Flat cable with 1.27mm spacing needed to be soldered to received CC3200MOD (it was a process I would rather not repeat - I like software more and more :) ). Additionally I crimped connector on the cable. I was worried that module schematics will be a mystery since I found no official document but it seems that schematics is like suggested by TI. I couldn't figure out the SPI FLASH device as marking seem custom.
[UDATE] According to SPI flash ID read out with command 0x9F returning EF 40 14 it should be W25Q80 8Mbit device from Winbond.
[UDATE] According to SPI flash ID read out with command 0x9F returning EF 40 14 it should be W25Q80 8Mbit device from Winbond.
Photo below shows CC3200MOD with flat cable breakout, MM232R module from FTDI with FT232RQ USB to UART bridge for UNIFLASH software from TI to load firmware, iTAG50 debugger from iSYSTEM connected to debug pins, DHT22 and 2xAA battery pack for supply.
Code
I don't have nicely packed project to show the code (yet). Posting to dweet.io is shown below. Other than that it's DHT22 reading (you can get code for this everywhere on the web) and hibernation call in a loop.
#define SERVER_NAME "dweet.io"
void POST2dweet_io(float fTemp, float fHum)
{
signed char g_Host[] = SERVER_NAME;
unsigned int uiIP;
long lRetVal = sl_NetAppDnsGetHostByName(g_Host, strlen((const char *)g_Host), (unsigned long*)&uiIP, SL_AF_INET);
int iSockID = 0;
iSockID = sl_Socket(SL_AF_INET,SL_SOCK_STREAM, 0);
SlSockAddrIn_t Addr;
int iAddrSize;
Addr.sin_family = SL_AF_INET;
Addr.sin_port = sl_Htons(80); // default port for http
Addr.sin_addr.s_addr = sl_Htonl(uiIP);
iAddrSize = sizeof(SlSockAddrIn_t);
lRetVal = sl_Connect(iSockID, ( SlSockAddr_t *)&Addr, iAddrSize);
const char *pPOSTHeaderFormat =
"POST http://dweet.io/dweet/for/CC3200MODDHT22 HTTP/1.1\r\n"
"Content-Type: application/json\r\n"
"Content-Length: %d\r\n"
"\r\n";
const char *pPOSTBodyFormat =
"{\"Hum\":%3.1f,\"Tmp\":%3.1f}";
char acSendBuff[512] = { 0 };
long lBodyLen = sprintf(acSendBuff, pPOSTBodyFormat, fHum, fTemp);
lBodyLen = sprintf(acSendBuff, pPOSTHeaderFormat, lBodyLen);
lBodyLen += sprintf(acSendBuff + lBodyLen, pPOSTBodyFormat, fHum, fTemp);
acSendBuff[lBodyLen] = 0;
int iTXStatus;
iTXStatus = sl_Send(iSockID, acSendBuff, lBodyLen, 0);
}
Current usage
I couldn't measure hibernation consumption. It seems that my ampere meter has too much influence on supply rail. It looks like CC3200 is restarted on supply voltage drop in the moment of consumption change. Without ampere meter CC3200 works on lower voltages (tested with two rechargeable batteries at 2.4V).
Using active supply instead of AA batteries or proper shunt resistor for current measurement helped. I got cca. 5uA hibernation consumption and 25mA active mode consumption. I would agree that It takes around 5s for CC3200 to wake up, read DHT22 connect to WLAN and send data. From this one can evaluate how long a set of average AA with 2000mAh capacity will last. It's one year by waking up every 10 minutes.
Simplified calculation without taking into account all variables (e.g. battery self discharge) is as follows:
Charge used during active period:
Qap = Ia * Ta = 25mA * 5s = 125mAs
Charge used during idle period:
Qip = Ii * (Tp - Ta) = 5uA * (10min - 5s) = 2.975mAs
Sum of two makes up total charge used in one period:
Qpp = Qap + Qip = 127.975mAs (= 128mAs)
So the count of all periods per available charge in batteries is:
N = Qb / Qpp = 2000mAh / 128mAs = 56250
And total time:
T = N * Tp = 56250 * 10min = 390days
You can use function below in Google Sheets to test other combinations (provide values in SI units - s, A, As).
Note: current in hibernation mode was measured with DHT22 disconnected!
Using active supply instead of AA batteries or proper shunt resistor for current measurement helped. I got cca. 5uA hibernation consumption and 25mA active mode consumption. I would agree that It takes around 5s for CC3200 to wake up, read DHT22 connect to WLAN and send data. From this one can evaluate how long a set of average AA with 2000mAh capacity will last. It's one year by waking up every 10 minutes.
Simplified calculation without taking into account all variables (e.g. battery self discharge) is as follows:
Charge used during active period:
Qap = Ia * Ta = 25mA * 5s = 125mAs
Charge used during idle period:
Qip = Ii * (Tp - Ta) = 5uA * (10min - 5s) = 2.975mAs
Sum of two makes up total charge used in one period:
Qpp = Qap + Qip = 127.975mAs (= 128mAs)
So the count of all periods per available charge in batteries is:
N = Qb / Qpp = 2000mAh / 128mAs = 56250
And total time:
T = N * Tp = 56250 * 10min = 390days
You can use function below in Google Sheets to test other combinations (provide values in SI units - s, A, As).
function BattDuration(BattCapacity, Iidle, Iactive, Tactive, Tperiod)
{
var QperPeriod = Iidle * (Tperiod - Tactive) + Iactive * Tactive;
var numCycles = BattCapacity / QperPeriod;
var duration = numCycles * Tperiod;
return duration;
}
Note: current in hibernation mode was measured with DHT22 disconnected!
CC3200 is awesome
With integrated FLASH it would be even better. But from what I understand it is difficult to mix silicon process for analog and FLASH. Maybe in next generation?
I don't get why ESP8266 is generating so much noise while CC3200 is getting so little coverage. I would agree that it depends on the usage scenario where for low power CC3200 wins as it was designed for it. But it also works without hibernation. And it offers more than twice as much with less than half hassle to get it to work for twice the price of a module compared to ESP8266. Is the $5 absolute price all we are going for? From what I read on the internet (and I could be wrong) ESP8266 doesn't have popular CPU with compilers and debuggers available - young open source solutions don't count. I didn't see HTTP server ready to use on ESP8266 nor out-of-the-box SSL support like CC3200 has. Not to mention peripherals, more RAM and bigger SPI FLASH support. I'm not saying CC3200 is better than ESP8266, except that it is :). Again, I might be biased because I never used ESP8266 and I don't want to start a war. However I did decide on CC3200 based on information I got from internet.
