TI CC2650STK IOT Smart Sensor Tag

[BobS0327]

I just ordered one TI CC2650 IOT Smart Sensor Tag  http://www.mouser.com/new/Texas-Instruments/ti-cc2650stk-kit/  for evaluation.  I'm in need of wireless temp/humidity sensors and these TI sensors may satisfy that requirement.
 
These sensors have a lot of functionality for a $29.00 price tag.  Each sensor has 10 built in functions:
 
1.  light sensor
2.  digital microphone (Not currently implemented,  TI has not finished the driver)
3.  magnetic sensor,
4.  humidity sensor
5.  pressure sensor
6.  accelerometer
7.  gyroscope
8.  magnetometer
9.  object temperature sensor
10.ambient temperature sensor
 
Each device is shipped by default with the Bluetooth Low Energy (BLE) technology enabled.  But the devices can also use ZigBee and 6LoWPAN thru a firmware upgrade.  Currently, a Zigbee upgrade will only get you temp/humidity sensors.
 
I plan to implement these wireless sensors in my own Raspberry Pi HA implementation after some extensive (if they pass my tests). I'm curious as to whether anyone else has used these wireless sensors in any HA project.  The obvious use would be for temp/humidity sensing.  But has anyone implemented any of the other sensors such as the magnetometer sensor etc in any project?
 

 

[vc1234]

I just ordered one TI CC2650 IOT Smart Sensor Tag  http://www.mouser.com/new/Texas-Instruments/ti-cc2650stk-kit/  for evaluation.  I'm in need of wireless temp/humidity sensors and these TI sensors may satisfy that requirement.

 
Too expensive.
 
I have similar need for multiple temp/humidity sensors.  Currently, I can read data from La Crosse sensors (https://www.amazon.com/Crosse-Technology-TX29UDTH-Wireless-Temperature/dp/B0016ZWS5I ) using a CC1110, but there is a small problem with assigning a random id to those sensors when a battery is replaced. I may still end up using them when I confirm my suspicion that the 2.4Ghz gadget range is worse than that of TX29UDTH and possibly inadequate for my layout.
 
I am currently looking at eddystone beacons (estimote or similar) that transmit "telemetry" info in their advert frames. That's all I need along with a stable sensor id.  Then, I can read easily the stuff with a bluetooth le dongle, or an iphone or whatever.

 

[BobS0327]

Too expensive.
 

I am currently looking at eddystone beacons (estimote or similar) that transmit "telemetry" info in their advert frames. That's all I need along with a stable sensor id.  Then, I can read easily the stuff with a bluetooth le dongle, or an iphone or whatever.

I was previously paying $90 for basic "old school"  temp/humidity sensors.  So, to me, $29 is a real bargain.
 
I'm just not sure you'll be able to get a stable sensor id from the TX29UDTH-IT.  I checked the TX29 protocol and it indicates that the id is randomly generated every time you replace the batteries.  Thus, there isn't any rhyme or reason as to how these sensor ids are generated.  That certainly would drive me nuts.
 
Reviewing the eddystone spec https://github.com/google/eddystone, it appears that the unencrypted (plaintext) version of the eddystone-tlm frame provides four unused bytes that can possibly be used for data storage.You could possibly store your temp data in that area.  The eddystone-tlm frame has a fixed length of 17 bytes.  The last four bytes are used for encryption when you use the encrypted version of the eddystone-tlm frame.  In the plaintext version, the last four bytes are left as unused.
 
 
 
 

 

 

[ano]

Currently, a Zigbee upgrade will only get you temp/humidity sensors.

There is a reason for that. temp and humidity are included items of a home automation sensor in the Zigbee stack, the others items aren't.  This doesn't mean you couldn't write code to read these items if they were to be added, it just means that you can use this sensor with any standard device that can read Zigbee sensors without any modes. The sensor company probably felt it would be better to make the sensors standard than to pass the additional information.

 

[vc1234]

So, to me, $29 is a real bargain.

 
If one needs a dozen of them -- less of a bargain.
 

I'm just not sure you'll be able to get a stable sensor id from the TX29UDTH-IT.

 
Yes, I mentioned that. 
 
However, more importantly, the range may (or may not) be a problem with 2.4GHz  Currently,  I can read a TX29 located at about 50' in the shed window with the signal traversing one external house wall.  Not sure I can do that with a 2.4GHz signal, but I'll try different power levels and see where it will take me.
 
I briefly toyed with the idea of using the sensortag, perhaps I'll revisit it if I am satisfied with the range.
 
Here's a TI DN that does not inspire much confidence, especially indoors: http://www.ti.com.cn/cn/lit/an/swra479/swra479.pdf

 

[BobS0327]

There is a reason for that. temp and humidity are included items of a home automation sensor in the Zigbee stack, the others items aren't.  This doesn't mean you couldn't write code to read these items if they were to be added, it just means that you can use this sensor with any standard device that can read Zigbee sensors without any modes. The sensor company probably felt it would be better to make the sensors standard than to pass the additional information.

I'm not sure I understand.  Specifically, I'm not sure what you mean by "modes".  The only reference I found to modes in the ZigBee spec was under the Application Layer Message.  There is a Direct and Indirect Address mode. The former uses a 16 bit network address and the latter uses a Cluster ID and assistance from a ZB router to locate a destination node.  
 
I thought the Zigbee Alliance maintained/controlled all the public profiles such as the HA profile.  It appears to me that the alliance is trying to keep the public HA profile as generic as possible. I'm just not sure they would want to add a magnetometer feature to a basic HA profile. But a manufacturer could request a private profile ID from the alliance and put together a Manufacturer Specific Profile.  This "private" profile would not be useful to other manufacturers whose devices are  Zigbee compliant since they would probably  not be able to properly interpret it.  It would only benefit developers who wish to take full advantage of all the features of the device which are not available thru the public HA profile. Thus, a developer could fully utilize all the functions of a device such as the CC2650 via ZigBee by implementing the "private" profile.  IOW, I could fully utilize all 10 functions of the CC2560 via ZigBee using a RPI using the "private" profile.

 

[ano]

I'm not sure I understand.  Specifically, I'm not sure what you mean by "modes".  The only reference I found to modes in the ZigBee spec was under the Application Layer Message.  There is a Direct and Indirect Address mode. The former uses a 16 bit network address and the latter uses a Cluster ID and assistance from a ZB router to locate a destination node.  
 
I thought the Zigbee Alliance maintained/controlled all the public profiles such as the HA profile.  It appears to me that the alliance is trying to keep the public HA profile as generic as possible. I'm just not sure they would want to add a magnetometer feature to a basic HA profile. But a manufacturer could request a private profile ID from the alliance and put together a Manufacturer Specific Profile.  This "private" profile would not be useful to other manufacturers whose devices are  Zigbee compliant since they would probably  not be able to properly interpret it.  It would only benefit developers who wish to take full advantage of all the features of the device which are not available thru the public HA profile. Thus, a developer could fully utilize all the functions of a device such as the CC2650 via ZigBee by implementing the "private" profile.  IOW, I could fully utilize all 10 functions of the CC2560 via ZigBee using a RPI using the "private" profile.

What you said is correct. Here is an overview of the HA profile: http://www.zigbee.org/zigbee-for-developers/applicationstandards/zigbeehomeautomation/
A private profile is certainly an option, it just isn't a route the sensor manufacturer took. I don't know why, they probably just didn't bother.

 

[BobS0327]

If one needs a dozen of them -- less of a bargain.

 
Yes, that's true for the initial purchase.  But I plan to use these sensors in a smart home project. I plan to implement a HVAC optimization application which will utilize these wireless sensors and the hard wired sensors to accumulate temperature data and store it in ThingSpeak which is an open data cloud platform.  Other data such as weather, energy cost and power meter data will also be collected and stored in ThingSpeak.  I'll probably use MatLab's analytics tools and algorithms to perform the data analytics in order to minimize HVAC energy costs while maximizing the comfort level of the residents.
 
IOW, I want to implement a residential version of buildingIQ http://www.mathworks.com/company/user_stories/buildingiq-develops-proactive-algorithms-for-hvac-energy-optimization-in-large-scale-buildings.html I've just started working on this project.  So, I have my work cut out for me.  Here's a link to my ThingSpeak channel which has a few of my graphs. https://thingspeak.com/channels/public?username=BobS0327
 
So, as previously mentioned, initial cost may be a little high but if my project is a success, I'll be able to recoup my sensor cost in addition to substantially reducing my energy costs.

 

[vc1234]

 But I plan to use these sensors in a smart home project. I plan to implement a HVAC optimization application which will utilize these wireless sensors and the hard wired sensors to accumulate temperature data

 
I've just run some bluetooth le signal propagation tests with a beacon board (HM-10 /CC2541) which essentially confirm the TI design note. I used an iPad app and also a TI bluetooth sniffer to measure the signal RSSI. The CC2541  tx power was 0dbm (anything below basically reduces your range to a couple of feet).  Indoors, a LOS marginal reception (the error rate about 50%) was achieved at about 20' with the iPad and 30' with the sniffer. A drywall cuts the reception range almost by half. So, more or less reliable communication range was about 10' with the iPad and 15' with the sniffer assuming at most one drywall penetration.  Communication between floors was even worse, about 7-8' at best (I have hardwood).
 
I'll try to rerun the tests with estimotes when I figure out how to convert them to eddystones sending the temperature.
 
I'd be curious to know what range you'll experience with the sensortag.

 

[BobS0327]

I'd be curious to know what range you'll experience with the sensortag.

 
The Bluetooth SIG suggests a distance of at least 200 feet for a Bluetooth 4.0 device such as the CC2650.  I only need approximately 80 feet but I'll definitely test the device for maximum range under various conditions such as drywall barriers etc.  Fortunately, TI provides a mobile app for accessing the device.  So, that should make testing a "piece of cake".  I won't receive delivery of the device until Wednesday

 

[vc1234]

The Bluetooth SIG suggests a distance of at least 200 feet for a Bluetooth 4.0 device such as the CC2650.

That's probably achievable at the max tx power of 4dbm in close to ideal conditions, i.e. the LOS outdoors, at least 1m above the ground, a real quarter wave antenna, not the puny PCB one, no obstructions, etc.
 
Having said that,  I finally managed to configure the three estimotos I bought rather cheaply at e-bay, at about $12 per each,  as eddystones.  With tx power of 0 dbm, I was able to achieve a 75' reception range outdoors in approximately the conditions I described above sans a quarter wave antenna.  An external house wall reduces the range to about 35-37' with RSSI hovering around -81-82 which a marginal sensitivity threshold.  Both with the 75' outdoors and 35'  outdoors-to-indoors (RSSI below -80), the packet loss ratio is about 50% which is ok for my temp measurement.  In my experiments, the received signal was influenced rather heavily by obstructions other than walls, e.g. by trees, human bodies inserted in the signal path, but that's expected for a 2.4GHz signal.  I also observed signal quality deterioration when the receiver was in a close proximity to a wifi AP, especially on channel 39.  That was also expected.
 
So, if I can get at least 50% of packets at 35' - 40' with a properly placed receiver, there is some hope for the project based on ble, especially if I could find a nordic ble module that allows soldering a quarter wave whip to improve the reception.

 

[BobS0327]

I'd be curious to know what range you'll experience with the sensortag.

Using my VERY unscientific method of testing using the mobile app, I get a max distance of approximately 275 feet in an unobstructed direct line of sight test.  Any further distance and the Sensortag mobile app appears to update less often, giving me the impression that the app is not receiving all the data.  IOW, the app occasionally misses packets in distances greater than 275 feet.
 
I believe the CC2650 specs indicate a max range of 100 meters (330 ft).  But unfortunately, I can't find that spec sheet.
 
I've also tested the CC2650 under my worst case scenario.  The sensor is located approx 70 feet from the app inside a residence.  The mobile app is located on second floor at front of house and the the CC2650 is located in basement at rear of house.  The transmission signal must travel thru typical residential construction of drywall, wooden framing, hardwood floors etc. The CC2650 works fine under these conditions. 
 
My project requires accumulation of at least a years worth of temp/humidity etc. data.  What I'm really interested in is the delta values.  For example, the change from 70 degrees to 71 degrees. Thus, a missed packet or two really doesn't concern me as long as I get a delta value.
 
 

 

[BobS0327]

I did find some relevant info on TI forum site referencing the  maximum range of the CC2650 sensor which the predecessor to the CC2655.  I've linked the CC2650 spec http://www.ti.com/lit/ug/tidu797d/tidu797d.pdf
 
But what is of real interest is the max range testing that was performed.  The details are found in section 6.5...
 

6.5 CC2650 Radio Transmission Range
A brief transmission range test was performed with the TI Design hardware to get a rough approximation
of transmission range. The test was done inside a commercial office building hallway, with the TI Design
hardware placed at one end of the hallway on top of a fabric-covered metal chair. The hallway is
approximately 8 feet, 5 inches wide, a dropped ceiling 10 feet high, and a length of approximately
430 feet. There were not any significant obstacles in the hallway during the test.
A laptop with the CC2540EMK-USB and packet sniffer software was placed at varying intervals from the
TI Design hardware to test if the data packet successfully receivable. During the test, there was an
abundance of undesirable Bluetooth Smart packets received from the multitude of mobile phones in the
vicinity. However, the display filter setting on the packet sniffer software was set to only show data packets
from the TI Design hardware.
Packets received when the sniffer setup was in close proximity to the TI Design hardware were received
with a received signal strength indication (RSSI) of approximately –30 to –35 dBm. Packets received when
the sniffer setup was at the end of the hallway (~430 feet away) from the TI Design hardware were
received reliably with an RSSI of approximately –65 to –75 dBm. Packets beyond the end of the hallway
were not reliably received by the packet sniffer setup.
This TI Design was able to successfully transmit data packets down the entire length of a 430-foot hallway
with minimal obstructions. However, radio performance will likely vary in the end-equipment environment,
because obstructions in the RF transmit path will reduce range. For full verification of the TI Design
hardware transmitting characteristics, further testing with end-equipment context is required.

 
Apparently there is no written documentation limiting the range of this sensor class to a maximum specific target range.  Rather maximum range is based upon your operating environment.
 
 

 

[vc1234]

I've also tested the CC2650 under my worst case scenario.  The sensor is located approx 70 feet from the app inside a residence. 

 
That's pretty impressive. 
 
I've observed about 37' usable distance from a sensor with 0dbm tx power.  You are getting twice as much with probably 5dbm (the max cc2560 is capable of).  5dbm can get you about additional 4-5 meters indoors in comparison to 0dbm, so your usable distance should be about 52', but it's much better.  Perhaps, the antenna in the sensortag is better than in my estimoto.  I'll retry with 4dbm tx power (the max the estimoto nordic chip can produce).

 

[vc1234]

But what is of real interest is the max range testing that was performed.  The details are found in section 6.5...

They claim 430'.  The theoretical  loss in dbm in the absence of any obstructions for a 2.4Ghz signal is about 20*log(distance)+40.3 ( https://en.wikipedia.org/wiki/Free-space_path_loss )
 
With 150 m = 492',  20*log(150)+40.3 = 83.8 - 5dbm tx power = 78dbm loss.  So, 430' and -75 dbm is pretty close to the theoretical limit.