I'm cheating a little and basing my answer off of the 120 barcodes the OP provided in chat.
I'm reading the squares as bits from right-to-left, bottom-to-top, with black as 0
and white as 1
. Here is the bit numbering I use:
16 15 14 13 12 11 10 9
8 7 6 5 4 3 2 1
Note that this disagrees with the silkscreened labels on the barcode reader PCB. I don't think that the hardware labels necessarily correspond to the software's processing order though.
The first thing I noticed was that bits 6
-11
of the barcodes are just ((J - 1) >> 1) & 0x3F
(where J
is the number printed on each barcode).
However, J-045
, J-093
, and J-101
do not follow this pattern:
J-045
: should be 0x16
(22), actually 0x3E
(62)
J-093
: should be 0x2E
(46), actually 0x3F
(63)
J-101
: should be 0x32
(50), actually 0x3F
(63)
There are two other patterns that I am fairly sure about though:
- Bits
15
and 16
are always opposite of each other.
- Excluding bit
16
, the number of 1
s is always even.
Therefore I believe that bits 15
and 16
are some form of parity check.
The remaining bits, 1
-14
, seem to have an additional parity check. For all the barcodes we have, I found the following relations:
xor( b2, b3, b4, b5, b6, b7 ) = b11
xor(b1, b3, b4, b5, b8, b9 ) = b12
xor(b1, b2, b4, b5, b6, b8, b10) = b13
xor(b1, b2, b3, b5, b7, b9, b10) = b14
My best guess is that the first fourteen bits contain a ten-bit value and some sort of four-bit checksum. However, an exhaustive search of all 4- and 5-bit CRC generator polynomials has not yielded any results.
1
and white as0
). $\endgroup$