TI CC2650STK IOT Smart Sensor Tag

[BobS0327]

  But, it works now. I'll see how long the battery would last and then will try to implement  eddystone advertisement, perhaps.

 
Battery life is a major concern for me since the device now advertises 24/7.  It appears that there is some sort of battery service available to the sensortag service since there is a sensortag_batt.c file associated with the example. 
 
But running Gatttool utility on my device indicates that there is no  primary UUID available for the battery service.  At this point, I'm not sure how to implement/activate a battery monitoring service within the sensortag example to monitor battery level on a regular basis.

 

[vc1234]

I have an odd problem with the IR temp sensor.  Whilst the ambient reading is ok and matches the barometric sensor temp reading, the IR object temp is decoded as -256 degrees C. First I thought that it was an iOS app error, but a python script interprets the IR object temp exactly the same:
 
python stag.py a0:e6:f8:b6:60:86 -T -B
Connecting to a0:e6:f8:b6:60:86

('Temp: ', (22.125, -256.0))
('Barometer: ', (22.15, 1005.86))

('Temp: ', (22.125, -256.0))
('Barometer: ', (22.16, 1005.9))
 
When I look at the raw data with gatttool, the first half-word that represents IR object temperature does not change whlst the second half-word changes and is interpreted correctly:
 
gatttool -b A0:E6:F8:B6:60:86 --interactive
[A0:E6:F8:B6:60:86][LE]> connect
Attempting to connect to A0:E6:F8:B6:60:86
Connection successful
[A0:E6:F8:B6:60:86][LE]> char-desc
...
handle: 0x0024, uuid: f000aa01-0451-4000-b000-000000000000
...
handle: 0x0027, uuid: f000aa02-0451-4000-b000-000000000000
...
[A0:E6:F8:B6:60:86][LE]> char-write-cmd 0x27 01
[A0:E6:F8:B6:60:86][LE]> char-read-hnd 0x24
Characteristic value/descriptor: 01 80 10 0b
[A0:E6:F8:B6:60:86][LE]>
 
I.e. in "01 80 10 0b" , the first part (0x0180) is the IR object temp which is decoded as -256 Celsius and the second part ("0x100b") is the ambient temp raw data which is decoded as 22.125 degrees.  So, I am wondering if your IR sensor provides correct readings for IR object temperature.
 
The battery level is simple: TI uses the standard service 0x180f and in gatttool one could see this:
 
primary
...
attr handle: 0x001c, end grp handle: 0x0021 uuid: 0000180f-0000-1000-8000-00805f9b34fb

...
char-desc
...
handle: 0x001e, uuid: 00002a19-0000-1000-8000-00805f9b34fb

char-read-hnd 0x001e

[A0:E6:F8:B6:60:86][LE]> char-read-hnd 0x001e
Characteristic value/descriptor: 45
 
The battery level is 0x45 -> 69% in my case.

 

[BobS0327]

Listed below are the results from my Gatttool util..

[B0:B4:486B:82][LE]> primary
attr handle: 0x0001, end grp handle: 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0008, end grp handle: 0x000b uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x000c, end grp handle: 0x001e uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle: 0x001f, end grp handle: 0x0026 uuid: f000aa00-0451-4000-b000-000000000000
attr handle: 0x0027, end grp handle: 0x002e uuid: f000aa20-0451-4000-b000-000000000000
attr handle: 0x002f, end grp handle: 0x0036 uuid: f000aa40-0451-4000-b000-000000000000
attr handle: 0x0037, end grp handle: 0x003e uuid: f000aa80-0451-4000-b000-000000000000
attr handle: 0x003f, end grp handle: 0x0046 uuid: f000aa70-0451-4000-b000-000000000000
attr handle: 0x0047, end grp handle: 0x004b uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
attr handle: 0x004c, end grp handle: 0x0050 uuid: f000aa64-0451-4000-b000-000000000000
attr handle: 0x0051, end grp handle: 0x0058 uuid: f000ac00-0451-4000-b000-000000000000
attr handle: 0x0059, end grp handle: 0x0060 uuid: f000ccc0-0451-4000-b000-000000000000
attr handle: 0x0061, end grp handle: 0xffff uuid: f000ffc0-0451-4000-b000-000000000000


[a0:e6:f8:af:8e:83][LE]> char-desc
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0002, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0004, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb
handle: 0x0006, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb
handle: 0x0008, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0009, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x000a, uuid: 00002a05-0000-1000-8000-00805f9b34fb
handle: 0x000b, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x000c, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x000d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x000e, uuid: 00002a23-0000-1000-8000-00805f9b34fb
handle: 0x000f, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0010, uuid: 00002a24-0000-1000-8000-00805f9b34fb
handle: 0x0011, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0012, uuid: 00002a25-0000-1000-8000-00805f9b34fb
handle: 0x0013, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0014, uuid: 00002a26-0000-1000-8000-00805f9b34fb
handle: 0x0015, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb
handle: 0x0017, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0018, uuid: 00002a28-0000-1000-8000-00805f9b34fb
handle: 0x0019, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001a, uuid: 00002a29-0000-1000-8000-00805f9b34fb
handle: 0x001b, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001c, uuid: 00002a2a-0000-1000-8000-00805f9b34fb
handle: 0x001d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb
handle: 0x001f, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0020, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0021, uuid: f000aa01-0451-4000-b000-000000000000
handle: 0x0022, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0023, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0024, uuid: f000aa02-0451-4000-b000-000000000000
handle: 0x0025, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0026, uuid: f000aa03-0451-4000-b000-000000000000
handle: 0x0027, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0028, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0029, uuid: f000aa21-0451-4000-b000-000000000000
handle: 0x002a, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x002b, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x002c, uuid: f000aa22-0451-4000-b000-000000000000
handle: 0x002d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x002e, uuid: f000aa23-0451-4000-b000-000000000000
handle: 0x002f, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0030, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0031, uuid: f000aa41-0451-4000-b000-000000000000
handle: 0x0032, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0033, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0034, uuid: f000aa42-0451-4000-b000-000000000000
handle: 0x0035, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0036, uuid: f000aa44-0451-4000-b000-000000000000
handle: 0x0037, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0038, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0039, uuid: f000aa81-0451-4000-b000-000000000000
handle: 0x003a, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x003b, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x003c, uuid: f000aa82-0451-4000-b000-000000000000
handle: 0x003d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x003e, uuid: f000aa83-0451-4000-b000-000000000000
handle: 0x003f, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0040, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0041, uuid: f000aa71-0451-4000-b000-000000000000
handle: 0x0042, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0043, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0044, uuid: f000aa72-0451-4000-b000-000000000000
handle: 0x0045, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0046, uuid: f000aa73-0451-4000-b000-000000000000
handle: 0x0047, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0048, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0049, uuid: 0000ffe1-0000-1000-8000-00805f9b34fb
handle: 0x004a, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x004b, uuid: 00002901-0000-1000-8000-00805f9b34fb
handle: 0x004c, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x004d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x004e, uuid: f000aa65-0451-4000-b000-000000000000
handle: 0x004f, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0050, uuid: f000aa66-0451-4000-b000-000000000000
handle: 0x0051, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0052, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0053, uuid: f000ac01-0451-4000-b000-000000000000
handle: 0x0054, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0055, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0056, uuid: f000ac02-0451-4000-b000-000000000000
handle: 0x0057, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0058, uuid: f000ac03-0451-4000-b000-000000000000
handle: 0x0059, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x005a, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x005b, uuid: f000ccc1-0451-4000-b000-000000000000
handle: 0x005c, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x005d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x005e, uuid: f000ccc2-0451-4000-b000-000000000000
handle: 0x005f, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0060, uuid: f000ccc3-0451-4000-b000-000000000000
handle: 0x0061, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0062, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0063, uuid: f000ffc1-0451-4000-b000-000000000000
handle: 0x0064, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0065, uuid: 00002901-0000-1000-8000-00805f9b34fb
handle: 0x0066, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0067, uuid: f000ffc2-0451-4000-b000-000000000000
handle: 0x0068, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0069, uuid: 00002901-0000-1000-8000-00805f9b34fb
 
Executing with 0x27 and 0x24 yielded the following results..
 
[a0:e6:f8:af:8e:83][LE]> char-write-cmd 0x27 01
[a0:e6:f8:af:8e:83][LE]>  char-read-hnd 0x24
Characteristic value/descriptor: 01
 
Executing with 0x24 and 0x21 yielded the following results
[a0:e6:f8:af:8e:83][LE]> char-write-cmd 0x24 01
[a0:e6:f8:af:8e:83][LE]> char-read-hnd 0x21
Characteristic value/descriptor: 44 0a ec 0d

Converting 44 0a ec 0d to celsious, fahrenheit: using the python script found at https://developer.ibm.com/recipes/tutorials/ti-sensor-tag-and-raspberry-pi/ yielded the following results..
Celsious 27.84375
Fahrenheit 82.11875
 
Using the same python script on your data of 01 80 10 0b yields the following results...
Celsius = 22.125
Fahrenheit = 71.825

 

[vc1234]

Listed below are the results from my Gatttool util..
Executing with 0x27 and 0x24 yielded the following results..
 
[a0:e6:f8:af:8e:83][LE]> char-write-cmd 0x27 01
[a0:e6:f8:af:8e:83][LE]>  char-read-hnd 0x24
Characteristic value/descriptor: 01
 
Executing with 0x24 and 0x21 yielded the following results
[a0:e6:f8:af:8e:83][LE]> char-write-cmd 0x24 01
[a0:e6:f8:af:8e:83][LE]> char-read-hnd 0x21
Characteristic value/descriptor: 44 0a ec 0d

Converting 44 0a ec 0d to celsious, fahrenheit: using the python script found at https://developer.ibm.com/recipes/tutorials/ti-sensor-tag-and-raspberry-pi/ yielded the following results..
Celsious 27.84375
Fahrenheit 82.11875
 
Using the same python script on your data of 01 80 10 0b yields the following results...
Celsius = 22.125
Fahrenheit = 71.825

 
1. Our handles are numbered differently.  In your case, you'll have to enable the IR sensor through handle 0x24 and read from 0x21 because your IR service is:
handle: 0x001f, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0020, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0021, uuid: f000aa01-0451-4000-b000-000000000000
handle: 0x0022, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0023, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0024, uuid: f000aa02-0451-4000-b000-000000000000
handle: 0x0025, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0026, uuid: f000aa03-0451-4000-b000-000000000000
 
And these lines are of interest:
 
handle: 0x0021, uuid: f000aa01-0451-4000-b000-000000000000
..
handle: 0x0024, uuid: f000aa02-0451-4000-b000-000000000000
 
 
In my case:
 
handle: 0x0024, uuid: f000aa01-0451-4000-b000-000000000000
...
handle: 0x0027, uuid: f000aa02-0451-4000-b000-000000000000
 
The numbering is shifted by 3 positions.
 
 
2. You do not have the battery service whilst I do (observe the 0x180f row):
[A0:E6:F8:B6:60:86][LE]> primary

[A0:E6:F8:B6:60:86][LE]> primary
attr handle: 0x0001, end grp handle: 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0008, end grp handle: 0x0008 uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x0009, end grp handle: 0x001b uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle: 0x001c, end grp handle: 0x0021 uuid: 0000180f-0000-1000-8000-00805f9b34fb
attr handle: 0x0022, end grp handle: 0x0029 uuid: f000aa00-0451-4000-b000-000000000000
attr handle: 0x002a, end grp handle: 0x0031 uuid: f000aa20-0451-4000-b000-000000000000
attr handle: 0x0032, end grp handle: 0x0039 uuid: f000aa40-0451-4000-b000-000000000000
attr handle: 0x003a, end grp handle: 0x0041 uuid: f000aa80-0451-4000-b000-000000000000
attr handle: 0x0042, end grp handle: 0x0049 uuid: f000aa70-0451-4000-b000-000000000000
attr handle: 0x004a, end grp handle: 0x004e uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
attr handle: 0x004f, end grp handle: 0x0053 uuid: f000aa64-0451-4000-b000-000000000000
attr handle: 0x0054, end grp handle: 0x005a uuid: f000ac00-0451-4000-b000-000000000000
attr handle: 0x005b, end grp handle: 0x0062 uuid: f000ccc0-0451-4000-b000-000000000000
 
 
Not sure why the difference.  I've compiled the firmware yesterday with the ble_2_02_00_31 stack.  Perhaps, your ble stack is older and does not include the battery service. Also, perhaps, that's why my handle numbering is shifted up by three entries.
 
3. Yes, the *ambient* temperature is correct, but the object temp in my case is incorrect and has been since day one:
 
Yours:
 
 44 0a ec 0d

SCALE_LSB = 0.03125;
rawTobj, rawTamb = int('0x0a44', 16), int('0dec', 16)
tObj = (rawTobj >> 2) * SCALE_LSB;
tAmb = (rawTamb >> 2) * SCALE_LSB;
print tObj, tAmb
 
20.53125 27.84375
 
-- Mine:
01 80 10 0b

SCALE_LSB = 0.03125;
rawTobj, rawTamb = int('0x8001', 16), int('0b10', 16)
tObj = (rawTobj >> 2) * SCALE_LSB;
tAmb = (rawTamb >> 2) * SCALE_LSB;
print tObj, tAmb
 
256.0 22.125
 
In your case, there is a 7 degrees difference between the ambient and the object temperatures, so it's hard to believe the object temp is so comparatively low.  In my case, the sensor appears completely broken in comparison to yours, at least.

 

[BobS0327]

Not sure why the difference.  I've compiled the firmware yesterday with the ble_2_02_00_31 stack.  Perhaps, your ble stack is older and does not include the battery service. Also, perhaps, that's why my handle numbering is shifted up by three entries.

 
 
I've been using BLE-Stack-2.2.0 from the very beginning. Downloaded it from http://www.ti.com/tool/ble-stack?keyMatch=ble%20stack%20download&tisearch=Search-EN-Everything
 
 
I noticed on the wiki http://processors.wiki.ti.com/index.php/CC2650_SensorTag_User's_Guide#IR_Temperature_Sensor that they cast the values to float prior to multiplying by SCALE_LSB.  I'm not sure that has anything to do with the problem.
 
I tried to update firmware over the air (OAD) using an Android tablet and unfortunately bricked the device.  Thus, how did you compile and download firmware?
 
 

 

[vc1234]

I've downloaded:
ble_sdk_2_02_00_31_setup.exe -- the ble stack with the sensortag source and other examples
tirtos_cc13xx_cc26xx_setupwin32_2_18_00_03.exe -- RTOS stuff required to compile the firmware
ccs_setup_win32.exe  -- Code Composer Studio -- the toolchain (compiler, linker)
 
To restore the tag original firmware, you need the SmartFR flash programmer can use use your XDS110 debugger -- a free download from TI.  In the flash programmer you can browse to the precompiled "super" hex file located in C:\ti\simplelink\ble_sdk_2_02_00_31\examples\hex\cc2650stk_sensortag_rel.hex and flash it. I did that a couple of times when I was playing with the debugger(see below).
 
If you decide to use the studio, there are a couple of inconveniences along the way.
The tag "super"-hex file has three parts: BIM(boot image manager), the bt stack, and the app proper. So, you need to compile three projects from CCS and combine the files into one using a ti python script -- pretty low tech, and then flash.
 
Or, you can compile the app itself only and load it directly from CCS using the "debug" command (start debug on the app project and after it's ready, exit the debugger).  From CCS, you will overwrite only the app firmware with the BIM and the stack intact. When I tried to flash the app alone from the SmartRF flasher, the tag became unresponsive with the red led faintly glowing.  I was not motivated enough to investigate, so I just flashed from the studio as described above.
 
Now, the XDS110 problem/"feature".  The XDS proper firmware is different between CCS and the SmartRF 2 programmer, so each time you use the XDS110 from either, you'll need to load the XDS110 firmware compatible with the tool you use (CCS uses a newer version but the SmartRF flasher insists on using the older version).  It's pretty easy to do but annoying.  I am not too happy with the TI toolset, as I mentioned especially CCS , being accustommed to much leaner and faster toolchains.

 

[BobS0327]

I used the SmartRF flash method you suggested and it was successful.  Thanx.
 
I think I found the issue with my missing battery service.  I've been flashing the device using the TI cloud tools which does not include the sensor_batt files in the Application folder whereas the local CSS tool has the sensor_batt files included in the Application folder.  I'm assuming you're working with the local TI CSS.  Thus, you have the battery service listed in your primary UUIDs.  Whereas, the cloud tool doesn't have the battery service UUID since it's not included in the Application folder.
 
Unfortunately, when I try using the local CCS, it  repeatedly fails with...
 

INTERNAL ERROR: C:\ti\ccsv6\tools\compiler\ti-cgt-arm_15.12.1.LTS\bin\armlnk.exe experienced an unhandled exception. 
 
This is caused by a defect in the compiler itself. TI Customer Support may be able to suggest a workaround to avoid this.

 

 

[vc1234]

I used the SmartRF flash method you suggested and it was successful.  Thanx.
 
I think I found the issue with my missing battery service.  I've been flashing the device using the TI cloud tools which does not include the sensor_batt files in the Application folder whereas the local CSS tool has the sensor_batt files included in the Application folder.  I'm assuming you're working with the local TI CSS.  Thus, you have the battery service listed in your primary UUIDs.  Whereas, the cloud tool doesn't have the battery service UUID since it's not included in the Application folder.
 
Unfortunately, when I try using the local CCS, it  repeatedly fails with...
 

For fear of sounding too negative, I was rather mild in my CCS criticism -- it's covered with bugs like a stray dog with fleas.  The bulk of time I've spent was on fighting CCS anomalies and its general slowness. But, In any case, I found some random TI employee advice to disable the '-compress_dwarf' option in a project's properties/ARM Linker/Advanced.  After that, I could compile the stack.  I do not believe I needed to change anything  for the app or the bim.

 

[BobS0327]

I have finally been able to successfully build the sensortag app and stack using the local CCS v6.
 
 
My results......

handle: 0x0024, uuid: f000aa01-0451-4000-b000-000000000000

handle: 0x0027, uuid: f000aa02-0451-4000-b000-000000000000

 
 

[B0:B4:486B:82][LE]> char-write-cmd 0x27 01
[B0:B4:486B:82][LE]> char-read-hnd 0x24

Characteristic value/descriptor: 24 0a 98 0f 

 
 
 
I also have the battery service.

 

[vc1234]

I have finally been able to successfully build the sensortag app and stack using the local CCS v6.
 
 
My results......

handle: 0x0024, uuid: f000aa01-0451-4000-b000-000000000000

handle: 0x0027, uuid: f000aa02-0451-4000-b000-000000000000

 
 

[B0:B4:486B:82][LE]> char-write-cmd 0x27 01
[B0:B4:486B:82][LE]> char-read-hnd 0x24

Characteristic value/descriptor: 24 0a 98 0f 

 
 
 
I also have the battery service.

I've started looking at the battery life a couple days ago. The original level before the permanent advertising was 82%.  After two days, it dropped to 70%.  My sensortag advertises once a second.  Perhaps, the first step would to disable the silly led to conserve some energy.
 
As to my IR object temperature, it seems to be broken -- it stays at  01 80.

 

[BobS0327]

I've started looking at the battery life a couple days ago. The original level before the permanent advertising was 82%.  After two days, it dropped to 70%.  My sensortag advertises once a second.  Perhaps, the first step would to disable the silly led to conserve some energy.
 
As to my IR object temperature, it seems to be broken -- it stays at  01 80.

 
In my IOT project, advertising (a blinking green led) really shouldn't be an issue since I'll be connected to the device just about all the time in order to collect data. Thus, the led will rarely be blinking.  My concern is how fast a continually active processor will drain the battery.
 
Maybe your IR temperature object isn't broken.  Maybe there was a quirk in the build and flashing of the software.  This has been my personal experience where although the build and flash appeared to be successful but yet I bricked the device upon flashing it.  After repeating the process (build and flash) three times, I had a successfully working IOT device.  Note, that I didn't update the code at all.  I just repeatedly built and flashed the code until it worked.  I'm not sure why this happened.  It may very well be a noob error. But anyway, everything is now working fine.

 

[vc1234]

In my IOT project, advertising (a blinking green led) really shouldn't be an issue since I'll be connected to the device just about all the time in order to collect data. Thus, the led will rarely be blinking.  My concern is how fast a continually active processor will drain the battery.
 
Maybe your IR temperature object isn't broken.  Maybe there was a quirk in the build and flashing of the software.  This has been my personal experience where although the build and flash appeared to be successful but yet I bricked the device upon flashing it.  After repeating the process (build and flash) three times, I had a successfully working IOT device.  Note, that I didn't update the code at all.  I just repeatedly built and flashed the code until it worked.  I'm not sure why this happened.  It may very well be a noob error. But anyway, everything is now working fine.

Well,  I re-flashed many times without any change for the better.  I do not care too much about this specific sensor because out of four available temp sensors three do work and somewhat agree with each other:
 
Connecting to A0:E6:F8:B6:60:86
Temp:  (25.78125, -256.0)
Humidity:  (24.84588623046875, 62.530517578125)
Barometer:  (25.36, 1003.72)

Connecting to A0:E6:F8:B6:60:86
Temp:  (25.6875, -256.0)
Humidity:  (24.775390625, 62.8173828125)
Barometer:  (25.28, 1003.68)

Connecting to A0:E6:F8:B6:60:86
Temp:  (25.59375, -256.0)
Humidity:  (24.69482421875, 62.982177734375)
Barometer:  (25.19, 1003.7)
 
It's just annoying that the IR object  temp sensor does not work (the -256 reading).  I have not  experienced breaking the device while flashing except when I forgot to flash the stack the first time.
 
I've just put in a new battery because my humidity sensor stopped working when the battery level went below 69%.  Other sensors continued working, though.  I read in loop -- once a minute.  Interestingly, when I connected the debugger, the humidity sensor started to work again -- that's when I realized that the firmware was not corrupted, just the battery level was not  good enough. I'll see how the new battery will work. What's your experience wrt the battery life ?
 
Here's some fellow who measured CC2650 energy consumption:
http://mobilemodding.info/2015/06/ti-sensortag-2-power-consumption-analysys/

 

[BobS0327]

What's your experience wrt the battery life ?

I haven't really used the sensor enough to provide any insights on battery life.  But I've spent a lot of time learning Node.js in order to write a util to not only continually monitor temp/humidity data but also to continually monitor the battery.  I should be able to provide fairly accurate battery life data once I debug the util and get it functioning properly.

 

[BobS0327]

What's your experience wrt the battery life ?

 
I have been continuously querying object and ambient temperature from the sensor for 15 days.  The results of my very unscientific testing indicated a battery level drop of 4% from 86% at start of testing  to 82% at the end of 15 continuous days of testing. The object/ambient temperature values were queried once a second 24/7 for 15 days.
 
I'm not sure if this battery level result is good bad or indifferent.

 

[vc1234]

I have been continuously querying object and ambient temperature from the sensor for 15 days.  The results of my very unscientific testing indicated a battery level drop of 4% from 86% at start of testing  to 82% at the end of 15 continuous days of testing. The object/ambient temperature values were queried once a second 24/7 for 15 days.
 
I'm not sure if this battery level result is good bad or indifferent.

I think it's quite good in comparison to my case where the battery went flat after only 2 weeks.  I kept reconnecting every minute to read the sensors.