SP105E (MixUp Pixel v1): protocol

Interface

• the BLE name usually contains SP105;
• service: FFE0;
• characteristic: FFE1;
• protocol: binary;
• command size: 5 bytes;
• no terminator.

Commands

Bytes	Purpose
38 RR GG BB 1E	static RGB
38 CA CA CA 10	status query
38 CA CA CA AA	toggle power
38 CA CA CA 03	speed +1
38 CA CA CA 09	speed -1
38 CA CA CA 2A	brightness +1
38 CA CA CA 06	scene 0
38 SS CA CA 2C	scene SS, when SS > 0

Examples:

RGB(255,128,0): 38 FF 80 00 1E
Scene 3:        38 03 CA CA 2C
Status:         38 CA CA CA 10
Power toggle:   38 CA CA CA AA

Status

The reply may contain extra firmware-specific bytes. The first four bytes:

Offset	Field
0	power: 00 off, non-zero on
1	scene ID
2	speed step
3	brightness step
4..N	firmware-specific, keep for diagnostics

Clear stale notifications before a status query. If no notification arrives, a GATT read of the same characteristic is acceptable.

Power toggle

Caution

The 38 CA CA CA AA command does not set a specific state — it toggles it.

The correct algorithm:

actualPower = queryStatus().power
if actualPower != desiredPower:
    send 38 CA CA CA AA
    wait
    verify queryStatus().power == desiredPower

Repeating the toggle without reading the status can put the device back into its original state.

The device reports the new state on its own

After a toggle the controller pushes a status of its own accord, with no status query in front of it. On an SP105E-0288 byte 0 walked 01 → 00 → 01 across two toggles this way. Running the confirming status query afterwards then produces a second, identical status.

So the parser must tolerate:

• a status arriving without a preceding status query;
• two identical statuses in a row;
• updating the known state from either frame — without toggling again.

Treating the unsolicited frame as unexpected, or the duplicate as a failed read, is what leads to a second toggle and the state flipping back.

RGB, scene and speed

RGB:

1. read the status;
2. for a non-zero RGB, power on via the conditional toggle;
3. send 38 RR GG BB 1E;
4. check the status if the firmware reports the applied mode.

Scene:

1. ensure power is on;
2. for scene 0 send 38 CA CA CA 06;
3. for the rest send 38 SS CA CA 2C;
4. re-read the status.

Speed is set relative to the current value:

steps = abs(targetSpeed - currentSpeed)

Send 03 or 09 the required number of times, then check the status. Recommended target speed range: 0..6.

Leave at least 120 ms between steps

The write acknowledgement arrives well before the controller is ready for the next 5-byte command, so a burst silently loses steps. Sent back to back on an SP105E-0288:

Sequence	Expected	Actually landed
speed 6, then 09 ×6	0	2
then 03 ×4	6	4

With a 120 ms gap the same sequences land exactly:

Sequence	RX status byte 2
speed 4, then 09 ×4	0
speed 0, then 03 ×6	6

120 ms is the safe minimum measured on that unit. A shorter gap is not trustworthy just because CoreBluetooth confirmed the write — the acknowledgement says the bytes reached the stack, not that the firmware applied them.