TI CC2650STK IOT Smart Sensor Tag

[vc1234]

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).

Tested indoors with a tx power of 4dbm.  A reliable range is about 60' with occasional  packet loss.  At 70' -- 80% packet loss.

 

[BobS0327]

I would presume that some packet loss is taking place using the CC2650 under my worst case scenario situation.  But for my project, the loss of a few packets every now and then is really not an issue.  As a matter of fact, I would probably be tossing most of the received data packets since they would not represent a significant temp/humidity change.  For example, I would only want to track temp changes from 70.0 to 71.0 degrees.  I would not want to track 70.1 ,70.2 70.3 degrees etc.  Thus, those miniscule incremental data change packets would be tossed.
 
TI does offer a dev pack that can run a packet error rate test.  But that would be overkill for my implementation.  I've been lurking on the TI forums and it appears to me that the CC2650 can also be tweaked to minimize packet loss under various conditions.  I currently don't have any plans to do any tweaking since the default sensor state works for me.
 
Now, if I were to implement the accelerometer or gyroscope, I definitely would be concerned about packet loss and would do extensive (advanced) packet loss testing prior to implementing these functions.
 
So, I guess packet loss can be an issue based upon your specific needs.
 
 

 

[vc1234]

What receiver do you intend to use to collect data ?  A Linux node or just an iphone/android app ? I may get a sensortag  for a specific location indoors myself.
 
Please keep us posted, it would be interesting to compare our experience with the unit.

 

[BobS0327]

What receiver do you intend to use to collect data ?  A Linux node or just an iphone/android app ? I may get a sensortag  for a specific location indoors myself.
 
Please keep us posted, it would be interesting to compare our experience with the unit.

 
I'll be using a Raspberry Pi 3 https://www.amazon.com/Raspberry-Pi-RASP-PI-3-Model-Motherboard/dp/B01CD5VC92 with a BLE adapter https://www.amazon.com/gp/product/B009ZIILLI/ref=ox_sc_act_title_2?ie=UTF8&psc=1&smid=A3HIHADV23VGU1 using the BlueZ protocol stack http://www.bluez.org/
 
I'll probably use IBM's recipe as a starting point  https://developer.ibm.com/recipes/tutorials/ti-sensor-tag-and-raspberry-pi/
 
I have the RPI3.  So, I just have to order the adapter to get started on this project.

 

[vc1234]

I have the RPI3.  So, I just have to order the adapter to get started on this project.

As far as I know, the rpi3 already has a BLE radio, so you do not need an adapter.

 

[BobS0327]

As far as I know, the rpi3 already has a BLE radio, so you do not need an adapter.

You're right!.  I just checked the RPI3 specs and it does have a BLE radio.  I made the unfortunate mistake of reviewing BLE projects which used previous versions of the RPI.  All these projects gave a hardware list which included a required BLE adapter.  So, I just incorrectly ASSUMED that the RPI3 also needed this adapter.
 
Thanx for the heads up.  It saved me a few bucks and a lot of time.

 

[BobS0327]

I just posted node.js code to my github repo which queries the TI cc2650 IOT sensor for object/ambient temperature and humidity. I used Sandepp Mistry's sensortag library  https://github.com/sandeepmistry/node-sensortag   to implement this code example   This initial code will be the starting point to extensively test the IOT device prior to implementing it in my smart home project.
 
I'm running the code on  RPI3 hardware.
 
My github repo link https://github.com/BobS0327/cc2650test
 
 

 

[vc1234]

I just got one for experimentation.
 
I noticed that it advertises only for two minutes after it's powered on and then shuts itself down.  How do you handle this feature ? 
 
I am thinking of modifying the firmware to make it advertise not so frequently as it does (once every 200ms) but permanently.  Unfortunately,  I am not familiar with the 2650 soc at all so it'll take a bit of digging.  Fortunately, the flasher is only $15 plus shipping.

 

[BobS0327]

 

I noticed that it advertises only for two minutes after it's powered on and then shuts itself down.  How do you handle this feature ? 

 
I currently do not have anything (software, firmware etc) to address the advertising issue. I have to manually depress the power on/off button to have the device start advertising prior to executing the code.
 

I am thinking of modifying the firmware to make it advertise not so frequently as it does (once every 200ms) but permanently.  Unfortunately,  I am not familiar with the 2650 soc at all so it'll take a bit of digging.

 
I've just ordered the $15 DevPak which will allow me to experiment with the device.  I also am not familiar with the device.  So, it'll take some learning on my part to get comfortable with programming the firmware etc.  Searching the TI forum for posts addressing the advertising issue seems to indicate one option is to create a RTOS schedule event.  This event would periodically wake up the processor which in turn would advertise for a set period of time and then finally go back to sleep.  One priority would be to balance battery life with how often the device wakes up and goes into advertising mode.
 

 

[vc1234]

I've just ordered the $15 DevPak which will allow me to experiment with the device.  I also am not familiar with the device.  So, it'll take some learning on my part to get comfortable with programming the firmware etc.  Searching the TI forum for posts addressing the advertising issue seems to indicate one option is to create a RTOS schedule event.  This event would periodically wake up the processor which in turn would advertise for a set period of time and then finally go back to sleep.  One priority would be to balance battery life with how often the device wakes up and goes into advertising mode.

 
It seems that the sensortag uses the "limited discovery" (l120sec)  option rather than "general" (unlimited)  as the message below seems to indicate. So, I'll try to recompile the code with the "general discovery" option and also increase the advertising interval to 1sec and see how  the battery would fare.
 
"
Change GAP_ADTYPE_FLAGS_LIMITED  //Limited discovery
to GAP_ADTYPE_FLAGS_GENERAL      //General indefinite discovery
"  https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/295219
 
A more ambitious plan is to convert the tag to an eddystone.  In this case, I could use estimote eddystones and the sensortag in the same manner. There is a skeleton CC2640 application ( https://github.com/TI-LPRF-Software/CC2640_SimpleEddystoneBeacon ) that lacks, however,  actual sensor readings, so I'll have to figure out how to do that in the firmware.

 

[LarrylLix]

I have four CAI tags and through a brick wall I cannot make them disconnect at 1000 feet to the end of my street. I am in the rural with low rf noise though.
 
I hate that they rely on the cloud for approval when they don't actually use it.

 

[vc1234]

I have four CAI tags and through a brick wall I cannot make them disconnect at 1000 feet to the end of my street. I am in the rural with low rf noise though.

 
They use 6x lower frequency (~433MHz), that's why. 
 
Using the 2.4GHz band for home automation is a pretty dumb design decision due to poor propagation characteristics, especially given the relatively low tx power (typically 0dbm).  I am getting not so good but acceptable for my purposes range with the sensortag, actually worse than BobS0327's but I do not want to kick this poor-range-dead-horse any more. I am getting slightly better range with estimotoes with the same 0dbm tx level.  I can boost the power on estimotoes to 4dbm and I will get a bit of reliability margin.  I can probably play with an external antenna a bit but I won't since while the range in my environment is not great, it's acceptable.
 
I'd rather use LaCross 915Mhz sensors that I could easily read with a CC1111, but they do not provide a stable sensor id. So, I am forced to fight the 2.4GHz limitations in order to be able to use an *open* protocol I can easily process without relying on another "cloudy" misguided HA implementation.
 

I hate that they rely on the cloud for approval when they don't actually use it.

Likewise, especially for sensors.

 

[BobS0327]

It seems that the sensortag uses the "limited discovery" (l120sec)  option rather than "general" (unlimited)  as the message below seems to indicate. So, I'll try to recompile the code with the "general discovery" option and also increase the advertising interval to 1sec and see how  the battery would fare.
 
"
Change GAP_ADTYPE_FLAGS_LIMITED  //Limited discovery
to GAP_ADTYPE_FLAGS_GENERAL      //General indefinite discovery
"  https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/295219
 
A more ambitious plan is to convert the tag to an eddystone.  In this case, I could use estimote eddystones and the sensortag in the same manner. There is a skeleton CC2640 application ( https://github.com/TI-LPRF-Software/CC2640_SimpleEddystoneBeacon ) that lacks, however,  actual sensor readings, so I'll have to figure out how to do that in the firmware.

 
Just a FYI..
Here's a link to a interesting YouTube video  https://www.youtube.com/watch?v=Ag4EDXVZ7HQ demonstrating usage of TI's cloud tools for the cc2560.  You can reference the Sensortag.c  file using this YouTube tutorial where the TI forum users suggest to make advertising changes.  The DevPack is needed to flash the device with the updates.  Unfortunately, I won't receive the DevPack for a few days.

 

[BobS0327]

Change GAP_ADTYPE_FLAGS_LIMITED  //Limited discovery

to GAP_ADTYPE_FLAGS_GENERAL      //General indefinite discovery
"  https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/295219

 
Yep, that worked.  Now the CC2650 continuously advertises until a host connects to it.
 
I had a tough time setting up the TI cloud tools in order to flash the device via the DevPack-Debugger.  I had to set up and use the cloud tools under a Windows Admin account in order to successfully flash the device.  Being a noob, I'm assuming that I can't use a common user account to work with these devices.

 

[vc1234]

Yep, that worked.  Now the CC2650 continuously advertises until a host connects to it.

 
I got the debugger yesterday and decided to go hard way with the real CCS. It was pretty unpleasant experience -- the toolchain is extremely sluggish on my windows notebook and buggy.  For something so trivial as to change two defs in the code,  I spent several hours fighting the Studio.  But, it works now. I'll see how long the battery would last and then will try to implement  eddystone advertisement, perhaps.