Just a little followup that might help you get started on that algorithm.
Given the protocol as you've described it, and my warning that the first "0x0D" byte you happen to see may *NOT* actually be the 1st byte of the 10-byte packet:
1. Within any set of 10 consecutive bytes you read, 1 of them *will* be the first byte of the packet. And its value will be 0x0D.
2. If it's the *only* 0x0D value in a set of 10, congrats, you've established your proper framing.
3. If there are other 0x0D values, then you can treat each as a candidate, rotate the string to put it at the beginning of the string, then test whether the 9 following bytes would all have valid values according to the protocol. (Some of the bitflag bytes imply that only 1 bit would be high. Bytes 2,4,5. Byte 6 also only has a small # of valid values.)
4. If only one candidate passes the test, congrats again. Else, keep trying with another set of 10 bytes.
If this doesn't work, then the protocol description is either wrong or incomplete.
Note: I would definitely not rule this out! Its ambiguity already lets us know that it was ill-considered, making it that much more likely that there was also carelessness in the implementation.
Over the years, I've seen a *lot* of anomalies in serial communication that couldn't have been anticipated from the concise protocol description. (Recent example: a device that sporadically reports status update messages in a way that essentially inserts its string into the midst of a normal data string. Must be a higher priority interrupt on the device that pushes its characters to the serial buffer when the normal process was part way through pushing its characters there.)
If the actual communication is not *exactly* as described in the docs, you'll have a lot more work ahead.
-Kevin P