Spinner360: protocol

Spinner360 BLE/USB protocol V1.1. ASCII commands, each terminated with \r (0x0D).

Interfaces

• BLE name mask: DT-SPIN-XXXX, where XXXX is the controller serial (e.g. DT-SPIN-1234);
• BLE service: FFE0;
• BLE characteristic: FFE1;
• USB (serial): 9600 8N1, device name mask CP210 — the Silabs CP210x bridge may need its driver, see Integration basics;
• protocol: ASCII; terminator: \r.

Commands

Command	Purpose	Reply
V?\r	controller version	DT-SPINNER-VX.Y (older controllers may stay silent)
A\r	status	Azxcv (see below)
P\r	start rotation	echo P\r
W\r	stop rotation	echo W\r
S?\r	current speed	Phhhh\r — hexadecimal
Sxxxx\r	set speed	Phhhh\r with the applied speed
C?\r	current acceleration	Chhhh\r — hexadecimal
Cxxxx\r	set acceleration	Chhhh\r with the applied value
B0001\r / B0000\r	BLE safety ON / OFF	echo of the command

xxxx — four ASCII digits. Speed — recommended S0015 (slow) … S0090 (very fast).

Decimal in, hexadecimal out

Set commands take decimal ASCII; the reply carries the value in hexadecimal ASCII. The speed reply is prefixed with P, not S:

TX	RX	Value
S0093\r	P005D\r	0x005D = 93
S0081\r	P0051\r	0x0051 = 81
S0059\r	P003B\r	0x003B = 59

So the contract is Sdddd\r on write and Phhhh\r in the reply. Acceleration behaves the same way, keeping its own C prefix in both directions.

Note

Every set command answers — including P, W and B, which simply echo what you sent. If you follow Sdddd or Cdddd with a confirming S? / C?, the device may send a second, identical frame. Both the echo and the repeated reply are normal; do not treat them as protocol errors.

Confirmed on a physical DT-SPIN-0053 running DT-SPINNER-V1.1 over BLE.

Acceleration

Acceleration control works only on supported controllers. To detect support, send V?: if the controller replies with a version string (DT-SPINNER-VX.Y), it supports the acceleration setting. If there is no reply, do not use C? / Cxxxx — but note that this says nothing about the rest of the protocol, see Older controllers.

The acceleration value is the time in seconds the platform takes to reach its maximum rotation speed. Default: 20 s.

Command	Meaning
C?\r	get acceleration → C + value in hexadecimal
Cxxxx\r	set acceleration, value in seconds

Recommended range:

• C0005\r — very fast acceleration (5 s);
• C0020\r — very slow acceleration (20 s).

Note

Some controllers report the default incorrectly, returning C0000 to the first C?. After you set the acceleration value once following startup, the replies become correct.

Status

A\r returns A followed by status flags: Azxcv over BLE, Azxc over USB (the USB reply omits the BLE-safety flag).

Flag	Meaning	0	1
z	platform rotation	stopped	rotating
x	Safe stop	safe stop activated	normal state
c	platform power	power cord not connected	connection OK
v	BLE safety system (BLE only)	OFF	ON

Rotation flag: verified polarity

Earlier revisions of this page had z the other way round. On hardware the polarity is:

Physical state	RX
platform stopped	A0110\r
platform rotating	A1110\r

Reading z inverted flips the platform state in your UI and in any safety logic built on it, so check this against your own trace before shipping.

Measured on a physical DT-SPIN-0053 / DT-SPINNER-V1.1 over BLE. USB and other firmware revisions were not re-measured, so treat the polarity above as confirmed for BLE V1.1 and verify anything else yourself.

BLE safety

Set the BLE safety system with B0001\r (ON) / B0000\r (OFF).

Caution

While BLE safety is ON, you must send a status (A\r) or get-speed (S?\r) command every 1000–1500 ms. Otherwise the platform stops while spinning.

Reading replies over BLE

A notification boundary is not a frame boundary. One callback may deliver a partial frame, and just as often it delivers more than one — an echo together with a status or query reply, or two identical replies in a row.

Buffer the incoming bytes and:

• accumulate until each 0x0D;
• drain every complete frame from the buffer, not just the first;
• treat a second frame as real data, not as trailing garbage;
• never assume one GATT write produces exactly one notification.

Start-up sequencing

A successful GATT write acknowledgement only means the bytes reached the BLE stack. It does not mean the controller’s parser has processed the command yet, so replies sent immediately after subscribing — or fired off as a tight burst — can be missed entirely.

A sequence that proved reliable on hardware:

1. wait for the notification subscription to be confirmed;
2. send V?, A, S?, C?, A one at a time;
3. leave roughly 400–500 ms between these initial queries;
4. repeat V? or A if the reply you need did not arrive.

Older controllers

A silent V? does not mean the controller is incompatible. A physical DT-SPIN-0052, with its notification subscription confirmed, ignored two V? probes and a C? — yet ran A, S?, P and W normally.

Read it narrowly: no version reply means the firmware revision and acceleration support are unconfirmed, nothing more. Probe the basic commands separately before deciding the device is unsupported.

Typical flow

1. Read the version with V? — this also tells you whether acceleration is supported. Silence here is not fatal; see Older controllers.
2. Read the status with A.
3. Read the speed with S?; set it with Sxxxx if needed.
4. If acceleration is supported, read C? and set it with Cxxxx if needed.
5. Start with P, stop with W.
6. If BLE safety is on, keep sending A or S? every 1000–1500 ms while spinning.
7. Before closing, stop the platform with W.

Over BLE, pace the opening queries as described in Start-up sequencing.