Possible fault with `enable_motor` notification responses

I’m working on decoding the response messages in my reverse engineering of the protocol for C++. The response from the two enable_motor_XXX_notify requests may be faulty because they are missing the sequence number.

Also, shouldn’t the response for an enable message with a data of 1 be returning a 0 indicating the request is ‘okay’?

I am assuming a in the data field enables notifications while a 0 will disable.

drive	enable_motor_stall_notify	
Send: 8D 12 2 16 25 1 86 29 D8 << enable with data as 1
Resp: 8D 21 2 16 25 1 0 A0 D8 

Send: 8D 12 2 16 25 0 88 28 D8 << disable with the data as 0???
Resp: 8D 21 2 16 25 0 0 A1 D8 

drive	enable_motor_fault_notify	
Send: 8D 12 2 16 27 1 87 26 D8 
Resp: 8D 21 2 16 27 1 0 9E D8 

Send: 8D 12 2 16 27 0 89 25 D8 
Resp: 8D 21 2 16 27 0 0 9F D8
2 Likes

Hey @rmerriam!

I can totally see where you are coming from. You are correct that a non-zero value in the data field enables notifications while a 0 will disable. (Also, it is awesome that you are doing this!) It seems like the point where the confusion comes in is that you seem to have switched your sequence number and your data. The packet is ordered as such:
SOP – Flags – Target ID – Source ID – Device ID – Command ID – Sequence – (optional) Error --Data – Checksum – EOP

Your first two Comand/Responses are sending a sequence of 1 and then 0 and data of 86, then 88 (both of which are non-zero, so the response is “0” both times, indicating that there were no errors).

Please let me know if this helps!!

Kelsey

1 Like

Yup, added a quick function to send requests with a single value and got the value in the wrong position.

Rud

2 Likes

Also wanted to add a note that this information and more on the inner workings of the API are on sdk.sphero.com!

2 Likes

Thanks, that’s new. :grinning::grinning:

1 Like