1. Example description

The example can be downloaded from Here.

1.1. Quuppa technology overview

The Quuppa Intelligent Locating System™ is a powerful engine for various location-based services and applications. It provides accurate (down to few centimeters) real-time (location update rate of up to 50 Hz, and latency down to 100 ms) positioning data using Bluetooth® Low Energy (Bluetooth LE) technology, unique Direction Finding signal processing methods and advanced proprietary algorithms.

position

1.2. Capacity of Quuppa solution

Quuppa system can support up to 400-500 Quuppa radio packets per second in a “same location” without major impact to the system performance.

The Quuppa radio packets can be generated by either:

  • tens of tags using fast TX rate
  • thousands of tags using slow TX rate
  • anything in between.

Note, that when BLE mode is used there may be other BLE radio packets in the air that also contribute to that 400-500 packets limit. Also, Data Packets contribute to that packet limit.

For defining the “same location” a concept of detection area can be used. Detection area is the area within which a Locator can detect a tag but cannot necessarily estimate the position of the tag accurately. Typical radius for a detection area is about 30-60 meters but it can vary from 5 to 300 meters depending on the tag’s TX power and used locator type. The smaller the used detection area, the greater the total system capacity.

It is important to understand that the 400-500 packets/second limit only defines how many tags can be active in a given location at a given time. For example, in a large deployment such as a warehouse, there can be tens of thousands of tags being tracked around the facility. The only limitation is that all tags cannot be tracked accurately at a given time if they all happen to be active at the same location at the same time.

1.3. Quuppa Tag Emulation

Quuppa Tag emulation may be implemented with any device that supports Low Energy Advertising State as defined in Bluetooth Core Specification version 4.0 and higher.

For example, a smartphone running Android 5.0 and Bluetooth version 4.1 can perform Quuppa Tag emulation.

A device emulating Quuppa Tag shall send Quuppa Direction Finding and Quuppa Data packets as specified in Quuppa Tag Emulation using Bluetooth Ⓡ Wireless Technology v1.3 document.

A system employing Quuppa Intelligent Locating Technology ™ can accurately track the position of Quuppa Tags as well as receive and expose data transmitted by Quuppa Tags.

Quuppa Direction Finding packets are used for position tracking whereas Quuppa Data packets are used for data transfer.

Note: Quuppa assigned 0x0080 to Dialog as Developer ID which can be used for evaluation and prototyping. For new product design, please request your own Developer ID.

1.4. Quuppa Data Packets

A device emulating Quuppa Tag may use the payload field of the Quuppa Data Packet to transmit data which will be exposed through the Quuppa Web Services API.

Different payload formats may be interleaved in any order. Whenever the content of the payload data is updated or payload is intended to be considered new by the receiver the Payload Counter in the header of the Quuppa data packet shall be updated.

Note, as the data transmission is based on broadcasting, there is no guarantee that a certain single payload will be received by the receiver. Therefore, it is advised to send “critical” data, such as button press, in several subsequent packets with incremented Payload Counter values.

A Quuppa Tag shall send data about itself and its operation using Device Info payload. This can include information such as battery level, temperature, button states, fw and hw versions. The data in Device Info payload will be available through the Quuppa Web Services API.

It is also possible to send Developer specific payload which may be used to carry 13 bytes of developer specific data, such as custom sensor data. The Developer specific payload will appear as is over the Quuppa Web Services API.

1.5. Quuppa Back Channel

Quuppa Tag Back Channel is a mechanism that allows the user of the Quuppa Intelligent Locating Technology ™ to write/read data to/from Quuppa Tags using Quuppa Web API.

The mechanism uses Quuppa Request (REQ) packets to carry data from Quuppa Locators to Quuppa tags and Quuppa Response (RSP) packets to carry response data from Quuppa Tags to Quuppa Locators. The tag shall periodically scan for the back channel REQ packets and then response with an appropriate RSP packet.

The Quuppa REQ and RSP packets are Non-Connectable Bluetooth Low Energy advertising packets with manufacturer specific advertising data Note, the Quuppa RSP packet shall only be used as a response for REQ packet. Simple data transmission from Quuppa Tag to Quuppa Web API via Quuppa Locators shall be done by using Quuppa Data packet.

1.6. Quuppa Tag Emulation Pro Profiles (To Be Implemented)

Quuppa Tag Emulation Pro profiles A profile is a collection of the tag state machine settings that should be included in the Quuppa Tag Emulation Pro library implementation as pre-configured parameters. A profile can be recalled when the Tag is configured or with a specific Back Channel command.
List of available profiles (as of v0.91)

  1. Asset Tag
  2. ID Badge
  3. ID Badge Fast Alarm
  4. Forklift / Vehicle
  5. Forklift / Vehicle Fast RX Rate
  6. Demo Tag
  7. Powersave

profiles

2. HW & SW Configurations

  • Hardware Configurations
    • This example runs on a DA14531 Bluetooth Smart SoC.
    • A DA14531 Pro Development Kit is needed for this example.
    • An MCube MC3635 should be interfaced with the mother board.
  • Software Configurations
    • Download the respective SDK version for the DA14531 family of devices (SDK_6.0.14.1114)
    • Keil software compiler
    • SEGGER’s J-Link tools should be downloaded and installed.

3. How to run the example

3.1. Initial Setup

  • For the initial setup, please refer to this section.
  • For the DA14531 Getting started guide you can refer to this link.

The MC3635 and the Flash should be connected as described in the block diagram:

block_diagram

3.2. Quuppa Profiles and Device Info (DEV) packet in the DEMO SW

Two simplified version of ID BADGE and FORKLIFT/VEHICLE FAST RX RATE profiles has been implemented in the demo sw as pre-compiled options:

Device Type 0x20 => ID BADGE

tag_id2

Device Type 0x80 => FORKLIFT/VEHICLE FAST RX

tag_id3

In order to change the tag ID one DA14531_Quuppa_DF_BckChn_mc3665.h, Line 68 and edit the tag ID

3.3. BLE Scanner Demo Sw testing

  • SW2 button or accelerometer switch from Default to Triggered state
  • Quuppa Device type 0x08
    • Triggered STATE (MOTION)
      • Rate:
        • TX = 9Hz (111ms)
        • RX = 5Hz
        • DEV = 5Hz
      • Headers:
        • TX = 0x6A
        • RX_ON = 0xE9
        • DEV = 0xF0
    • Default STATE (STATIC)
      • Rate:
        • TX = 0.1Hz (10000ms)
        • RX = 0.1Hz
        • DEV = 0.1Hz
      • Headers:
        • TX = 0x68
        • RX_ON = 0xE8
        • DEV = 0xF0

scan_state

3.4. Power profiles

3.4.1. Device Type 0x20 => ID BADGE

pp1

To distinguish in the power profile, RXON=1 adv has TX PW=2.5dBm, normal TX adv has TX PW=0dBm and DEV adv has TX PW=-7dBm Here DA14531 is in extended sleep between adv, you can see that from the avg current of 11.7uA

pp2

Here DA14531 is in extended sleep between adv, you can see that from the avg current of 11.7uA Toggle LED command received and processed

pp3

Here DA14531 is in extended sleep between adv, you can see that from the avg current of 10.9uA Toggle LED command received and processed

pp4

3.4.2. Device Type 0x80 => FORKLIFT/VEHICLE FAST RX

pp5

To distinguish in the power profile, RXON=1 adv has TX PW=2.5dBm, normal TX adv has TX PW=0dBm and DEV adv has TX PW=-7dBm Here DA14531 is in extended sleep between adv, you can see that from the avg current of 13.8uA Toggle LED command received and processed

pp6

pp7

3.5. Quuppa Back Channel testing with Web Console API

back_channel_test

3.6. Compile & Run

  • Νavigate to the Keil_5 folder and open the Keil project.
  • Compile and launch the example. You should download the firmware either into System-RAM or SPI Flash through the SPI Flash programmer of the SmartSnippets Toolbox. When booting from SPI Flash, jumpers should be placed on the standard SPI flash setup.

3.7. Alternative load

Alternatively, the binaries can be flash into memory

4. Known Issue

5. License


Copyright (c) 2020 Dialog Semiconductor. All rights reserved.

This software (“Software”) is owned by Dialog Semiconductor. By using this Software you agree that Dialog Semiconductor retains all intellectual property and proprietary rights in and to this Software and any use, reproduction, disclosure or distribution of the Software without express written permission or a license agreement from Dialog Semiconductor is strictly prohibited. This Software is solely for use on or in conjunction with Dialog Semiconductor products.

EXCEPT AS OTHERWISE PROVIDED IN A LICENSE AGREEMENT BETWEEN THE PARTIES OR AS REQUIRED BY LAW, THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. EXCEPT AS OTHERWISE PROVIDED IN A LICENSE AGREEMENT BETWEEN THE PARTIES OR BY LAW, IN NO EVENT SHALL DIALOG SEMICONDUCTOR BE LIABLE FOR ANY DIRECT, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE SOFTWARE.