Introduction

This article introduces a demo project about Apple Notification Center Service (ANCS). The demo project is able to receive ANCS notifications like phone calls, calendar events, etc.

What is ANCS?

The information below can be found on the Apple specification linked below, but for the convenience we summarize it here.

The purpose of the Apple Notification Center Service (ANCS) is to give Bluetooth accessories (that connect to iOS devices through a Bluetooth Low Energy link) a simple and convenient way to access many kinds of notifications that are generated on iOS devices.

Terminology

The Apple Notification Center Service is referred to as the ANCS.

The publisher of the ANCS service (the iOS device) is referred to as Notification Provider (NP).

Any client of the ANCS service (an accessory) is referred to as a Notification Consumer (NC).

A notification displayed on an iOS device in the iOS Notification Center is referred to as iOS notification.

A notification sent by a GATT characteristic as an asynchronous message is referred to as a GATT notification.

The Apple Notifications Center Service

In its basic form, the ANCS exposes three characteristics:

• Notification Source: UUID: 9FBF120D-6301-42D9-8C58-25E699A21DBD (notifiable)

• Control Point: UUID: 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (writable with response)

• Data Source: UUID: 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (notifiable)

All these characteristics require authorization for access.

Support for the Notification Source characteristic is mandatory, whereas support for the Control Point characteristic and Data Source characteristic is optional.

Note: In this demo project we use the Notification Source characteristic only .

A GATT notification delivered through the Notification Source characteristic contains the following information:

• EventID: This field informs the accessory whether the given iOS notification was added, modified, or removed. The enumerated values for this field are defined in EventID Values.

• EventFlags: A bitmask whose set bits inform an NC of specificities with the iOS notification. For example, if an iOS notification is considered “important”, the NC may want to display a more aggressive user interface (UI) to make sure the user is properly alerted. The enumerated bits for this field are defined in EventFlags.

• CategoryID: A numerical value providing a category in which the iOS notification can be classified. The NP will make a best effort to provide an accurate category for each iOS notification. The enumerated values for this field are defined in CategoryID Values.

• CategoryCount: The current number of active iOS notifications in the given category. For example, if two unread emails are sitting in a user’s email inbox, and a new email is pushed to the user’s iOS device, the value of CategoryCount is 3.

• NotificationUID: A 32-bit numerical value that is the unique identifier (UID) for the iOS notification. This value can be used as a handle in commands sent to the Control Point characteristic to interact with the iOS notification.

For more information about ANCS, please check specification linked below.

Demo Implementation

The demo project is able to receive ANCS notifications like phone calls, calendar events, etc. and prints them out to the VCOM. The software flow goes as follows:

1. At first the software initialize the peripherals, the Bluetooth stack and logging to the virtual COM port.

2. After the gecko_evt_system_boot_id event arrived it sets up the security manager in order to able to bond with iOS device. Then it starts advertising.

3. Once gecko_evt_gatt_mtu_exchanged_id event received the device connected and the connection parameters negotiated. Then the device starts to search for the ANCS service in the remote GATT with the gecko_cmd_gatt_discover_primary_services_by_uuidAPI.

4. If it finds the ANCS service, it will start searching for the notification source characteristic in the remote GATT with the gecko_cmd_gatt_discover_characteristics_by_uuid API.

5. If the notification source characteristic is found in the remote GATT, the device tries to subscribe to characteristic notification with the gecko_cmd_gatt_set_characteristic_notification API. If the iOS device and the BGM module are not bonded, it is not possible. First the pairing and bonding process have to be completed. Once the bonding is completed, we have to enable the characteristic notification again. This time it will work.

6. Receiving a gecko_evt_gatt_characteristic_value_id event with the att_opcode == gatt_handle_value_notification means the we got a GATT notification from the remote device. In this case, we determine the notification type based on the notification UID and print it out with the ancCharValueReceivedCallback function.

The activity diagram below shows the described flow.

Running the Demo

1. Get an iOS device and switch on the Bluetooth in it. Enable application notifications.

2. Create a new SoC-Empty project for your device (tested with EFR32BG13) in Simplicity Studio.

3. Copy the attached files into the project:

   • app.c
   • anc.c and anc.h
   • anc-callback.c and anc-callback.h
   • connection.c and connection.h

4. Change the "Device Name" characteristic value to "ANCS Example" to better recognize the device in Bluetooth browsers.

5. Change DEBUG_LEVEL to 1 in app.h.

6. Build and flash the project to your device.

7. Start a terminal like TeraTerm and open the virtual COM port of the J-Link CDC device.

8. Connect to the BG13 "ANCS Example" with a Bluetooth browser app like the Blue Gecko and accept the pairing request.

9. Now you should get ANCS notifications like below when you get email, for example.

Further Reading

Apple Notification Center Service (ANCS) Specification

Bluetooth Software API Reference

Blue Gecko iOS app

Hello again,

I took a look at the Python script and with my limited familiarity with bluepy, I would say that it seems fine (Considering you get data back).

I would maybe check if getDescriptors() shows you the Client Characteristic Configuration and then subscribe. Other than that, I can't really say as we don't have a Raspberry Pi setup in place to test these. 

(What is wrong with the second run logs here? It seems the latter 9 notifications arrive within about 13 ms?)

Have you tested with 2 WSTKs and used the gatt_set_characteristic_notification command on the client side? I would suggest that you take the SPP example and try that. It uses notifications from server to client and is quite proven. Test that and observe with Network Analyzer and/or Energy Profiler what is going on, if that doesn't work. Those tools in Simplicity Studio should give better view of the timing.

BR,
-Harri

Hi again, 

I tested your example code (same board, same SDK version). The client I used was BGTool. 
 

I think you are doing enabling notifications wrong:

//*** Event for notification subscription
        else if (evt->data.evt_gatt_server_user_write_request.characteristic == gattdb_start_notification)
        {
          notification_count = evt->data.evt_gatt_server_user_write_request.value.data[0];
          bt_connection = evt->data.evt_gatt_server_user_write_request.connection;
          notif_enable = 1;
          op_result = gecko_cmd_gatt_write_descriptor_value(evt->data.evt_gatt_server_user_write_request.connection, gattdb_data_notification+1, 1, &notif_enable) ->result;
          gecko_cmd_gatt_server_send_user_write_response( evt->data.evt_gatt_server_user_write_request.connection, gattdb_start_notification, op_result );
          printLog("%lu\t Notification requested = %d, Result = %d\r\n", RTCC_CounterGet(), notification_count, op_result );
        }
        break;

This command: op_result = gecko_cmd_gatt_write_descriptor_value(evt->data.evt_gatt_server_user_write_request.connection, gattdb_data_notification+1, 1, &notif_enable) ->result;

is a GATT Client API, but you are calling it from the server side device. This doesn't write the descriptor on the local device, but on the remote (RasPi) side. 

What I did instead:

1. Connect and discover whole database
2. Change connection parameters to 20, 20, 0, 2000
3. Write e.g. 4 to start_notification characteristic
4. Enable notifications = Write value 1 to handle 31 with BGTool (in your case Raspberry Pi should write this somehow)

5. Success, all notifications received in about 2.1 ms so well within one interval.

Let me know if this helps,

-Harri

Introduction

The Low Energy Timer is a 2 channel 16-bit down count timer and is available in energy mode EM2 DeepSleep, EM1 Sleep, and EM0 Active. Because of this, it can be used for timing and output generation when most of the device is powered down, allowing simple tasks to be performed while the power consumption of the system is kept at an absolute minimum. Timer runs from the LFACLK which can be clocked by the LFXO, LFRCO or HFCORECLKLE/2. In my example LFXO is used as an clock source and it has frequency of 32768 Hz. The LETIMER can be used to output a variety of waveforms with minimal software intervention. It can also be connected to the Real-Time Counter (RTC) using the Peripheral Reflex System (PRS), and can be configured to start counting on compare matches from the RTC. Supported waveforms:

• Toggle output pin
• Apply a positive pulse (pulse width of one LFACLKLETIMER period)
• PWM

LETIMER also support interrupts from the following events:

• Compare matches
• Timer underflow
• Repeat done

In this example, I show how to use Low Energy timer with a simple software example. This example is created for the BG13 but is easily portable to other devices as well. More detailed information about the Low Energy Timer can be found from the AN0026 document and EFR32xG1x Wireless Gecko Reference Manual.

Requirements:

• Wireless Starter Kit and EFR32XG1X based radio board (Or your own solution with minor modifications to the code).

Implementation

I have divided the implementation to 6 steps. Example application file, which can be copied on top of SoC - Empty, is also attached below.

1. Create a new SoC – Empty project for your preferred device, Bluetooth SDK and compiler.

   After the project is created, the BLE GATT Configurator is opened automatically and it shows the GATT database of the project. The project template includes a minimal GATT database that includes three services (Generic Access, Device Information and Silicon Labs OTA).

2. Copy em_letimer.c and em_letimer.h file to the project folder.

   • Find your project folder in Simplicity Studio and open emlib folder.
   • Navigate to emlib folder in the SDK directories (location is at C:\SiliconLabs\SimplicityStudio\vX\developer\sdks\gecko_sdk_suite\vY\platform\emlib\src (and inc)).
   • Find em_letimer.c/.h file and copy it to your project emlib folder in Simplicity Studio.

3. Include LE Timer, CMU and GPIO libraries in app.c file. These libraries are required for PWM signal.

   Add these lines next to other includes:

#include "em_letimer.h"
#include "em_gpio.h"
#include "em_cmu.h"

4.  Include LETIMER_setup function. This function initializes LETIMER and routes timer output to WSTK led pins. Please keep in mind that if you are not using BG13 and LED output pins are not PF4 and PF5, you need to configure your timer routing location.

E.g. for BGM111, the respective pins are PF6 and PF7 and routing location 30.

static void LETIMER_setup(void)
{
  /* Enable necessary clocks */
  CMU_ClockSelectSet(cmuClock_LFA, cmuSelect_LFXO);
  CMU_ClockEnable(cmuClock_CORELE, true);
  CMU_ClockEnable(cmuClock_LETIMER0, true);
  CMU_ClockEnable(cmuClock_GPIO, true);

  /* WSTK LED pins are configured to Push-pull */
  GPIO_PinModeSet(BSP_LED0_PORT, BSP_LED0_PIN, gpioModePushPull, 0);
  GPIO_PinModeSet(BSP_LED1_PORT, BSP_LED1_PIN, gpioModePushPull, 0);

  /* Repetition values must be nonzero so that the outputs
   return switch between idle and active state */
  LETIMER_RepeatSet(LETIMER0, 0, 0x01);
  LETIMER_RepeatSet(LETIMER0, 1, 0x01);

  // This configuration is valid only if PF4 and PF5 are
  // used for output signal. Change this "LOC28" value to
  // preferred value that can be found from Device datasheet
  // section Alternate Functionality Pinout.

  /* Set up PF4 pin <- LETIM0_OUT0 */
  LETIMER0->ROUTELOC0 = (LETIMER0->ROUTELOC0
      & ~_LETIMER_ROUTELOC0_OUT0LOC_MASK)
      | LETIMER_ROUTELOC0_OUT0LOC_LOC28;
  LETIMER0->ROUTEPEN |= LETIMER_ROUTEPEN_OUT0PEN;

  /* Set up PF5 pin <- LETIM0_OUT1 */
  LETIMER0->ROUTELOC0 = (LETIMER0->ROUTELOC0
      & ~_LETIMER_ROUTELOC0_OUT1LOC_MASK)
      | LETIMER_ROUTELOC0_OUT1LOC_LOC28;
  LETIMER0->ROUTEPEN |= LETIMER_ROUTEPEN_OUT1PEN;

  /* Set configurations for LETIMER 0 */
  const LETIMER_Init_TypeDef LETIMER_INITIAL_CONFIG = {
    .enable = true,               /* Start counting when init completed. */
    .debugRun = false,            /* Counter shall not keep running during debug halt. */
    .comp0Top = true,             /* Load COMP0 register into CNT when counter underflows. COMP0 is used as TOP */
    .bufTop = false,              /* Don't load COMP1 into COMP0 when REP0 reaches 0. */
    .out0Pol = 0,                 /* Idle value for output 0. */
    .out1Pol = 0,                 /* Idle value for output 1. */
    .ufoa0 = letimerUFOAPwm,      /* PWM output on output 0 */
    .ufoa1 = letimerUFOAPwm,      /* PWM output on output 1*/
    .repMode = letimerRepeatFree  /* Count until stopped */
  };

  /* Initialize LETIMER */
  LETIMER_Init(LETIMER0, &LETIMER_INITIAL_CONFIG);

  // LETimer is 16-bit down counting timer and oscillator frequency is 32768 Hz.
  // PWM duty-cycle and frequency can be determined using these compare values.
  // In short, the first one determines frequency and second one determines duty-cycle.
  // Frequency = 32768 / COMP0, Duty-cycle [%] = COMP1 / COMP0 * 100

  LETIMER_CompareSet(LETIMER0, 0, 32768);     // COMP0
  LETIMER_CompareSet(LETIMER0, 1, 32768 / 2); // COMP1
}

5. Call LETIMER setup function after stack initialization.

// Initialize LETIMER
LETIMER_setup();

6. Observe the LEDs blinking at roughly 1 Hz, duty-cycle 50 %. You can verify that your device goes to sleep with Energy Profiler. Peaks are sections where LEDs are turned on and lows are sections where LEDs are off. Changing the PWM frequency and duty-cycle is done by adjusting the above compare value registers according to commented formulas.

Further Reading

AN0026.1: EFM32 and EFR32 Wireless SoC Series 1 Low Energy Timer

EFR32BG13 Blue Gecko Bluetooth® Low Energy SoC Family Datasheet

Hi Syed,

So, to clarify your description:
 

1. You have a characteristic to "Write"  to trigger the 4-notification sequence
2. You want to send 4 notifications in one interval each with 130B of payload
3. You get the data that you sent uncorrupted, but just in 4 intervals instead of 1
 

It is certainly possible to send more than one per interval, so more information is needed. 

Is there some snippet of source code that you could provide here? 

Just as a side note, smaller connection interval doesn't guarantee higher throughput always, as explained here

Example of high throughput application can be found here

Also, you do not need to limit the MTU size to 133 as that is just the maximum limit. You can send anything below the limit.

BR,
-Harri

Introduction

The command system_set_tx_power can be used to set the maximum TX power, but the value which is set by the Bluetooth stack may not be the same that is given as input to the command. The actual set value can be read from the command response.

The TX power values of EFR32xG chipset are not continuous, the lower the value, the coarser the adjustment. Attachment is a test result by iterating value from -300 to +80 on a BGM111. Note the TX power is in 0.1 dBm steps, so for example the value of 50 equals to +5 dBm. For more information, refer to the API reference manual, system_set_tx_power command.

Running the Example

Attached is an application, which will iterate through a minimum and a maximum TX power value given to system_set_tx_power command, and it will print out both the input parameter and the response. This sweep runs only once out of reset and if you open a terminal (115200 baud, 8N1) it will show output like in the below image.

To run the application, follow these steps:

1. Create an SoC - Empty project in Simplicity Studio for the radio board that you want to use.

2. Copy the attached app.c to the root directory of the project.

3. Change DEBUG_LEVEL to 1 in app.h file to enable logging to UART.

4. Compile and run the program. The results will go out through the VCOM and you can visualize them on a terminal application such as TeraTerm or PuTTY.