No worries at all. If you have a question, it is likely someone else will have the same question in the future. You're just helping us improve our docs.
Data Block is a special case where the checksum is performed over all of the preceding bytes in the message. I'm sure you've already worked through the article, but for future viewers.... this article describes the
Data Block and how to perform the checksum on a
Data Block for a moment, consider the protocol in general. For all other commands which include it, the sum byte enables the user to perform a checksum on the two status bytes. This article has a section that describes how to perform the checksum on a normal command response.
Any kind of response that is capable of including a status code should also have a sum byte. This includes commands like
DX. Typically the two status bytes are used to convey status codes (error or failure messages) when necessary. If no specific information about status codes is presented, it is safe to assume that the only status code implemented for that response is the default
00 indicating successful handling of the command.
what the Sum field means on the return of the DX command. Is it really needed.
DX response contains two status bytes. Therefore it also includes a sum byte, so the user can perform a checksum. Currently the
DX response does not produce any special status codes other than
00 indicating the
DX command was successfully processed. While this status bytes might seem unnecessary for now, we leave them so the protocol can evolve without requiring that people re-write their interpreters. In the future, the protocol might expand to include new status codes that convey necessary information related to the processing of a
DX command. If this occurs, we'll already have support for status codes.
Sum field on the LR command is it really needed
The LR command is capable of failing if the parameter (sample rate code) provided in the initial command was invalid. In the event of this failure it will respond with a status code of
11. The manual should cover these kinds of codes. Make sure that you are always using the latest protocol documentation. You can grab the latest manual from the downloads page.
Protocol field and whether there are other values on the return of the IV command
Protocol field should be renamed to
Protocol Version to better match the other fields (
Firmware Version +
Hardware Version). The
Protocol represents the version of the communication protocol the device is using. Just like the
Firmware Version the
Protocol field is formatted in the "Major.Minor" style. It will increase as the protocol evolves. All fields in the
IV response are encoded in ASCII. You can always use the visualizer to send the IV command and see the parsed/interpreted output, to compare to your own parsing.
ID command; are there other values for the Laser State, Mode and Diagnostic fields
Currently, those values are consistent. But it is possible they will support multiple values in the future.
the MS command has a status field, what are the potential failure codes used.
Similar to the
LR command discussed above, there are failure conditions that can be conveyed using the status bytes in the
MS response. The major difference is that an
MS command can fail to process if the device is still adjusting/stabilizing motor speed and has yet to finish it's calibration routine. More info on these codes is available in the sweep manual. Always be sure to use the latest documentation. You can grab the latest manual from the downloads page.
Great to hear you're getting so much out of the unit. Keep at it!