Estimote Web Bluetooth

ซาลาเปา หมั่นโถว
30 พ.ค. 2561
ยาว 5 นาที

อัปเดตเมื่อ 1 มิ.ย. 2561

ที่มาและปัญหา

การออกบูธหรือออกนอกสถานที่ในแต่ละครั้งต้องเตรียมเอกสารมากมาย เพื่อประชาสัมพันธ์ สอบถาม พร้อมทั้งต้องข้อมูลเพิ่มเติ่มต่างๆ อีก ซึ่งต้องเสียเวลาเตรียมการ เหนื่อยต่อการขนของ และเปลืองพื้นที่วางของต่างๆ

รูปภาพ 1 แสดงรูปแบบการประชาสัมพันธ์แบบเดิม

หลังจากมี QR Code เข้ามา จึงเริ่มมีการเปลี่ยนให้ผู้เข้าชม สแกน QR Code แทน แต่ก็ยังคงต้องเตรียม QR Code ไว้แจก หรือ ประชาสัมพันธ์ด้านหน้าโต๊ะ

รูปภาพ 2 แสดงการประชาสัมพันธ์แบบ QR Code

ทางทีมจึงลองเสนออีกแนวทางหนึ่ง คือ การใช้ Beacon Estimote Location ส่ง Link ข้อมูลไปยังมือถือผ่านบลูธูท ทำให้ไม่ต้องเตรียมเอกสารใช้เพียง Beacon Estimote Location ติดไว้ที่โต๊ะหรือสถานที่ต่างๆ เท่านั้น

รูปภาพ 3 แสดง Beacon Estimote Location ที่ใช้ในต้นแบบการประชาสัมพันธ์

วัตถุประสงค์

เพื่อเป็นต้นแบบการนำไปประยุกต์ใช้ประชาสัมพันธ์ขณะลงพื้นที่จริง

สมมุติฐาน

ต้นแบบการประชาสัมพันธ์นี้จะช่วยลดต้นทุนในการจัดเตรียมเอกสารต่างๆ

ขอบเขตการศึกษา

1. ด้าน Software

Estimote Cloud
Estimote Application
Deployment Application
PhyWeb Application
link website

FIBO's Facebook (https://www.facebook.com/fibokmutt)
แบบสอบถามหลังการใช้โปรแกรม Interactive Museum ของ FIBO พระจอมเกล้าธนบุรี (https://goo.gl/fsRQGg)
Ban Chang background with Interactive (https://pigtime.wixsite.com/interactive)

2. ด้าน Hardware

Beacon Estimote Location จำนวน 3 ตัว
iPhone จำนวน 1 เครื่อง
Laptop จำนวน 1 เครื่อง

ประโยชน์ที่คาดว่าจะได้รับ

เพิ่มความสะดวกสบายให้กับผู้เข้าชม
ลดภาระการทำงานของผู้ดูแล

ผลงานวิจัยและทฤษฎีที่เกี่ยวข้อง

Chapter 1: Estimote Beacons are…

Tiny, specialized computers

Think about your smartphone, laptop, or desktop: they’re all computers with processors, flash drives, RAM, wireless connectivity… Each beacon also has:

- a low-power ARM® CPU

e.g., 32-bit, 64 MHz CPU in Proximity beacons, or a quad-core, 64-bit, 1.2 GHz CPU in Mirror

- flash memory to store apps and data

e.g., 512 kB in Proximity beacons, 8 GB in Mirror

- RAM memory for the apps to use while running

e.g, 64 kB in Proximity beacons, 1 GB in Mirror

- a Bluetooth antenna and chip to communicate with other devices, and between the beacons themselves

Battery-powered

One big theme which differentiates Estimote Beacons from other computers is energy usage. Unlike:

desktops, which are constantly plugged to power,
or laptops and smartphones, which you recharge daily,

Estimote Beacons are generally optimized to run on battery power for months or years. Mirror video-beacon is the notable exception here, since it can draw the power from the TV/screen it’s connected to.

Running Estimote firmware

These tiny beacon-computers are mostly running apps and services written by Estimote, usually referred to as firmware or “Estimote OS”.

Most of the time that’s all you need, because you won’t be actually writing apps for beacons themselves. You’ll be writing iOS, Android, Linux, or other apps that use beacons.

Depending on the beacon and its specialization, there might be some programmable aspects to it, for example:

beacons with Generic Advertisers can be set to broadcast custom Bluetooth packets
beacons with GPIO can have their Generic Advertisers controlled from an external device in real-time via UART
Mirror beacons run HTML5 and JavaScript apps to render content on the big screen

Interacting with other devices via Bluetooth

Unlike regular computers, which you interact with via keyboard, mouse, or touch-screen, Estimote Beacons are primarily interacted with via Bluetooth Low Energy (Bluetooth “LE”, or “BLE” in short).

Most of the time, you won’t be doing this yourself, directly. An Estimote SDK will do all the Bluetooth-handling for you, leaving you to work with a higher-level API and your business logic.

Estimote SDKs are available for iOS, Android, and Android Things. If you’re using some other platform, you can still use Estimote Beacons, but you’ll need to handle the Bluetooth connectivity yourself, or use a 3rd-party library. Naturally, your platform also needs to support Bluetooth Low Energy.

Chapter 2: How Estimote Beacons use Bluetooth

Since Bluetooth is the primary way to interact with Estimote Beacons, we dedicate an entire chapter to explore this in more detail.

Undirected, non-connectable advertising

Estimote Beacons don’t use Bluetooth in the “classic” sense of pairing or connecting to them, like you pair and connect to a Bluetooth mouse or headset. Instead, they do something described in the Bluetooth spec as “undirected advertising”. This means that the beacon broadcasts its data “into the air”, and that there’s no specific recipient for these broadcasts. Any BLE device (smartphones for example) in range can scan for these advertisements and pick them up. No pairing or establishing a connection is required.

Also, there’s no limit to how many scanners can pick beacon advertisements up.

The BLE hardware in Estimote Beacons is capable of pretty much everything defined by the BLE spec. For example, Location Beacons can scan for Estimote Stickers nearby, for asset tracking purposes. Mirror beacons can scan for any other Estimote Beacons nearby, and adjust the display—for example, if a person with a beacon-ified badge comes in range.

However, BLE scanning consumes much more power than BLE advertising. With advertising, the beacon turns its radio on for just a brief moment (~ 3 ms), broadcasts the data, and goes back to sleep. Scanning requires the radio to be on for longer periods of time (for example, 3 seconds), consuming appropriately more energy. (in this example, 1 scan = 1000x advertisements)

Because of that, battery-powered beacons generally don’t use their scanning powers very often or at all.

A common misconception is that beacons use Bluetooth advertising to broadcast text, images, videos, and others kinds of rich media content. That’s … not the case.

The amount of data that can fit into the broadcast is quite limited: in Bluetooth 4.x, it’s 20* bytes … which would only be enough for a 20-character tweet. In Bluetooth 5, that’s extended up to 243* bytes—better for text, still not enough for richer content. (* numbers after excluding all the headers & commonly used metadata)

Because of that, the most scalable, flexible, and common approach is for beacons to only broadcast some kind of identifier (think, “beacon #1”, “beacon #2”), and to store any extra data in the cloud.

For Estimote Beacons, that extra data can be stored and queried in Estimote Cloud, mostly with the Devices and Attachments APIs.

Some other data commonly broadcast by beacons are:

short URLs
data from the beacon’s sensors (beacon’s motion, ambient temperature, light, etc.)

BLE signal range & distance estimations

BLE signal is a 2.4 GHz radio wave that the beacon transmits with a certain “strength”, often called Broadcasting or Transmit (Tx) Power. The strength of that radio radio wave decreases as it travels further and further away from the beacon.

The BLE receiver “catches” that radio wave with its own antenna, and tries to convert it back into usable, digital data. As the signal gets weaker, the probability of being able to do that successfully decreases. At some point, when the “error rate” or “packet loss” reach certain levels, we’re talking about the “max range” of the signal.

The strength of the received signal is known as RSSI. Since the signal strength decreases with distance, if we know both the RSSI and the “original” strength at a point very close to the beacon, we can approximate how much distance the signal has traveled. Such approximation is more accurate closer to the beacon: ± a few meters, and gets less and less acurrate very quickly as the distance increases.

Both the max range and the distance estimations are further affected by:

the receiver. Each has its own sensitivity, antenna placement and polarization; the material that the receiver’s case is made of can also impact the signal, etc.
the environment. BLE radio waves can bounce off walls and objects, or get some of its strength absorbed on the way to the receiver. Water, metal, and glass in particular are known “troublemakers”—and do note that 80% of the human body consists of water.

We often use numbers to give you an idea whether your should expect something closer to 10 m range or 200 m range, or APIs for you to express whether you want to trigger events closer to 1 m or 10 m. Just be aware that these numbers are only a rough approximation.

Beacons generally don’t use GATT or Bluetooth profiles

If you’re a little bit more familiar with Bluetooth, you may ask what Bluetooth profiles or GATT services Estimote Beacons support, and where you can find the appropriate specifications.

Generally speaking, apps don’t interact with Estimote Beacons via profiles or GATT services. Beacons are primarily designed around advertising, and are mostly meant to be scanned for. Estimote Beacons don’t implement any Bluetooth profiles.

Advertising specifications are available on:

for select Estimote advertising protocols: github.com/estimote/estimote-specs
for iBeacon: developer.apple.com/ibeacon
for Eddystone: github.com/google/eddystone

Estimote Beacons do implement some GATT services, primarily for configuration and fleet management. These are proprietary Estimote services, and we don’t currently share their specs.