Chris,
Patent documents do NOT contain precise, real-world specifications for an invention. Patent documents do not serve to reveal trade secrets. Rather, they exist to present ONLY as much information as would be necessary to legally secure the rights to an invention by a demonstration of what makes the concept unique.
It sounds like you think you are going to find these "12/13 bits" (referenced in the patent) of information in the bar code, or that the decimal numbers to which the symbology decodes can be directly mapped to device operation.
This is incorrect. You risk wasting virtually all of your time if you take this approach.
The T-DISC barcode uses interleaved 2 of 5 symbology to encode a series of subfields into one larger bitfield. The bitfield is exactly 48 bits wide. Within this bitfield are an unknown number of subfields. Each subfield represents a metric with a maximum value of the fieldlength to the second power.
In order to decipher exactly how the numeric values contained within the subfields map to device operation parameters, you will need to first identify the boundaries of the subfields. Note that the decimal representation of the subfields and overall bitfield have nothing at all to do with the device's interpretation of the encoded information. Therefore, the subfields are unlikely to be aligned with any easy-to-realize boundaries, such as fields of size 8 or 16. More likely, you'll see flags and fields of size 2 through 6.
Once you discover the field boundaries, you should then encode sequential values into these fields, and measure the operational deltas of the device.
One caveat, however:
I strongly intuit that a checksum algorithm is in place. It could be as simple as the last 8 bits of 48 bits encoded as simple CRC or LRC value (computed by logically XOR'ing the binary values of decimal numbers together.)
If you are unable to decipher the checksumming mechanism, you will never be able to map subfield values to device operation paramaters because they will be rejected by the device! Therefore, you'll often end up in "manual" mode, like you saw when entering repeated decimal numbers.
[I theorize that the checksum is only 8 bits wide, because you had one success out of nine when using repeated decimals as input.]
Discovering the field boundries might be accomplished by mapping out known-good bitfields along with the corresponding device operation parameters. One could then observe the differences in the fields in relation to device function, and intuit the subfield ranges in use.
It will be near impossible to dechipher the feilds without knowing the checksum algorithm by mapping input to operation. However, as I just mentioned, you do still have a change of mapping known-good input to operation, and from there -- you stand a chance of revealing the checksum mechanism.
Patent documents do NOT contain precise, real-world specifications for an invention. Patent documents do not serve to reveal trade secrets. Rather, they exist to present ONLY as much information as would be necessary to legally secure the rights to an invention by a demonstration of what makes the concept unique.
It sounds like you think you are going to find these "12/13 bits" (referenced in the patent) of information in the bar code, or that the decimal numbers to which the symbology decodes can be directly mapped to device operation.
This is incorrect. You risk wasting virtually all of your time if you take this approach.
The T-DISC barcode uses interleaved 2 of 5 symbology to encode a series of subfields into one larger bitfield. The bitfield is exactly 48 bits wide. Within this bitfield are an unknown number of subfields. Each subfield represents a metric with a maximum value of the fieldlength to the second power.
In order to decipher exactly how the numeric values contained within the subfields map to device operation parameters, you will need to first identify the boundaries of the subfields. Note that the decimal representation of the subfields and overall bitfield have nothing at all to do with the device's interpretation of the encoded information. Therefore, the subfields are unlikely to be aligned with any easy-to-realize boundaries, such as fields of size 8 or 16. More likely, you'll see flags and fields of size 2 through 6.
Once you discover the field boundaries, you should then encode sequential values into these fields, and measure the operational deltas of the device.
One caveat, however:
I strongly intuit that a checksum algorithm is in place. It could be as simple as the last 8 bits of 48 bits encoded as simple CRC or LRC value (computed by logically XOR'ing the binary values of decimal numbers together.)
If you are unable to decipher the checksumming mechanism, you will never be able to map subfield values to device operation paramaters because they will be rejected by the device! Therefore, you'll often end up in "manual" mode, like you saw when entering repeated decimal numbers.
[I theorize that the checksum is only 8 bits wide, because you had one success out of nine when using repeated decimals as input.]
Discovering the field boundries might be accomplished by mapping out known-good bitfields along with the corresponding device operation parameters. One could then observe the differences in the fields in relation to device function, and intuit the subfield ranges in use.
It will be near impossible to dechipher the feilds without knowing the checksum algorithm by mapping input to operation. However, as I just mentioned, you do still have a change of mapping known-good input to operation, and from there -- you stand a chance of revealing the checksum mechanism.