Energy savings:

 

this chip suppose to be small. For that, the CR-2032 battery should fit within.

We wanted to calculate for how long this battery may be used with BLE communication.

Those are out assumptions:

* The CR-2032 may be used for long enough time if the device is idle

* Most of the time the device is advertising, then rest in idle mode until it is advertising again.

* The BLE communication with the mobile application is rare.Therefore we focused in the energy consumption of our BLE advertisements.

 

Solution: We used TI power calculator for BLE (in this link ) with the following parameters:

** Power level: 0 dBM (The default power level)

** Role: Broadcast/beacon

** We assumed that the device is in advertisement mode in 100% of the day (the interval time is included in this mode)

** We transmit at most 31 bytes in one channel

** The advertising interval is at least 1 second

 

The result was that the battery can hold for 981.218 days (which is more than 2.5 years), so if we neglect the consumption of the board itself, and for the BLE communication with the application (because its rare), the battery might be used for at least 2 years in the most wasteful mode (big house mode - 1 second interval)

 

Buffer-overflow on advertisement packet

 

* Buffer overflow upon generating the bt_struct with the ap_name.
* We've done some changes to the code and in one of the changes we've given the bt_struct less space than really required, the result was surely unexpected.
* the device was still running but no advertisments were correctly sent.
* it seems that also some part of the code was overflowed but it was changing only data sections so the code was running correctly.
* it took some time to find out the bug, extend the buffer and restart again with the correct results.

 

 

The non-exisiting SysCtrlSystemReset() Bug

 

* seems that when the device is being debugged - the call to reset it is interruped by the debugger itself and the device doesn't start back up again.

* It can be related to the fact that JTAG connection is stopped and might be that power supply is changing because of stopping/reseting the current debug state.

* It seems that upon steady power-supply the device always resets correctly.

references: https://e2e.ti.com/support/wireless_connectivity/zigbee_6lowpan_802-15-4_mac/f/158/t/449271

 

 

The Double Pin init Bug:

 

We connected the speaker to pin number 25 in the cc2650. So we wanted to "turn the pin on" when the application sends "FindMe!" command (over BLE). For that, we had to initialize pin number 25, and open it for setting output. We also wanted to keep the good design of the project, so we inserted in the initialization of out BLE service the initialization of pin number 25(PIN_init()). It didn't work! It turns out that you can't call twice to PIN_init, and the main.c already called PIN_init.To solve this bug, insert the pin to the BoardGpioInitTable which defines all the pins for initialization (from the main).

 

Battery VS. usability: Advertisement interval issue:

 

We wanted to find the biggest interval time between every BLE advertisement, so we use as least energy as we still enables to the device to be found in every (normal) case.

 

We figured out that if the interval time is bigger than 4 seconds, the cellphone didn't manage to pair with the device.

So, we planned the device for 3 advertisement modes, depend on the size of the house.

The guideline was that the bigger the house, the faster the people walk while they are trying to finding the device. so for small houses - we advertise every 4 seconds, for medium houses every 2 seconds, and for big houses - every 1 second.

BLE endians:

It took us some time to figure that our Android application expects to receive (and send) data in big endian, while the cc2650 is arm-little endian.
The results of this was that some number didn't transmitted well over BLE. We solved it after we figured it out, and added a translation of big-little endian before sending or receiving (in the cc2650).

 

The one-configuration Bug:

 

Our implementation of FindMe! defines BtConfig struct which defines the configuration of the device (BLE ap, intervals and so on...).

The program reads the BtConfig struct from the flash (from constant address), verify that this struct is BtConfig struct, and reads its configuration. If the data isn't valid BtConfig struct, the program generates BtConfig struct for default configuration, and writes it to the flash (to the same address).

 

In the process of the development we wanted to test the configuration changes from the BLE. The device output the right debug prints, but the configuration didn't change as we expected. It did look like the first write to the flash worked every time we change the constant flash address, but the following writes didn't happen.

 

We suspected that there is some "voodoo" with the memcpy() function which copy the value of the change from the BLE to the BtConfig struct, but when we debugged it, we saw that the registers and the memory behave like we expected.

Finally, we understood that we assumed that the ExtFlash library performs automatically "Erase" operation, before it "Write" to the flash, but in-fact, it just wrap "Write" operation and doesn't erasing the relevant sectors before it writing.

Because the nature of the flash (AND writing technique) , every time we changed the constant flash address, we wrote in the first time to "erased" sector, so the writing succeeded, but in the following writing attempts, the sector wasn't erased so the writing wasn't succeeded (at least not as expected)