Document Ankni Candy Protocol

[blackspherefollower]

BLE Name: DSJM Service UUID: 0000fe00-0000-1000-8000-00805f9b34fb Tx Characteristic UUID: 0000fe01-0000-1000-8000-00805f9b34fb Rx Characteristic UUID: 0000fe02-0000-1000-8000-00805f9b34fb

Initialisation (2 packets must be set):

• 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00 00
• 01 02 fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 00 00

Control: 03 12 XX 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

• XX=00: off
• XX=01-03: speeds
• XX=04-0a: patterns

[VoidField101]

Tested on a Roselex jump egg which seems to use the same protocol.

Initialization:

• Host > Device 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00 00 (as mentioned above)
• Device > Host 01 02 YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY YY 00 00
• Host > Device 01 02 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 00 00
• Device > Host 01 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00(*)

XX is the high byte of the CRC checksum (mentioned below) YY is the low byte of the CRC checksum (mentioned below)

Note (*): If the handshake fails because a wrong checksum, the device will respond with 00 in the 3. byte instead of 01.

The CRC checksum is a CRC16/XModem (Init: 0x0000, Poly: 0x1021) of 0x01 followed by the reversed MAC address of the device.

The MAC address is also available in the bluetooth manufacturer data under different manufacturer keys (depending on the device/version), however, the device should only have a manufacturer data entry. (So the right key should be the only one that is available) In the manufacturer data the MAC address is already reversed.

Another way to get the MAC is trough the ATT endpoint 0x2f50 ( UUID: 00002a50-0000-1000-8000-00805f9b34fb). This characteristic also contains the reversed MAC address similar to the manufacturer data.

Example: MAC: 11:22:33:44:55:66 Manufacturer data: 66 55 44 33 22 11

CRC16 input: 01 66 55 44 33 22 11 CRC16 output: 06F1 therefor for the initialization YY = F1 and XX = 06

Control signals are as described in the original comment.

Note: There seems to be another firmware revision from Roselex which doesn't react to the handshake (can be performed but without reposes from the device). Those devices may also contain an invalid MAC in the manufacturer data and device characteristics (data is not 6 bytes long).