The beginning of every GATT database (GATTDB) within the SDK begins the comment:

      // Service change characteristic is optional and is not present

What is the service change characteristic? Why would I want it? And how would I implement it?

Introduction:

     When a GATT client and server connect for the very first time, the client knows nothing about the server. In order to achieve a useful relationship, the client performs a GATT discovery on the server. There are a few variations in how the client can choose to go about this--search by handle, by type, etc.--we won't delve into the specifics of discovery.

     With low power in mind, these GATT discoveries are costly. Given that the client has the resources, it is far more efficient to jot down the details of the server's GATTDB and store that locally--this is called an Attribute Cache. In order to save power, upon future reconnections, the client will not perform a GATT discovery, but rather reach into its local memory to save power on both the client and server devices.

     However, a problem arises when we change the GATTDB between connections. The client will think the servers GATTDB is of the old form and begin operating on that basis. Now, this will only happen in the field under the premise that your firmware alters the GATTDB between connections.

     How do we fix this? One way is to utilize the Service Changed Characteristic. This characteristic is essentially a way for the server to indicate to the client that a change has been made to its GATTDB. The client should then update its Attribute Cache with the newest values.

Implementation:

This is how you would implement it in your GATTDB:

     const UINT8 gatt_database[]=

     {    

          // Handle 0x01: GATT service

          PRIMARY_SERVICE_UUID16 (0x0001, UUID_SERVICE_GATT),

          // Indicate that entire GATTDB has been altered

          // (handles: 0x0000 - 0xffff)

          CHARACTERISTIC_UUID16(0x0002, 0x0003,

               UUID_CHARACTERISTIC_SERVICE_CHANGED,

               LEGATTDB_CHAR_PROP_INDICATE,

               LEGATTDB_PERM_NONE, 4),

               0x00, 0x00, 0xff, 0xff,

          CHAR_DESCRIPTOR_UUID16_WRITABLE (0x0004,

               UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

               LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ, 2),

               0x00, 0x00,

          ...

     }

     This characteristic is implemented under the GATT Service that is mandatory to all GATTDB's. The Service Change Characteristic has a spec defined UUID. It needs only the ability to indicate and should have no required permissions. Lastly, it needs a value length of 4 bytes. These 4 bytes are used to designate the range of handles which have been changed. The first 2 bytes are the start handle, the last 2 bytes are the stop handle. As can be seen in the code above, we have specified this range to be all handles 0x0000 - 0xffff--tlling the client to completely rediscover the GATTDB.

     Since we need to use indications, this characteristic now needs a Client Configuration Descriptor--as all server initiated communications need. This descriptor is, essentially, two client-writable bytes that allow the client to give the server permission to transmit asynchronous communications--one byte is for notifications and the other is for indications. The service changed characteristic requires the use of indications (a notification with an application level ACK).

Use:

     The actual use of the Service Changed Characteristic requires the implementation of indications, GATT discovery by the client, and a change in the GATTDB by the server. These will not be covered here, but there exist individual resources for each:

     For implementation of indications see:

          Wiced-Smart-SDK/Apps/hello_client

          Wiced-Smart-SDK/Apps/hello_server

     For example firmware of a GATT change see:

          Re: How to change the GATT database after init (bleapp_set_cfg) ?

     For implementation of GATT discovery see:

          Wiced-Smart-SDK/Apps/automation_io_client

          Wiced-Smart-SDK/Apps/http_client

The maximum LL PDU (Packet Data Unit) for BLE 4.1 is 27 Bytes. In these 27 Bytes, the actual data that is transferred as a GATT Write or Notification can be upto 20 bytes, excluding the L2CAP header, Data PDU Header and Attribute Operation Code. If the link is encrypted, the LL PDU will additionally have a 4 Byte MIC (Message Integrity Check), there by making the LL PDU as 31 Bytes.

The LL Packet comprises of LL PDU (31 Bytes) + PDU Header (2 Bytes) Header (1 Bytes) + Access Address (4 Bytes) + Cyclic Redundancy Check (3 Bytes)

= 41 Bytes

= 41 * 8 Bits

= 328 Bits

The propagation time of each bit is 1uS. So for 328 Bits it is 328 uS. After each packet is sent, an additional 80 uS is spent for acknowledgement. Also, there is T_IFS, (Interframe time between a packet and acknowledgement and also between acknowledgement and next packet)

So time taken for 1 packet to be sent is:

328uS (actual data) + 150 uS (T_IFS) + 80 uS + 150 uS (T_IFS) = 708 uS

The number of packets per connection interval = Connection interval / 708 uS.

If the connection  interval is 7.5 mS, approximately, 10 packets can be sent.

The relation between the throughput and the connection interval is not so straight forward. As discussed in the previous interaction the time taken for sending 20 bytes is 708 uS.

Now let us discuss this with 3 cases of connection interval:

1) Assume that connection interval is 7.5 mS.

Number of packets sent is 7.5 mS / 708 uS = 10 packets.

Actually 708 uS * 10 = 7080 uS = 7.08 mS. So remaining 0.42 mS is idle (wasted)

2) Assume that connection interval is 8.75 mS.

Number of packets sent is 7.5 mS / 708 uS = 12 packets.

Actually 708 uS * 10 = 7080 uS = 8.496 mS. So remaining is only 0.254 mS is idle (wasted) (8.75 - 8.496 = 0.254 mS)

3) Assume that connection interval is 11.25 mS.

Number of packets sent is 11.25 mS / 708 uS = 15 packets

Actually 708 uS * 15 = 7080 uS = 10.620 mS. So remaining is 0.63mS is idle (wasted).

If you compare 1 and 2, increase in connection interval will result in less idle time. So increased throughput.

If you compare 2 and 3, increase in connection interval will result in more idle time. So less throughput.

So throughput and connection interval will not have a linear relation. However, if you increase the connection interval, power consumption will decrease. And vice versa. Because, less the connection interval, more often it has to be switched from sleep to awake and vice versa.

                                   

• Code Overview
  
  • iBeacon and SDK 2.1 Code Overview
  • WICED Smart BCM2073X Coding Tips from user maxsong...
  • WICED Smart Training videos, compliments of Macnica North America...
  • BCM92073X BLE Profile Configuration

• General Questions
  
  • BCM20732 questions
  • How to get started (coming from arduino)
  • What is difference between being connected versus paired?
  • Wiced Smart Software Runtime -- Lots of Questions
  • About BCM20737S
  • BCM20737s: NFC Reader or only TAG?

• Hardware Design between 2073X and External MCU

• Reference Design/Schematics
  
  • New iBeacon BCM20737 Reference Design
  • Experts Interview Video: Michael L. - IBCN BCM20737 Schematic Review
  • BCM20737TAG Board - Gerbers and Schematics

• Layout
  
  • BCM20732 layout options
  • BCM20737S input capacitors and placement
  • BCM20732S layout
  • Are pullup resistors always needed on 20732 SCL and SCA pins?
  • Exact Location of internal PIFA Antenna on BCM20737S
  • 20732S XTAL (32KHz)

• General
  
  • WICED Smart Video BLOG: SDK 2.1 Smart Designer Tool Walk-Thru
  • WICED Smart BCM92073X GATT DB Operation
  • Lots of questions.. L2CAP/GATT/GAP, etc
  • Multiple Notifications in an App...?
  • Support for very large characteristics

• Other
  • How to change the GATT database after init (bleapp_set_cfg) ?
  • Is pairing/encryption mandatory to allow a peer to write in GATT

• Advertising
  
  • Customizing Advertising on WICED Smart
  • Best way to rewrite advertisement data
  • Connectable vs. nonconnectable Advertisements.
  • How to change advertisement interval after init?
  • Advertising during connection
  • bleprofile_notifyAdvPacketTransmissions doesn't work.

• Callback to modify single advertisments?
• About the bleprofile_GenerateScanRspData function?
• How to register callback for ADV events ?

• Scanning
  
  • Scan sometimes stops working
  • Scheduling of scan window and connection window

• Additional master/slave questions on BCM20736/7 family
• Re: How best to implement bulk data transport
• smp_bond_result 04
• Connection Event Callback API
• Connection Event Callback API (follow-on)
• Connection Interval and Connection Slave Latency
• When does bleprofile_sendNotification() actually send?
• Check if bleprofile_sendNotification() was successful
• Slow reconnection
• Sometimes connection not bonding

• Adding and removing master nodes to a whitelist running on a peripheral device

• General
  
  • BCM2073XS GPIO Basics
  • Can someone tutor me on GPIO usage?
  • GPIO Headers
  • BCM20732S PIN information
  • BCM2073xS (BCM20737S) GPIO bonding

• Interrupts
  • Access_tag_interrupt_handler
  • How to identify GPIO interrupt source pin?
  • Buttons in hello_sensor.c
  • How can I wake BCM20737S up by using GPIO interrupt?
  • How to disable interrupt?
  • GPIO in high impedance mode
  • Wake up on GPIO interrupt

• General
  
  • Information: Debug the BCM20732 Tag over HCI-UART using a COM port via USB on the PC
  • How to debug the board step by step?
  • Information: BCM20732S debug/trace capabilities through the HCI UART port
  • How do I interpret the extra tracing data ?
  • Testing Master and Slave Roles
  • How can I use ble_trace() for application debug?
  • How to get debug traces ?
  • WICED Sense debug with UART
  • How to disable 20737S SDK trace, BLE_TRACE_DISABLE?

• J-Link
  • WICED Smart J-Link Debugger
  • WICED Smart - Debugging Support Using a J-Link Probe Application Note

• BCM92073X TAG Power Supply Configurations
• Power level granularity in blecm_setTxPowerInConnection() and blecm_setTxPowerInADV()
• Current Draw and Advertising Timing on the WICED Sense (BCM20737S)
• how to reduce the power consumption when use puart ?
• BCM20737S Current Consumption Voltage Condition and more...
• [BC20636S] Power consumption advantages when using external oscillator

• BLE RF Testing Specification Introduction
• BLE RF Testing Setup Procedures

• General
  
  • WICED Smart Video BLOG: Experts Interview - Sleep Deep_Sleep and Advertising
  • Sleep Deep_Sleep Explanation and Techniques
  • WICED Smart Sleep/Deep-Sleep Explanation and Techniques Design Guide
  • BCM20736S Sleep Example Firmware
  • Questions sleep and deep sleep modes on BCM20737
  • GPIO Interrupt State after Deep Sleep

• Entering Sleep
  
  • How to enter HIDOFF?  How to detect if the request is not honored?
  • Putting '20732S into sleep or deep sleep mode
  • BCM20736S HIDOFF problem
  • Problem with sleep mode
  • Sleep Mode on 20736S

• Waking From Sleep
  • Boot Time of WICED Smart Tag Board (BCM20737)
  • GPIO state in deep sleep
  • For wake on GPIO interrupts, please look under GPIO->Interrupt
    

• WICED™ Smart Hardware Interfaces
• BCM20736S I2C, PUART and SPI comms
• SPI1 access or send command to flash in application level.

• Memory:
  • BCM20732 Memory Map Architecture
  • BCM92073X TAG Memory and Programming Configurations
  • WICED Smart BCM92073X I2C EEPROM Emulation Porting Guide
  • WICED Smart BCM92073X EEPROM and SFLASH Layout
  • WICED Smart BCM92073X NVRAM Access
  • Memory size limits on 20732?
  • BCM20732S NVRAM Size
  • nvram: number of locations to write to
  • BCM20736S I2C, PUART and SPI comms
  • It seems that I can not read the data is stored in NVRAM before the last power off.
  • Layout of VS1 in the EEPROM
  • Re: Accessing the 512 kb (64 kB) EEPROM in the 20737S module

• PWM:
  • LED with PWM
  • Different Frequencies for PWM
  • How many PWM channels available in BCM20732S ?
  • BCM92073x periodic interrupt rate
  • How to turn on LED

• ADC:
  • BCM20732S ADC Configuration
  • Questions related to the ADC implementation on the BCM2073XS...
  • ADC on BCM20732

• UART:
  • Information: Programming your BCM20732S-based board from an onboard UART header
  • UART does not receive
  • UART Routines
  • BCM20732S based boards sometimes develop UART failure
  • Spec for uploading firmware to the BCM20732S via HCI UART?
  • puart_write() crashing on BCM20736?
  • Peripheral UART missing bytes
  • Problem with UART watermarks
  • PUART RTS/CTS Hardware Flow Control
  • What are the PUART FIFO Rx interrupt threshold settings?
  • Need clarification on PUART RTS/CTS flow control support

• I2C:
  • I2C Discussion
  • BCM20736S recovery problem - SDA high does not enter recovery mode
  • How can I use i2c in BCM20737S?

• SPI:
  • SPI on BCM920732TAG
  • Spi Debug
  • SPI flow control

• Timer in 2073x
• BCM20737S Timer Module

• Software/Usage
  
  • appFineTimer
  • FineTimer
  • What is the best way to set an application timer to fire?
  • how to config RTC use external 32.768?
  • Re: How to use real time tick clock?
  • rtc_sample bricks our BCM20736S-based board
  • Turning off the timers in BCM20736S
  • Hello_client/blecen Timer Callback Questions

• Watchdog Timer
  • How can I get bcm20732s reset reason?
  • Increasing/Disabling the watchdog timer

• Crystal
  • Explanation of Crystal Warmup Issue
  • Crystal warm-up work-around video...
  • 32kHz Crystal Spec?
  • Internal vs. External Oscillator

• RTC
  • rtc_RtcTime2Sec() returns wrong seconds when RtcTime.year is 2016
  • How to use real time tick clock?
  • rtc_sample bricks our BCM20736S-based board
  • how to config RTC use external 32.768?

• Watchdog Timer
  • Increasing/Disabling the watchdog timer
  • How can I get bcm20732s reset reason?

• Hardware Timer
  • How to use 100us interval timer?
  • Hardware Timer (hw_timer.h) usage
  • HW Timer in 2073x
  • Timer in 2073x
  • Wiced Sense hardware timer example
  • Wiced Sense hardware timer example (part 2)

• WICED Smart BCM92073X OTA Firmware Upgrade (1)
• WICED Smart BCM92073X OTA Firmware Upgrade (2)
• How to do OTA: Step by Step with PDF
• SOTAFU for Android and iOS
• Why error occur when I open WsOtaUpgrade.exe?
• Why error occur when I open WsOtaUpgrade.exe? (continued)
• Issue with using Windows OTA upgrade app

• How to recover BCM20736S on custom board?

Security:

• Encryption API
• How to operate RSA in BCM20737S & BCM20737S document
• Update on RSA and/or app note for BCM20737?
• BCM20736S and RSA
• RSA Document
• BCM20737S: LE security mode1 level3/4 supported?

• Programming manufacturing data during production
• Do I need to register separately with the Bluetooth SIG to use the Bluetooth logo in my product?

• BD_ADDR - how do you get one?
• BD_ADDR: Changing BCM20737 Board Address for Production
• Changing BD_ADDR from the application
• Video Link : 1216

• Programming the TAG2/TAG3 Board using command line tools
• BCM20732S refuses to program
• cgs.exe and ChipLoad.exe

• WICED Smart BCM92073X Generate Your Own UUID

• Broadcom BCM20732S/BCM20736S/BCM20737S Regulatory Approvals
• Certification from Bluetooth SIG
• 20732S regulatory certification
• More questions regarding FCC certification on the BCM2073XS Product
• FCC Certification Flow for Broadcom module products
• FCC approval for BCM20736S