Hi there pvogel,
That is correct. The data stream is sent in binary format for performance reasons. Simple delimiters would not have worked well here. The values of data bytes are variable binary, so a byte could potentially masquerade as a delimiter value. Instead the protocol design relies on the constant assumption that the data-block bytes arrive in order and without interruption until the stream is stopped.
Having said that, the data packets do contain a checksum and a consistent structure. The sensor is also guaranteed to always send complete data packets (ie: all 7 bytes, never more or less). If you are writing your own parser, and want to be robust to data corruption, you could combine knowledge of this behaviour with a validated checksum and a check for valid ranges on each data field to try and locate yourself in the stream. If the following check out, it is rather unlikely due to random chance...
- validating the checksum
- validating angle falls between [0:360]
Technically, because each byte can take any form, it isn't possible to guarantee that you can find the next valid packet after an error. Consider the case of a missing byte, where the first byte of the proceeding data block is incorrectly included in the interpretation of the last byte of the current data block. When trying to find the next valid data block, you could slide a window (7 bytes long) across the incoming stream, checking if the values make sense.... but it wouldn't be a guarantee.
If the data is corrupt there is likely an error and the sensor should be reset anyways.
There is an article in the support section on the general parsing of sensor reading data blocks, here.
For an implementation, see the sweep-sdk.