Device
- Brand / model: Arcwave Thruster
- BLE advertised name:
Thruster
- Product code:
0x00015A
- Firmware tested:
2.2
- Product page: Arcwave
- KooSync device id:
D606 / DD060
- App: KooSync and SVAKOM. SVAKOM displayed an unsupported firmware warning and offered fewer controls. I haven't tested the toys original firmware because it had already autoupdated.
GATT layout
The control service and characteristic identified for the commands below are:
| Service |
Characteristic |
Properties |
0000ffe0-0000-1000-8000-00805f9b34fb |
0000ffe1-0000-1000-8000-00805f9b34fb |
WRITE |
0000ffe0-0000-1000-8000-00805f9b34fb |
0000ffe2-0000-1000-8000-00805f9b34fb |
NOTIFY |
A second service was also discovered but has not been mapped to these motor commands:
| Service |
Characteristic |
Properties |
0000ff12-0000-1000-8000-00805f9b34fb |
0000ff13-0000-1000-8000-00805f9b34fb |
WRITE |
0000ff12-0000-1000-8000-00805f9b34fb |
0000ff14-0000-1000-8000-00805f9b34fb |
NOTIFY |
0000ff12-0000-1000-8000-00805f9b34fb |
0000ff15-0000-1000-8000-00805f9b34fb |
READ, WRITE_WITHOUT_RESPONSE |
Hardware verification
The KooSync app traffic and local BLE testing showed these command formats:
- Stretch:
55 08 00 00 NN 00 00, with NN in the range 0–9.
- Rotation:
55 0D NN 00 00 00 00, with NN in the range 0–9. I have only seen rotation in one direction and have not found a reverse command.
- The app sends a zero level frame when the control is released but the toys motion may continue briefly afterward.
In manual mode, the app also sends 55 04 00 00 00 LL AA. In one sequential test, perceived speed increased as LL increased across a moderate range, but I could not reproduce a reliably distinct response at every level. Maximum manual slider speed also felt similar to maximum stretch/rotation speed, so I cannot yet confirm that 0x04 gives useful finer control.
Passive notification tests did not reveal position data during the idle and movement phases tested. This does ofcourse not rule out undocumented commands or other untested paths.
Proposed change
- Add an Arcwave Thruster device configuration matching the
Thruster BLE name and control service.
- Initially expose stretch as Buttplug
Oscillate using 0x08, and Rotate using 0x0D.
- Keep the
0x04 manual slider command out of the initial public feature mapping until its behavior and relationship to 0x08 are better established.
Would this mapping be appropriate? In particular, is Rotate suitable when I have only found one rotation direction, and should the 0x04 command be investigated as a possible higher resolution command for the same Oscillate actuator?
I have a local prototype and framemapping unit tests, and can test changes on the physical device. The local prototype has not yet completed an end-to-end test through Intiface Central.
Device
Thruster0x00015A2.2D606 / DD060GATT layout
The control service and characteristic identified for the commands below are:
0000ffe0-0000-1000-8000-00805f9b34fb0000ffe1-0000-1000-8000-00805f9b34fb0000ffe0-0000-1000-8000-00805f9b34fb0000ffe2-0000-1000-8000-00805f9b34fbA second service was also discovered but has not been mapped to these motor commands:
0000ff12-0000-1000-8000-00805f9b34fb0000ff13-0000-1000-8000-00805f9b34fb0000ff12-0000-1000-8000-00805f9b34fb0000ff14-0000-1000-8000-00805f9b34fb0000ff12-0000-1000-8000-00805f9b34fb0000ff15-0000-1000-8000-00805f9b34fbHardware verification
The KooSync app traffic and local BLE testing showed these command formats:
55 08 00 00 NN 00 00, withNNin the range 0–9.55 0D NN 00 00 00 00, withNNin the range 0–9. I have only seen rotation in one direction and have not found a reverse command.In manual mode, the app also sends
55 04 00 00 00 LL AA. In one sequential test, perceived speed increased asLLincreased across a moderate range, but I could not reproduce a reliably distinct response at every level. Maximum manual slider speed also felt similar to maximum stretch/rotation speed, so I cannot yet confirm that0x04gives useful finer control.Passive notification tests did not reveal position data during the idle and movement phases tested. This does ofcourse not rule out undocumented commands or other untested paths.
Proposed change
ThrusterBLE name and control service.Oscillateusing0x08, andRotateusing0x0D.0x04manual slider command out of the initial public feature mapping until its behavior and relationship to0x08are better established.Would this mapping be appropriate? In particular, is
Rotatesuitable when I have only found one rotation direction, and should the0x04command be investigated as a possible higher resolution command for the sameOscillateactuator?I have a local prototype and framemapping unit tests, and can test changes on the physical device. The local prototype has not yet completed an end-to-end test through Intiface Central.