Here's hacking at you, Sony

Bluetooth module

BC4RE A16U
Bluetooth transmitter: this is the BC4RE produced by Cambridge Silicon Radio. While CSR doesn't list it on their website, it's reasonable to think that it's part of the BlueCore4 product line. After a bit of digging, I found the BlueCore4 chip doc, but I couldn’t conclude if this chipdoc pertains to this exact chip or not. 

For the moment, I'm unsure what the PE... pin is doing. Is suspect it might have something to do with a serial port DRTS, or something like that. I'm not familiar enough with the serial protocol to really say. I hope to learn more about the BC4RE with additional poking and prodding, although considering its complexity that will have to wait some time. Hopefully, some enterprising soul will pick up my work and completely specify this module.

Finally, the small chip just to the side of the BC4RE is the 24C23, a 4KByte EEPROM chip from Seiko Instruments. Since it’s inside the BT module’s metal shielding, it would make sense that this chip serve the BT chip, and no the STM32. As the STM32 has no onboard EEPROM, it might be nice if a few bytes of this could be repurposed.

Outgoing data
The outgoing data format is quite simple. Here is an example message:

0x34 0x00 0xA1 0x01 0x00 0x00 0x00 0x05 0x00 0x00 0x7F 0x7F 0x7F 0x7F 0xC6 0x04 0x17 0x90 0x71 0x80 0x71 0x7B 0x18 0x90 0x76 0x80 0x63 0x7B 0x03 0x80 0xFD 0x7F 0x0D 0x80 0x01 0x80 0xFF 0x7F 0xEE 0x7F 0x79 0x22 0x85 0x09 0x71 0x67 0x71 0x00 0x00 0x00 0x00 0x00

The instructions to the bluetooth module are the first two bytes. I don’t know what these do, but I suspect that the first byte indicates how many bytes are in the message (52 in our case), and the
0x00 indicates that the message follows immediately afterwards.
0x34 0x00

Packet body, transmitted via bluetooth. The first byte is always
0xA1, and is not part of the Move’s input report:
0xA1 0x01 0x00 0x00 0x00 0x05 0x00 0x00 0x7F 0x7F 0x7F 0x7F 0xC6 0x04 0x17 0x90 0x71 0x80 0x71 0x7B 0x18 0x90 0x76 0x80 0x63 0x7B 0x03 0x80 0xFD 0x7F 0x0D 0x80 0x01 0x80 0xFF 0x7F 0xEE 0x7F 0x79 0x22 0x85 0x09 0x71 0x67 0x71 0x00 0x00 0x00 0x00 0x00

The moveonpc project has a wiki page describing the
format of the input report message. Again, note that the 0xA1 is not part of the input report, and so can be ignored when decoding the sensor data.

Incoming data
From hcidump, I can see that the outgoing bluetooth packet:
0x02 0x28 0x20 0x0C 0x00 0x08 0x00 0x48 0x00 0x52 0x02 0x00 0xFA 0xAA 0xAF 0x00 0x5A

outputs the following from the bluetooth module:
0x52 0x07 0x02 0x00 0xFA 0xAA 0xAF 0x00 0x5A

where the field occupied by
0xFA is the red LED, by 0xAA the green LED, 0xAF the blue LED, and finally 0x5A the vibrating motor.

I suppose that the
0x07 added by the bluetooth module is the data packet length.

Resources:
Table of notable pins
Outgoing communications at startup
Incoming communications at startup
Outgoing communications at wakeup
Incoming communications at wakeup
Outgoing communications during run
Incoming communications during run

Comments