Eddystone BLE beacon using nrf24l01+ and ATTiny
C Makefile
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.gitignore
Makefile
main.c
readme.md

readme.md

Eddystone Beacons Using nRF24l01+ and ATTiny

Create Eddystone Beacons for the Physical Web using nRF24l01+ radio modules and simple ATTiny microcontrollers. Broadcast up 12 byte encoded URLs and/or Eddystone-TLM.

Eddystone Beacon in iOS Notification Center

Build

The Makefile currently includes configuration for ATTiny44 and an USBasp programmer.

Notes

BLE Service Advertisements

BLE service advertisement packets have the following format (here is a great overview):

Preamble 1 byte | Access Address 4 bytes | Payload 2-39 bytes | CRC 3 bytes

where Payload:

Header 2 bytes | MAC Address 6 bytes | Data <= 31 bytes

The non-connectable undirected advertising packets use the following values:

  • Preamble is 0xAA
  • Access address is 0x8E89BED6
  • PDU header:
    • PDU Type ADV_NONCONN_IND or 0b0010
    • Payload length
  • PDU MAC Address
  • PDU Data
    • Advertisement Flags (3 bytes)
    • Advertisement Services Header (4 bytes)
    • Advertisement Frames (the actual Eddystone frame)
  • CRC

Using nRF24l01+ for BLE

Turns out the nRF24l01+ uses the same modulation scheme and frequencies as BLE. The ShockBurst packet format is also very similar to the BLE advertising packet format:

Preamble 1 byte | Address 3-5 byte | Payload 1-32 byte | CRC 1-2 byte

By using a 4 byte address and disabling the automatic CRC we're able to send a BLE advertising packet, however the 32 byte payload is reduced by 18 bytes:

  • 2 byte PDU Header
  • 6 byte MAC Address
  • 3 byte Advertisement Service Flags
  • 3 byte CRC

which leaves us with 18 bytes for the actual Eddystone frame payload.

Eddystone

Eddystone defines the structure of the Eddystone frames. For example, the Eddystone-URL frame contains the following:

Data Length 1 byte | Data Type 1 byte | Eddystone Service UUID 2 bytes | Frame Type 1 byte | TX Power 1 byte | URL Scheme 1 byte | Encoded URL 1-17 bytes

where

  • Data Type "Service Data" is 0x16
  • Eddystone Service UUID is 0xFEAA
  • Frame type for Eddystone-URL is 0x10
  • TX power is the received power at 0 meters in dBm and the value ranges from -100 dBm to +20 dBm to a resolution of 1 dBm
  • URL Scheme is 0x03 for https://, for example
  • Encoded URL

With 6 bytes used for the frame header we're left with only 12 bytes for the actual encoded URL. We're also able to broadcast the Eddystone-TLM frame which requires exactly 14 bytes.

Notes on nRF24l01+ SPI Commands

  • Every new command must be started by a high to low transition on CSN. In parallel to the SPI command word applied on the MOSI pin, the STATUS register is shifted serially out on the MISO pin.

  • We use the regular or non-Enhanced ShockBurst packet format which allows disabling the automatic CRC. Set the register EN_AA = 0x00 and ARC = 0 to disable Enhanced ShockBurst. In addition, the nRF24L01+ air data rate must be set to 1Mbps or 250kbps. Set EN_CRC = 0 to disable the automatic CRC.

Credits

Kaspars Dambis based on the work by Dmitry Grinberg described in Faking Bluetooth LE.