As I wrote in a previous post, I have been trying to experimentally determine the control commands you can use with a violet mir:ror.I have determined that the 64-byte communications packets break down something like this:
| Size | 1 byte | 1 byte | 2 bytes | 1 byte | 59 bytes |
|---|---|---|---|---|---|
| Meaning | Interface ID | Method ID | Correlation ID | Data Length | Data, followed by zeroes |
If the device sends a packet in response to a command packet, the Correlation ID field in the response is the same as that which was set in the command. If the response is unsolicited, the Correlation ID field is set zero.
The following commands and responses I believe I understand. These were relatively easy to find – observe what the mir:ror sends spontaneously (0104, 0105, 0201, 0202) then try sending it the obvious missing numbers (0102, 0103, 0104) and see what comes back:
| Meaning | Interface | Method | CID | Data |
|---|---|---|---|---|
| Request mir:ror ID | 01 | 01 | CID | No parameters |
| Report mir:ror ID | 01 | 02 | CID from 0101 message | mir:ror ID |
| Request orientation | 01 | 03 | CID | No parameters |
| Report oriented up | 01 | 04 | CID from 0103 message or zeroes | No data |
| Report oriented down | 01 | 05 | CID from 0103 message or zeroes | No data |
| Report tag on | 02 | 01 | Zeroes | ID from tag |
| Report tag off | 02 | 02 | Zeroes | ID from tag |
Unfortunately that didn’t reveal a way to change the ring colour, provoke sound effects, or suppress the sound effects. However, having inferred the message structure I set about sending the mir:ror every structurally valid message (with no parameters) and recording its responses. My expectation was that the responses to most of the methods in interface 01 which I hadn’t already decoded would be an indication of ‘invalid method’. If later interfaces existed, I expected to receive a mix of ‘invalid method’, ‘invalid parameter’ and responses from them. If later interfaces were not defined, I expected to be able to infer what the ‘invalid interface’ method was. I wrote a program to collect this data, and I am able I think to draw some conclusions from it. Interface FF as the response interface appears to indicate an exception; I have listed the ones I have encountered and I believe I have decoded below. These commands I believe to be safe to use on your mir:ror; I think that interface 03 probably controls the speaker (and possibly the ring light) in some way, as I got some chirps around the time my program was exploring that area. I have not listed commands which received an FF02 response.
| Meaning | Interface | Method | CID | Data |
|---|---|---|---|---|
| Invalid method exception | FF | 02 | From request | No parameters |
| Invalid (insufficient?) parameters exception | FF | 01 | From request | No parameters |
| Exception in called method???? | FF | 33 | From request | No parameters |
| Echo request/response | 01 | FF | From request | Any parameters; copied into response message data |
| Requests 0302 response? | 03 | 01 | Any | Zero parameters got FF01 |
| Meaning unknown | 03 | 03 | Any | Zero parameters got FF01 |
| Requests 0305 response? | 03 | 04 | Any | Zero parameters got FF33 |
| Meaning unknown | 03 | 06 | Any | Zero parameters got FF01 |
| Request 0308 response | 03 | 07 | Any | Zero parameters accepted |
| Response to 0307 | 03 | 08 | From 0307 request | 4 byte length, 046400f8 data |
Now, onto the commands I do not believe are safe to use on your mir:ror. I suspect that interface 04 allows you to read and write the control software (or firmware if you like) in the mir:ror device. Unfortunately, it turns out that pinging all the methods in interface 04 with zero data has done some damage. Anyway, here are the requests and responses I got from exploring interface 04:
| Request | Response | ||||||
|---|---|---|---|---|---|---|---|
| Interface | Method | CID | Interface | Response | CID | Length | Data |
| 04 | 00 | 0400 | ff | 03 | 0400 | 00 | |
| 04 | 01 | 0401 | ff | 03 | 0401 | 00 | |
| 04 | 02 | 0402 | ff | 03 | 0402 | 00 | |
| 04 | 03 | 0403 | ff | 03 | 0403 | 00 | |
| 04 | 04 | 0404 | 04 | 05 | 0404 | 06 | 000f004f0300 |
| 04 | 05 | 0405 | ff | 03 | 0405 | 00 | |
| 04 | 06 | 0406 | 04 | 07 | 0406 | 06 | 000a004b0200 |
| 04 | 07 | 0407 | ff | 03 | 0407 | 00 | |
| 04 | 08 | 0408 | ff | 03 | 0408 | 00 | |
| 04 | 09 | 0409 | 04 | 01 | 0000 | 00 | |
| 04 | 0a | 040a | ff | 01 | 040a | 00 | |
| 04 | 0b | 040b | ff | 01 | 040b | 00 | |
After there, every method invoked on any interface (except for 0101) gets a response of 0401 with no data. One of the commands in the table above (and I point the finger at 0409) switches the mir:ror into a mode where it is a very unhappy thing. Later this weekend I will try issuing more 04 commands with non-zero data to see if I can get it back working, but for now my mir:ror is an ineffective paperweight.
