Difference between revisions of "AntiLost"

From RevSpace
Jump to navigation Jump to search
m
(iTag collection)
(15 intermediate revisions by the same user not shown)
Line 7: Line 7:
  
 
== Introduction ==
 
== Introduction ==
[[File:AntiLostServices.png|thumb|right|250px|BLE GATT services advertised]]
+
This page is about so-called "anti-lost" tags (sometimes called iTAG) and understanding how to communicate with them.
  
This page is about so-called "anti-lost" tags and how to communicate with them.
+
They act as a Bluetooth low-energy (BLE) GATT server, implementing a bunch of services.
  
 
This allows them to implement the following functions:
 
This allows them to implement the following functions:
* read out general characteristics of the anti-lost, like the name
+
* read out general characteristics of the anti-lost, like the name (usually just "iTAG")
 
* read out battery level of the anti-lost
 
* read out battery level of the anti-lost
* enable beeping from the client
+
* enable beeping from the client (e.g. smartphone)
 
* notify when the button is pressed on the anti-lost
 
* notify when the button is pressed on the anti-lost
  
Line 20: Line 20:
 
* start beeping when the connection is lost (silenced by a button press)
 
* start beeping when the connection is lost (silenced by a button press)
  
They do this by implementing a BLE GATT server, with a bunch of services.
+
== Technical ==
 +
 
 +
=== iTag collection ===
 +
I have the following:
 +
* "drop" shaped iTag ("iTAG"): has id FF:FF:60:25:2E:FF
 +
* rectangular shaped iTag ("iTAG"): has id FF:FF:C0:1F:9B:B5, appears identical in GATT profile
 +
 
 +
=== GATT services ===
 +
[[File:AntiLostServices.png|thumb|right|250px|BLE GATT services advertised]]
 +
See https://en.wikipedia.org/wiki/Bluetooth_Low_Energy#Software_model
 +
 
 +
The services exposed by the anti-lost are:
 +
* 0x1800: generic access for name and type of device
 +
* 0x180F: battery service, allows you to read the battery level characteristic
 +
* 0x1802: immediate alert, allows you to make the anti-lost beep
 +
* 0x000FFE0-0000-1000-80000-00805F9B34FB: allows you to get notified when the button is pressed
 +
 
 +
=== BLE on ESP32 ===
 +
The ESP32 is capable of doing BLE operations.
 +
 
 +
In particular, this library allows you to control the anti-lost as a GATT device: https://github.com/nkolban/ESP32_BLE_Arduino
 +
Relevant example code is BLE_client.ino
 +
 
 +
The library is now part of the default Arduino package, so there's no longer a need to explicitly include it.
 +
 
 +
=== iTag operation ===
 +
I'm trying to describe how I think it works:
 +
 
 +
The iTag has a couple of states:
 +
* OFF: the LED doesn't blink and it is not BLE discoverable. You can turn it on by keeping the button pressed for several seconds, it beeps for a second, then goes to the UNCONNECTED state. Likewise you can also turn it off again by keeping the button pressed for a several seconds.
 +
* UNCONNECTED: the device is discoverable, blinking briefly every 3 seconds or so. If you connect to it using a BLE client (like a phone), it goes into CONNECTED state
 +
* CONNECTED: the device is connected and monitoring the connection. If the connection is lost (e.g. phone out of range, or it is actively disconnected), it beeps once a second with the LED also blinking (but not as frequent) and eventually goes back to UNCONNECTED mode. You can stop the beeping by either waiting for about 38 seconds or by pressing the button.
 +
 
 +
In the UNCONNECTED state, the device transmits periodic beacon packets. You can use the received signal strength of these to find how to get closer to the device.
 +
 
 +
In the CONNECTED state, it accepts commands from the connected BLE client, e.g. requests to read the battery level, start the alarm immediately.
 +
It will also send a BLE notification if the button is pressed.
 +
 
 +
== Links ==
 +
See also:
 +
* https://thejeshgn.com/2017/06/20/reverse-engineering-itag-bluetooth-low-energy-button/
 +
* https://github.com/sylvek/itracing2/issues/5 tear-down of an anti-lost
 +
 
 +
== BLE serial port ==
 +
Not really related to an AntiLost, but interesting to see what kind of configuration a BLE BT-serial converter has.
 +
 
 +
[[File:BLESerialPortServices.png|thumb|right|250px|BLE GATT services advertised of a BT BLE serial converter]]
 +
 
 +
A BLE USB-BT converter has the configuration as shown on the right:
 +
 
 +
The services exposed by the device are:
 +
* 0x180A: device information
 +
* 0x1800: generic access for name and type of device
 +
* 0x1801: generic attribute, with a 'service changed' characteristic
 +
* 0x000FFE0-0000-1000-80000-00805F9B34FB: ?
 +
 
 +
See also:
 +
* https://thejeshgn.com/2016/10/01/uart-over-bluetooth-low-energy/

Revision as of 17:45, 18 September 2018

Project AntiLost
NewAntiLost.jpg
Status Initializing
Contact bertrik
Last Update 2018-09-18

Introduction

This page is about so-called "anti-lost" tags (sometimes called iTAG) and understanding how to communicate with them.

They act as a Bluetooth low-energy (BLE) GATT server, implementing a bunch of services.

This allows them to implement the following functions:

  • read out general characteristics of the anti-lost, like the name (usually just "iTAG")
  • read out battery level of the anti-lost
  • enable beeping from the client (e.g. smartphone)
  • notify when the button is pressed on the anti-lost

Also:

  • start beeping when the connection is lost (silenced by a button press)

Technical

iTag collection

I have the following:

  • "drop" shaped iTag ("iTAG"): has id FF:FF:60:25:2E:FF
  • rectangular shaped iTag ("iTAG"): has id FF:FF:C0:1F:9B:B5, appears identical in GATT profile

GATT services

BLE GATT services advertised

See https://en.wikipedia.org/wiki/Bluetooth_Low_Energy#Software_model

The services exposed by the anti-lost are:

  • 0x1800: generic access for name and type of device
  • 0x180F: battery service, allows you to read the battery level characteristic
  • 0x1802: immediate alert, allows you to make the anti-lost beep
  • 0x000FFE0-0000-1000-80000-00805F9B34FB: allows you to get notified when the button is pressed

BLE on ESP32

The ESP32 is capable of doing BLE operations.

In particular, this library allows you to control the anti-lost as a GATT device: https://github.com/nkolban/ESP32_BLE_Arduino Relevant example code is BLE_client.ino

The library is now part of the default Arduino package, so there's no longer a need to explicitly include it.

iTag operation

I'm trying to describe how I think it works:

The iTag has a couple of states:

  • OFF: the LED doesn't blink and it is not BLE discoverable. You can turn it on by keeping the button pressed for several seconds, it beeps for a second, then goes to the UNCONNECTED state. Likewise you can also turn it off again by keeping the button pressed for a several seconds.
  • UNCONNECTED: the device is discoverable, blinking briefly every 3 seconds or so. If you connect to it using a BLE client (like a phone), it goes into CONNECTED state
  • CONNECTED: the device is connected and monitoring the connection. If the connection is lost (e.g. phone out of range, or it is actively disconnected), it beeps once a second with the LED also blinking (but not as frequent) and eventually goes back to UNCONNECTED mode. You can stop the beeping by either waiting for about 38 seconds or by pressing the button.

In the UNCONNECTED state, the device transmits periodic beacon packets. You can use the received signal strength of these to find how to get closer to the device.

In the CONNECTED state, it accepts commands from the connected BLE client, e.g. requests to read the battery level, start the alarm immediately. It will also send a BLE notification if the button is pressed.

Links

See also:

BLE serial port

Not really related to an AntiLost, but interesting to see what kind of configuration a BLE BT-serial converter has.

BLE GATT services advertised of a BT BLE serial converter

A BLE USB-BT converter has the configuration as shown on the right:

The services exposed by the device are:

  • 0x180A: device information
  • 0x1800: generic access for name and type of device
  • 0x1801: generic attribute, with a 'service changed' characteristic
  • 0x000FFE0-0000-1000-80000-00805F9B34FB: ?

See also: