security device

Hardware of Misfit fitness tracker ("Misfit Link"/"Misfit Flash", $15-$30) is converted to a security device by re-flashing with custom firmware. Accelerometer watches for tiny (or not) movements and reports trigger events if predefined conditions are met. Triggers are delivered via BLE (Bluetooth Low Energy) link to a smartphone device (Android). On triggers smartphone plays sounds (alarms) and/or takes pictures even in the background. At the same time, on trigger events, accelerometer data and device orientation can be recorded to internal memory of the device and later be watched on a smartphone.

After re-flashing, firmware updates or new programs can be uploaded over-the-air with dfu bootloader.

Development includes 2 parts: a) firmware for NRF51822 Nordic Semiconductor MCU (program and bootloader) and 2) Ionic framework Android apk. Android OS >4.4 is needed (BLE support). Source is available.

Re-flashing is not reversible, fitness trackers becomes new device permanently.

Mikhail Sharonov, 2016, aka obelix662000

Usage scenarious

Attach to a surface. Knock the surface and picture of the scene will be taken. (hidden camera trigger)

Attach to a door, a pipe, a chair, a computer, a purse, a bag, wine bottle etc. Alarm will sound and/or picture will be taken on every touch/move of the object.

Attach to a package, a cat, a window frame. Current orientation of the object is clearly seen remotely. If recorded, can later be analized.

Attach to a bed frame, a pipe, a furnace, a pijama, a parcell. Record move events for a period of time (upto months). Latter we can easily see how we move in the sleep, what was cat doing during the day, when furnace/air conditioner was turned on and off, when someone was used the bed and how, how parcell was handled.


Security device video (June, 2016). Turn sound on. (https://youtu.be/XsGhyzCalJk)


Teardown. Remove plastic ring by applying force with small screwdriver at 3 joints. Take device apart.

Key parts are: NRF51822AA by Nordic Semiconductor MCU+BLE, LIS2DH 3axis accelerometer by STMicroelectronics, button and 12 red LEDs

2 pictures below show pinout of major components to NRF51822 pins. UART is flexible and is assigned by my firmware, it is used for debug purposes only. Release version of firmware does not use UART


NRF51822 chip is protected by Misfit. So to reflash we need to erase the whole chip by hardware way ("erase all" from Keil will not work). According to NRF51822 reference manual, we need first write "erase enabled" (2) to UICR control register at 0x4001e504 address, and then "erase all" (write 1) to "erase all" register at 4001e50c

Here is how it looks for Segger J-link debugger

Now we are able to flash the chip with custom firmware.

The firmware consists of 3 parts: 1. SoftDevice (some kind of RTOS developed by Nordic Semiconductor) it is fixed and is a part of SDK, it occupies first ~80 kB of flash memory. 2. Our program which does the job is located above SoftDevice 3. DFU Bootloader, it located at the top of memory space.

~100 kB of free space between top of the program and bottom of the bootloader is used as a storage space for data in a record mode. In the download section source code (Keil u-Vision projects, requires Keil+MDK ADM) are available. The "mshdev_firmware" folder must be unpacked to the "SDK_PATH/examples/ble_peripheral" folder of SDK to keep all paths to SDK valid. "mshdev_bootloader" folder is located at the "SDK_PATH/examples/dfu" The SDK must be installed by "zip" installer way (see https://developer.nordicsemi.com/, SDK v9 was used.

The sequence is: a. flash SoftDevice b. flash the program and run c. flash bootloader. Restart the program. No need to write "bootloader address" and "application valid" to UICR, program does it on its first run automatically.

Alternatively you can flash all 3 parts with provided compiled *.hex files ("Intel hex format" ) , or merge them into one and flash at once (google "mergehex" tool from Nordic).

Short description

There are 3 major states of the device:

a). "OFF", MCU and accelerometer are off. The only way to wake up is to push the button.
b). "ACTIVE", consists of two submodes: bb) "ADVERTISING" (1s intervals) this is one-way communication from the device to a smartphone and bbb) "CONNECTED" is two-way communication like wireless UART
c). "DFU", in this mode device is advertising itself as "dfuTag" and firmware can be uploaded with standard Nordic Semiconductor tools.

To switch device to the "OFF" mode, long push the button. The ring of LEDs light indicates this mode
To wake up from the "OFF" to the "ADVERTISING" mode, short push the button. One LED is flashing indicating advertising. It will turn off in about 15 sec.
To switch to the "DFU" mode, long push (>2s) the button when device is in the "OFF" mode. 3 LEDs will be flashing. DFU mode switches itself to the advertising mode in the case of either a)new firmware uploaded or b) 1 min passed. DFU mode cannot be canceled, if you need to switch dfu off just wait for 1 min until it terminates by itself.

VIDEO: "OFF"-"ADVERTISING"-"DFU" modes and over-the-air firmware update example. (https://youtu.be/SlxVI5KYimM)

Firmware logic

1. "Live" mode. The device and a smartphone are connected. The accelerometer is sending 3 axis data (DC mode) continuously via connected link to a smartphone. A smartphone plots the graph, calculates angles and draws 3D model .

2. "Online alarm". The device and a smartphone are connected. Predefined trigger conditions are sent to a device. The accelerometer is in AC mode. When trigger conditions are met, the accelerometer issues hardware interrupt. On interrupt, "alarm" state is sent via BLE link immediately, the MCU starts read the accelerometer and continuously sends data over BLE link. If no new trigger conditions occur within predefined "rest interval", the firmware switches the accelerometer to DC reading, calculates angles and sends it to a smartphone. This is done to get static angles not being affected by acceleration. If new trigger condition occurs within "rest interval" firmware continue reading and sending accelerometer data.

3. "Offline alarm". The device and a smartphone are disconnected. This mode is useful in case of rare events; it saves battery because two-way connection requires more current. In opposite, a smartphone in this mode is more current consuming, because it is in a scan mode. This mode is also convenient to see current state of the device fast. Just run the program and watch for status and 3D model. In this mode device is sending advertising packets every 1s. Each advertising packet includes name of the device, rssi, battery level, current state of the device and last known angles. The accelerometer is set similar to the above "live alarm" mode, but on interrupt it a) inserts "alarm" to the next advertising packet b) starts reading data to FIFO of the accelerometer, on FIFO fill, it reads the data and picks maximal values of the acceleration (total of 3 axis)(the values are used in the "record" mode only), on FIFO read, FIFO fills again etc. Until "rest interval" conditions are met. (FIFO is used to avoid current consuming MCU at HF clock as much as possible) Firmware calculates angles and inserts it into advertising packet.

3. "Record". The device and a smartphone are disconnected. Same as above but on "at rest" condition it in addition saves timestamp, maximal acceleration and static angles into its own flash memory. Total of about 12000 records are fit. The memory is filled in a circular way. After pointer reaches next sector; it erases it and starts fill with data. At the end of memory it starts writing from the beginning. Data are available until next record request, even if the device is switched off. In addition to the above data, the "record" mode inserts current number of records to the advertising packets.

All time another 3s timer is running to update advertising packets with battery level and current state.

RTC is synchronized on every connection to a smartphone and is running with a great accuracy with 32768 quarz which is a part of the misfit hardware.

Current consumption

Here are approximate valus of average current draw:
1. DFU advertising ~1mA
2. Advertising, "stopped" ~50uA
3. Connected, "stopped" ~200uA
4. Connected, "live" 100Hz ~350uA
5. Offline alarm, 100Hz ~70uA, 10Hz ~57uA
6. Device off ~1uA

Please remeber, to measure current, the debugger should be disconnected and the device should be restarted. Otherwise you will see currents in mA range.